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

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

[Stefan Wahren]

This series adds support for the chargebyte Charge Control Y, which is
an Electrical Vehicle Supply Equipment (EVSE) for MCS (Megawatt
Charging System) charging stations.

sashiko reported in the first version of the series [1] that X_nRST_LAN
is available via GPIO line names, but there is no reset mechanismn in the
device tree. This finding is valid. Since the reset line feature isn't
implemented for LAN8651 driver yet, I like to proceed with the current
version. The LAN8651 handles reset via SPI commands and in rare cases
we still have the possibility to control the reset from userspace.
Btw the pin has a pull resistor in hardware, so it's not floating.

[1] - https://lore.kernel.org/linux-devicetree/20260818093147.E556C1F000E9@smtp.kernel.org/

Changes in V2:
- drop phy-can-transceiver changes and make MCP2542 compatible to TI TCAN1042
  as suggested by Marc Kleine-Budde & Frank Li
- implemented SD2_nRESET as vmmc supply for SD card interface
  (reported by sashiko)
- add UHS support for SD card interface
- dropped downstream property ti,leds-polarity (reported by sashiko)
- fix GPIO line name of X_LAN_nCS (reported by sashiko)
- drop unconnected pins (X_TDI, X_TMS_SWDIO, X_TDO) from GPIO line names 

Stefan Wahren (3):
  dt-bindings: arm: fsl: Add chargebyte Charge Control Y
  dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542
  arm64: dts: freescale: Add chargebyte Charge Control Y

 .../devicetree/bindings/arm/fsl.yaml          |   1 +
 .../bindings/phy/ti,tcan104x-can.yaml         |   1 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-charge-control-y.dts  | 426 ++++++++++++++++++
 .../boot/dts/freescale/imx93-phycore-som.dtsi |   2 +-
 5 files changed, 430 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts

-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH V2 1/3] dt-bindings: arm: fsl: Add chargebyte Charge Control Y

[Stefan Wahren]

Add device-tree bindings for chargebyte Charge Control Y board based on
the PHYTEC phyCORE-i.MX93 SoM (System-on-Module).

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59..a7a1dc6b0ea3 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1633,6 +1633,7 @@ properties:
       - description: PHYTEC phyCORE-i.MX93 SoM based boards
         items:
           - enum:
+              - chargebyte,imx93-charge-control-y # chargebyte Charge Control Y
               - phytec,imx93-phyboard-nash  # phyBOARD-Nash-i.MX93
               - phytec,imx93-phyboard-segin # phyBOARD-Segin with i.MX93
           - const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH V2 2/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542

[Stefan Wahren]

The Microchip MCP2542 High-speed CAN transceiver with Sleep mode is a
pin-compatible alternative for the TI TCAN1042.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 9f5c37ca6496..3ed4ce219120 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -18,6 +18,7 @@ properties:
       - items:
           - enum:
               - microchip,ata6561
+              - microchip,mcp2542
               - ti,tcan1051
           - const: ti,tcan1042
       - items:
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Stefan Wahren]

This adds the support for chargebyte Charge Control Y, which is
an Electrical Vehicle Supply Equipment (EVSE) for MCS (Megawatt
Charging System) charging stations (according to IEC 61851-23-1).

chargebyte Charge Control Y uses phyCORE-i.MX 93 ARM
- NXP i.MX93 1.7 GHz
- 1 GB DDR4 RAM
- up to 8 GB eMMC
- 2x 100 MBit/s Ethernet interfaces
- 10BASE-T1S Ethernet for MCS communication
- CAN interface
- separate safety chip
- TPM chip
- power buffered RTC

