The Liontron H-A133L board features an Ethernet controller with a
JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO.
Note that the reset pin must be handled as a bus-wide reset GPIO in
order to let the MDIO core properly reset it before trying to read
its identification registers. There's no other device on the MDIO bus.
The datasheet of the PHY mentions that the reset signal must be held
for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to
be on the safe side without wasting too much time during boot.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
.../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
index fe77178d3e33..90a50910f07b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts
@@ -65,6 +65,25 @@ &ehci1 {
status = "okay";
};
+&emac0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rmii0_pins>;
+ phy-handle = <&rmii_phy>;
+ phy-mode = "rmii";
+ status = "okay";
+};
+
+&mdio0 {
+ reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */
+ reset-delay-us = <2000>;
+ reset-post-delay-us = <2000>;
+
+ rmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
--
2.49.0
On Mon, 7 Jul 2025 18:51:55 +0200 Paul Kocialkowski <paulk@sys-base.io> wrote: Hi Paul, > The Liontron H-A133L board features an Ethernet controller with a > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > Note that the reset pin must be handled as a bus-wide reset GPIO in > order to let the MDIO core properly reset it before trying to read > its identification registers. There's no other device on the MDIO bus. putting the PHY reset GPIO into the MDIO node is a clever solution, I was struggling with putting it either in the MAC or PHY node, though conceptually it would still belong in the latter, I think. But this might be a more generic problem: for most other devices we activate reset and clock gates *before* trying to access them, though this might be historically different for Ethernet PHYs. > The datasheet of the PHY mentions that the reset signal must be held > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > be on the safe side without wasting too much time during boot. > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Despite the above, this looks fine, and works for me: Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Andre Przywara <andre.przywara@arm.com> Cheers, Andre > --- > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > index fe77178d3e33..90a50910f07b 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > @@ -65,6 +65,25 @@ &ehci1 { > status = "okay"; > }; > > +&emac0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&rmii0_pins>; > + phy-handle = <&rmii_phy>; > + phy-mode = "rmii"; > + status = "okay"; > +}; > + > +&mdio0 { > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > + reset-delay-us = <2000>; > + reset-post-delay-us = <2000>; > + > + rmii_phy: ethernet-phy@1 { > + compatible = "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > +}; > + > &mmc0 { > vmmc-supply = <®_dcdc1>; > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
Hi Andre, Le Tue 08 Jul 25, 00:34, Andre Przywara a écrit : > On Mon, 7 Jul 2025 18:51:55 +0200 > Paul Kocialkowski <paulk@sys-base.io> wrote: > > Hi Paul, > > > The Liontron H-A133L board features an Ethernet controller with a > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > > > Note that the reset pin must be handled as a bus-wide reset GPIO in > > order to let the MDIO core properly reset it before trying to read > > its identification registers. There's no other device on the MDIO bus. > > putting the PHY reset GPIO into the MDIO node is a clever solution, I > was struggling with putting it either in the MAC or PHY node, though > conceptually it would still belong in the latter, I think. But this > might be a more generic problem: for most other devices we activate > reset and clock gates *before* trying to access them, though this might > be historically different for Ethernet PHYs. Yes this feels a bit unusual. Unfortunately the mdio bus performs probing on the PHYs before registering them as devices, which gives us no hope of running driver-specific code to power the PHY up. So the only device we can hold on to is the mdio bus. I think there was an initial design assumption that 1 mdio bus == 1 PHY device > > The datasheet of the PHY mentions that the reset signal must be held > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > > be on the safe side without wasting too much time during boot. > > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> > > Despite the above, this looks fine, and works for me: > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > Tested-by: Andre Przywara <andre.przywara@arm.com> Thanks for the review and test! Paul > Cheers, > Andre > > > --- > > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > index fe77178d3e33..90a50910f07b 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > @@ -65,6 +65,25 @@ &ehci1 { > > status = "okay"; > > }; > > > > +&emac0 { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&rmii0_pins>; > > + phy-handle = <&rmii_phy>; > > + phy-mode = "rmii"; > > + status = "okay"; > > +}; > > + > > +&mdio0 { > > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > > + reset-delay-us = <2000>; > > + reset-post-delay-us = <2000>; > > + > > + rmii_phy: ethernet-phy@1 { > > + compatible = "ethernet-phy-ieee802.3-c22"; > > + reg = <1>; > > + }; > > +}; > > + > > &mmc0 { > > vmmc-supply = <®_dcdc1>; > > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ > -- Paul Kocialkowski, Independent contractor - sys-base - https://www.sys-base.io/ Free software developer - https://www.paulk.fr/ Expert in multimedia, graphics and embedded hardware support with Linux.
On Tue, Jul 8, 2025 at 7:36 AM Andre Przywara <andre.przywara@arm.com> wrote: > > On Mon, 7 Jul 2025 18:51:55 +0200 > Paul Kocialkowski <paulk@sys-base.io> wrote: > > Hi Paul, > > > The Liontron H-A133L board features an Ethernet controller with a > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > > > Note that the reset pin must be handled as a bus-wide reset GPIO in > > order to let the MDIO core properly reset it before trying to read > > its identification registers. There's no other device on the MDIO bus. > > putting the PHY reset GPIO into the MDIO node is a clever solution, I > was struggling with putting it either in the MAC or PHY node, though > conceptually it would still belong in the latter, I think. But this > might be a more generic problem: for most other devices we activate > reset and clock gates *before* trying to access them, though this might > be historically different for Ethernet PHYs. The phylib core has code to deal with reset GPIOs listed under the PHY node. It might be worth checking why that doesn't work. OOTH, there's no code to deal with regulator supplies for PHYs. ChenYu > > The datasheet of the PHY mentions that the reset signal must be held > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > > be on the safe side without wasting too much time during boot. > > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> > > Despite the above, this looks fine, and works for me: > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > Tested-by: Andre Przywara <andre.przywara@arm.com> > > Cheers, > Andre > > > --- > > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > index fe77178d3e33..90a50910f07b 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > @@ -65,6 +65,25 @@ &ehci1 { > > status = "okay"; > > }; > > > > +&emac0 { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&rmii0_pins>; > > + phy-handle = <&rmii_phy>; > > + phy-mode = "rmii"; > > + status = "okay"; > > +}; > > + > > +&mdio0 { > > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > > + reset-delay-us = <2000>; > > + reset-post-delay-us = <2000>; > > + > > + rmii_phy: ethernet-phy@1 { > > + compatible = "ethernet-phy-ieee802.3-c22"; > > + reg = <1>; > > + }; > > +}; > > + > > &mmc0 { > > vmmc-supply = <®_dcdc1>; > > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ > >
Hi, Le Tue 08 Jul 25, 16:18, Chen-Yu Tsai a écrit : > On Tue, Jul 8, 2025 at 7:36 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > On Mon, 7 Jul 2025 18:51:55 +0200 > > Paul Kocialkowski <paulk@sys-base.io> wrote: > > > > Hi Paul, > > > > > The Liontron H-A133L board features an Ethernet controller with a > > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > > > > > Note that the reset pin must be handled as a bus-wide reset GPIO in > > > order to let the MDIO core properly reset it before trying to read > > > its identification registers. There's no other device on the MDIO bus. > > > > putting the PHY reset GPIO into the MDIO node is a clever solution, I > > was struggling with putting it either in the MAC or PHY node, though > > conceptually it would still belong in the latter, I think. But this > > might be a more generic problem: for most other devices we activate > > reset and clock gates *before* trying to access them, though this might > > be historically different for Ethernet PHYs. > > The phylib core has code to deal with reset GPIOs listed under the PHY node. > It might be worth checking why that doesn't work. While this code does exist, it's too early to be called when the mdio bus is trying to probe the phy. I was also surprised the existing reset gpio support in the phylib core didn't take effect (that's how I tried to implement it first) only to find that the code was never called. It's only called once the phy was probed and registered. Cheers, Paul > OOTH, there's no code to deal with regulator supplies for PHYs. > > ChenYu > > > > The datasheet of the PHY mentions that the reset signal must be held > > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > > > be on the safe side without wasting too much time during boot. > > > > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> > > > > Despite the above, this looks fine, and works for me: > > > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > > Tested-by: Andre Przywara <andre.przywara@arm.com> > > > > Cheers, > > Andre > > > > > --- > > > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > > > 1 file changed, 19 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > index fe77178d3e33..90a50910f07b 100644 > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > @@ -65,6 +65,25 @@ &ehci1 { > > > status = "okay"; > > > }; > > > > > > +&emac0 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&rmii0_pins>; > > > + phy-handle = <&rmii_phy>; > > > + phy-mode = "rmii"; > > > + status = "okay"; > > > +}; > > > + > > > +&mdio0 { > > > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > > > + reset-delay-us = <2000>; > > > + reset-post-delay-us = <2000>; > > > + > > > + rmii_phy: ethernet-phy@1 { > > > + compatible = "ethernet-phy-ieee802.3-c22"; > > > + reg = <1>; > > > + }; > > > +}; > > > + > > > &mmc0 { > > > vmmc-supply = <®_dcdc1>; > > > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ > > > > -- Paul Kocialkowski, Independent contractor - sys-base - https://www.sys-base.io/ Free software developer - https://www.paulk.fr/ Expert in multimedia, graphics and embedded hardware support with Linux.
On Tue, Jul 8, 2025 at 9:22 PM Paul Kocialkowski <paulk@sys-base.io> wrote: > > Hi, > > Le Tue 08 Jul 25, 16:18, Chen-Yu Tsai a écrit : > > On Tue, Jul 8, 2025 at 7:36 AM Andre Przywara <andre.przywara@arm.com> wrote: > > > > > > On Mon, 7 Jul 2025 18:51:55 +0200 > > > Paul Kocialkowski <paulk@sys-base.io> wrote: > > > > > > Hi Paul, > > > > > > > The Liontron H-A133L board features an Ethernet controller with a > > > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > > > > > > > Note that the reset pin must be handled as a bus-wide reset GPIO in > > > > order to let the MDIO core properly reset it before trying to read > > > > its identification registers. There's no other device on the MDIO bus. > > > > > > putting the PHY reset GPIO into the MDIO node is a clever solution, I > > > was struggling with putting it either in the MAC or PHY node, though > > > conceptually it would still belong in the latter, I think. But this > > > might be a more generic problem: for most other devices we activate > > > reset and clock gates *before* trying to access them, though this might > > > be historically different for Ethernet PHYs. > > > > The phylib core has code to deal with reset GPIOs listed under the PHY node. > > It might be worth checking why that doesn't work. > > While this code does exist, it's too early to be called when the mdio bus is > trying to probe the phy. I was also surprised the existing reset gpio support > in the phylib core didn't take effect (that's how I tried to implement it first) > only to find that the code was never called. It's only called once the phy was > probed and registered. OK, that's definitely weird. The code looked like it just walked the DT and registered PHY devices, upon which the GPIO lines would be found and toggled. ChenYu > Cheers, > > Paul > > > OOTH, there's no code to deal with regulator supplies for PHYs. > > > > ChenYu > > > > > > The datasheet of the PHY mentions that the reset signal must be held > > > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > > > > be on the safe side without wasting too much time during boot. > > > > > > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> > > > > > > Despite the above, this looks fine, and works for me: > > > > > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > > > Tested-by: Andre Przywara <andre.przywara@arm.com> > > > > > > Cheers, > > > Andre > > > > > > > --- > > > > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > > > > 1 file changed, 19 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > > index fe77178d3e33..90a50910f07b 100644 > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > > @@ -65,6 +65,25 @@ &ehci1 { > > > > status = "okay"; > > > > }; > > > > > > > > +&emac0 { > > > > + pinctrl-names = "default"; > > > > + pinctrl-0 = <&rmii0_pins>; > > > > + phy-handle = <&rmii_phy>; > > > > + phy-mode = "rmii"; > > > > + status = "okay"; > > > > +}; > > > > + > > > > +&mdio0 { > > > > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > > > > + reset-delay-us = <2000>; > > > > + reset-post-delay-us = <2000>; > > > > + > > > > + rmii_phy: ethernet-phy@1 { > > > > + compatible = "ethernet-phy-ieee802.3-c22"; > > > > + reg = <1>; > > > > + }; > > > > +}; > > > > + > > > > &mmc0 { > > > > vmmc-supply = <®_dcdc1>; > > > > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ > > > > > > > > -- > Paul Kocialkowski, > > Independent contractor - sys-base - https://www.sys-base.io/ > Free software developer - https://www.paulk.fr/ > > Expert in multimedia, graphics and embedded hardware support with Linux.
On Tue, 8 Jul 2025 00:34:25 +0100 Andre Przywara <andre.przywara@arm.com> wrote: Hi Paul, forgot to mention: can you please add an ethernet0 alias, to make U-Boot generate a MAC address, from the SID? Cheers, Andre > On Mon, 7 Jul 2025 18:51:55 +0200 > Paul Kocialkowski <paulk@sys-base.io> wrote: > > Hi Paul, > > > The Liontron H-A133L board features an Ethernet controller with a > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > > > Note that the reset pin must be handled as a bus-wide reset GPIO in > > order to let the MDIO core properly reset it before trying to read > > its identification registers. There's no other device on the MDIO bus. > > putting the PHY reset GPIO into the MDIO node is a clever solution, I > was struggling with putting it either in the MAC or PHY node, though > conceptually it would still belong in the latter, I think. But this > might be a more generic problem: for most other devices we activate > reset and clock gates *before* trying to access them, though this might > be historically different for Ethernet PHYs. > > > The datasheet of the PHY mentions that the reset signal must be held > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > > be on the safe side without wasting too much time during boot. > > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> > > Despite the above, this looks fine, and works for me: > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > Tested-by: Andre Przywara <andre.przywara@arm.com> > > Cheers, > Andre > > > --- > > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > index fe77178d3e33..90a50910f07b 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > @@ -65,6 +65,25 @@ &ehci1 { > > status = "okay"; > > }; > > > > +&emac0 { > > + pinctrl-names = "default"; > > + pinctrl-0 = <&rmii0_pins>; > > + phy-handle = <&rmii_phy>; > > + phy-mode = "rmii"; > > + status = "okay"; > > +}; > > + > > +&mdio0 { > > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > > + reset-delay-us = <2000>; > > + reset-post-delay-us = <2000>; > > + > > + rmii_phy: ethernet-phy@1 { > > + compatible = "ethernet-phy-ieee802.3-c22"; > > + reg = <1>; > > + }; > > +}; > > + > > &mmc0 { > > vmmc-supply = <®_dcdc1>; > > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ >
Hi Andre, Le Tue 08 Jul 25, 00:48, Andre Przywara a écrit : > On Tue, 8 Jul 2025 00:34:25 +0100 > Andre Przywara <andre.przywara@arm.com> wrote: > > Hi Paul, > > forgot to mention: can you please add an ethernet0 alias, to make > U-Boot generate a MAC address, from the SID? Ah yes, sorry I forgot to do that. Will respin the series then. Cheers, Paul > Cheers, > Andre > > > On Mon, 7 Jul 2025 18:51:55 +0200 > > Paul Kocialkowski <paulk@sys-base.io> wrote: > > > > Hi Paul, > > > > > The Liontron H-A133L board features an Ethernet controller with a > > > JLSemi JL1101 PHY. Its reset pin is tied to the PH12 GPIO. > > > > > > Note that the reset pin must be handled as a bus-wide reset GPIO in > > > order to let the MDIO core properly reset it before trying to read > > > its identification registers. There's no other device on the MDIO bus. > > > > putting the PHY reset GPIO into the MDIO node is a clever solution, I > > was struggling with putting it either in the MAC or PHY node, though > > conceptually it would still belong in the latter, I think. But this > > might be a more generic problem: for most other devices we activate > > reset and clock gates *before* trying to access them, though this might > > be historically different for Ethernet PHYs. > > > > > The datasheet of the PHY mentions that the reset signal must be held > > > for 1 ms to take effect. Make it 2 ms (and the same for post-delay) to > > > be on the safe side without wasting too much time during boot. > > > > > > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> > > > > Despite the above, this looks fine, and works for me: > > > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > > Tested-by: Andre Przywara <andre.przywara@arm.com> > > > > Cheers, > > Andre > > > > > --- > > > .../sun50i-a133-liontron-h-a133l.dts | 19 +++++++++++++++++++ > > > 1 file changed, 19 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > index fe77178d3e33..90a50910f07b 100644 > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a133-liontron-h-a133l.dts > > > @@ -65,6 +65,25 @@ &ehci1 { > > > status = "okay"; > > > }; > > > > > > +&emac0 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&rmii0_pins>; > > > + phy-handle = <&rmii_phy>; > > > + phy-mode = "rmii"; > > > + status = "okay"; > > > +}; > > > + > > > +&mdio0 { > > > + reset-gpios = <&pio 7 12 GPIO_ACTIVE_LOW>; /* PH12 */ > > > + reset-delay-us = <2000>; > > > + reset-post-delay-us = <2000>; > > > + > > > + rmii_phy: ethernet-phy@1 { > > > + compatible = "ethernet-phy-ieee802.3-c22"; > > > + reg = <1>; > > > + }; > > > +}; > > > + > > > &mmc0 { > > > vmmc-supply = <®_dcdc1>; > > > cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ > > > -- Paul Kocialkowski, Independent contractor - sys-base - https://www.sys-base.io/ Free software developer - https://www.paulk.fr/ Expert in multimedia, graphics and embedded hardware support with Linux.
© 2016 - 2025 Red Hat, Inc.