[PATCH RESEND] mux: gpio-mux: add support for 4:1 2-channels mux

[PATCH RESEND] mux: gpio-mux: add support for 4:1 2-channels mux

[Andrea Tomassetti]

Some gpio multiplexers, like TMUX1209, offer differential 4:1
or dual 4:1 single-ended channels. Similarly to what already done by
the adg792a driver, the gpio-mux driver has to take into account
the #mux-control-cells property and allocate as many controllers
as advised by it.

So, in the DTS you can now define:

	tmux1209: mux-controller {
		compatible = "gpio-mux";
		#mux-control-cells = <1>;

		mux-gpios = <&gpio_expander 01 GPIO_ACTIVE_HIGH>,
					<&gpio_expander 02 GPIO_ACTIVE_HIGH>;
	};

	adcmux30: adcmux30 {
		compatible = "io-channel-mux";
		io-channels = <&adc1 4>;
		io-channel-names = "parent";
		#io-channel-cells = <1>;
		mux-controls = <&tmux1209 0>;

		channels = "S1A", "S2A", "S3A", "S4A";
	};

	adcmux31: adcmux31 {
		compatible = "io-channel-mux";
		io-channels = <&adc1 5>;
		io-channel-names = "parent";
		#io-channel-cells = <1>;
		mux-controls = <&tmux1209 1>;

		channels = "S1B", "S2B", "S3B", "S4B";
	};

Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
---
 drivers/mux/gpio.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c
index 4cc3202c58f3..01ce3f878b9e 100644
--- a/drivers/mux/gpio.c
+++ b/drivers/mux/gpio.c
@@ -52,12 +52,23 @@ static int mux_gpio_probe(struct platform_device *pdev)
 	int pins;
 	s32 idle_state;
 	int ret;
+	u32 cells;
+	int i;

 	pins = gpiod_count(dev, "mux");
 	if (pins < 0)
 		return pins;

-	mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio));
+	ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
+	if (ret < 0)
+		cells = 0;
+
+	if (cells >= 2) {
+		dev_err(dev, "invalid control-cells %u\n", cells);
+		return -EINVAL;
+	}
+
+	mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));
 	if (IS_ERR(mux_chip))
 		return PTR_ERR(mux_chip);

@@ -69,7 +80,9 @@ static int mux_gpio_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(mux_gpio->gpios),
 				     "failed to get gpios\n");
 	WARN_ON(pins != mux_gpio->gpios->ndescs);
-	mux_chip->mux->states = BIT(pins);
+
+	for (i = 0; i < mux_chip->controllers; ++i)
+		mux_chip->mux[i].states = BIT(pins);

 	ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
 	if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) {

base-commit: 80234b5ab240f52fa45d201e899e207b9265ef91
--
2.51.2

Re: [PATCH RESEND] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

Hi Andrea,

thanks for your patch!

On Thu, Apr 30, 2026 at 4:13 PM Andrea Tomassetti
<andrea.tomassetti@sipearl.com> wrote:

> Some gpio multiplexers, like TMUX1209, offer differential 4:1
> or dual 4:1 single-ended channels. Similarly to what already done by
> the adg792a driver, the gpio-mux driver has to take into account
> the #mux-control-cells property and allocate as many controllers
> as advised by it.
>
> So, in the DTS you can now define:
>
>         tmux1209: mux-controller {
>                 compatible = "gpio-mux";
>                 #mux-control-cells = <1>;
>
>                 mux-gpios = <&gpio_expander 01 GPIO_ACTIVE_HIGH>,
>                                         <&gpio_expander 02 GPIO_ACTIVE_HIGH>;
>         };
>
>         adcmux30: adcmux30 {
>                 compatible = "io-channel-mux";
>                 io-channels = <&adc1 4>;
>                 io-channel-names = "parent";
>                 #io-channel-cells = <1>;
>                 mux-controls = <&tmux1209 0>;
>
>                 channels = "S1A", "S2A", "S3A", "S4A";
>         };
>
>         adcmux31: adcmux31 {
>                 compatible = "io-channel-mux";
>                 io-channels = <&adc1 5>;
>                 io-channel-names = "parent";
>                 #io-channel-cells = <1>;
>                 mux-controls = <&tmux1209 1>;
>
>                 channels = "S1B", "S2B", "S3B", "S4B";
>         };
>
> Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>

The mux controller binding looks like this:

properties:
  '#mux-control-cells':
    enum: [ 0, 1 ]

So you do not patch the bindings, you actually implement this
for the case when #mux-control-cells is 1.

Please detail this in the commit.

> -       mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio));
> +       ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
> +       if (ret < 0)
> +               cells = 0;
> +
> +       if (cells >= 2) {
> +               dev_err(dev, "invalid control-cells %u\n", cells);
> +               return -EINVAL;
> +       }

Maybe put in a comment that the bindings only allow 0 or 1 cell.

> +
> +       mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));

Otherwise looks correct to me.

> -       mux_chip->mux->states = BIT(pins);
> +
> +       for (i = 0; i < mux_chip->controllers; ++i)
> +               mux_chip->mux[i].states = BIT(pins);

Is the mux core handling any other specifics? (I guess so...)

With the above added comments, details:
Reviewed-by: Linus Walleij <linusw@kernel.org>

Thanks!
Linus Walleij

Re: [PATCH RESEND] mux: gpio-mux: add support for 4:1 2-channels mux

[Andrea Tomassetti]

Hi Linus,
thank you very much for taking the time to review and reply.

On 5/5/26 10:23, Linus Walleij wrote:
> **Warning** This email is from an external address. Please take care to proceed.
> 
> 
> Hi Andrea,
> 
> thanks for your patch!
> 
> On Thu, Apr 30, 2026 at 4:13 PM Andrea Tomassetti
> <andrea.tomassetti@sipearl.com> wrote:
> 
>> Some gpio multiplexers, like TMUX1209, offer differential 4:1
>> or dual 4:1 single-ended channels. Similarly to what already done by
>> the adg792a driver, the gpio-mux driver has to take into account
>> the #mux-control-cells property and allocate as many controllers
>> as advised by it.
>>
>> So, in the DTS you can now define:
>>
>>         tmux1209: mux-controller {
>>                 compatible = "gpio-mux";
>>                 #mux-control-cells = <1>;
>>
>>                 mux-gpios = <&gpio_expander 01 GPIO_ACTIVE_HIGH>,
>>                                         <&gpio_expander 02 GPIO_ACTIVE_HIGH>;
>>         };
>>
>>         adcmux30: adcmux30 {
>>                 compatible = "io-channel-mux";
>>                 io-channels = <&adc1 4>;
>>                 io-channel-names = "parent";
>>                 #io-channel-cells = <1>;
>>                 mux-controls = <&tmux1209 0>;
>>
>>                 channels = "S1A", "S2A", "S3A", "S4A";
>>         };
>>
>>         adcmux31: adcmux31 {
>>                 compatible = "io-channel-mux";
>>                 io-channels = <&adc1 5>;
>>                 io-channel-names = "parent";
>>                 #io-channel-cells = <1>;
>>                 mux-controls = <&tmux1209 1>;
>>
>>                 channels = "S1B", "S2B", "S3B", "S4B";
>>         };
>>
>> Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
> 
> The mux controller binding looks like this:
> 
> properties:
>   '#mux-control-cells':
>     enum: [ 0, 1 ]
> 
> So you do not patch the bindings, you actually implement this
> for the case when #mux-control-cells is 1.
> 
> Please detail this in the commit.
> 
Exactly, I'm not patching the bindings, there's no need. I tried to detail this
in my commit message:

    [...] the gpio-mux driver has to take into account
    the #mux-control-cells property and allocate as many controllers
    as advised by it.

