Re: Broken ethernet on SolidRun cubox-i

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

On Fri, Jan 08, 2021 at 12:58:17PM +0100, Michael Walle wrote:
> Am 2021-01-08 12:53, schrieb Russell King - ARM Linux admin:
> > 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?
> 
> I don't have a cubox. But it's just a device tree patch. I could
> try to hack one based on Christophs dtb and he could just replace
> it on his sd card and test. Seems easy enough.

This sounds like a mess of indirection. What is "Christophs dtb"?
Why are there different dtbs out there for the same platform? If
there's changes necessary, why aren't they being submitted to the
mainline kernel?

In fact, why aren't users reporting these problems to mainline kernel
developers? Why do we have to have this tortuous bug reporting route
which makes testing fixes difficult?

This rather makes me not want to care about this.

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

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