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

[Josua Mayer <josua@solid-run.com>]

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.
> 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.
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"?