Hi,
I have a board with a c22 phy (microchip lan8814) and a c45 phy
(intel/maxlinear gyp215) on one bus. If I understand it correctly, both
accesses should be able to coexist on one bus. But the microchip lan8814
actually has a bug and gets confused by c45 accesses. For example it
will
respond in the middle of another transaction with its own data if it
decodes it as a read. That is something we can see on a logic analyzer.
But we also see random register writes on the lan8814 (which you don't
see
on the logic analyzer obviously). Fortunately, the GPY215 supports
indirect
MMD access by the standard c22 registers. Thus as a workaround for the
problem, we could have a c22 only mdio bus.
The SoC I'm using is the LAN9668, which uses the mdio-mscc-mdio driver.
First problem there, it doesn't support C45 (yet) but also doesn't check
for MII_ADDR_C45 and happily reads/writes bogus registers.
I've looked at the mdio subsystem in linux, there is probe_capabilities
(MDIOBUS_C45 and friends) but the mxl-gpy.c is using c45 accesses
nevertheless. I'm not sure if this is a bug or not.
I was thinking of a fallback mechanism for the c45 read access like
in read_mmd. And even if the mdio controller is c45 capable, a PHY
might opt out. In my case, the lan8814.
What do you think?
-michael
On Mon, Mar 21, 2022 at 10:51:29PM +0100, Michael Walle wrote:
> Am 2022-03-21 21:21, schrieb Andrew Lunn:
> > On Mon, Mar 21, 2022 at 12:21:48PM +0100, Michael Walle wrote:
> > > The SoC I'm using is the LAN9668, which uses the mdio-mscc-mdio
> > > driver.
> > > First problem there, it doesn't support C45 (yet) but also doesn't
> > > check
> > > for MII_ADDR_C45 and happily reads/writes bogus registers.
> >
> > There are many drivers like that :-(
> >
> > Whenever a new driver is posted, it is one of the things i ask
> > for. But older drivers are missing such checks.
>
> Should that be a patch for net or net-next? One thing to consider;
> The gpy215 is probing just fine with a c22 only mdio driver which doesn't
> check for c45 accesses. It might read fishy registers during its probe,
> though. After adding the c45 check in the mdio drivers read and write
> it will fail to probe. So depending on the mdio driver it might went
> unnoticed that the phy_get_c45_ids() could fail.
>
> If it should go via net, then it should probably be accompanied
> by a patch to fix the gpy_probe() (i.e. ignoring -EOPNOTSUPP
> error).
I would suggest net-next first, so it gets some testing. We can then
add it to net later. We just need to keep an eye out for the automagic
bots which magically pick patches to backport. We don't want them to
pickup these patches too soon and only take part of the fix.
Andrew