[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