Linux-PHY Archive on lore.kernel.org

* Re: [PATCH v9 3/7] mux: add help text for MULTIPLEXER config option
From: Josua Mayer @ 2026-02-09 20:02 UTC (permalink / raw)
  To: Peter Rosin, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
	Neil Armstrong, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
	Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
	Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang
  Cc: Yazan Shhady, Jon Nettleton, Mikhail Anikin,
	linux-can@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-mmc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <f4d8547d-3de3-0de5-da61-3de57d9af895@axentia.se>

On 2/9/26 15:08, Peter Rosin wrote:
> 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@solid-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,

Considering the large number of existing users, I tend to agree here:

drivers/gpu/drm/bridge/Kconfig: select MULTIPLEXER
drivers/i2c/busses/Kconfig:     select MULTIPLEXER
drivers/i2c/muxes/Kconfig:      select MULTIPLEXER
drivers/iio/multiplexer/Kconfig:        select MULTIPLEXER
drivers/media/platform/Kconfig: select MULTIPLEXER
drivers/mtd/hyperbus/Kconfig:   select MULTIPLEXER
drivers/mtd/maps/Kconfig:       select MULTIPLEXER
drivers/net/mdio/Kconfig:       select MULTIPLEXER
drivers/phy/ti/Kconfig: select MULTIPLEXER
drivers/phy/ti/Kconfig: select MULTIPLEXER
drivers/phy/Kconfig:    select MULTIPLEXER
drivers/spi/Kconfig:    select MULTIPLEXER
drivers/spi/Kconfig:    select MULTIPLEXER
sound/soc/codecs/Kconfig:       select MULTIPLEXER

> making it perfectly fine to
> leave all the existing select MULTIPLEXER users as-is?
However I think each of them should be reviewed as to whether
their use of mux is mandatory or optional (phy-can-transceiver).

A "depends" relationship might be clearer long-term,
and perhaps all users should be converted eventually.

It is rather frustrating that the consideration to make mux framework
an optional dependency to drivers, rather than mandatory,
came after so many uses were already established.

Any suggestion how to name the new config symbol that can have
a visible prompt?

- regards
Josua Mayer
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply