Variscite has updated the Ethernet PHY on the VAR-SOM-MX93 from the
Murata CYW43353 to the MaxLinear MXL86110, as documented in the
August 2023 revision changelog.
Link: https://variwiki.com/index.php?title=VAR-SOM-MX93_rev_changelog

Update the device tree accordingly:
- Drop the unused regulator node previously used to power the Murata PHY.
- Add support for the reset line using GPIO1_IO07 with proper timings.
- Configure the PHY LEDs via the LED subsystem under /sys/class/leds/,
  leveraging the support implemented in the mxl86110 PHY driver
  (drivers/net/phy/mxl-86110.c).
  Two LEDs are defined to match the LED configuration on the Variscite
  VAR-SOM Carrier Boards:
    * LED@0: Yellow, netdev trigger.
    * LED@1: Green, netdev trigger.
- Adjust the RGMII clock pad control settings to match the updated PHY
  requirements.

These changes ensure proper PHY initialization and LED status indication
for the new MaxLinear MXL86110, improving board compatibility with the
latest hardware revision.

Signed-off-by: Stefano Radaelli <stefano.radaelli21@gmail.com>
---
 .../boot/dts/freescale/imx93-var-som.dtsi     | 40 ++++++++++++-------
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
index 783938245e4f..402a28d0ed8d 100644
--- a/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-var-som.dtsi
@@ -19,19 +19,6 @@ mmc_pwrseq: mmc-pwrseq {
 		reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>,	/* WIFI_RESET */
 			      <&gpio3 7 GPIO_ACTIVE_LOW>;	/* WIFI_PWR_EN */
 	};
-
-	reg_eqos_phy: regulator-eqos-phy {
-		compatible = "regulator-fixed";
-		pinctrl-names = "default";
-		pinctrl-0 = <&pinctrl_reg_eqos_phy>;
-		regulator-name = "eth_phy_pwr";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-		startup-delay-us = <100000>;
-		regulator-always-on;
-	};
 };
 
 &eqos {
@@ -39,6 +26,7 @@ &eqos {
 	pinctrl-0 = <&pinctrl_eqos>;
 	phy-mode = "rgmii";
 	phy-handle = <&ethphy0>;
+	snps,clk-csr = <5>;
 	status = "okay";
 
 	mdio {
@@ -51,6 +39,27 @@ ethphy0: ethernet-phy@0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <0>;
 			eee-broken-1000t;
+			reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <100000>;
+			leds {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				led@0 {
+					reg = <0>;
+					color = <LED_COLOR_ID_YELLOW>;
+					function = LED_FUNCTION_LAN;
+					linux,default-trigger = "netdev";
+				};
+
+				led@1 {
+					reg = <1>;
+					color = <LED_COLOR_ID_GREEN>;
+					function = LED_FUNCTION_LAN;
+					linux,default-trigger = "netdev";
+				};
+			};
 		};
 	};
 };
@@ -75,14 +84,15 @@ MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0			0x57e
 			MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1			0x57e
 			MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2			0x57e
 			MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3			0x57e
-			MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x5fe
+			MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x58e
 			MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL		0x57e
 			MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0			0x57e
 			MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1			0x57e
 			MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2			0x57e
 			MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3			0x57e
-			MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x5fe
+			MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x58e
 			MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL		0x57e
+			MX93_PAD_UART2_TXD__GPIO1_IO07				0x51e
 		>;
 	};
 

base-commit: a9dfb7db96f7bc1f30feae673aab7fdbfbc94e9c
prerequisite-patch-id: 2335ebcc90360b008c840e7edf7e34a595880edf
-- 
2.43.0

+Mathieu who upstreamed the initial support for this board.

Regards,
Peng

