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

Powered by blists - more mailing lists