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

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

On 09/02/2026 12:17, Geert Uytterhoeven wrote:
> Hi Josua,
>
> On Mon, 9 Feb 2026 at 11:12, Josua Mayer <josua@solid-run.com> wrote:
>> On 09/02/2026 10:06, Geert Uytterhoeven wrote:
>>> On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@solid-run.com> wrote:
>>>> On 03/02/2026 15:01, 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 | 8 +++++++-
>>>>>     1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>> index c68132e38138..e31c46820bdf 100644
>>>>> --- a/drivers/mux/Kconfig
>>>>> +++ b/drivers/mux/Kconfig
>>>>> @@ -4,7 +4,13 @@
>>>>>     #
>>>>>
>>>>>     config MULTIPLEXER
>>>>> -     tristate
>>>>> +     tristate "Generic Multiplexer Support" if COMPILE_TEST
>>>> This didn't do what I thought it would.
>>>> It was my intention to allow enabling this through menuconfig / .config.
>>>>
>>>> With the syntax above menuconfig shows:
>>>>
>>>> │ Symbol: MULTIPLEXER [=n]
>>>> │ Type  : tristate
>>>> │ Defined at drivers/mux/Kconfig:6
>>>> │   Prompt: Generic Multiplexer Support
>>>> │   Visible if: COMPILE_TEST [=n]
>>>>
>>>> This means it cannot be selected.
>>> Looks like you haven't enabled COMPILE_TEST first?
>> Correct.
>> But CONFIG_MULTIPLEXER should be visible always,
>> not just when COMPILE_TEST is set.
> Why should it always be visible? All users select it?

This is not relevant for v7 now and can be handled later.

It was discussed previously that drivers supporting optional muxes
do not need to "select" MULTIPLEXER through Kconfig,
E.g. the renesas sdhi driver.

However other drivers are already selecting it even though the mux
is optional, see e.g. phy-can-transceiver.

In order to support muxes in renesas sdhi driver e.g., users must choose to
enable both the renesas driver, and multiplexer subsystem via the 
configuration.

The mux core standalone also supports a limited use-case without other 
driver
interactions, setting idle-state e.g.:

mux-controller {
     compatible = "gpio-mux";
     #mux-control-cells = <0>;
     mux-gpios = <&tca6416_u20 0 GPIO_ACTIVE_HIGH>;
     idle-state = <0>;
};

So it can be generally useful for a user to enable CONFIG_MULTIPLEXER.

>
>>>> Instead I (think I) should use
>>>> default m if COMPILE_TEST
>>> No, merely enabling COMPILE_TEST must not enable additional
>>> functionality.
>>>
>>>> Since my patch-set broke x86_64 allmodconfig and failed merge into
>>>> linux-next,
>>>> this presents an opportunity to change the above as well with v9.
>>> Ulf has already applied this series to mmc/next.
>> What would be the process to fix the build error for x86_64 allmodconfig
>> now?
> Incremental patches, cfr. Ulf's response to [PATCH v9 0/7].
>
> Gr{oetje,eeting}s,
>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds