linux-kernel - Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

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: <704210e0-2e53-09f6-9f8c-3ae0c4b8e0da@axentia.se>
Date: Mon, 9 Feb 2026 12:43:17 +0100
From: Peter Rosin <peda@...ntia.se>
To: Josua Mayer <josua@...id-run.com>, Marc Kleine-Budde
 <mkl@...gutronix.de>, Vincent Mailhol <mailhol@...nel.org>,
 Vinod Koul <vkoul@...nel.org>, Neil Armstrong <neil.armstrong@...aro.org>,
 Aaro Koskinen <aaro.koskinen@....fi>, Andreas Kemnade
 <andreas@...nade.info>, Kevin Hilman <khilman@...libre.com>,
 Roger Quadros <rogerq@...nel.org>, Tony Lindgren <tony@...mide.com>,
 Janusz Krzysztofik <jmkrzyszt@...il.com>, Vignesh R <vigneshr@...com>,
 Andi Shyti <andi.shyti@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Magnus Damm <magnus.damm@...il.com>,
 Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Yazan Shhady <yazan.shhady@...id-run.com>,
 Jon Nettleton <jon@...id-run.com>,
 Mikhail Anikin <mikhail.anikin@...id-run.com>,
 "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
 "linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
 "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
 "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option

Hi!

2026-02-09 at 12:31, Josua Mayer wrote:
> Hi Peter,
> 
> On 09/02/2026 13:10, Peter Rosin wrote:
>> Hi!
>>
>> 2026-02-08 at 16:38, Josua Mayer wrote:
>>> Add prompt and help text for CONFIG_MULTIPLEXER to allow enabling this
>>> option thorugh the kernel configuration without explicit "select" driver
>>> dependencies.
>>>
>>> Select it by default when COMPILE_TEST is set for better coverage.
>>>
>>> Signed-off-by: Josua Mayer <josua@...id-run.com>
>>> ---
>>>   drivers/mux/Kconfig | 9 ++++++++-
>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>> index c68132e38138..4f7c6bb86fc6 100644
>>> --- a/drivers/mux/Kconfig
>>> +++ b/drivers/mux/Kconfig
>>> @@ -4,7 +4,14 @@
>>>   #
>>>   
>>>   config MULTIPLEXER
>>> -	tristate
>>> +	tristate "Generic Multiplexer Support"
>>> +	default m if COMPILE_TEST
>>> +	help
>>> +	  This framework is designed to abstract multiplexer handling for
>>> +	  devices via various GPIO-, MMIO/Regmap or specific multiplexer
>>> +	  controller chips.
>>> +
>>> +	  If unsure, say no.
>>>   
>>>   menu "Multiplexer drivers"
>>>   	depends on MULTIPLEXER
>>>
>> I'm not comfortable with making MULTIPLEXER a visible symbol. It is meant to
>> be selected when needed (and there are a dozen or so instances). The kbuild
>> docs has this on the subject:
>>
>> 	"In general use select only for non-visible symbols (no prompts
>> 	 anywhere) and for symbols with no dependencies."
> The patch description didn't make the decision logic clear,
> and I plan to submit a standalone patch for this after v7.0-rc1.
> 
> Basically existing drivers using mux core used "select" to enable it,
> even though the core can function standalone with device-tree.
> 
> Some of these users (phy-can-transceiver) function perfectly
> perfectly fine without mux, and use it as an optional feature.
> 
> Likely drivers only used "select" to avoid writing helper functions,
> prompt, kconfig description and stubs - which this patch-set added.
> 
> So I will argue that some existing users relying on "select" was wrong,
> and that the mux framework is generally useful on its own.

When I wrote the mux sub-system it was very much intentional and by
design that drivers needing a mux should select MULTIPLEXER, and that
MULTIPLEXER should not be a visible symbol.

You say that it could be useful to have it visible, which is all fine
I suppose. But, you fail to address that quote from the kbuild docs.
Why is it OK to have the preexisting drivers select a visible symbol,
when the kbuild documentation states that it should not be done that
way?

Cheers,
Peter