but it looks like is not as clear as I thought. Maybe I can add the fact that
"patching the binding is not needed because the binding already supports
#mux-control-cells 0 and 1". What do you think?


>> -       mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio));
>> +       ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
>> +       if (ret < 0)
>> +               cells = 0;
>> +
>> +       if (cells >= 2) {
>> +               dev_err(dev, "invalid control-cells %u\n", cells);
>> +               return -EINVAL;
>> +       }
> 
> Maybe put in a comment that the bindings only allow 0 or 1 cell.
> 
Noted it!

>> +
>> +       mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));
> 
> Otherwise looks correct to me.
> 
>> -       mux_chip->mux->states = BIT(pins);
>> +
>> +       for (i = 0; i < mux_chip->controllers; ++i)
>> +               mux_chip->mux[i].states = BIT(pins);
> 
> Is the mux core handling any other specifics? (I guess so...)
> 
I guess so too but if there's something specific I'm missing, please let me know.

Moreover, I just realized that I missed two lines that should be probably
adjusted as well:

@@ -78,7 +91,8 @@ static int mux_gpio_probe(struct platform_device *pdev)
                        return -EINVAL;
                }

-               mux_chip->mux->idle_state = idle_state;
+               for (i = 0; i < mux_chip->controllers; ++i)
+                       mux_chip->mux[i].idle_state = idle_state;
        }

        ret = devm_regulator_get_enable_optional(dev, "mux");
@@ -89,8 +103,8 @@ static int mux_gpio_probe(struct platform_device *pdev)
        if (ret < 0)
                return ret;

-       dev_info(dev, "%u-way mux-controller registered\n",
-                mux_chip->mux->states);
+       dev_info(dev, "%u-way mux-controller registered, %u controllers\n",
+                mux_chip->mux->states, mux_chip->controllers);

        return 0;
 }

Should I integrate these modifications on the next version of the patch?

Thank you very much,
Andrea

> With the above added comments, details:
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> 
> Thanks!
> Linus Walleij
> 

Re: [PATCH RESEND] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

On Tue, May 5, 2026 at 5:21 PM Andrea Tomassetti
<andrea.tomassetti@sipearl.com> wrote:

> Should I integrate these modifications on the next version of the patch?

Yeah looks good, just respin it.

Yours,
Linus Walleij

[PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Andrea Tomassetti]

Some gpio multiplexers, like TMUX1209, offer differential 4:1
or dual 4:1 single-ended channels. No binding changes are needed
because the DT binding already supports #mux-control-cells
with values 0 and 1. So, similarly to what was already done by the
adg792a driver, the gpio-mux driver has to take into account
the #mux-control-cells property and allocate as many controllers as
advised by it.

As an example, in the DTS you can now define:

	tmux1209: mux-controller {
		compatible = "gpio-mux";
		#mux-control-cells = <1>;

		mux-gpios = <&gpio_expander 01 GPIO_ACTIVE_HIGH>,
			    <&gpio_expander 02 GPIO_ACTIVE_HIGH>;
	};

And use it like this:

	adcmux30: adcmux30 {
		compatible = "io-channel-mux";
		io-channels = <&adc1 4>;
		io-channel-names = "parent";
		#io-channel-cells = <1>;
		mux-controls = <&tmux1209 0>;

		channels = "S1A", "S2A", "S3A", "S4A";
	};

	adcmux31: adcmux31 {
		compatible = "io-channel-mux";
		io-channels = <&adc1 5>;
		io-channel-names = "parent";
		#io-channel-cells = <1>;
		mux-controls = <&tmux1209 1>;

		channels = "S1B", "S2B", "S3B", "S4B";
	};

Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
v2: Address feedback from Linus Walleij
  - reword commit message by making clear that patching the binding
    is not needed
  - make clear from error message that binding only allows 0 or 1
  - fix two other locations where `mux` was accessed

 drivers/mux/gpio.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c
index 4cc3202c58f3..ab3ed5247d2c 100644
--- a/drivers/mux/gpio.c
+++ b/drivers/mux/gpio.c
@@ -52,12 +52,23 @@ static int mux_gpio_probe(struct platform_device *pdev)
 	int pins;
 	s32 idle_state;
 	int ret;
+	u32 cells;
+	int i;

 	pins = gpiod_count(dev, "mux");
 	if (pins < 0)
 		return pins;

-	mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio));
+	ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
+	if (ret < 0)
+		cells = 0;
+
+	if (cells >= 2) {
+		dev_err(dev, "invalid control-cells %u, must be 0 or 1\n", cells);
+		return -EINVAL;
+	}
+
+	mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));
 	if (IS_ERR(mux_chip))
 		return PTR_ERR(mux_chip);

@@ -69,7 +80,9 @@ static int mux_gpio_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(mux_gpio->gpios),
 				     "failed to get gpios\n");
 	WARN_ON(pins != mux_gpio->gpios->ndescs);
-	mux_chip->mux->states = BIT(pins);
+
+	for (i = 0; i < mux_chip->controllers; ++i)
+		mux_chip->mux[i].states = BIT(pins);

 	ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
 	if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) {
@@ -78,7 +91,8 @@ static int mux_gpio_probe(struct platform_device *pdev)
 			return -EINVAL;
 		}

-		mux_chip->mux->idle_state = idle_state;
+		for (i = 0; i < mux_chip->controllers; ++i)
+			mux_chip->mux[i].idle_state = idle_state;
 	}

 	ret = devm_regulator_get_enable_optional(dev, "mux");
@@ -89,8 +103,8 @@ static int mux_gpio_probe(struct platform_device *pdev)
 	if (ret < 0)
 		return ret;

-	dev_info(dev, "%u-way mux-controller registered\n",
-		 mux_chip->mux->states);
+	dev_info(dev, "%u-way mux-controller registered, %u controllers\n",
+		 mux_chip->mux->states, mux_chip->controllers);

 	return 0;
 }

base-commit: 74fe02ce122a6103f207d29fafc8b3a53de6abaf
--
2.51.2

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Andrea Tomassetti]

Hi Linus,
do you know if Peter Rosin is still actively maintaining this driver? I see that
there are other developers that sent patches months ago and that are still
waiting for a reply.

Do you have any insight? How's the process now?

Thank you very much,
Andrea

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Krzysztof Kozlowski]

On 03/06/2026 13:43, Andrea Tomassetti wrote:
> Hi Linus,
> do you know if Peter Rosin is still actively maintaining this driver? I see that
> there are other developers that sent patches months ago and that are still
> waiting for a reply.
> 
> Do you have any insight? How's the process now?

I think Peter looks at mux subsystem only occasionally so that's I
marked it as Odd Fixes in commit ff91020412.

Best regards,
Krzysztof

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

