Re: Broken ethernet on SolidRun cubox-i

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

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

On Sun, Dec 27, 2020 at 04:11:14PM +0000, Russell King - ARM Linux admin wrote:
> On Sun, Dec 27, 2020 at 04:59:39PM +0100, Michael Walle wrote:
> > Am 2020-12-27 16:33, schrieb Michael Walle:
> > > Am 2020-12-26 13:34, schrieb Russell King - ARM Linux admin:
> > > > I'd forgotten that there were boards out there with this problem...
> > > > the PHY address configuration is done via the LED_ACT pin, and
> > > > SolidRun
> > > > omitted a pull resistor on it, so it "floats" with the leakage current
> > > > of the LED/pin - resulting in it sometimes appearing at address 0 and
> > > > sometimes at address 4.
> > > 
> > > Mh, I've guessed that too, but there must be more to it. The datasheet
> > > says it has an internal weak pull-up. Or Atheros messed up and it
> > > doesn't
> > > reliably work if there is actually an LED attached to it. But then, why
> > > would any other stronger pull-up/down work..
> > 
> > Mhh, nevermind, from the commit log [1].
> > 
> >   "The LED_ACT pin on the carrier-one boards had a pull down that
> >   forces the phy address to 0x0; where on CuBox-i and the production
> >   HummingBoard that pin is connected directly to LED that depending
> >   on the pull down strength of the LED it might be sampled as '0' or '1'
> > thus
> >   the phy address might appear as either address 0x0 or 0x4."
> > 
> > So it actually depends on the forward voltage of the LED and the
> > hi/low thresholds of the AT8035.. nice! Oh and btw. this pin also
> > switches between high and low-active LED output. So the missing
> > pull-down might not only switch the PHY address to 4 but also invert
> > the LED state.
> 
> Indeed. And whether it appears at address 0 or 4 will depend on many
> factors, including temperature - LEDs have a decrease of 2mV/°C.
> 
> I wonder if we can just delete the phy-handle property, and list a
> PHY at both address 0 and 4 with the appropriate configuration...

Michael, can you try the attached patch please?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[-- Attachment #2: sr-som.diff --]
[-- Type: text/x-diff, Size: 717 bytes --]

diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
index b06577808ff4..3db08363d3fb 100644
--- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
@@ -53,7 +53,6 @@
 &fec {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_microsom_enet_ar8035>;
-	phy-handle = <&phy>;
 	phy-mode = "rgmii-id";
 	phy-reset-duration = <2>;
 	phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
@@ -63,10 +62,15 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		phy: ethernet-phy@0 {
+		ethernet-phy@0 {
 			reg = <0>;
 			qca,clk-out-frequency = <125000000>;
 		};
+
+		ethernet-phy@4 {
+			reg = <4>;
+			qca,clk-out-frequency = <125000000>;
+		};
 	};
 };
 

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel