Re: [PATCH v2 4/6] pinctrl: add generic board-level pinctrl driver using mux framework

From: Linus Walleij

Date: Mon Mar 02 2026 - 05:17:08 EST


On Fri, Feb 27, 2026 at 4:23 PM Frank Li <Frank.li@xxxxxxx> wrote:
> On Fri, Feb 27, 2026 at 10:20:14AM +0100, Linus Walleij wrote:
> > On Thu, Feb 26, 2026 at 12:55 AM Frank Li <Frank.Li@xxxxxxx> wrote:

> > > +static void mux_pinmux_release_mux(struct pinctrl_dev *pctldev,
> > > + unsigned int func_selector,
> > > + unsigned int group_selector)
> > > +{
> > > + struct mux_pinctrl *mpctl = pinctrl_dev_get_drvdata(pctldev);
> > > + const struct function_desc *function;
> > > + struct mux_pin_function *func;
> > > +
> > > + guard(mutex)(&mpctl->lock);
> > > +
> > > + function = pinmux_generic_get_function(pctldev, func_selector);
> > > + func = function->data;
> > > +
> > > + mux_state_deselect(func->mux_state);
> > > +
> > > + mpctl->cur_select = -1;
> > > +}
> >
> > As mentioned I have my doubts about this, explain why this hardware
> > is so different that this is needed.
>
> As board mux (uart and flexcan) exist, for example, only one of UART and
> FlexCAN work.
>
> when modprobe uart.ko, mux_state_select called.
>
> So flexcan driver can't get such mux as expected.
>
> when remmod uart.ko, we need release mux_state, so flexcan driver can
> get such resource.
>
> Genernally, DT may only enouble one of UART or flexcan.
>
> but insmod uart.ko
> rmmod uart.ko
>
> insmod uart.ko (here also need release previous's state at prevous rmmod).

Can't you just enter the state "init"? This can be used
explicitly on the uart .remove() path using pinctrl_pm_select_init_state().

Sure the device core does not do it automatically but this is a
special case.

If you want a generic solution without having to change any drivers,
Add pinctrl_unbind_pins() to drivers/base/pinctrl.c and call on the
generic .remove path for all drivers to put the device into "init"
state during rmmod.

This gives us better control of the actual hardware states I think?

Yours,
Linus Walleij