[PATCH RFC 0/4] arm64: dts: freescale: Add chargebyte Charge Control Y

[PATCH RFC 0/4] 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.

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

 .../devicetree/bindings/arm/fsl.yaml          |   1 +
 .../bindings/phy/ti,tcan104x-can.yaml         |   2 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 .../dts/freescale/imx93-charge-control-y.dts  | 387 ++++++++++++++++++
 .../boot/dts/freescale/imx93-phycore-som.dtsi |   2 +-
 drivers/phy/phy-can-transceiver.c             |   8 +
 6 files changed, 400 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts

-- 
2.43.0

[PATCH RFC 1/4] 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

[PATCH RFC 2/4] 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 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 9f5c37ca6496..2ebc954ce769 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -24,6 +24,7 @@ properties:
           - const: ti,tcan1046
           - const: nxp,tja1048
       - enum:
+          - microchip,mcp2542
           - ti,tcan1042
           - ti,tcan1043
           - nxp,tja1048
@@ -72,6 +73,7 @@ allOf:
       properties:
         compatible:
           enum:
+            - microchip,mcp2542
             - nxp,tjr1443
             - ti,tcan1042
             - ti,tcan1043
-- 
2.43.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The new compatible string 'microchip,mcp2542' is added as a standalone enum item in the binding but lacks corresponding support in the CAN transceiver PHY driver.
--

--- Patch [2]: [PATCH RFC 2/4] dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542 ---
commit 43adb87775584a977c1d440864b9e805fba31d0e
Author: Stefan Wahren <wahrenst@gmx.net>

dt-bindings: phy: ti,tcan104x-can: Document Microchip MCP2542

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

> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -24,6 +24,7 @@ properties:
>            - const: ti,tcan1046
>            - const: nxp,tja1048
>        - enum:
> +          - microchip,mcp2542

[Severity: High]
Since the compatible string is added as a standalone enum item, a device tree
node will not have a fallback string. Looking at the CAN transceiver PHY driver
in drivers/phy/phy-can-transceiver.c, the match table lacks this new string:

static const struct of_device_id can_transceiver_phy_ids[] = {
	{
		.compatible = "ti,tcan1042",
		.data = &tcan1042_drvdata
	},

Does this cause the PHY driver to fail to probe for the new device? If this is
a pin-compatible alternative for ti,tcan1042, should the binding require a
fallback compatible string so the existing driver can match it, or does the
driver need to be updated to support the standalone string?

>            - ti,tcan1042
>            - ti,tcan1043

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

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

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On 18.08.2026 11:16:59, Stefan Wahren wrote:
> The Microchip MCP2542 High-speed CAN transceiver with Sleep mode is a
> pin-compatible alternative for the TI TCAN1042.

If it's compatible with the TCAN1042, why don't you add it with the
ti,tcan1042 as required fallback?

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

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

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

[Frank Li]

On Tue, Aug 18, 2026 at 11:16:59AM +0200, Stefan Wahren wrote:
> [You don't often get email from wahrenst@gmx.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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 | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 9f5c37ca6496..2ebc954ce769 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -24,6 +24,7 @@ properties:
>            - const: ti,tcan1046
>            - const: nxp,tja1048
>        - enum:
> +          - microchip,mcp2542


which compatible with ti,jia1042 according to second patch.

so just add microchip,mcp2542 after microchip,ata6561

          - enum:
              - microchip,ata6561
              - microchip,mcp2542
                ^^^^^^^^^^^^^^^^
              - ti,tcan1051
          - const: ti,tcan1042

use
	compatible = "microchip,ata6561", "microchip,ata6561" in dts

Frank

>            - ti,tcan1042
>            - ti,tcan1043
>            - nxp,tja1048
> @@ -72,6 +73,7 @@ allOf:
>        properties:
>          compatible:
>            enum:
> +            - microchip,mcp2542
>              - nxp,tjr1443
>              - ti,tcan1042
>              - ti,tcan1043
> --
> 2.43.0
>
>

[PATCH RFC 3/4] phy: phy-can-transceiver: Add support for 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>
---
 drivers/phy/phy-can-transceiver.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 75dc49e75ca0..1606384d4a0e 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -96,6 +96,10 @@ static const struct can_transceiver_data tja1057_drvdata = {
 	.flags = CAN_TRANSCEIVER_SILENT_PRESENT,
 };
 
+static const struct can_transceiver_data mcp2542_drvdata = {
+	.flags = CAN_TRANSCEIVER_STB_PRESENT,
+};
+
 static struct phy *can_transceiver_phy_xlate(struct device *dev,
 					     const struct of_phandle_args *args)
 {
@@ -238,6 +242,10 @@ static const struct of_device_id can_transceiver_phy_ids[] = {
 		.compatible = "nxp,tjr1443",
 		.data = &tcan1043_drvdata
 	},
+	{
+		.compatible = "microchip,mcp2542",
+		.data = &mcp2542_drvdata
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
-- 
2.43.0

Re: [PATCH RFC 3/4] phy: phy-can-transceiver: Add support for Microchip MCP2542

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On 18.08.2026 11:17:00, Stefan Wahren wrote:
> 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>

Not needed, if the binding requires "ti,tcan1042" as fallback.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

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

[PATCH RFC 4/4] 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  | 387 ++++++++++++++++++
 .../boot/dts/freescale/imx93-phycore-som.dtsi |   2 +-
 3 files changed, 389 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..348a3a24887b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts
@@ -0,0 +1,387 @@
+// 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";
+		#phy-cells = <0>;
+		max-bitrate = <1000000>;
+	};
+
+	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 PHY */
+&ethphy1 {
+	ti,leds-polarity = <1>; // active-high
+};
+
+/* 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_nCS", "", "", "", "",
+			  "", "", "X_LAN_nIRQ", "", "",
+			  "", "", "", "", "",
+			  "", "", "", "", "",
+			  "", "", "", "", "GREEN_LED",
+			  "RED_LED", "", "", "", "";
+};
+
+&gpio3 {
+	gpio-line-names = "SD2_nCD", "", "", "", "",
+			  "", "", "SD2_nRESET", "", "",
+			  "", "", "", "", "",
+			  "", "", "", "", "",
+			  "SOM_EMMC_nRESET", "", "", "", "",
+			  "", "", "", "X_TDI", "X_TMS_SWDIO",
+			  "", "X_TDO";
+};
+
+&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>;
+		ti,leds-polarity = <1>; // active-high
+	};
+};
+
+/* SD */
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2_default>, <&pinctrl_usdhc2_cd>;
+	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
+	bus-width = <4>;
+	disable-wp;
+	no-sdio;
+	no-mmc;
+	no-1-8-v;
+	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_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
+		>;
+	};
+
+	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

Re: [PATCH RFC 4/4] arm64: dts: freescale: Add chargebyte Charge Control Y

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The LAN8651 ethernet device is missing its hardware reset configuration, leaving the `X_nRST_LAN` pin unmanaged.
- [Medium] The SD card slot power/reset pin (`SD2_nRESET`) is named in `gpio-line-names` but is not associated with any regulator or reset control.
- [Low] The GPIO label `X_LAN_nCS` is incorrectly placed at index 0 of `&gpio2`'s `gpio-line-names` array, but the `lan8651` chip select is actually wired to index 8.
- [Low] The `ti,leds-polarity` property used in both Ethernet PHY nodes is undocumented, invalid, and will cause `dtbs_check` validation errors.
--

--- Patch [4]: [PATCH RFC 4/4] arm64: dts: freescale: Add chargebyte Charge Control Y ---
commit a177a5e0acba62156876ea6dc84457789786bfb8
Author: Stefan Wahren <wahrenst@gmx.net>

arm64: dts: freescale: Add chargebyte Charge Control Y

This commit adds support for the chargebyte Charge Control Y, an EVSE
for MCS charging stations based on the phyCORE-i.MX 93 ARM SoM. It
adds the devicetree for the board, including ethernet interfaces, CAN,
SPI, and SD card configurations.

> 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
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx93-charge-control-y.dts
> @@ -0,0 +1,387 @@
[ ... ]
> +/* Ethernet 1 PHY */
> +&ethphy1 {
> +	ti,leds-polarity = <1>; // active-high
> +};

[Severity: Low]
Is ti,leds-polarity supported by the devicetree bindings? It does not
appear to be documented in the schema and might cause dtbs_check validation
errors.

[ ... ]
> +&gpio2 {
> +	gpio-line-names = "X_LAN_nCS", "", "", "", "",
> +			  "", "", "X_LAN_nIRQ", "", "",

[Severity: Low]
Should the X_LAN_nCS label be placed at index 8 instead of index 0? The
lpspi3 node below configures the cs-gpios using index 8 on this bank.

[ ... ]
> +/* 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";
> +	};
> +};

[Severity: Medium]
The pin X_nRST_LAN is labeled in the gpio1 node, but this ethernet node
doesn't seem to configure a reset mechanism. Does the LAN8651 need a reset
control or gpio-hog to ensure the pin is driven and not left floating?

[ ... ]
> +/* 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>;
> +		ti,leds-polarity = <1>; // active-high
> +	};
> +};

[Severity: Low]
Similar to the ethernet 1 PHY above, is this ti,leds-polarity property
supported by the devicetree bindings?

> +
> +/* SD */
> +&usdhc2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc2_default>, <&pinctrl_usdhc2_cd>;
> +	cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
> +	bus-width = <4>;
> +	disable-wp;
> +	no-sdio;
> +	no-mmc;
> +	no-1-8-v;
> +	status = "okay";
> +};

[Severity: Medium]
The SD2_nRESET pin is labeled in the gpio3 node, but does this usdhc2 node
need a vmmc-supply using that pin as a fixed regulator to ensure the SD
card slot is reliably powered?

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

Re: [PATCH RFC 4/4] arm64: dts: freescale: Add chargebyte Charge Control Y

[Stefan Wahren]

Hi Parthiban,
hi Selvamani,
hi Ciprian,

Am 18.08.26 um 11:31 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [Medium] The LAN8651 ethernet device is missing its hardware reset configuration, leaving the `X_nRST_LAN` pin unmanaged.
> - [Medium] The SD card slot power/reset pin (`SD2_nRESET`) is named in `gpio-line-names` but is not associated with any regulator or reset control.
> - [Low] The GPIO label `X_LAN_nCS` is incorrectly placed at index 0 of `&gpio2`'s `gpio-line-names` array, but the `lan8651` chip select is actually wired to index 8.
> - [Low] The `ti,leds-polarity` property used in both Ethernet PHY nodes is undocumented, invalid, and will cause `dtbs_check` validation errors.
> --
>
> --- Patch [4]: [PATCH RFC 4/4] arm64: dts: freescale: Add chargebyte Charge Control Y ---
> commit a177a5e0acba62156876ea6dc84457789786bfb8
> Author: Stefan Wahren <wahrenst@gmx.net>
...
> +/* 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";
> +	};
> +};
> [Severity: Medium]
> The pin X_nRST_LAN is labeled in the gpio1 node, but this ethernet node
> doesn't seem to configure a reset mechanism. Does the LAN8651 need a reset
> control or gpio-hog to ensure the pin is driven and not left floating?
according to the current DT binding of LAN8651 there is no reset 
control, but the chip has a reset line and its wired on our board.

Are there any plans to implement reset control for OA TC6 or LAN8651?

Best regards