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: <f4d8547d-3de3-0de5-da61-3de57d9af895@axentia.se>
Date: Mon, 9 Feb 2026 14:08:58 +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 13:07, Josua Mayer wrote:
> On 09/02/2026 13:43, Peter Rosin wrote:
>> 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.
> Need is a strong word here, and doesn't address the optional case.

"Need" was the correct verb up until you needed the subsystem to be
optional. If you need the mux subsystem to be optional, you need to
do it in a way that does not introduce headaches.

>> 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?
> 
> It might have been okay for a transitional period.

What would be ok for a transitional period? Introducing potentially
problematic kbuild dependencies? I'd rather not...

> My original patch-set had already exploded due to the request to
> introduce general purpose devm_*_optional_* helpers,
> and the fact phy-can-transceiver already had a local version of the same.
> 
> So perhaps if I will submit a patch-set changing to visible symbol,
> I shall also change the few drivers that are now using "select"?

I think it would be simpler to introduce some new visible symbol
that triggers select MULTIPLEXER, making it perfectly fine to
leave all the existing select MULTIPLEXER users as-is?

Cheers,
Peter