On Wed, Jun 3, 2026 at 1:43 PM Andrea Tomassetti
<andrea.tomassetti@sipearl.com> wrote:

> Hi Linus,
> do you know if Peter Rosin is still actively maintaining this driver? I see that
> there are other developers that sent patches months ago and that are still
> waiting for a reply.
>
> Do you have any insight? How's the process now?

If Peter is unable to attend to it send a pull request to the SoC
tree (if this concerns an SoC) and explain the situation and the
SoC maintainers can pull it in while we are looking for a new
mux (co)maintainer. Unless you're interested in the job?

Yours,
Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Tommaso Merciai]

Hi Linus, Andrea, Krzysztof,

On Tue, Jun 09, 2026 at 12:54:10AM +0200, Linus Walleij wrote:
> On Wed, Jun 3, 2026 at 1:43 PM Andrea Tomassetti
> <andrea.tomassetti@sipearl.com> wrote:
> 
> > Hi Linus,
> > do you know if Peter Rosin is still actively maintaining this driver? I see that
> > there are other developers that sent patches months ago and that are still
> > waiting for a reply.
> >
> > Do you have any insight? How's the process now?
> 
> If Peter is unable to attend to it send a pull request to the SoC
> tree (if this concerns an SoC) and explain the situation and the
> SoC maintainers can pull it in while we are looking for a new
> mux (co)maintainer. Unless you're interested in the job?

I have the same issue with [1].

Starting from [2] (Date: Wed,  5 Nov 2025)
I have never received any feedback.

How should I proceed?
Maybe I'm missing something?

[1] https://lore.kernel.org/all/cover.1777294876.git.tommaso.merciai.xr@bp.renesas.com/
[2] https://lore.kernel.org/all/b0aeaea6408319ba7ae525d19bb6ff6dd566e2bb.1762354366.git.tommaso.merciai.xr@bp.renesas.com/

Thanks to all!

Kind Regards,
Tommaso

> 
> Yours,
> Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:

> > If Peter is unable to attend to it send a pull request to the SoC
> > tree (if this concerns an SoC) and explain the situation and the
> > SoC maintainers can pull it in while we are looking for a new
> > mux (co)maintainer. Unless you're interested in the job?
>
> I have the same issue with [1].
>
> Starting from [2] (Date: Wed,  5 Nov 2025)
> I have never received any feedback.
>
> How should I proceed?

If Greg can ACK patch 1/2 we can probably merge this set through the
SoC tree as well. If the PWM subsystem is practically orphaned we
need to step in and merge stuff.

Yours,
Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Tommaso Merciai]

Hi Linus,
Thanks for your comment,

On Thu, Jun 18, 2026 at 03:04:20PM +0200, Linus Walleij wrote:
> On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
> <tommaso.merciai.xr@bp.renesas.com> wrote:
> 
> > > If Peter is unable to attend to it send a pull request to the SoC
> > > tree (if this concerns an SoC) and explain the situation and the
> > > SoC maintainers can pull it in while we are looking for a new
> > > mux (co)maintainer. Unless you're interested in the job?
> >
> > I have the same issue with [1].
> >
> > Starting from [2] (Date: Wed,  5 Nov 2025)
> > I have never received any feedback.
> >
> > How should I proceed?
> 
> If Greg can ACK patch 1/2 we can probably merge this set through the
> SoC tree as well. If the PWM subsystem is practically orphaned we
> need to step in and merge stuff.

+Cc GregKH

What is your suggestion here?
Thank all.

Kind Regards,
Tommaso

> 
> Yours,
> Linus Walleij
> 

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Krzysztof Kozlowski]

On 18/06/2026 15:27, Tommaso Merciai wrote:
> Hi Linus,
> Thanks for your comment,
> 
> On Thu, Jun 18, 2026 at 03:04:20PM +0200, Linus Walleij wrote:
>> On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
>> <tommaso.merciai.xr@bp.renesas.com> wrote:
>>
>>>> If Peter is unable to attend to it send a pull request to the SoC
>>>> tree (if this concerns an SoC) and explain the situation and the
>>>> SoC maintainers can pull it in while we are looking for a new
>>>> mux (co)maintainer. Unless you're interested in the job?
>>>
>>> I have the same issue with [1].
>>>
>>> Starting from [2] (Date: Wed,  5 Nov 2025)
>>> I have never received any feedback.
>>>
>>> How should I proceed?
>>
>> If Greg can ACK patch 1/2 we can probably merge this set through the
>> SoC tree as well. If the PWM subsystem is practically orphaned we
>> need to step in and merge stuff.
> 
> +Cc GregKH
> 
> What is your suggestion here?
> Thank all.

In the past I took a few MUX patches and then send them further to Greg.
I did it once and then kind of did not continue. I could do that again,
but it won't really solve the problem that MUX needs person actively
looking at this. Me taking patches is rather band-aid and I do not have
particular business interests around MUX. But maybe you or Renesas have
and could help here?

Best regards,
Krzysztof

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Srinivas Kandagatla]

"mux: gpio-mux: add support for multiple mux controls" would be more
reflective of what is done in  the patch.

On 5/6/26 1:33 PM, Andrea Tomassetti wrote:
> Some gpio multiplexers, like TMUX1209, offer differential 4:1
> or dual 4:1 single-ended channels. No binding changes are needed
> because the DT binding already supports #mux-control-cells
> with values 0 and 1. So, similarly to what was already done by the
> adg792a driver, the gpio-mux driver has to take into account
I guess adg792a does not have same issue(described below) as gpio mux

> the #mux-control-cells property and allocate as many controllers as
> advised by it.>

 drivers/mux/gpio.c | 24 +++++++++++++++++++-----
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mux/gpio.c b/drivers/mux/gpio.c
> index 4cc3202c58f3..ab3ed5247d2c 100644
> --- a/drivers/mux/gpio.c
> +++ b/drivers/mux/gpio.c
> @@ -52,12 +52,23 @@ static int mux_gpio_probe(struct platform_device *pdev)
>  	int pins;
>  	s32 idle_state;
>  	int ret;
> +	u32 cells;
> +	int i;
> 
>  	pins = gpiod_count(dev, "mux");
>  	if (pins < 0)
>  		return pins;
> 
> -	mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio));
> +	ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
> +	if (ret < 0)
> +		cells = 0;
> +
> +	if (cells >= 2) {

This code snippet is duplicated once again, may its time for this to go
to as helper function, either in core or somewhere common.

> +		dev_err(dev, "invalid control-cells %u, must be 0 or 1\n", cells);

 mux-control-cells would give useful message to user rather than just
control-cells.

> +		return -EINVAL;
> +	}
> +
> +	mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));

We are now allocating n mux_controls, however mux_gpio_set is not
protected against multiple controllers accessing the same gpio resource.


