[PATCH v2] mux: remove the Kconfig question for the subsystem

[PATCH v2] mux: remove the Kconfig question for the subsystem

[Peter Rosin]

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>
---
 drivers/mux/Kconfig | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

On 2017-07-04 08:00, Linus Torvalds wrote:
> On Jul 3, 2017 22:53, "Peter Rosin" <peda@axentia.se <mailto:peda@axentia.se>> wrote:
>> But ok, is something like this what you wanted?
> 
> I *think* this week just result in an empty menu if there are
> no drivers selecting it.
> 
> Shouldn't the 'if' be outside the menu? But I didn't test
> anything, since I'm not in front of my computer any more..

Right, the previous patch also had the problem that it removed
the MULTIPLEXER option completely and was therefore total crap.

I have tested this patch more thoroughly and it should be a
definite improvement. Sorry for the noise...

Cheers,
peda

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 7c754a0..19e4e90 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -2,20 +2,11 @@
 # Multiplexer devices
 #
 
-menuconfig MULTIPLEXER
-	tristate "Multiplexer subsystem"
-	help
-	  Multiplexer controller subsystem. Multiplexers are used in a
-	  variety of settings, and this subsystem abstracts their use
-	  so that the rest of the kernel sees a common interface. When
-	  multiple parallel multiplexers are controlled by one single
-	  multiplexer controller, this subsystem also coordinates the
-	  multiplexer accesses.
-
-	  To compile the subsystem as a module, choose M here: the module will
-	  be called mux-core.
+config MULTIPLEXER
+	tristate
 
-if MULTIPLEXER
+menu "Multiplexer drivers"
+	depends on MULTIPLEXER
 
 config MUX_ADG792A
 	tristate "Analog Devices ADG792A/ADG792G Multiplexers"
@@ -56,4 +47,4 @@ config MUX_MMIO
 	  To compile the driver as a module, choose M here: the module will
 	  be called mux-mmio.
 
-endif
+endmenu
-- 
2.1.4

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Greg KH]

On Tue, Jul 04, 2017 at 10:22:44AM +0200, 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>
> ---
>  drivers/mux/Kconfig | 19 +++++--------------
>  1 file changed, 5 insertions(+), 14 deletions(-)

Looks good to me, I'll queue it up for after 4.13-rc1, unless Linus
wants to take this now directly.

greg k-h

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Linus Torvalds]

On Tue, Jul 4, 2017 at 1:22 AM, Peter Rosin <peda@axentia.se> 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.

Yes, this looks good to me.

Still no actual *testing*, but the change looks entirely sensible and
does what I think the code should do.

Thanks,

               Linus

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Randy Dunlap]

Hi,

Sorry to drag up such an old thread, but: (please see below)


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>
> ---
>  drivers/mux/Kconfig | 19 +++++--------------
>  1 file changed, 5 insertions(+), 14 deletions(-)
> 
> On 2017-07-04 08:00, Linus Torvalds wrote:
>> On Jul 3, 2017 22:53, "Peter Rosin" <peda@axentia.se <mailto:peda@axentia.se>> wrote:
>>> But ok, is something like this what you wanted?
>>
>> I *think* this week just result in an empty menu if there are
>> no drivers selecting it.
>>
>> Shouldn't the 'if' be outside the menu? But I didn't test
>> anything, since I'm not in front of my computer any more..
> 
> Right, the previous patch also had the problem that it removed
> the MULTIPLEXER option completely and was therefore total crap.
> 
> I have tested this patch more thoroughly and it should be a
> definite improvement. Sorry for the noise...
> 
> Cheers,
> peda
> 
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> index 7c754a0..19e4e90 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -2,20 +2,11 @@
>  # Multiplexer devices
>  #
>  
> -menuconfig MULTIPLEXER
> -	tristate "Multiplexer subsystem"
> -	help
> -	  Multiplexer controller subsystem. Multiplexers are used in a
> -	  variety of settings, and this subsystem abstracts their use
> -	  so that the rest of the kernel sees a common interface. When
> -	  multiple parallel multiplexers are controlled by one single
> -	  multiplexer controller, this subsystem also coordinates the
> -	  multiplexer accesses.
> -
> -	  To compile the subsystem as a module, choose M here: the module will
> -	  be called mux-core.
> +config MULTIPLEXER
> +	tristate
>  
> -if MULTIPLEXER
> +menu "Multiplexer drivers"
> +	depends on MULTIPLEXER
>  
>  config MUX_ADG792A
>  	tristate "Analog Devices ADG792A/ADG792G Multiplexers"
> @@ -56,4 +47,4 @@ config MUX_MMIO
>  	  To compile the driver as a module, choose M here: the module will
>  	  be called mux-mmio.
>  
> -endif
> +endmenu


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?

