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

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

Hi Andrew,

> The IPQ5018 PHY driver does have cable test support, have you tried it
> out?

Yes. I ran it seven times on the IPQ5018 PHY under OpenWrt 6.18.44
(NSS build). All four pairs reported OK each time. This was a working
link, so the result does not show what the QCA8337 sees during a failed
boot, or confirm or rule out insufficient attenuation.

I also ran an A/B test on the OpenWrt 6.18.52 backport, using identical
kernel and rootfs contents. Before the initial PHY software reset,
both paths read register 0x14 once and unconditionally wrote it once:
either the original value, or the value with SmartSpeed disabled.

Across six alternating warm boots on this board:

- Writing back 0x082c failed all three times. PHY4's CTRL1000 read
  0x0400, register 0x11 read 0x1030, and the CPU link did not come up.
- Writing 0x080c worked all three times. CTRL1000 read 0x0600 and the
  CPU link came up at 1 Gb/s.

The pre-reset value was 0x082c in every run; the two written values
therefore differed only in the SmartSpeed enable bit. Writing the
original value back did not avoid the failure, despite the same MDIO
access sequence. This strengthens the case for disabling SmartSpeed
on this link, but does not establish the electrical cause.

I'm open to selecting the workaround through DT, so that it is enabled
only on boards known to need it. What I can document at this point is
the PHY-to-PHY connection, the reproducible boot failure and the effect
of disabling SmartSpeed. I have not established whether the cause is
the board's electrical design or something else.

Would that be sufficient justification for a DT property, with the
underlying cause left open in the commit message? If so, would you
prefer a generic PHY property to disable downshift, or a
Qualcomm-specific property for this workaround?

Thanks,
Yongzhao Chen