>  	if (IS_ERR(mux_chip))
>  		return PTR_ERR(mux_chip);
> 
> @@ -69,7 +80,9 @@ static int mux_gpio_probe(struct platform_device *pdev)
>  		return dev_err_probe(dev, PTR_ERR(mux_gpio->gpios),
>  				     "failed to get gpios\n");
>  	WARN_ON(pins != mux_gpio->gpios->ndescs);
> -	mux_chip->mux->states = BIT(pins);
> +
> +	for (i = 0; i < mux_chip->controllers; ++i)
> +		mux_chip->mux[i].states = BIT(pins);
> 
>  	ret = device_property_read_u32(dev, "idle-state", (u32 *)&idle_state);
>  	if (ret >= 0 && idle_state != MUX_IDLE_AS_IS) {
> @@ -78,7 +91,8 @@ static int mux_gpio_probe(struct platform_device *pdev)
>  			return -EINVAL;
>  		}
> 
> -		mux_chip->mux->idle_state = idle_state;
> +		for (i = 0; i < mux_chip->controllers; ++i)
> +			mux_chip->mux[i].idle_state = idle_state;
>  	}
>.

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Tommaso Merciai]

Hi Krzysztof,

Sorry for the late reply.

On Fri, Jun 19, 2026 at 05:51:13AM +0200, Krzysztof Kozlowski wrote:
> On 18/06/2026 15:27, Tommaso Merciai wrote:
> > Hi Linus,
> > Thanks for your comment,
> > 
> > On Thu, Jun 18, 2026 at 03:04:20PM +0200, Linus Walleij wrote:
> >> On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
> >> <tommaso.merciai.xr@bp.renesas.com> wrote:
> >>
> >>>> If Peter is unable to attend to it send a pull request to the SoC
> >>>> tree (if this concerns an SoC) and explain the situation and the
> >>>> SoC maintainers can pull it in while we are looking for a new
> >>>> mux (co)maintainer. Unless you're interested in the job?
> >>>
> >>> I have the same issue with [1].
> >>>
> >>> Starting from [2] (Date: Wed,  5 Nov 2025)
> >>> I have never received any feedback.
> >>>
> >>> How should I proceed?
> >>
> >> If Greg can ACK patch 1/2 we can probably merge this set through the
> >> SoC tree as well. If the PWM subsystem is practically orphaned we
> >> need to step in and merge stuff.
> > 
> > +Cc GregKH
> > 
> > What is your suggestion here?
> > Thank all.
> 
> In the past I took a few MUX patches and then send them further to Greg.
> I did it once and then kind of did not continue. I could do that again,
> but it won't really solve the problem that MUX needs person actively
> looking at this. Me taking patches is rather band-aid and I do not have
> particular business interests around MUX. But maybe you or Renesas have
> and could help here?

Thank you for the context. I understand your position, being a
band-aidmaintainer without direct business interest is not a sustainable
solutionfor the MUX subsystem long term.

That said, this patch has now been blocked for more than 6 months,
and we are looking for a way to get it upstream. Since you mentioned
you have picked MUX patches before and routed them through the SoC tree
to Greg, would you bewilling to do the same here?

It would unblock us while the question of active MUX maintainership is
sorted out separately.

+Cc: Geert, Philipp, Ulf

Geert, what is your take on this? Would you prefer to route it through
your tree instead, or do you think Krzysztof picking it via the SoC tree
makes more sense?

I believe it is better handled by the experts in that area, P Zabel, Ulf,
Geert, and others.

Thanks to both of you for considering this.

Kind Regards,
Tommaso

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Geert Uytterhoeven]

Hi Tommaso,

On Tue, 23 Jun 2026 at 18:44, Tommaso Merciai
<tommaso.merciai.xr@bp.renesas.com> wrote:
> On Fri, Jun 19, 2026 at 05:51:13AM +0200, Krzysztof Kozlowski wrote:
> > On 18/06/2026 15:27, Tommaso Merciai wrote:
> > > On Thu, Jun 18, 2026 at 03:04:20PM +0200, Linus Walleij wrote:
> > >> On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
> > >> <tommaso.merciai.xr@bp.renesas.com> wrote:
> > >>
> > >>>> If Peter is unable to attend to it send a pull request to the SoC
> > >>>> tree (if this concerns an SoC) and explain the situation and the
> > >>>> SoC maintainers can pull it in while we are looking for a new
> > >>>> mux (co)maintainer. Unless you're interested in the job?
> > >>>
> > >>> I have the same issue with [1].
> > >>>
> > >>> Starting from [2] (Date: Wed,  5 Nov 2025)
> > >>> I have never received any feedback.
> > >>>
> > >>> How should I proceed?
> > >>
> > >> If Greg can ACK patch 1/2 we can probably merge this set through the
> > >> SoC tree as well. If the PWM subsystem is practically orphaned we
> > >> need to step in and merge stuff.
> > >
> > > +Cc GregKH
> > >
> > > What is your suggestion here?
> > > Thank all.
> >
> > In the past I took a few MUX patches and then send them further to Greg.
> > I did it once and then kind of did not continue. I could do that again,
> > but it won't really solve the problem that MUX needs person actively
> > looking at this. Me taking patches is rather band-aid and I do not have
> > particular business interests around MUX. But maybe you or Renesas have
> > and could help here?
>
> Thank you for the context. I understand your position, being a
> band-aidmaintainer without direct business interest is not a sustainable
> solutionfor the MUX subsystem long term.
>
> That said, this patch has now been blocked for more than 6 months,
> and we are looking for a way to get it upstream. Since you mentioned
> you have picked MUX patches before and routed them through the SoC tree
> to Greg, would you bewilling to do the same here?
>
> It would unblock us while the question of active MUX maintainership is
> sorted out separately.
>
> +Cc: Geert, Philipp, Ulf
>
> Geert, what is your take on this? Would you prefer to route it through
> your tree instead, or do you think Krzysztof picking it via the SoC tree
> makes more sense?
>
> I believe it is better handled by the experts in that area, P Zabel, Ulf,
> Geert, and others.

As Philipp already reviewed the patch[A], and took its user/consumer[B],
I think he's best suited to pick it up.

If that fails, I can take it through renesas-devel.
Thanks!

[A] "[PATCH v11 1/1] mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL
      mux"
    https://lore.kernel.org/all/582eb5408684786577e5fa85b80f585c8739be15.1777294876.git.tommaso.merciai.xr@bp.renesas.com/
[B] Commit f62fcdf8ab826ffc ("reset: rzv2h-usb2phy: Add support for
    VBUS mux controller registration") in v7.1.

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

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Krzysztof Kozlowski]

On 23/06/2026 18:44, Tommaso Merciai wrote:
> Hi Krzysztof,
> 
> Sorry for the late reply.
> 
> On Fri, Jun 19, 2026 at 05:51:13AM +0200, Krzysztof Kozlowski wrote:
>> On 18/06/2026 15:27, Tommaso Merciai wrote:
>>> Hi Linus,
>>> Thanks for your comment,
>>>
>>> On Thu, Jun 18, 2026 at 03:04:20PM +0200, Linus Walleij wrote:
>>>> On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
>>>> <tommaso.merciai.xr@bp.renesas.com> wrote:
>>>>
>>>>>> If Peter is unable to attend to it send a pull request to the SoC
>>>>>> tree (if this concerns an SoC) and explain the situation and the
>>>>>> SoC maintainers can pull it in while we are looking for a new
>>>>>> mux (co)maintainer. Unless you're interested in the job?
>>>>>
>>>>> I have the same issue with [1].
>>>>>
>>>>> Starting from [2] (Date: Wed,  5 Nov 2025)
>>>>> I have never received any feedback.
>>>>>
>>>>> How should I proceed?
>>>>
>>>> If Greg can ACK patch 1/2 we can probably merge this set through the
>>>> SoC tree as well. If the PWM subsystem is practically orphaned we
>>>> need to step in and merge stuff.
>>>
>>> +Cc GregKH
>>>
>>> What is your suggestion here?
>>> Thank all.
>>
>> In the past I took a few MUX patches and then send them further to Greg.
>> I did it once and then kind of did not continue. I could do that again,
>> but it won't really solve the problem that MUX needs person actively
>> looking at this. Me taking patches is rather band-aid and I do not have
>> particular business interests around MUX. But maybe you or Renesas have
>> and could help here?
> 
> Thank you for the context. I understand your position, being a
> band-aidmaintainer without direct business interest is not a sustainable
> solutionfor the MUX subsystem long term.