I was just about to send a patch (basically a revert but I didn't know it
until I looked up the git blame history/hash for 4c19c0ec73241:
  mux: remove the Kconfig question for the subsystem

Thanks.


-- 
~Randy

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Arnd Bergmann]

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

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Randy Dunlap]

On 12/7/22 00:41, Arnd Bergmann wrote:
> 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.

Yes, sure.

> 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.

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?

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?

thanks.

-- 
~Randy

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Arnd Bergmann]

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

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Randy Dunlap]

On 12/7/22 10:57, Arnd Bergmann wrote:
> 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.

OK, if you say so. That doesn't make any sense to me, but whatever,
I'll drop it.

Thanks.

-- 
~Randy

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Randy Dunlap]

On 12/7/22 11:03, Randy Dunlap wrote:
> 
> 
> On 12/7/22 10:57, Arnd Bergmann wrote:
>> 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.
> 
> OK, if you say so. That doesn't make any sense to me, but whatever,
> I'll drop it.

Oops. One more thing:
Your statement leads me to conclude that since nothing selects those 3 mux drivers,
they don't need to be in the kernel tree at all.

Done. (I hope.)

-- 
~Randy

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Linus Torvalds]

On Wed, Dec 7, 2022 at 11:15 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Oops. One more thing:
> Your statement leads me to conclude that since nothing selects those 3 mux drivers,
> they don't need to be in the kernel tree at all.
>
> Done. (I hope.)

What?

Randy, do you even *read* what you write? Or, perhaps even more
importantly, what *other* people write?

It's not that those individual MUX drivers need to be selected to be
asked about.

But they won't be asked about UNLESS SOMEBODY WANTS A MULTIPLEXER.

What is your problem here?

Basically, you will only see those questions if you have a driver (or
subsystem) that does

        select MULTIPLEXER

to let the Kconfig know that "yes, I'm actually interested".

If there is no use for those mux drivers, the "depends on MULTIPLEXER"
means that those STUPID AND POINTLESS questions won't be asked.

What's so hard to understand about this?

               Linus

Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

[Linus Torvalds]

On Wed, Dec 7, 2022 at 11:03 AM Randy Dunlap <rdunlap@infradead.org> wrote:
> On 12/7/22 10:57, Arnd Bergmann wrote:
> >
> > They cannot, that is the entire point of hiding the subsystem
> > when it is not used.
>
> OK, if you say so. That doesn't make any sense to me, but whatever,
> I'll drop it.

The config phase of the kernel is one of the more annoying parts (the
rest is pretty much "make" and "make install"), and we should strive
to make it as simple and obvious as possible.

One big thing for that is to *not* ask questions that make no sense.

We already hide a number of them, either by disallowing them ("this
driver only makes sense on this architecture" kinds of things) or by
always forcing them on  ("if you're building for a PC, you're getting
the keyboard driver whether you want it or not").

And in many cases, we don't have questions at all, but enable code
based on automatic selection (ie "you wanted ACPI support, so we'll
enable CRC32 support because the ACPI code needs it").

I don't understand *why* you'd ever want more nonsensical questions?

Why would you ever want to ask a human "do you want this code that is
never used"?

That, to me, is actively a horrible thing to do. It only makes the
Kconfig worse. Don't do it.

         Linus