RE: [PATCH 07/17] arm64: dts: imx93-14x14-evk: Add pinmux and mark conflicting devices for MQS1
"Chancel Liu (OSS)" <[email protected]>
| Newsgroups | dev.linux.lists.sashiko-reviews,dev.linux.lists.imx,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <AM9PR04MB83536B482CE48E651905D968E3D92@AM9PR04MB8353.eurprd04.prod.outlook.com> |
> > Thank you for your contribution! Sashiko AI review found 1 potential > issue(s) to consider: > > - [Medium] The `&flexcan1` node is missing the `<&can1_fun>` pinctrl > state to claim the board multiplexer, potentially leaving the physical > pins disconnected from the CAN transceiver. > > -- > > > > --- Patch [7]: [PATCH 07/17] arm64: dts: imx93-14x14-evk: Add pinmux > > and mark conflicting devices for MQS1 --- commit > > dcb616d828fd4526406432c88e7ade3c33414225 > > Author: Chancel Liu <[email protected]> > > > > arm64: dts: imx93-14x14-evk: Add pinmux and mark conflicting devices > > for MQS1 > > > > This commit adds the MQS1 pinctrl group and labels conflicting devices > > (BT SCO card and FlexCAN1) so they can be disabled by a shared overlay. > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx93-14x14-evk.dts > > > b/arch/arm64/boot/dts/freescale/imx93-14x14-evk.dts > > > index 502237fab3324..11bb7e52fbb1e 100644 > > > --- a/arch/arm64/boot/dts/freescale/imx93-14x14-evk.dts > > > +++ b/arch/arm64/boot/dts/freescale/imx93-14x14-evk.dts > > > > [ ... ] > > > > > @@ -282,7 +282,7 @@ ethphy2: ethernet-phy@2 { > > > }; > > > }; > > > > > > -&flexcan1 { > > > +mqs1_conflict_dev: &flexcan1 { > > > pinctrl-names = "default"; > > > pinctrl-0 = <&pinctrl_flexcan1>; > > > > [Severity: Medium] > > Is the &can1_fun pinctrl state missing from the pinctrl-0 list here? > > > > If the MQS1 overlay is applied (setting the mux to state 1) and later > > reverted, or if the hardware boots with the multiplexer GPIO high, > > flexcan1 will become active but will fail to assert mux state 0. > > > > Without the &can1_fun reference to claim the board multiplexer, the > > physical pins may remain disconnected from the CAN transceiver, > > causing it to silently fail to communicate on the bus. > > Make sense. > > Frank > Yes, &can1_fun should be referenced in CAN1 node. Regards, Chancel Liu > > > > > xceiver-supply = <®_can1_stby>; > > > status = "okay"; > > > }; > > > > -- > > Sashiko AI review * > > https://sashiko.dev/#/patchset/20260814072022.4064009-1-chancel.liu@os > > s.nxp.com?part=7 NXP Confidential