From: Stefano Radaelli <stefano.r@variscite.com>
Update the FEC Ethernet controller on the i.MX8MM VAR-SOM to match the
latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY.
This patch adds:
- PHY VDDIO 1.8V supply regulator.
- Proper reset timings for the MXL86110.
- LED configuration for link/activity indication via the LED subsystem
under /sys/class/leds/, leveraging the support in the MXL86110 PHY
driver.
Two LEDs are defined to match the VAR-SOM carrier design:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.
- A pinctrl sleep state for low-power operation.
The PHY reset is now handled in the SOM .dtsi using the SoC GPIO.
The previous carrier-specific reset-gpios property in the Symphony
device tree is therefore removed.
The enet_rst GPIO hog on the carrier is kept to ensure a defined
board-level reset line state during boot.
Wake-on-LAN via magic packet is not supported at the VAR-SOM level and
is therefore not enabled in the SOM device tree nor in the official
evaluation carrier board configuration (symphony).
Designs requiring WoL support may enable it in their own carrier-specific
device trees if properly integrated at the hardware level.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
.../dts/freescale/imx8mm-var-som-symphony.dts | 11 ++--
.../boot/dts/freescale/imx8mm-var-som.dtsi | 59 ++++++++++++++++++-
2 files changed, 63 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
index 819707e6f3bf..689894405b27 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dts
@@ -70,10 +70,6 @@ led {
};
};
-ðphy {
- reset-gpios = <&pca9534 5 GPIO_ACTIVE_HIGH>;
-};
-
&i2c2 {
clock-frequency = <400000>;
pinctrl-names = "default";
@@ -99,6 +95,13 @@ usb3-sata-sel-hog {
line-name = "usb3_sata_sel";
};
+ enet-rst-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "enet_rst";
+ };
+
som-vselect-hog {
gpio-hog;
gpios = <6 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
index da3c7332ec34..23045f54e00e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-som.dtsi
@@ -4,6 +4,7 @@
* Copyright (C) 2020 Krzysztof Kozlowski <krzk@kernel.org>
*/
+#include <dt-bindings/leds/common.h>
#include "imx8mm.dtsi"
/ {
@@ -24,6 +25,13 @@ reg_eth_phy: regulator-eth-phy {
gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ reg_phy_vddio: regulator-phy-vddio {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
&A53_0 {
@@ -99,12 +107,17 @@ touchscreen@0 {
};
&fec1 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_fec1>;
+ pinctrl-1 = <&pinctrl_fec1_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
phy-mode = "rgmii";
phy-handle = <ðphy>;
phy-supply = <®_eth_phy>;
- fsl,magic-packet;
status = "okay";
mdio {
@@ -116,7 +129,27 @@ ethphy: ethernet-phy@4 {
reg = <4>;
reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
reset-assert-us = <10000>;
- reset-deassert-us = <10000>;
+ reset-deassert-us = <100000>;
+ vddio-supply = <®_phy_vddio>;
+
+ 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";
+ };
+ };
};
};
};
@@ -366,6 +399,26 @@ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
>;
};
+ pinctrl_fec1_sleep: fec1sleepgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ENET_MDC_GPIO1_IO16 0x120
+ MX8MM_IOMUXC_ENET_MDIO_GPIO1_IO17 0x120
+ MX8MM_IOMUXC_ENET_TD3_GPIO1_IO18 0x120
+ MX8MM_IOMUXC_ENET_TD2_GPIO1_IO19 0x120
+ MX8MM_IOMUXC_ENET_TD1_GPIO1_IO20 0x120
+ MX8MM_IOMUXC_ENET_TD0_GPIO1_IO21 0x120
+ MX8MM_IOMUXC_ENET_RD3_GPIO1_IO29 0x120
+ MX8MM_IOMUXC_ENET_RD2_GPIO1_IO28 0x120
+ MX8MM_IOMUXC_ENET_RD1_GPIO1_IO27 0x120
+ MX8MM_IOMUXC_ENET_RD0_GPIO1_IO26 0x120
+ MX8MM_IOMUXC_ENET_TXC_GPIO1_IO23 0x120
+ MX8MM_IOMUXC_ENET_RXC_GPIO1_IO25 0x120
+ MX8MM_IOMUXC_ENET_RX_CTL_GPIO1_IO24 0x120
+ MX8MM_IOMUXC_ENET_TX_CTL_GPIO1_IO22 0x120
+ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x100
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3
--
2.47.3On Tue, Feb 17, 2026 at 07:42:37PM +0100, Stefano Radaelli wrote: > From: Stefano Radaelli <stefano.r@variscite.com> > > Update the FEC Ethernet controller on the i.MX8MM VAR-SOM to match the > latest SOM hardware revision using the integrated MaxLinear MXL86110 PHY. I don't think you say this explicitly anywhere, so i will ask. The PHY is on the SOM? The carrier just has magnetics and the RJ45? > Two LEDs are defined to match the VAR-SOM carrier design: > * LED@0: Yellow, netdev trigger. > * LED@1: Green, netdev trigger. Where are the LEDs? You say "carrier design", so are they on the carrier? The DT properties should then be in the .dts file for the carrier. Andrew
Hi Andrew! > > I don't think you say this explicitly anywhere, so i will ask. The PHY > is on the SOM? The carrier just has magnetics and the RJ45? Yes, the Ethernet PHY (MXL86110) is physically mounted on the VAR-SOM. All RGMII signals, MDIO and the LED outputs are routed to the SOM board-to-board connector. The carrier board only provides the magnetics and the RJ45 connector. > > > Two LEDs are defined to match the VAR-SOM carrier design: > > * LED@0: Yellow, netdev trigger. > > * LED@1: Green, netdev trigger. > > Where are the LEDs? You say "carrier design", so are they on the > carrier? The DT properties should then be in the .dts file for the > carrier. > The LED signals are driven directly by the PHY and originate on the SOM. They are exposed on the SOM connector and are typically routed straight to the RJ45 integrated LEDs on the carrier. For this reason, the LED configuration belongs in the SOM .dtsi rather than the carrier .dts. That said, you are right that describing them as "Yellow" and "Green" ties the description to a specific carrier implementation. I will drop the `color` property and keep only the LED function and trigger so that carrier designs can reflect the actual LED implementation if needed. Does that approach sound acceptable? As always, thank you for your review. Best regards, Stefano
On Tue, Feb 17, 2026 at 08:31:36PM +0100, Stefano Radaelli wrote: > Hi Andrew! > > > > I don't think you say this explicitly anywhere, so i will ask. The PHY > > is on the SOM? The carrier just has magnetics and the RJ45? > > Yes, the Ethernet PHY (MXL86110) is physically mounted on the VAR-SOM. O.K. so far. > All RGMII signals, MDIO and the LED outputs are routed to the SOM > board-to-board connector. The carrier board only provides the magnetics > and the RJ45 connector. And here you loose me. RGMII is between the MAC and the PHY. The PHY is on the SOM, so there is no need for RGMII to leave the SOM. MDIO is can understand going to the carrier, because there can be other devices on the bus, such as an Ethernet switch. You say the LEDs are not on the SOM. So they should not be listed in the .dtsi file for the SOM. It could be the RJ45 is a cheap one, without LEDs. The colours will depend on the RJ45 socket. It could be a single LED is connected to the front panel, which is typical of STB etc. So the LEDs are a board property, not a SOM property. > > > Two LEDs are defined to match the VAR-SOM carrier design: > > > * LED@0: Yellow, netdev trigger. > > > * LED@1: Green, netdev trigger. > > > > Where are the LEDs? You say "carrier design", so are they on the > > carrier? The DT properties should then be in the .dts file for the > > carrier. > > > > The LED signals are driven directly by the PHY and originate on the SOM. > They are exposed on the SOM connector and are typically routed straight > to the RJ45 integrated LEDs on the carrier. The problem here is 'typically', not absolutely required, otherwise the magic smoke will escape making the box useless. Andrew
Hi Andrew, On Tue, Feb 17, 2026 at 09:43:16PM +0100, Andrew Lunn wrote: > > And here you loose me. RGMII is between the MAC and the PHY. The PHY > is on the SOM, so there is no need for RGMII to leave the SOM. > > MDIO is can understand going to the carrier, because there can be > other devices on the bus, such as an Ethernet switch. > > You say the LEDs are not on the SOM. So they should not be listed in > the .dtsi file for the SOM. It could be the RJ45 is a cheap one, > without LEDs. The colours will depend on the RJ45 socket. It could be > a single LED is connected to the front panel, which is typical of STB > etc. So the LEDs are a board property, not a SOM property. > > > > > Two LEDs are defined to match the VAR-SOM carrier design: > > > > * LED@0: Yellow, netdev trigger. > > > > * LED@1: Green, netdev trigger. > > > > > > Where are the LEDs? You say "carrier design", so are they on the > > > carrier? The DT properties should then be in the .dts file for the > > > carrier. > > > > > > > The LED signals are driven directly by the PHY and originate on the SOM. > > They are exposed on the SOM connector and are typically routed straight > > to the RJ45 integrated LEDs on the carrier. > > The problem here is 'typically', not absolutely required, otherwise > the magic smoke will escape making the box useless. > You are right sorry for the confusion: RGMII is internal between the MAC and the PHY and does not leave the SOM. What is exposed on the SOM connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED output signals. Given that the actual LEDs are implemented on the carrier side (RJ45 with integrated LEDs, pull-ups and LED supply), would you prefer that the LED description is moved out of the SOM .dtsi and into the carrier .dts? My idea would be to keep the Ethernet controller/PHY node fully described in the SOM .dtsi (since the PHY is on-module), and add only the LED subnode/definition in the carrier .dts where the LEDs are actually present. If this is the right approach, I will apply the same pattern to the other Variscite SOMs where we currently describe PHY LEDs at the SOM level (e.g. imx8mp-var-som, imx93-var-som). Thanks again for the review. Best regards, Stefano
On Wed, Feb 18, 2026 at 09:59:31AM +0100, Stefano Radaelli wrote:
> Hi Andrew,
>
> On Tue, Feb 17, 2026 at 09:43:16PM +0100, Andrew Lunn wrote:
> >
> > And here you loose me. RGMII is between the MAC and the PHY. The PHY
> > is on the SOM, so there is no need for RGMII to leave the SOM.
> >
> > MDIO is can understand going to the carrier, because there can be
> > other devices on the bus, such as an Ethernet switch.
> >
> > You say the LEDs are not on the SOM. So they should not be listed in
> > the .dtsi file for the SOM. It could be the RJ45 is a cheap one,
> > without LEDs. The colours will depend on the RJ45 socket. It could be
> > a single LED is connected to the front panel, which is typical of STB
> > etc. So the LEDs are a board property, not a SOM property.
> >
> > > > > Two LEDs are defined to match the VAR-SOM carrier design:
> > > > > * LED@0: Yellow, netdev trigger.
> > > > > * LED@1: Green, netdev trigger.
> > > >
> > > > Where are the LEDs? You say "carrier design", so are they on the
> > > > carrier? The DT properties should then be in the .dts file for the
> > > > carrier.
> > > >
> > >
> > > The LED signals are driven directly by the PHY and originate on the SOM.
> > > They are exposed on the SOM connector and are typically routed straight
> > > to the RJ45 integrated LEDs on the carrier.
> >
> > The problem here is 'typically', not absolutely required, otherwise
> > the magic smoke will escape making the box useless.
> >
>
> You are right sorry for the confusion: RGMII is internal between the MAC
> and the PHY and does not leave the SOM. What is exposed on the SOM
> connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED
> output signals.
O.K, that is what i expected.
> Given that the actual LEDs are implemented on the carrier side (RJ45
> with integrated LEDs, pull-ups and LED supply), would you prefer that
> the LED description is moved out of the SOM .dtsi and into the carrier
> .dts?
Yes please.
> My idea would be to keep the Ethernet controller/PHY node fully
> described in the SOM .dtsi (since the PHY is on-module), and add only
> the LED subnode/definition in the carrier .dts where the LEDs are
> actually present.
Yes. That is good.
Thanks
Andrew
Hi Andrew, On Wed, Feb 18, 2026 at 02:23:40PM +0100, Andrew Lunn wrote: > On Wed, Feb 18, 2026 at 09:59:31AM +0100, Stefano Radaelli wrote: > > Hi Andrew, > > > > On Tue, Feb 17, 2026 at 09:43:16PM +0100, Andrew Lunn wrote: > > > > > > And here you loose me. RGMII is between the MAC and the PHY. The PHY > > > is on the SOM, so there is no need for RGMII to leave the SOM. > > > > > > MDIO is can understand going to the carrier, because there can be > > > other devices on the bus, such as an Ethernet switch. > > > > > > You say the LEDs are not on the SOM. So they should not be listed in > > > the .dtsi file for the SOM. It could be the RJ45 is a cheap one, > > > without LEDs. The colours will depend on the RJ45 socket. It could be > > > a single LED is connected to the front panel, which is typical of STB > > > etc. So the LEDs are a board property, not a SOM property. > > > > > > > > > Two LEDs are defined to match the VAR-SOM carrier design: > > > > > > * LED@0: Yellow, netdev trigger. > > > > > > * LED@1: Green, netdev trigger. > > > > > > > > > > Where are the LEDs? You say "carrier design", so are they on the > > > > > carrier? The DT properties should then be in the .dts file for the > > > > > carrier. > > > > > > > > > > > > > The LED signals are driven directly by the PHY and originate on the SOM. > > > > They are exposed on the SOM connector and are typically routed straight > > > > to the RJ45 integrated LEDs on the carrier. > > > > > > The problem here is 'typically', not absolutely required, otherwise > > > the magic smoke will escape making the box useless. > > > > > > > You are right sorry for the confusion: RGMII is internal between the MAC > > and the PHY and does not leave the SOM. What is exposed on the SOM > > connector are the MDI pairs towards the magnetics/RJ45 and the PHY LED > > output signals. > > O.K, that is what i expected. > > > Given that the actual LEDs are implemented on the carrier side (RJ45 > > with integrated LEDs, pull-ups and LED supply), would you prefer that > > the LED description is moved out of the SOM .dtsi and into the carrier > > .dts? > > Yes please. > > > My idea would be to keep the Ethernet controller/PHY node fully > > described in the SOM .dtsi (since the PHY is on-module), and add only > > the LED subnode/definition in the carrier .dts where the LEDs are > > actually present. > > Yes. That is good. > > Thanks > Andrew I will send the v2 with led descriptions in Symphony dts instead of SOM dtsi. Thank you again, Best Regards, Stefano
© 2016 - 2026 Red Hat, Inc.