No, you did not get the point.

Why shall we take this unmaintained code? I know you have reasons (you
want), but what are the reasons for us?

> 
> That said, this patch has now been blocked for more than 6 months,

And? This does not mean I should take it.

> and we are looking for a way to get it upstream. Since you mentioned
> you have picked MUX patches before and routed them through the SoC tree
> to Greg, would you bewilling to do the same here?
> 
> It would unblock us while the question of active MUX maintainership is
> sorted out separately.

No. Every other case was following the same process "let's just unblock
my work" and never fixed the actual problem of someone devoting time to
take care of this stuff.

If there is no one looking at this, we should consider removing it.

> 
> +Cc: Geert, Philipp, Ulf
> 
> Geert, what is your take on this? Would you prefer to route it through

I will object when renesas sends it to SoC.


> your tree instead, or do you think Krzysztof picking it via the SoC tree
> makes more sense?

Probably my "no" in this reply feel harsh, but I started in polite way
trying to move it to right direction and you opposed doing standard
vendor throw-over-the-wall approach.

You want to solve only your problem.

Well, I don't want to solve your problem, so if you do not intend to
solve our problem, let's just move on and skip this code.

> 
> I believe it is better handled by the experts in that area, P Zabel, Ulf,
> Geert, and others.
> 
> Thanks to both of you for considering this.

Best regards,
Krzysztof

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Krzysztof Kozlowski]

On 24/06/2026 10:59, Geert Uytterhoeven wrote:
> Hi Tommaso,
> 
> On Tue, 23 Jun 2026 at 18:44, Tommaso Merciai
> <tommaso.merciai.xr@bp.renesas.com> wrote:
>> On Fri, Jun 19, 2026 at 05:51:13AM +0200, Krzysztof Kozlowski wrote:
>>> On 18/06/2026 15:27, Tommaso Merciai wrote:
>>>> On Thu, Jun 18, 2026 at 03:04:20PM +0200, Linus Walleij wrote:
>>>>> On Wed, Jun 17, 2026 at 3:09 PM Tommaso Merciai
>>>>> <tommaso.merciai.xr@bp.renesas.com> wrote:
>>>>>
>>>>>>> If Peter is unable to attend to it send a pull request to the SoC
>>>>>>> tree (if this concerns an SoC) and explain the situation and the
>>>>>>> SoC maintainers can pull it in while we are looking for a new
>>>>>>> mux (co)maintainer. Unless you're interested in the job?
>>>>>>
>>>>>> I have the same issue with [1].
>>>>>>
>>>>>> Starting from [2] (Date: Wed,  5 Nov 2025)
>>>>>> I have never received any feedback.
>>>>>>
>>>>>> How should I proceed?
>>>>>
>>>>> If Greg can ACK patch 1/2 we can probably merge this set through the
>>>>> SoC tree as well. If the PWM subsystem is practically orphaned we
>>>>> need to step in and merge stuff.
>>>>
>>>> +Cc GregKH
>>>>
>>>> What is your suggestion here?
>>>> Thank all.
>>>
>>> In the past I took a few MUX patches and then send them further to Greg.
>>> I did it once and then kind of did not continue. I could do that again,
>>> but it won't really solve the problem that MUX needs person actively
>>> looking at this. Me taking patches is rather band-aid and I do not have
>>> particular business interests around MUX. But maybe you or Renesas have
>>> and could help here?
>>
>> Thank you for the context. I understand your position, being a
>> band-aidmaintainer without direct business interest is not a sustainable
>> solutionfor the MUX subsystem long term.
>>
>> That said, this patch has now been blocked for more than 6 months,
>> and we are looking for a way to get it upstream. Since you mentioned
>> you have picked MUX patches before and routed them through the SoC tree
>> to Greg, would you bewilling to do the same here?
>>
>> It would unblock us while the question of active MUX maintainership is
>> sorted out separately.
>>
>> +Cc: Geert, Philipp, Ulf
>>
>> Geert, what is your take on this? Would you prefer to route it through
>> your tree instead, or do you think Krzysztof picking it via the SoC tree
>> makes more sense?
>>
>> I believe it is better handled by the experts in that area, P Zabel, Ulf,
>> Geert, and others.
> 
> As Philipp already reviewed the patch[A], and took its user/consumer[B],
> I think he's best suited to pick it up.
> 
> If that fails, I can take it through renesas-devel.

This means you intend to send it to soc@ which I disagree. This goes
through Greg, not soc@.

I provided my expectations how Renesas could help here. Renesas as a
company, not you as Renesas maintainer. If Renesas is not willing to
help, it is fine and fair, but I see no reasons to be responsible for
this code.

Let me quote my "Guide to Becoming a Linux Kernel Maintainer" slides
from this OSS India:

"We might remove code, which is not maintained"

Best regards,
Krzysztof

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

On Wed, Jun 24, 2026 at 11:56 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:

> > and we are looking for a way to get it upstream. Since you mentioned
> > you have picked MUX patches before and routed them through the SoC tree
> > to Greg, would you bewilling to do the same here?
> >
> > It would unblock us while the question of active MUX maintainership is
> > sorted out separately.
>
> No. Every other case was following the same process "let's just unblock
> my work" and never fixed the actual problem of someone devoting time to
> take care of this stuff.
>
> If there is no one looking at this, we should consider removing it.

Mircea from Analog Devices contributed two important drivers for
drivers/mux in committ
8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.

Perhaps Analog Devices are interested in picking up and
maintaining drivers/mux?

Mircea what do you say?

Can you bring it up with your organization?

Yours,
Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

Michael, Nuno, Radu, Ramona, Antoniu, Sergiu, Dragos,

bring the below up in your internal slack/teams or whatever
discussion system Analog is using:

On Thu, Jun 25, 2026 at 12:03 AM Linus Walleij <linusw@kernel.org> wrote:
> On Wed, Jun 24, 2026 at 11:56 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> > > and we are looking for a way to get it upstream. Since you mentioned
> > > you have picked MUX patches before and routed them through the SoC tree
> > > to Greg, would you bewilling to do the same here?
> > >
> > > It would unblock us while the question of active MUX maintainership is
> > > sorted out separately.
> >
> > No. Every other case was following the same process "let's just unblock
> > my work" and never fixed the actual problem of someone devoting time to
> > take care of this stuff.
> >
> > If there is no one looking at this, we should consider removing it.
>
> Mircea from Analog Devices contributed two important drivers for
> drivers/mux in committ
> 8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.
>
> Perhaps Analog Devices are interested in picking up and
> maintaining drivers/mux?
>
> Mircea what do you say?
>
> Can you bring it up with your organization?

