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

[sashiko-bot@kernel.org]

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?

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