mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Randy Dunlap" <rdunlap@infradead.org>,
	"Peter Rosin" <peda@axentia.se>,
	"Linus Torvalds" <torvalds@linux-foundation.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] mux: remove the Kconfig question for the subsystem
Date: Wed, 07 Dec 2022 09:41:50 +0100	[thread overview]
Message-ID: <a546f2db-371e-4d2f-a0ee-c71fcae8c548@app.fastmail.com> (raw)
In-Reply-To: <053d7bf2-9bf3-a71c-5713-7cce19413c37@infradead.org>

On Tue, Dec 6, 2022, at 23:20, Randy Dunlap wrote:
> On 7/4/17 01:22, Peter Rosin wrote:
>> The MULTIPLEXER question in the Kconfig might be confusing and is
>> of dubious value. Remove it. This makes consumers responsible for
>> selecting MULTIPLEXER, which they already do.
>> 
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>
>
> How does a user enable any of the 4 drivers in drivers/mux/Kconfig unless
> some other totally unrelated driver has just happened to select MULTIPLEXER
> so that the mux driver menu is visible to them?

We have this mechanism for a few subsystems, LEDS_CLASS/NEW_LEDS and
CRYPTO being more common examples.

The idea clearly is that there is no need for the subsystem if no
drivers call into it. This works if every single driver calling
\(devm_\|\)mux_control_get also results in 'select MULTIPLEXER'
in Kconfig, and none of them ever uses 'depends on MULTIPLEXER'.
I think this is used correctly most of the time in mainline:
git grep '\<\(mux/consumer.h\|MULTIPLEXER\)\>' indicates that
PHY_J721E_WIZ and MTD_PHYSMAP_BT1_ROM may not actually need it,
but that is fairly harmless.

For the other subsystems I mentioned, there are occasionally 
problems with missing 'select' that tend to be a pain to find,
compared to subsystems consistently using 'depends on', which
show up as link failures in randconfig builds.

    Arnd

  reply	other threads:[~2022-12-07  8:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+55aFyJkpSa6rwZ-5xTihfGiNC_T0oL6txrodYBEo2-0O=p7g@mail.gmail.com>
2017-07-04  8:22 ` Peter Rosin
2017-07-04  9:01   ` Greg KH
2017-07-04 21:03   ` Linus Torvalds
2022-12-06 22:20   ` Randy Dunlap
2022-12-07  8:41     ` Arnd Bergmann [this message]
2022-12-07 17:19       ` Randy Dunlap
2022-12-07 18:57         ` Arnd Bergmann
2022-12-07 19:03           ` Randy Dunlap
2022-12-07 19:15             ` Randy Dunlap
2022-12-07 19:23               ` Linus Torvalds
2022-12-07 19:16             ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a546f2db-371e-4d2f-a0ee-c71fcae8c548@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=rdunlap@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®