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

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 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

[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 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

[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

[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

[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;
>  	}
>.