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: <1a4288f2-ee5c-494f-9fbe-ea3a90a16014@solid-run.com>
Date: Mon, 9 Feb 2026 10:47:35 +0000
From: Josua Mayer <josua@...id-run.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Marc Kleine-Budde <mkl@...gutronix.de>, Vincent Mailhol
	<mailhol@...nel.org>, Vinod Koul <vkoul@...nel.org>, Neil Armstrong
	<neil.armstrong@...aro.org>, Peter Rosin <peda@...ntia.se>, 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>, 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 v8 3/7] mux: add help text for MULTIPLEXER config option

On 09/02/2026 12:17, Geert Uytterhoeven wrote:
> Hi Josua,
>
> On Mon, 9 Feb 2026 at 11:12, Josua Mayer <josua@...id-run.com> wrote:
>> On 09/02/2026 10:06, Geert Uytterhoeven wrote:
>>> On Sun, 8 Feb 2026 at 16:16, Josua Mayer <josua@...id-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@...id-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@...ux-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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