Re: [PATCH V2 3/3] arm64: dts: freescale: Add chargebyte Charge Control Y

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Missing GPIO initialization / Unused pin for X_nRST_LAN
- [Medium] Missing Pin Mux Configuration for USDHC2_VSELECT in default state
- [Low] DT Binding Violation: Undocumented compatible string 'microchip,mcp2542'
--

commit c595019b7dc419cc298a111c2b215904a12f65e1
Author: Stefan Wahren <wahrenst@gmx.net>
arm64: dts: freescale: Add chargebyte Charge Control Y

This commit introduces device tree support for the chargebyte Charge Control Y,
an Electrical Vehicle Supply Equipment for MCS charging stations based on the
phyCORE-i.MX 93 ARM SoM. It defines necessary pin multiplexing, peripherals
like CAN and Ethernet, and device-specific layouts.

> diff --git a/arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts b/arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts
> new file mode 100644
> index 0000000000000..0405098cc05c4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts

[ ... ]

> +	// Heartbeat LED of phyCore is not populated
> +	/delete-node/ leds;
> +
> +	flexcan1_tc: can-phy0 {
> +		compatible = "microchip,mcp2542", "ti,tcan1042";

[Severity: Low]
Is the "microchip,mcp2542" compatible string documented in any devicetree
binding schema?

Using an undocumented compatible string here might cause `make dtbs_check`
validation tooling to fail.

> +		#phy-cells = <0>;
> +		max-bitrate = <1000000>;
> +	};

[ ... ]

> +	pinctrl_flexcan1: flexcan1grp {
> +		fsl,pins = <
> +			MX93_PAD_PDM_BIT_STREAM0__CAN1_RX	0x139e
> +			MX93_PAD_PDM_CLK__CAN1_TX		0x1382
> +		>;
> +	};
> +
> +	pinctrl_gpio1: gpio1grp {
> +		fsl,pins = <
> +			MX93_PAD_I2C2_SDA__GPIO1_IO03		0x31e

[Severity: Medium]
Does the X_nRST_LAN reset pin (GPIO1_IO03) need a GPIO hog or a driver
consumer (e.g., via a reset-gpios property) in the device tree?

Since the upstream lan865x SPI kernel driver does not parse or manage
reset-gpios, leaving its functional state unmanaged here might result in the
hardware reset pin floating or being left in an indeterminate state.

Could this cause the LAN8651 Ethernet interface to fail to emerge from reset
and initialize properly on a cold boot?

> +			MX93_PAD_PDM_BIT_STREAM1__GPIO1_IO10	0x382
> +		>;
> +	};
> +
> +	pinctrl_gpio4: gpio4grp {

[ ... ]

> +	pinctrl_usdhc2_cd: usdhc2cdgrp {
> +		fsl,pins = <
> +			MX93_PAD_SD2_CD_B__GPIO3_IO00		0x31e
> +		>;
> +	};
> +
> +	/* need to config the SION for data and cmd pad, refer to ERR052021 */
> +	pinctrl_usdhc2_default: usdhc2grp {
> +		fsl,pins = <
> +			MX93_PAD_SD2_CLK__USDHC2_CLK		0x119e
> +			MX93_PAD_SD2_CMD__USDHC2_CMD		0x4000139e
> +			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x4000138e
> +			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x4000138e
> +			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x4000138e
> +			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x4000139e

[Severity: Medium]
Should MX93_PAD_SD2_VSELECT__USDHC2_VSELECT be included in this default
state group?

The MMC core initially brings up the SD card in the default 3.3V state. Without
the USDHC2_VSELECT pad configured here, the controller might not be able to
actively manage the IO voltage selection in its default state.

Could this absence lead to unpredictable external voltage regulator behavior or
SD card initialization failures?

> +		>;
> +	};
> +
> +	/* need to config the SION for data and cmd pad, refer to ERR052021 */
> +	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831083539.8287-1-wahrenst@gmx.net?part=3