That mail bounced, OK let's page some other analog people
because I think they like and use this subsystem so maybe one
of them want to step up and maintain drivers/mux?

Yours,
Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Nuno Sá]

On Thu, Jun 25, 2026 at 12:11:28AM +0200, Linus Walleij wrote:
> Michael, Nuno, Radu, Ramona, Antoniu, Sergiu, Dragos,
> 
> bring the below up in your internal slack/teams or whatever
> discussion system Analog is using:
> 
> On Thu, Jun 25, 2026 at 12:03 AM Linus Walleij <linusw@kernel.org> wrote:
> > On Wed, Jun 24, 2026 at 11:56 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > > > and we are looking for a way to get it upstream. Since you mentioned
> > > > you have picked MUX patches before and routed them through the SoC tree
> > > > to Greg, would you bewilling to do the same here?
> > > >
> > > > It would unblock us while the question of active MUX maintainership is
> > > > sorted out separately.
> > >
> > > No. Every other case was following the same process "let's just unblock
> > > my work" and never fixed the actual problem of someone devoting time to
> > > take care of this stuff.
> > >
> > > If there is no one looking at this, we should consider removing it.
> >
> > Mircea from Analog Devices contributed two important drivers for
> > drivers/mux in committ
> > 8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.
> >
> > Perhaps Analog Devices are interested in picking up and
> > maintaining drivers/mux?
> >
> > Mircea what do you say?
> >
> > Can you bring it up with your organization?
> 
> That mail bounced, OK let's page some other analog people
> because I think they like and use this subsystem so maybe one
> of them want to step up and maintain drivers/mux?

Hi Linus!

Yeah, Mircea is not on ADI for a long time. Let me see this internally.
Not that long (some months), Peter did participated in a review for
something Antoniu was sending IIRC but looks like he's silent for too
long now...

- Nuno Sá

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Lad, Prabhakar]

On Thu, Jun 25, 2026 at 10:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> Mircea from Analog Devices contributed two important drivers for
> drivers/mux in committ
> 8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.
>
> Perhaps Analog Devices are interested in picking up and
> maintaining drivers/mux?
>
> Mircea what do you say?
>
> Can you bring it up with your organization?

Hi Linus, Krzysztof, All,

While Linus mentioned Analog Devices, we at Renesas would be glad to
step up here.

I have discussed this internally, and Renesas is willing to dedicate
the necessary engineering time to take over the active maintainership
of drivers/mux. I am happy to act as the maintainer to review incoming
patches, handle testing, and keep the subsystem moving forward so it
doesn't stall out. If the community is on board with this, I can send
a patch updating the MAINTAINERS file to make it official.

Cheers,
Prabhakar

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Krzysztof Kozlowski]

On 25/06/2026 11:32, Lad, Prabhakar wrote:
> On Thu, Jun 25, 2026 at 10:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>> Mircea from Analog Devices contributed two important drivers for
>> drivers/mux in committ
>> 8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.
>>
>> Perhaps Analog Devices are interested in picking up and
>> maintaining drivers/mux?
>>
>> Mircea what do you say?
>>
>> Can you bring it up with your organization?
> 
> Hi Linus, Krzysztof, All,
> 
> While Linus mentioned Analog Devices, we at Renesas would be glad to
> step up here.
> 
> I have discussed this internally, and Renesas is willing to dedicate
> the necessary engineering time to take over the active maintainership
> of drivers/mux. I am happy to act as the maintainer to review incoming
> patches, handle testing, and keep the subsystem moving forward so it

Great to hear! I appreciate. The initial pushback was a bit confusing.

> doesn't stall out. If the community is on board with this, I can send
> a patch updating the MAINTAINERS file to make it official.

Awesome, please do so. Put on CC existing maintainer (Peter), Greg and
me, change to "Maintained" (or Supported, up to you). Once you review
and collect the patches, make your tree part of Linux next and then
closer to RC5-RC6, send them as patches or pull request to Greg (Greg,
please correct me if anything here is inaccurate).

I recommend also slides from my talk from LPC 2023 - Beginner's Linux
kernel maintainer toolbox. If all this is obvious to you, then of course
apologies for lecturing.

Best regards,
Krzysztof

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Greg Kroah-Hartman]

On Thu, Jun 25, 2026 at 11:43:56AM +0200, Krzysztof Kozlowski wrote:
> On 25/06/2026 11:32, Lad, Prabhakar wrote:
> > On Thu, Jun 25, 2026 at 10:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >> Mircea from Analog Devices contributed two important drivers for
> >> drivers/mux in committ
> >> 8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.
> >>
> >> Perhaps Analog Devices are interested in picking up and
> >> maintaining drivers/mux?
> >>
> >> Mircea what do you say?
> >>
> >> Can you bring it up with your organization?
> > 
> > Hi Linus, Krzysztof, All,
> > 
> > While Linus mentioned Analog Devices, we at Renesas would be glad to
> > step up here.
> > 
> > I have discussed this internally, and Renesas is willing to dedicate
> > the necessary engineering time to take over the active maintainership
> > of drivers/mux. I am happy to act as the maintainer to review incoming
> > patches, handle testing, and keep the subsystem moving forward so it
> 
> Great to hear! I appreciate. The initial pushback was a bit confusing.
> 
> > doesn't stall out. If the community is on board with this, I can send
> > a patch updating the MAINTAINERS file to make it official.
> 
> Awesome, please do so. Put on CC existing maintainer (Peter), Greg and
> me, change to "Maintained" (or Supported, up to you). Once you review
> and collect the patches, make your tree part of Linux next and then
> closer to RC5-RC6, send them as patches or pull request to Greg (Greg,
> please correct me if anything here is inaccurate).

Nope, that works for me!

thanks,

greg k-h

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Lad, Prabhakar]

Hi Krzysztof,

On Thu, Jun 25, 2026 at 10:44 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 25/06/2026 11:32, Lad, Prabhakar wrote:
> > On Thu, Jun 25, 2026 at 10:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >> Mircea from Analog Devices contributed two important drivers for
> >> drivers/mux in committ
> >> 8b9ce6954c05e3e4115f54444c7eaf2aa2dd5e65.
> >>
> >> Perhaps Analog Devices are interested in picking up and
> >> maintaining drivers/mux?
> >>
> >> Mircea what do you say?
> >>
> >> Can you bring it up with your organization?
> >
> > Hi Linus, Krzysztof, All,
> >
> > While Linus mentioned Analog Devices, we at Renesas would be glad to
> > step up here.
> >
> > I have discussed this internally, and Renesas is willing to dedicate
> > the necessary engineering time to take over the active maintainership
> > of drivers/mux. I am happy to act as the maintainer to review incoming
> > patches, handle testing, and keep the subsystem moving forward so it
>
> Great to hear! I appreciate. The initial pushback was a bit confusing.
>
> > doesn't stall out. If the community is on board with this, I can send
> > a patch updating the MAINTAINERS file to make it official.
>
> Awesome, please do so. Put on CC existing maintainer (Peter), Greg and
> me, change to "Maintained" (or Supported, up to you). Once you review
> and collect the patches, make your tree part of Linux next and then
> closer to RC5-RC6, send them as patches or pull request to Greg (Greg,
> please correct me if anything here is inaccurate).
>
> I recommend also slides from my talk from LPC 2023 - Beginner's Linux
> kernel maintainer toolbox. If all this is obvious to you, then of course
> apologies for lecturing.
>
Thanks for the guidance and the pointer to your LPC talk definitely
not a lecture, I appreciate the resource and will take a look. I will
put together the MAINTAINERS patch shortly, changing the status to
"Maintained", and make sure Peter, Greg, and you are CC'd.

