Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: odroid-c1's awge0 on 9?



On Sat, Nov 02, 2019 at 12:55:16PM -0700, Jason Thorpe wrote:
> > On Nov 2, 2019, at 10:42 AM, Christoph Badura <bad%bsd.de@localhost> wrote:
> > Or maybe fix rgephy and back out the workarounds.  Jarend pointed out that
> > phy address 0 is a broadcast address on RTL8211[EF].
> 
> How is using the DT information to find the PHY a "workaround"?  It
> certainly seems like it would in fact be preferred.

Because it doesn't fix the underlying bug.

In all the cases (Andrew Cagney's odroid-c1, tih's rock64, my bananapi m1)
we saw rgephy attaching at id 0 and 1:

rgephy0 at awge0 phy 0: RTL8211F 1000BASE-T media interface
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
rgephy1 at awge0 phy 1: RTL8211F 1000BASE-T media interface
rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
awge0: interrupting on GIC irq 56

Per the RTL8211[EF] data sheets that googling turns up:

  The RTL8211E(...) support PHY addresses from 00001 to 00111. PHY address
  0 is a broadcast from the MAC; each PHY device should respond.

I.e. rgephy(4) should *not* attach phy address 0 when dwc_gmac_attach()
is passed MII_PHY_ANY as the phy_id and passes that down to mii_attach().

That's why tih's testing of the "workaround" failed because in the absence
of a phy selector in the DTS it returned MII_PHY_ANY.

I'll concede that using "workaround" wasn't the best choice without
explanation.  My thoughts at that time were that if rgephy(4) wasn't
attaching phy id in the first place we wouldn't have to "work around" that
problem by passing the correct phy id from the DTS.

Fixing rgephy would also have the benefit of people likely only needing to
update the kernel and not having to remember to update the DTB at the same
time.

Of course, I do see value in passing the phy id from the DTS in cases
where rgephy(4) can't determine the correct one automatically.  And that
the code for that should not be repeated over N drivers.

--chris


Home | Main Index | Thread Index | Old Index