On Wed, Jul 15, 2026 at 06:53:04PM +0000, [email protected] 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 <[email protected]>
> 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/[email protected]?part=5