Cheers,
Prabhakar

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

On Thu, Jun 25, 2026 at 11:32 AM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:

> While Linus mentioned Analog Devices, we at Renesas would be glad to
> step up here.

Excellent, thanks Lad.

Yours,
Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Linus Walleij]

On Thu, Jun 25, 2026 at 11:18 AM Nuno Sá <noname.nuno@gmail.com> wrote:
> On Thu, Jun 25, 2026 at 12:11:28AM +0200, Linus Walleij wrote:

> > That mail bounced, OK let's page some other analog people
> > because I think they like and use this subsystem so maybe one
> > of them want to step up and maintain drivers/mux?
>
> Yeah, Mircea is not on ADI for a long time. Let me see this internally.
> Not that long (some months), Peter did participated in a review for
> something Antoniu was sending IIRC but looks like he's silent for too
> long now...

Apparently Renesas has stepped up to maintain drivers/mux
but given there are two ADI drivers there, maybe you want to
add a co-maintainer.

Yours,
Linus Walleij

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Andrea Tomassetti]

Hi Srinivas,
thank you for your thorough review.

On 6/19/26 19:23, Srinivas Kandagatla wrote:
> "mux: gpio-mux: add support for multiple mux controls" would be more
> reflective of what is done in  the patch.
>
Noted, I will update it in v3.
>>
>> -	mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio));
>> +	ret = device_property_read_u32(dev, "#mux-control-cells", &cells);
>> +	if (ret < 0)
>> +		cells = 0;
>> +
>> +	if (cells >= 2) {
>
> This code snippet is duplicated once again, may its time for this to go
> to as helper function, either in core or somewhere common.
>
What were you envisioning? A simple macro in mux/driver.h? Or more a proper
function in drivers/mux/core.c?

>> +		dev_err(dev, "invalid control-cells %u, must be 0 or 1\n", cells);
>
>  mux-control-cells would give useful message to user rather than just
> control-cells.
>
Noted, I will update it in v3.

>> +		return -EINVAL;
>> +	}
>> +
>> +	mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));
>
> We are now allocating n mux_controls, however mux_gpio_set is not
> protected against multiple controllers accessing the same gpio resource.
>
>
This is a great point. I see two different type of "race conditions" here:
    1. serialize accesses in mux_gpio_set
    2. "logical race condition" due to how the upper locking mechanism is
handled by mux/core.c

The first issue can be easily solved by adding a mutex inside struct mux_gpio
and use it to serialize accesses in mux_gpio_set.

OTOH, the second issue is more nasty and depends on how the upper locking
mechanism is handled by mux/core.c. Please, correct me if I'm wrong, but to me
it looks like that the core's locking model assumes each mux_control is an
independently lockable resource. While this is generally true, it doesn't apply
in the case when there's only one controller that jointly controls two or more
gpio-muxes. Like in this case.

So, adding a mutex at gpio-mux level would fix the race condition of two
consumers changing the state at the same time (issue 1). But, to my
understanding, it won't fix issue 2: mutual exclusion on the write makes each
write atomic, but consumer A's selection can still be immediately hijacked by
consumer B's, leaving A believing it is reading what it just set when it's
actually reading whatever B last selected. This happens because the lock used in
mux/core.c is allocated _per controller_ and not _per chip_. Do you agree with
my analysis?

If you agree, I can fix issue 1 but I'd lean towards treating issue 2 as out of
scope for this patch. Let me know if you see it differently.

Br,
Andrea

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Michael Hennerich]

On 6/29/26 21:27, Linus Walleij wrote:
> On Thu, Jun 25, 2026 at 11:18 AM Nuno Sá <noname.nuno@gmail.com> wrote:
>> On Thu, Jun 25, 2026 at 12:11:28AM +0200, Linus Walleij wrote:
>>> That mail bounced, OK let's page some other analog people
>>> because I think they like and use this subsystem so maybe one
>>> of them want to step up and maintain drivers/mux?
>> Yeah, Mircea is not on ADI for a long time. Let me see this internally.
>> Not that long (some months), Peter did participated in a review for
>> something Antoniu was sending IIRC but looks like he's silent for too
>> long now...
> Apparently Renesas has stepped up to maintain drivers/mux
> but given there are two ADI drivers there, maybe you want to
> add a co-maintainer.
>
> Yours,
> Linus Walleij

Hi Linus,

Thanks for bringing this up.

Analog Devices is happy to help co-maintain the mux framework. We do 
have users of the subsystem and a couple of drivers in the tree, so it 
makes sense for us to contribute on the maintenance side as well.

Antoniu Miclaus and Alvin Sipraga are both active in upstream kernel 
development and can step in as co-maintainers from the ADI side.

Antoniu and Alvin, could you please chime in and confirm your interest?

Thanks,
Michael

Sorry for the noise: Re-sending due to previous HTML email

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Srinivas Kandagatla]

On 6/30/26 4:08 PM, Andrea Tomassetti wrote:
>>> +
>>> +	mux_chip = devm_mux_chip_alloc(dev, cells + 1, sizeof(*mux_gpio));
>> We are now allocating n mux_controls, however mux_gpio_set is not
>> protected against multiple controllers accessing the same gpio resource.
>>
>>
> This is a great point. I see two different type of "race conditions" here:
>     1. serialize accesses in mux_gpio_set
serializing is not the major issue. The end result is.
>     2. "logical race condition" due to how the upper locking mechanism is
> handled by mux/core.c

> 
> The first issue can be easily solved by adding a mutex inside struct mux_gpio
> and use it to serialize accesses in mux_gpio_set.
> 
> OTOH, the second issue is more nasty and depends on how the upper locking
> mechanism is handled by mux/core.c. Please, correct me if I'm wrong, but to me
> it looks like that the core's locking model assumes each mux_control is an
> independently lockable resource. While this is generally true, it doesn't apply
> in the case when there's only one controller that jointly controls two or more
> gpio-muxes. Like in this case.

Yes, we have locking per mux control for a reason, Mux resources are
protected in that control context to make sure the mux is always held in
requested state.

Now with this patch we are using shared resource for multiple mux, that
means an underlying resource can be updated by another mux control
without of each other knowing about it.

Two questions.
1. Why a single resource is split into different mux controls? (sorry In
case I missed previous discussions)

2. Does the hardware allow you to set two different values for the same
resource, respecting both values at any given time. If its gpio, then am
not sure it does.


--srini


