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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41a5931e-3543-6a3d-ca85-2dd8ad581f2e@infradead.org>
Date:   Wed, 7 Dec 2022 09:19:15 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Arnd Bergmann <arnd@...db.de>, Peter Rosin <peda@...ntia.se>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] mux: remove the Kconfig question for the subsystem



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