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

[Frank Li <Frank.li@nxp.com>]

On Mon, Mar 02, 2026 at 11:11:00AM +0100, Linus Walleij wrote:
> On Fri, Feb 27, 2026 at 4:23 PM Frank Li <Frank.li@nxp.com> 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@nxp.com> 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?

init state is before probe if exist, which not fit this case because:
- on board mux need be enabled before probe, some device need communicate
with periphal at probe, such as SD card. SD data/cmd line must be ready
to scan SD, similar case for all mtd devices.

if add new state "release",  when the pinctrl may switch between default,
sleep, ... , "release" have to switch between switch state, such as default
 -> sleep have to change to default->release->sleep.

mux device also have idle state, which map to pinctrl's "init" or "sleep"
state.

The key difference should be
- pinctrl can uncondtional switch state.
- mux frame have to use pair mux_control_(de)select() to switch state.

So, I think just need a hook in pinctrl system to call mux_control_deselect()
when switch state and release resource.

Frank

>
> Yours,
> Linus Walleij