Broken ethernet on SolidRun cubox-i

[Michael Walle]

Am 2021-01-08 13:01, schrieb Russell King - ARM Linux admin:
> 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.

Well first it was a suspected issue with 'my' change in the Atheros
PHY driver, which turned out to be not the case. I _voluntarily_
tried to debug the issue with a user (Christoph) just to find out
that it is likely caused by the commit mentioned above. So for
startes, why would I care? I just wanted to be kind and provide
some help. If anything, this shows me, I should rather stick to
my own problems.

So please advise Christoph, where he should report this bug.

-michael