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

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

On Thu, 08 Oct 2026 16:03:44 +0000 netdev-bot+sashiko@kernel.org wrote:
> Suppose BMSR shows link up and autoneg complete before
> AT803X_SS_SPEED_DUPLEX_RESOLVED is set in AT803X_SPECIFIC_STATUS. What ends
> up in phydev->speed and phydev->duplex in that case?

Both points are valid. Thanks.

In that case v3 reports the link up with SPEED_UNKNOWN, and the early
return in genphy_read_status() keeps it that way until the link
drops. The reserved speed value ends up the same way. I don't know
whether QCA8337 can report link up before the resolved bit is set,
but the driver should not depend on that.

v4 follows marvell_read_status_page_an(): if speed or duplex is still
unknown after at803x_read_specific_status(), it reports the link as
down. This driver has no interrupt support, so phylib polls the PHY
and reads the status again on the next poll. The qca808x approach does
not fit here. The value it falls back to is the advertisement-derived
speed this patch replaces, so after a downshift it would keep
1000 Mbit/s.

> Should mdix also be reset to ETH_TP_MDI_INVALID when the resolved status is
> not read?

Yes. v4 sets mdix to ETH_TP_MDI_INVALID on every poll except during
a steady autonegotiated link and reads it again only at link-up. That
covers both a link drop and autonegotiation being disabled.

at803x_read_status(), used by the other AT803x PHYs, clears speed and
duplex the same way before it calls the helper. I have not changed it
in this patch.

The model test now covers both cases, and v3 fails them. v4 has not
been tested on hardware. I will send it separately.

Thanks,
Yongzhao Chen

pw-bot: cr