Re: [RFC PATCH net-next v3 4/5] net: dsa: qca8k: flag QCA8337 internal CPU PHYs for SmartSpeed

[Yongzhao Chen]

Hi Andrew,

> But this is testing the wrong thing. This is testing downshift
> works. What you are actually interested in is downshift happening when
> it should not....
>
> So take a closer look at the user ports. phylib should report when a
> downshift occurs:

Thanks, that is a better test. I ran it on RA74 with the OpenWrt 6.18.52
backport that includes the read_status change, so phy_check_downshift()
sees the speed from 0x11. The user ports keep SmartSpeed at its hardware
default (enabled). The CPU PHY keeps the existing workaround, so
SmartSpeed stays disabled there.

Across 8 boots (1 after flashing, 4 warm reboots, 3 power cycles) and 10
"ethtool -r" on each of wan, lan1, lan2 and lan3, there was no
"Downshift occurred" message. CTRL1000 stayed at 0x0600 on all four user
PHYs, and each port came up at the speed its link partner supports. The
only unexpected event was one link drop on lan3 about 7 seconds after
its last renegotiation; it came back at 1 Gb/s after 3 seconds.

I also tried to recreate what the CPU link sees at boot, where the
IPQ5018 PHY does not advertise 1000BASE-T at first and adds it a few
seconds later. On lan1 I switched the PC NIC 30 times between
advertising only up to 100 Mb/s, with autonegotiation still enabled,
and full autonegotiation, then restarted it another 10 times. lan1
returned to 1 Gb/s every time. In 741 once-per-second samples CTRL1000
stayed at 0x0600 and 0x11 bit 5 was never set, and there was no
downshift warning.

So on this board I have not seen downshift misbehave on the user ports,
including when the link partner changes its advertisement in a similar
way. This is one board and a limited number of attempts, and the link
partner was a PC NIC rather than the IPQ5018 PHY. It also does not show
that downshift works on a bad cable, and the CPU link failure itself was
not exercised because SmartSpeed stays disabled on that PHY.

Disabling downshift for all qca83xx PHYs would also remove it from the
user ports, where I have not seen it misbehave. The CPU link has no
cable, only a fixed on-board connection, so disabling it there should
cost little. Given this, would you accept keeping the workaround limited
to the CPU link, or would you still prefer disabling it in the PHY
driver without a flag?

Thanks,
Yongzhao Chen