On Thu, May 28, 2020 at 06:54:24PM +0200, Petr Machata wrote: > > Andrew Lunn <and...@lunn.ch> writes: > > >> Andrew, pardon my ignorance in these matters, can a PHY driver in > >> general determine that the issue is with the cable, even without running > >> the fairly expensive cable test? > > > > No. To diagnose a problem, you need the link to be idle. If the link > > peer is sending frames, they interfere with TDR. So all the cable > > testing i've seen first manipulates the auto-negotiation to make the > > link peer go quiet. That takes 1 1/2 seconds. There are some > > optimizations possible, e.g. if the cable is so broken it never > > establishes link, you can skip this. But Ethernet tends to be robust, > > it drops back to 100Mbps only using two pairs if one of the four pairs > > is broken, for example. > > OK, thanks. I suspect our FW is doing this behind the scenes, because it > can report a shorted cable. > > In another e-mail you suggested this: > > Link detected: no (cable issue) > > But if the link just silently falls back to 100Mbps, there would never > be an opportunity for phy to actually report a down reason. So there > probably is no way for the phy layer to make use of this particular > down reason.
It is called downshift. And we have support for it in the phylib core, if the PHY has the needed vendor register. https://elixir.bootlin.com/linux/v5.7-rc7/source/drivers/net/phy/phy-core.c#L341 https://elixir.bootlin.com/linux/v5.7-rc7/source/drivers/net/phy/phy.c#L95 There are also standard phylib/ethtool ways to configure it, how many times the PHY should try to establish a 1G link before downshifting to 100M. So in theory we could report: Link detected: yes (downshifted) Assuming your proposed API support a reason why it is up, not just a reason why it is down? Andrew
