Re: [PATCH v10 8/9] mux: add prompt and help text to CONFIG_MULTIPLEXER making it visible

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

Am 25.02.26 um 13:24 schrieb Ulf Hansson:
> On Wed, 25 Feb 2026 at 12:35, Josua Mayer <josua@solid-run.com> wrote:
>> The multiplexer subsystem was initially designed only for use by drivers
>> that require muxes, and did in particular not consider optional muxes or
>> to compile as a module.
>>
>> Over time several drivers have added a "select MULTIPLEXER" dependency,
>> some of which require a mux and some consider it optional. v7.0-rc1
>> shows 15 such occurrences in Kconfig files, in a variety of subsystems.
>>
>> Further some drivers such as gpio-mux are useful on their own (e.g.
>> through device-tree idle-state property), but can not currently be
>> selected through menuconfig unless another driver selecting MULTIPLEXER
>> symbol was enabled first.
>>
>> The natural step forward to allow enabling mux core and drivers would be
>> adding prompt and help text to the existing symbol.
>>
>> This violates the general kbuild advice to avoid selecting visible
>> symbols.
>>
>> Alternatively addition of a wrapper symbol MUX_CORE was considered,
>> which in turn would "select MULTIPLEXER". This however creates new
>> issues and confusion as MULTIPLEXER and MUX_CORE need to share the same
>> state, i.e. MUX_CORE in menuconfig must not be set to m while
>> MULTIPLEXER was selected builtin. Further confusion occurs with Kconfig
>> "depends on" relationships that could reference either MUX_CORE or
>> MULTIPLEXER.
>>
>> It is common across the tree for subsystem symbols to be both visible
>> and selected, e.g. I2C & SPI. In the same spirit multiplexer needs to
>> ignore this particular kbuild rule.
>>
>> Add prompt and help text to the existing MULTIPLEXER symbol, making it
>> visible in (menu)config without breaking existing "select MULTIPLEXER"
>> occurrences in the tree.
>>
>> 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
> Allowing the core being a module makes things/code a bit unnecessarily
> complicated, I think.
>
> Similar to other subsystems (like regulators/clk/etc), the core is a
> bool and the menu below it for its provider drivers depends on it to
> be configurable, allowing them to be tristate.
This seems reasonable.

Before revising this patch I'd appreciate input from Peter Rosin,
who had strong opinions on v9.

>> +       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.
>>
> continuing from the above comment, this would instead be:
>
> if MULTIPLEXER
>
> menu "Multiplexer drivers"
>
>
>>  menu "Multiplexer drivers"
>>         depends on MULTIPLEXER
>>
>> --
>> 2.43.0
>>
> Kind regards
> Uffe