Re: [RFC PATCH net-next v2 5/5] net: phy: qca83xx: disable SmartSpeed before resetting CPU PHYs

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

Hi Andrew,

I agree that if downshift is broken more generally, disabling it in the
PHY driver, possibly with a default-off tunable, would avoid the need
for this flag. I have not established that. I ran into this on my own
home router and don't have a way to force a downshift, such as a
two-pair cable, so I have not tested user ports. If anyone with
QCA8337 hardware can try a user port with a two-pair cable, that would
answer the general question. Disabling it in qca83xx without a flag
would also remove downshift from user ports, where I have no evidence
that it misbehaves.

On how it differs from other PHYs: in the failing state there was no
link at any layer. BMSR read 0x7949 with link and AN-complete clear,
0x11 was 0x1030 with resolved and link clear, and the conduit had no
carrier. So I have not observed a downshifted link, only the 1000BASE-T
advertisement in CTRL1000 being cleared by a path I have not
identified. The 0x11 value does have bit 5 set, which the QCA8337N
datasheet I have describes as downgrade, but bit 4, documented as
reserved/always 0, is also set, so I am not relying on that decoding.

For the next RFC I would keep the flag, limited to QCA8337 internal CPU
ports. qca8k knows the switch model and port role, qca83xx owns the
registers and reset/resume, and get_phy_flags() delivers the
requirement before the first reset without the PHY driver inspecting
DSA topology. phydev->is_internal also covers user ports. The
workaround has only been tested on CPU PHY4 on RA74, and that result
does not by itself show that a flag is the right selection mechanism.

I have not found a verified erratum for this revision, and as a home
user I do not have a Qualcomm support channel, so I have added Jie Luo,
who has worked on the Qualcomm PHY drivers, to Cc.

Jie, could you forward this to someone at Qualcomm who can check
whether there is a SmartSpeed erratum for the QCA8337 internal PHYs?
If you have seen SmartSpeed problems on an internal PHY used as a CPU
link, or have a recommended way to handle it, that would also help.

Christian, as the qca8k maintainer, have you seen SmartSpeed cause
link problems on QCA8337 PHYs, either on CPU links or on user ports?
That would help answer whether this is specific to the CPU link.

Would you consider this CPU-link scope and get_phy_flags() approach
reasonable for the next RFC, or suggest a different way to select the
workaround?

Thanks,
Yongzhao Chen