>  &eqos {
> @@ -39,6 +26,7 @@ &eqos {
>  	pinctrl-0 = <&pinctrl_eqos>;
>  	phy-mode = "rgmii";

I know this is not in the scope of what you are trying to do, but this
is probably wrong:

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

	Andrew

Hi Andrew,

I double-checked with our hardware team, and it turns out that all required
RGMII delays are already handled by the hardware on the SOM (trace
tuning + PHY config).
So "rgmii" is indeed intentional here, no additional software delay needed.
Thanks for pointing it out, it made me double-check, which is always a
good thing.

Best Regards,

Stefano

Il giorno mer 4 giu 2025 alle ore 03:19 Andrew Lunn <andrew@lunn.ch> ha scritto:
>
> >  &eqos {
> > @@ -39,6 +26,7 @@ &eqos {
> >       pinctrl-0 = <&pinctrl_eqos>;
> >       phy-mode = "rgmii";
>
> I know this is not in the scope of what you are trying to do, but this
> is probably wrong:
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
>
>         Andrew

61;8001;1cOn Wed, Jun 04, 2025 at 09:37:39AM +0200, Stefano Radaelli wrote:
> Hi Andrew,
> 
> I double-checked with our hardware team, and it turns out that all required
> RGMII delays are already handled by the hardware on the SOM (trace
> tuning + PHY config).

What do you mean by PHY config?

The four RGMII modes you can use with phy-mode are purely about the
PCB. If you have the PHY strapped to add delays, what does not count
for PCB, and if you are not careful, future software could reconfigure
it.

	Andrew

Hi Andrew,

To clarify more precisely: hw team told me that the required 2 ns
RGMII delays are
implemented directly in hardware inside the SOM itself, through passive delay
elements (filters) placed on the RX and TX lines. There is no reliance on PHY
strap settings or any kind of delay configuration via registers.

This means:
- The delays are fixed and cannot be changed via software.
- From the point of view of any carrier board, the interface is
already timing-compliant.

Given that, using phy-mode = "rgmii" in the DTS is intentional and
correct, since the
necessary internal delays are already guaranteed by the SOM hardware design.

Let me know if further clarification would be helpful, would it help if I add a
clarification about this in the commit message for v2?

Best regards,
Stefano

Il giorno mer 4 giu 2025 alle ore 14:01 Andrew Lunn <andrew@lunn.ch> ha scritto:
>
>
> 61;8001;1cOn Wed, Jun 04, 2025 at 09:37:39AM +0200, Stefano Radaelli wrote:
> > Hi Andrew,
> >
> > I double-checked with our hardware team, and it turns out that all required
> > RGMII delays are already handled by the hardware on the SOM (trace
> > tuning + PHY config).
>
> What do you mean by PHY config?
>
> The four RGMII modes you can use with phy-mode are purely about the
> PCB. If you have the PHY strapped to add delays, what does not count
> for PCB, and if you are not careful, future software could reconfigure
> it.
>
>         Andrew

On Wed, Jun 04, 2025 at 03:08:09PM +0200, Stefano Radaelli wrote:
> Hi Andrew,
> 
> To clarify more precisely: hw team told me that the required 2 ns
> RGMII delays are
> implemented directly in hardware inside the SOM itself, through passive delay
> elements (filters) placed on the RX and TX lines. There is no reliance on PHY
> strap settings or any kind of delay configuration via registers.
> 
> This means:
> - The delays are fixed and cannot be changed via software.
> - From the point of view of any carrier board, the interface is
> already timing-compliant.

Great. Please add a comment in the DT explaining this. 99% of the time
'rgmii' is wrong, but this is the 1%. We should make it clear this is
not just another cut/paste error, but very intentional and correct
because of the PCB design.

There is a patch to checkpatch.pl i want to introduce in the next
development cycle which will look for 'rgmii', and if found, look on
the line before for a comment including the word 'PCB'. If it finds
'rgmii' without such a comment it will issue a warning. So it would be
nice to avoid that in your correct case.

     Andrew

Hi Andrew,

Absolutely, thanks again for pointing this out! I'm actually glad you asked,
because it pushed me to double-check internally with our hardware team
and confirm the exact implementation details.

I'll make sure to include a proper comment in the device tree right above the
'phy-mode = "rgmii";' line in v2, clearly stating that the RGMII delays are
handled via fixed passive components on the SOM's PCB itself, with no
software or strap-based configuration involved.

Thanks again,
Stefano

Il giorno mer 4 giu 2025 alle ore 17:13 Andrew Lunn <andrew@lunn.ch> ha scritto:
>
> On Wed, Jun 04, 2025 at 03:08:09PM +0200, Stefano Radaelli wrote:
> > Hi Andrew,
> >
> > To clarify more precisely: hw team told me that the required 2 ns
> > RGMII delays are
> > implemented directly in hardware inside the SOM itself, through passive delay
> > elements (filters) placed on the RX and TX lines. There is no reliance on PHY
> > strap settings or any kind of delay configuration via registers.
> >
> > This means:
> > - The delays are fixed and cannot be changed via software.
> > - From the point of view of any carrier board, the interface is
> > already timing-compliant.
>
> Great. Please add a comment in the DT explaining this. 99% of the time
> 'rgmii' is wrong, but this is the 1%. We should make it clear this is
> not just another cut/paste error, but very intentional and correct
> because of the PCB design.
>
> There is a patch to checkpatch.pl i want to introduce in the next
> development cycle which will look for 'rgmii', and if found, look on
> the line before for a comment including the word 'PCB'. If it finds
> 'rgmii' without such a comment it will issue a warning. So it would be
> nice to avoid that in your correct case.
>
>      Andrew