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? > + > + m4_debug_fun: cm4-uart-grp { > + mux-states = <&m4_debug_mux 1>; > + }; [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
