Re: [PATCH v2 5/7] arm64: dts: imx8dxl-evk: Add onboard GPIO mux controller

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

On Wed, Jul 15, 2026 at 06:53:04PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The generic pinctrl mux driver uses a blocking semaphore lock for mux states without registering pinctrl pins, causing an indefinite kernel thread hang if multiple devices request overlapping multiplexer states.
> --
>
> --- Patch [5]: [PATCH v2 5/7] arm64: dts: imx8dxl-evk: Add onboard GPIO mux controller ---
> commit 2474a73a6c541ff5bdb893980b3be68aefebe7b3
> Author: Frank Li <Frank.Li@nxp.com>
> Date:   Wed Jul 15 18:34:50 2026 +0000
>
> arm64: dts: imx8dxl-evk: Add onboard GPIO mux controller
>
> This commit adds a GPIO mux controller to explicitly describe the onboard
> signal multiplexer using the pinctrl-multiplexer framework. The patch routes
> signals for functions like lpuart1 and spi3, preparing the device tree for
> additional overlays that require different mux configurations.
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> > index 78e8d41e67916..33941645641f5 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
>
> [ ... ]
>
> > +	pinctrl-gpiomux {
> > +		compatible = "pinctrl-multiplexer";
>
> [Severity: High]
> This isn't a bug introduced by this patch, but since this patch makes this
> board the first real in-tree consumer of the pinctrl-multiplexer framework,
> could it expose a deadlock risk in the generic mux driver?
>
> Looking at drivers/pinctrl/pinctrl-generic-mux.c, the driver registers the
> pinctrl provider without defining any pins (npins = 0) in mux_pinctrl_probe():
>
> drivers/pinctrl/pinctrl-generic-mux.c:mux_pinctrl_probe() {
> 	pctl_desc->pctlops = &mux_pinctrl_ops;
> 	pctl_desc->pmxops = &mux_pinmux_ops;
>
> 	ret = devm_pinctrl_register_and_init(dev, pctl_desc, mpctl,
> 					     &mpctl->pctl);
> 	...
> }
>
> Because it bypasses the pinctrl core's built-in pin conflict detection,
> any overlapping state conflicts are deferred to the mux subsystem API:
>
> drivers/pinctrl/pinctrl-generic-mux.c:mux_pinmux_set_mux() {
> 	...
> 	ret = mux_state_select(func->mux_state);
> 	...
> }
>
> If two devices (e.g., via the DT overlays mentioned in the commit message)
> define pinctrl states sharing the same underlying mux-controller, the first
> device will acquire the mux lock semaphore and hold it for its bound lifetime.
>
> When the second device probes, it calls mux_state_select() and blocks
> indefinitely on down_killable(), causing a kernel thread hang instead of a
> graceful failure.
>
> Should the generic pinctrl mux driver use mux_state_try_select() instead of
> mux_state_select() so that conflicting overlay requests fail gracefully with
> -EBUSY?

Yes, use the new patch fix this problem.

Frank
>
> > +
> > +		m4_debug_fun: cm4-uart-grp {
> > +			mux-states = <&m4_debug_mux 1>;
> > +		};
>
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260715-dxl_lcdif-v2-0-da797562636e@nxp.com?part=5