From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE5D9EE14C3 for ; Sun, 10 Sep 2023 02:24:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345383AbjIJCUP (ORCPT ); Sat, 9 Sep 2023 22:20:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233350AbjIJCUO (ORCPT ); Sat, 9 Sep 2023 22:20:14 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9177F1B5 for ; Sat, 9 Sep 2023 19:20:09 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 90AAE5C00F4; Sat, 9 Sep 2023 22:20:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 09 Sep 2023 22:20:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sakamocchi.jp; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1694312408; x= 1694398808; bh=xrUrQhu0bKn4V0R/7QZgiQCA2ML5d9qouROX3hkBCJo=; b=t ZmU/8ZK10ef7RQsh5BbFhHq3gBSIRMNFClmXdXSHMHbTHt2EmETGJbH5xJ9y36FX Nll8R4rt+MLvFZBETxIRdsyuaAY4EQgGrtqtpkSY5C20UFX7JI+3HyJPVH75Xjtr H5532wpifrx2zUcXJWI7V0s4ljQi9j+ew0+lwv0bi8eMQZ1A4PELioo7SNHrZ7ks wKoES4EE4yvHjC/3wtGbOHEfWNzrFtqW2sq97vou5tkYsqKlSJuPl8GZFjObcvvz zM/xesdiFZfrSsyQ9kimDtzis4+BBkJz/ZmFmY+mUI96r7MYpd4GsETD2R/WTB3W wF1bBGBHkNLw2Umgr8Ybw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1694312408; x=1694398808; bh=xrUrQhu0bKn4V 0R/7QZgiQCA2ML5d9qouROX3hkBCJo=; b=Q1aR05P2kxJu/pkxX6HD+PD9WiWdT rEV2MmSvQsDphpr3/6cWGKSfvivTcTcMMKS1blX7sFkk6sCS+muH8yRk6IFAOm2a vZff7lxnuXUJQE4LVScEavHWF8ZWa3MnxIrf8wc430PBnNAIqYXs/0ypULff/a4w 9qoeVYbf+EcuqbzDRdW6mIRnxJX5NWKoye2BNjZmsZdGC/Q8k5SB6RMjQK4w1z3w 7P5t3mQDhf0jYlFE++FxWM64QLYUWdz0ITi2GUG4NOyJY8eM6hxyHRJJGlqeHer3 CG1AhVlutdZTKRjhk+2vnK355BXzp0RBbCrU8knnKtC0B2J4Wrd8lvz0A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeitddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfgrkhgr shhhihcuufgrkhgrmhhothhouceoohdqthgrkhgrshhhihesshgrkhgrmhhotggthhhird hjpheqnecuggftrfgrthhtvghrnhepveeilefhudekffehkeffudduvedvfeduleelfeeg ieeljeehjeeuvdeghfetvedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehoqdhtrghkrghs hhhisehsrghkrghmohgttghhihdrjhhp X-ME-Proxy: Feedback-ID: ie8e14432:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 9 Sep 2023 22:20:07 -0400 (EDT) Date: Sun, 10 Sep 2023 11:20:03 +0900 From: Takashi Sakamoto To: Linus Torvalds Cc: Jan Engelhardt , linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] firewire updates for 6.6 Message-ID: <20230910022003.GA67045@workstation.local> Mail-Followup-To: Takashi Sakamoto , Linus Torvalds , Jan Engelhardt , linux-kernel@vger.kernel.org References: <20230909033457.GA59845@workstation.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Sat, Sep 09, 2023 at 11:28:14AM -0700, Linus Torvalds wrote: > On Fri, 8 Sept 2023 at 20:35, Takashi Sakamoto wrote: > > > > In the second half of 6.6 merge window, Jan Engelhardt sent the change. It > > allows any front ends of Kconfig to deactivate FireWire subsystem at a > > clip. > > I pulled this, but after looking at it, I unpulled it again. > > We *already* had this. Saying 'N' to the existing FIREWIRE option > would disable all of the firewire stack, since the rest then just has > > depends on FIREWIRE > > on it. > > The only exception is the firewire sniffing side (FIREWIRE_NOSY), > which technically doesn't need the firewire stack to exist or to work. > > The other thing this adds is a > > depends on PCI || COMPILE_TEST > > for the firewire subsystem, which makes sense since the controllers > all depend on PCI even if the code itself doesn't care (thus the > COMPILE_TEST) part. > > Anyway, both of those changes are fine by me - but adding a new config > option, and bothering users that want firewire support with TWO > questions about "do you want firewire" is just annoying and frankly > just stupid. > > I have said this five hundred times before, but I guess I'll say it > five hundred times again (the Proclaimers even wrote a song about it): > we don't make the config options worse, and we don't ask people stupid > things. > > So no. > > The actual core limitations I'd be ok with: just add that > > depends on PCI || COMPILE_TEST > > to the *existing* FIREWIRE config, and add a > > depends on FIREWIRE > > to FIREWIRE_NOSY for all I care. That potentiall y*removes* annoying > questions, not adds them. > > And if people want to change the existing menu to a menuconfig > (*keeping* the existing FIREWIRE config option, not adding a new one), > that's fine too. > > But this "let's add yet another mindless option to ask users" is _not_ > acceptable. > > Linus Indeed, the additional option would be annoying to users. I figure out that It is reasonable to avoid the change and stop 'history repeats'. Ideally, core functions of FireWire subsystem in firewire-core can be built without dependency on PCI subsystem, but actually it depends, as we can see in comment of the menu option. The nosy driver is for Texus Instruments PCILynx device and should depends on PCI subsystem. We can see apparent difference between these two cases of dependency on PCI subsystem. I doubt the loss of direct dependency on PCI subsystem in nosy, at present. Anyway, the requester has already sent another patch[1]. I postpone it and continue discussion with him for next merge window. [1] https://lore.kernel.org/lkml/20230909221248.2598-1-jengelh@inai.de/ Thanks Takashi Sakamoto