Co-developed-by: Martin Lukas <martin.lukas@chargebyte.com>
Signed-off-by: Martin Lukas <martin.lukas@chargebyte.com>
Co-developed-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-charge-control-y.dts  | 426 ++++++++++++++++++
 .../boot/dts/freescale/imx93-phycore-som.dtsi |   2 +-
 3 files changed, 428 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9..c64902dfc6f3 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -594,6 +594,7 @@ imx93-11x11-frdm-pixpaper-dtbs += imx93-11x11-frdm.dtb imx93-11x11-frdm-pixpaper
 dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm-pixpaper.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx93-14x14-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-charge-control-y.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-kontron-bl-osm-s.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin.dtb
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 000000000000..0405098cc05c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts
@@ -0,0 +1,426 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2025-2026 chargebyte GmbH
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "imx93-phycore-som.dtsi"
+
+/ {
+	model = "chargebyte Charge Control Y";
+	compatible = "chargebyte,imx93-charge-control-y", "phytec,imx93-phycore-som", "fsl,imx93";
+
+	aliases {
+		ethernet0 = &fec;
+		ethernet1 = &lan8651;
+		ethernet2 = &eqos;
+		gpio0 = &gpio1;
+		gpio1 = &gpio2;
+		gpio2 = &gpio3;
+		gpio3 = &gpio4;
+		mmc0 = &usdhc1;
+		mmc1 = &usdhc2;
+		rtc0 = &rv3028;
+		rtc1 = &bbnsm_rtc;
+		serial0 = &lpuart1;
+		serial1 = &lpuart2;
+		serial2 = &lpuart3;
+		serial3 = &lpuart4;
+		serial4 = &lpuart5;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	// Heartbeat LED of phyCore is not populated
+	/delete-node/ leds;
+
+	flexcan1_tc: can-phy0 {
+		compatible = "microchip,mcp2542", "ti,tcan1042";
+		#phy-cells = <0>;
+		max-bitrate = <1000000>;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "VCC_SD";
+	};
+
+	user_leds: user-leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_user_leds>;
+
+		led_user_green: led-user-green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_BOOT;
+			gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "timer";
+		};
+
+		led_user_red: led-user-red {
+			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_SD;
+			gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "mmc1";
+		};
+	};
+};
+
+&eeprom0 {
+	nvmem-layout {
+		compatible = "fixed-layout";
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* Wired ethernet interface */
+		eth1_mac_address: base-mac-address@100 {
+			compatible = "mac-base";
+			reg = <0x100 0x6>;
+			#nvmem-cell-cells = <1>;
+		};
+
+		/* MCS ethernet interface */
+		eth2_mac_address: base-mac-address@108 {
+			compatible = "mac-base";
+			reg = <0x108 0x6>;
+			#nvmem-cell-cells = <1>;
+		};
+	};
+};
+
+/* Ethernet 2 */
+&eqos {
+	phy-mode = "rmii";
+	phy-handle = <&ethphy2>;
+	assigned-clocks = <&clk IMX93_CLK_ENET_TIMER2>,
+			  <&clk IMX93_CLK_ENET>;
+	assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>,
+				 <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>;
+	assigned-clock-rates = <100000000>, <50000000>;
+
+	nvmem-cells = <&eth1_mac_address 0>;
+	nvmem-cell-names = "mac-address";
+
+	status = "okay";
+};
+
+/* Ethernet 1 */
+&fec {
+	/* Since MDIO bus is handled by FEC, all PHY strap pins and
+	 * reference clock must be initialized at the same time.
+	 */
+	pinctrl-0 = <&pinctrl_fec &pinctrl_eqos &pinctrl_eqos_strap>;
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	phys = <&flexcan1_tc>;
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpio1>;
+	gpio-line-names = "", "", "", "X_nRST_LAN", "",
+			  "", "LPUART2_RX", "LPUART2_TX", "CAN1_TX", "CAN1_RX",
+			  "", "SPI_TPM_nCS0", "", "", "",
+			  "";
+};
+
+&gpio2 {
+	gpio-line-names = "", "", "", "", "",
+			  "", "", "X_LAN_nIRQ", "X_LAN_nCS", "",
+			  "", "", "", "", "",
+			  "", "", "", "", "",
+			  "", "", "", "", "GREEN_LED",
+			  "RED_LED", "", "", "", "";
+};
+
+&gpio3 {
+	gpio-line-names = "SD2_nCD", "", "", "", "",
+			  "", "", "SD2_nRESET", "", "",
+			  "", "", "", "", "",
+			  "", "", "", "", "",
+			  "SOM_EMMC_nRESET", "", "", "", "",
+			  "", "", "", "", "",
+			  "", "";
+};
+
+&gpio4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpio4>;
+	gpio-line-names = "", "", "X_RTC_nINT", "", "",
+			  "", "", "", "", "",
+			  "", "", "SAFETY_BOOTMODE_SET", "ENET1_RST", "",
+			  "", "", "", "", "",
+			  "", "SOM_EEPROM_WP", "", "SOM_PHY_RESET", "",
+			  "", "", "PMIC_IRQ_B", "nSAFETY_RESET_INT", "SPI_TPM_nINT0";
+};
+
+&lpi2c1 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_lpi2c1>;
+	pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+	scl-gpios = <&gpio1 00 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio1 01 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	rv3028: rtc@52 {
+		compatible = "microcrystal,rv3028";
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio4>;
+		wakeup-source;
+		trickle-resistor-ohms = <3000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rtc>;
+		reg = <0x52>;
+	};
+};
+
+&lpspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpspi1>;
+	num-cs = <1>;
+	cs-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	tpm@0 {
+		compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+		reg = <0>;
+		spi-max-frequency = <10000000>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+/* MCS Ethernet SPI */
+&lpspi3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpspi3>;
+	num-cs = <1>;
+	cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	lan8651: ethernet@0 {
+		compatible = "microchip,lan8651", "microchip,lan8650";
+		reg = <0>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+		spi-max-frequency = <25000000>;
+
+		nvmem-cells = <&eth2_mac_address 0>;
+		nvmem-cell-names = "mac-address";
+	};
+};
+
+&lpuart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&lpuart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3>;
+	status = "okay";
+};
+
+/* Ethernet 2 PHY */
+&mdio {
+	ethphy2: ethernet-phy@2 {
+		reg = <2>;
+		compatible = "ethernet-phy-id2000.a140";
+		clocks = <&clk IMX93_CLK_ENET_REF_PHY>;
+		reset-gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;
+		reset-assert-us = <30>;
+		reset-deassert-us = <50000>;
+	};
+};
+
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2_default>, <&pinctrl_usdhc2_cd>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_cd>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_cd>;
+	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	disable-wp;
+	no-sdio;
+	no-mmc;
+	status = "okay";
+};
+
+&iomuxc {
+
+	// Heartbeat LED of phyCore is not populated
+	/delete-node/ pinctrl_leds;
+
+	pinctrl_eqos: eqosgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK		0x4000057e
+			MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0				0x50e
+			MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1				0x50e
+			MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL			0x50e
+		>;
+	};
+
+	pinctrl_eqos_strap: eqosstrapgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_RXC__ENET_QOS_RX_ER		0x17e
+			MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0		0x17e
+			MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1		0x17e
+			MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL	0x17e
+		>;
+	};
+
+	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
+			MX93_PAD_PDM_BIT_STREAM1__GPIO1_IO10	0x382
+		>;
+	};
+
+	pinctrl_gpio4: gpio4grp {
+		fsl,pins = <
+			MX93_PAD_ENET1_TXC__GPIO4_IO07		0x382
+			MX93_PAD_ENET1_RD2__GPIO4_IO12		0x39e
+			MX93_PAD_CCM_CLKO3__GPIO4_IO28		0x39e
+			MX93_PAD_ENET1_RD3__GPIO4_IO13		0x31e
+		>;
+	};
+
+	pinctrl_lpi2c1: lpi2c1grp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__LPI2C1_SCL		0x40000b86
+			MX93_PAD_I2C1_SDA__LPI2C1_SDA		0x40000b86
+		>;
+	};
+
+	pinctrl_lpi2c1_gpio: lpi2c1gpiogrp {
+		fsl,pins = <
+			MX93_PAD_I2C1_SCL__GPIO1_IO00		0x40000b9e
+			MX93_PAD_I2C1_SDA__GPIO1_IO01		0x40000b9e
+		>;
+	};
+
+	pinctrl_lpspi1: lpspi1grp {
+		fsl,pins = <
+			MX93_PAD_CCM_CLKO4__GPIO4_IO29		0x186
+			MX93_PAD_SAI1_TXFS__GPIO1_IO11		0x186
+			MX93_PAD_SAI1_TXC__LPSPI1_SIN		0x186
+			MX93_PAD_SAI1_TXD0__LPSPI1_SCK		0x186
+			MX93_PAD_SAI1_RXD0__LPSPI1_SOUT		0x186
+		>;
+	};
+
+	/* PinCtrl MCS LAN SPI */
+	pinctrl_lpspi3: lpspi3grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO07__GPIO2_IO07		0x186
+			MX93_PAD_GPIO_IO08__GPIO2_IO08		0x186
+			MX93_PAD_GPIO_IO09__LPSPI3_SIN		0x186
+			MX93_PAD_GPIO_IO10__LPSPI3_SOUT		0x186
+			MX93_PAD_GPIO_IO11__LPSPI3_SCK		0x186
+		>;
+	};
+
+	pinctrl_rtc: rtcgrp {
+		fsl,pins = <
+			MX93_PAD_ENET1_TD3__GPIO4_IO02		0x31e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX93_PAD_UART1_RXD__LPUART1_RX		0x31e
+			MX93_PAD_UART1_TXD__LPUART1_TX		0x30e
+		>;
+	};
+
+	pinctrl_uart3: uart3grp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO15__LPUART3_RX		0x31e
+			MX93_PAD_GPIO_IO14__LPUART3_TX		0x30e
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+		fsl,pins = <
+			MX93_PAD_SD2_RESET_B__GPIO3_IO07	0x31e
+		>;
+	};
+
+	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
+		>;
+	};
+
+	/* need to config the SION for data and cmd pad, refer to ERR052021 */
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		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	0x4000139e
+			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x4000139e
+			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	/* need to config the SION for data and cmd pad, refer to ERR052021 */
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			MX93_PAD_SD2_CLK__USDHC2_CLK		0x118e
+			MX93_PAD_SD2_CMD__USDHC2_CMD		0x4000139e
+			MX93_PAD_SD2_DATA0__USDHC2_DATA0	0x4000139e
+			MX93_PAD_SD2_DATA1__USDHC2_DATA1	0x4000139e
+			MX93_PAD_SD2_DATA2__USDHC2_DATA2	0x4000139e
+			MX93_PAD_SD2_DATA3__USDHC2_DATA3	0x4000139e
+			MX93_PAD_SD2_VSELECT__USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_user_leds: userledgrp {
+		fsl,pins = <
+			MX93_PAD_GPIO_IO24__GPIO2_IO24		0x31e
+			MX93_PAD_GPIO_IO25__GPIO2_IO25		0x31e
+		>;
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
index 325e465d0056..489ed3f7fb61 100644
--- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
@@ -201,7 +201,7 @@ ldo5: LDO5 {
 	};
 
 	/* EEPROM */
-	eeprom@50 {
+	eeprom0: eeprom@50 {
 		compatible = "atmel,24c32";
 		reg = <0x50>;
 		pagesize = <32>;
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[sashiko-bot]

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

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Stefan Wahren]

Am 31.08.26 um 11:04 schrieb 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?
This is included in patch #2.
> Using an undocumented compatible string here might cause `make dtbs_check`
> validation tooling to fail.
I verified this patch series with "make dtbs_check". False positive?
>
>> +		#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?
As already mentioned in the cover letter, I like to proceed with the 
version until the reset management is implemented in LAN8651.
The pin is not floating because there is a pull resistor in hardware.

Should I move the explanation to the commit message of this patch or add 
a comment in the DTS?
>
>> +			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?
Nice catch, will fix it

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


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Frank Li]

On Mon, Aug 31, 2026 at 03:47:15PM +0200, Stefan Wahren wrote:
> Am 31.08.26 um 11:04 schrieb 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?
> This is included in patch #2.
> > Using an undocumented compatible string here might cause `make dtbs_check`
> > validation tooling to fail.
> I verified this patch series with "make dtbs_check". False positive?
> >
> > > +		#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?
> As already mentioned in the cover letter, I like to proceed with the version
> until the reset management is implemented in LAN8651.
> The pin is not floating because there is a pull resistor in hardware.
>
> Should I move the explanation to the commit message of this patch or add a
> comment in the DTS?

Comments in code.

Frank

> >
> > > +			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?
> Nice catch, will fix it
>
> Best regards
> >
> > > +		>;
> > > +	};
> > > +
> > > +	/* need to config the SION for data and cmd pad, refer to ERR052021 */
> > > +	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH V2 1/3] dt-bindings: arm: fsl: Add chargebyte Charge Control Y

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH V2 2/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy