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 19:57:31 +0100 [thread overview]
Message-ID: <efaf326b-3cd9-40a4-8424-b5f60270beae@app.fastmail.com> (raw)
In-Reply-To: <41a5931e-3543-6a3d-ca85-2dd8ad581f2e@infradead.org>
On Wed, Dec 7, 2022, at 18:19, Randy Dunlap wrote:
> On 12/7/22 00:41, Arnd Bergmann wrote:
>> 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.
>
> I find that various drivers mixing the use of "select" and
> "depends on" is problematic.
Agreed. Even just mixing 'select' with user-visible symbols
is very confusing. The two sensible ways are either using
user-visible options with 'depends on' or hidden options with
'select'.
> However, there was no answer for the original question:
> How does a user enable the 4 Kconfig symbols in drivers/mux/Kconfig
> if some other random driver has not selected MULTIPLEXER?
There is no need to enable any of them in this case, because
the mux drivers are not usable by themselves.
> I.e.:
>
> config MUX_ADG792A
> tristate "Analog Devices ADG792A/ADG792G Multiplexers"
>
> config MUX_ADGS1408
> tristate "Analog Devices ADGS1408/ADGS1409 Multiplexers"
>
> config MUX_GPIO
> tristate "GPIO-controlled Multiplexer"
>
> config MUX_MMIO
> tristate "MMIO/Regmap register bitfield-controlled Multiplexer"
>
> OK, MUX_MMIO is selected from some other drivers, but if that is not done,
> how can the first 3 be enabled by a user?
They cannot, that is the entire point of hiding the subsystem
when it is not used.
Arnd
next prev parent reply other threads:[~2022-12-07 18:58 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
2022-12-07 17:19 ` Randy Dunlap
2022-12-07 18:57 ` Arnd Bergmann [this message]
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=efaf326b-3cd9-40a4-8424-b5f60270beae@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®