> 
> So, adding a mutex at gpio-mux level would fix the race condition of two
> consumers changing the state at the same time (issue 1). But, to my
> understanding, it won't fix issue 2: mutual exclusion on the write makes each
> write atomic, but consumer A's selection can still be immediately hijacked by
> consumer B's, leaving A believing it is reading what it just set when it's
> actually reading whatever B last selected. This happens because the lock used in
> mux/core.c is allocated _per controller_ and not _per chip_. Do you agree with
> my analysis?
> 
> If you agree, I can fix issue 1 but I'd lean towards treating issue 2 as out of
> scope for this patch. Let me know if you see it differently.
> 
> Br,

RE: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Miclaus, Antoniu]

Hi Michael, Linus,

> On 6/29/26 21:27, Linus Walleij wrote:
> > On Thu, Jun 25, 2026 at 11:18 AM Nuno Sá <noname.nuno@gmail.com>
> wrote:
> >> On Thu, Jun 25, 2026 at 12:11:28AM +0200, Linus Walleij wrote:
> >>> That mail bounced, OK let's page some other analog people
> >>> because I think they like and use this subsystem so maybe one
> >>> of them want to step up and maintain drivers/mux?
> >> Yeah, Mircea is not on ADI for a long time. Let me see this internally.
> >> Not that long (some months), Peter did participated in a review for
> >> something Antoniu was sending IIRC but looks like he's silent for too
> >> long now...
> > Apparently Renesas has stepped up to maintain drivers/mux
> > but given there are two ADI drivers there, maybe you want to
> > add a co-maintainer.
> >
> > Yours,
> > Linus Walleij
> 
> Hi Linus,
> 
> Thanks for bringing this up.
> 
> Analog Devices is happy to help co-maintain the mux framework. We do
> have users of the subsystem and a couple of drivers in the tree, so it
> makes sense for us to contribute on the maintenance side as well.
> 
> Antoniu Miclaus and Alvin Sipraga are both active in upstream kernel
> development and can step in as co-maintainers from the ADI side.
> 
> Antoniu and Alvin, could you please chime in and confirm your interest?

I'm happy to help co-maintain the mux framework. Confirming my interest. 

Thanks,
Antoniu

> Thanks,
> Michael
> 
> Sorry for the noise: Re-sending due to previous HTML email
> 

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Alvin Šipraga]

Hi all,

On Fri, Jul 03, 2026 at 10:02:21AM +0000, Miclaus, Antoniu wrote:
> Hi Michael, Linus,
> 
> > On 6/29/26 21:27, Linus Walleij wrote:
> > > On Thu, Jun 25, 2026 at 11:18 AM Nuno Sá <noname.nuno@gmail.com>
> > wrote:
> > >> On Thu, Jun 25, 2026 at 12:11:28AM +0200, Linus Walleij wrote:
> > >>> That mail bounced, OK let's page some other analog people
> > >>> because I think they like and use this subsystem so maybe one
> > >>> of them want to step up and maintain drivers/mux?
> > >> Yeah, Mircea is not on ADI for a long time. Let me see this internally.
> > >> Not that long (some months), Peter did participated in a review for
> > >> something Antoniu was sending IIRC but looks like he's silent for too
> > >> long now...
> > > Apparently Renesas has stepped up to maintain drivers/mux
> > > but given there are two ADI drivers there, maybe you want to
> > > add a co-maintainer.
> > >
> > > Yours,
> > > Linus Walleij
> > 
> > Hi Linus,
> > 
> > Thanks for bringing this up.
> > 
> > Analog Devices is happy to help co-maintain the mux framework. We do
> > have users of the subsystem and a couple of drivers in the tree, so it
> > makes sense for us to contribute on the maintenance side as well.
> > 
> > Antoniu Miclaus and Alvin Sipraga are both active in upstream kernel
> > development and can step in as co-maintainers from the ADI side.
> > 
> > Antoniu and Alvin, could you please chime in and confirm your interest?
> 
> I'm happy to help co-maintain the mux framework. Confirming my interest. 
> 
> Thanks,
> Antoniu

Happy to help too :-)

Adding Prabhakar to the thread, as he's already sent a MAINTAINERS
patch [1], but it doesn't look like it's been picked up yet.

Prabhakar, do you want to send a v3 with Antoniu and myself, or do you
prefer for me to do it? I have to update the MAINTAINERS file anyway,
since I've recently changed company and my old email there doesn't work
anymore.

If you do it, please use: Alvin Šipraga <alvin.sipraga@analog.com>

[1] https://lore.kernel.org/all/20260625121837.8359-1-prabhakar.mahadev-lad.rj@bp.renesas.com/

Kind regards,
Alvin

Re: [PATCH v2] mux: gpio-mux: add support for 4:1 2-channels mux

[Lad, Prabhakar]

Hi Alvin and Antoniu,

On Fri, Jul 3, 2026 at 2:19 PM Alvin Šipraga <alvin@pqrs.dk> wrote:
>
> Hi all,
>
> On Fri, Jul 03, 2026 at 10:02:21AM +0000, Miclaus, Antoniu wrote:
> > Hi Michael, Linus,
> >
> > > On 6/29/26 21:27, Linus Walleij wrote:
> > > > On Thu, Jun 25, 2026 at 11:18 AM Nuno Sá <noname.nuno@gmail.com>
> > > wrote:
> > > >> On Thu, Jun 25, 2026 at 12:11:28AM +0200, Linus Walleij wrote:
> > > >>> That mail bounced, OK let's page some other analog people
> > > >>> because I think they like and use this subsystem so maybe one
> > > >>> of them want to step up and maintain drivers/mux?
> > > >> Yeah, Mircea is not on ADI for a long time. Let me see this internally.
> > > >> Not that long (some months), Peter did participated in a review for
> > > >> something Antoniu was sending IIRC but looks like he's silent for too
> > > >> long now...
> > > > Apparently Renesas has stepped up to maintain drivers/mux
> > > > but given there are two ADI drivers there, maybe you want to
> > > > add a co-maintainer.
> > > >
> > > > Yours,
> > > > Linus Walleij
> > >
> > > Hi Linus,
> > >
> > > Thanks for bringing this up.
> > >
> > > Analog Devices is happy to help co-maintain the mux framework. We do
> > > have users of the subsystem and a couple of drivers in the tree, so it
> > > makes sense for us to contribute on the maintenance side as well.
> > >
> > > Antoniu Miclaus and Alvin Sipraga are both active in upstream kernel
> > > development and can step in as co-maintainers from the ADI side.
> > >
> > > Antoniu and Alvin, could you please chime in and confirm your interest?
> >
> > I'm happy to help co-maintain the mux framework. Confirming my interest.
> >
> > Thanks,
> > Antoniu
>
> Happy to help too :-)
>
> Adding Prabhakar to the thread, as he's already sent a MAINTAINERS
> patch [1], but it doesn't look like it's been picked up yet.
>
> Prabhakar, do you want to send a v3 with Antoniu and myself, or do you
> prefer for me to do it? I have to update the MAINTAINERS file anyway,
> since I've recently changed company and my old email there doesn't work
> anymore.
>
Thanks for the help!

I can definitely spin up a v3 and include both of you.

Cheers,
Prabhakar

> If you do it, please use: Alvin Šipraga <alvin.sipraga@analog.com>
>
> [1] https://lore.kernel.org/all/20260625121837.8359-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
>
> Kind regards,
> Alvin