Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Moving the MCLK pin to the `&acm` node does not prevent it from being unconditionally claimed, failing the stated goal of the patch. --
--- Patch [6]: [PATCH v2 6/7] arm64: dts: imx8dxl-evk: Move ACM MCLK pin to ACM pinctrl --- commit fb6f6ae3a276dd7b713e3fe1ab6ebf914e293471 Author: Frank Li <[email protected]> arm64: dts: imx8dxl-evk: Move ACM MCLK pin to ACM pinctrl This commit moves the IMX8DXL_SPI3_CS0_ADMA_ACM_MCLK_OUT1 pin from the iomuxc hog group to the ACM pinctrl state. The stated goal is to avoid unconditionally claiming the pin so that LCDIF can use it instead. > diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts > b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts > index 33941645641f5..3b96bab6aec80 100644 > --- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts > +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts > @@ -347,6 +347,11 @@ sound-wm8960-3 { > }; > }; > > +&acm { > + pinctrl-names = "default"; > + pinctrl-0 = <&pinctrl_mclk>; > +}; [Severity: Medium] Does moving this to the &acm node actually prevent the pin from being unconditionally claimed? Because the &acm node (a core clock controller) lacks a status = "disabled" property, it seems the driver core's pinctrl_bind_pins() function will still unconditionally claim the default pinctrl state at boot. If a user enables the LCDIF node, won't it still fail to probe with a pinctrl -EBUSY conflict? Should these pinctrl properties be attached to the optional end-consumer of the MCLK (like the sound card node) instead, so they are only claimed when LCDIF is inactive? [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
