Re: [PATCH net-next] net: phy: qca83xx: read resolved QCA8337 link status

[Yongzhao Chen <yongzhao.derek@gmail.com>]

Hi Andrew,

> If there is no link, genphy_read_status() will of already set these to
> _UNKNOWN etc. There is no need to clear them.

Right, thanks. In the next revision I have replaced the custom decoding
and state clearing with at803x_read_status(), followed by
genphy_read_master_slave() to keep the master/slave reporting from the
generic path.

> Can this really happen? BCMR says there is link, but this says there
> is no link? What does the data sheet say? It seems unlikely to me.

I have not observed it on hardware. The QCA8337 datasheet (80-Y0619-3
Rev. D, p. 328) describes the resolved bit and the speed/duplex fields
in register 0x11, and says speed/duplex are valid after autonegotiation
completes. I could not find anything there about the ordering of that
bit and the BMSR link status across separate reads. The unresolved case
in my test was synthetic input, not a state captured on hardware.

In that synthetic sequence, at803x_read_status() reports link up with
SPEED_UNKNOWN. If BMSR stays up when 0x11 later resolves, the speed
remains SPEED_UNKNOWN until the next link transition. So switching to
the helper does not by itself answer whether this state can occur on
real hardware. Is there a QCA8337-specific rule about when register 0x11
is updated relative to BMSR that I should check before deciding whether
this needs separate handling?

Separately, I have not yet reproduced on hardware the case this patch
targets, a QCA8337-side SmartSpeed downshift where the old code reports
the wrong speed; so far that difference is only shown by the model test.
With a two-pair cable, the link partner advertised gigabit and then
withdrew it, and the link came up at 100 Mb/s without the QCA8337
downshift status set.

If you know of a link partner or setup that reliably makes the QCA8337
side downshift, I would be glad to test with it.

Thanks,
Yongzhao Chen