Re: [PATCH net v3] net: phy: qcom: at803x: Apply IPQ5018 analog settings at probe

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

On Sat, 03 Oct 2026 21:21:08 +0000 netdev-bot+sashiko@kernel.org wrote:
> Is the GE PHY ready for these debug and MMD register accesses this soon
> after the reset?

[ ... ]

> The patch notes already ask whether a minimum delay or a readiness check
> is needed after ARES is deasserted. Would it make sense to add one after
> reset_control_reset() and before ipq5018_analog_init()?

I have found no basis for a delay after ARES, and the measurements on
the tested board show no sign that one is needed.

I have no data sheet figure for the time after GCC_GEPHY_MISC_ARES is
deasserted, and the GCC entry sets no udelay. The vendor SDK waits
200 ms after each assert and deassert, but it applies the same wait to
every Ethernet block reset (GE PHY, UNIPHY, both GMACs) in one loop.

On a Redmi AX5400, I logged six warm boots at register level. Every
access after the reset returned without error, and none read as
0xffff. In the three boots with the probe-time writes, the EEE, MSE
and DAC writes read back as written, the MDAC/EDAC values were still
in place before attach, and the PHY-to-PHY link came up at 1 Gb/s at
about 5 s. In the three boots without them, both PHYs downshifted at
about 15-17 s and the link stayed down. One write is an exception: the
LDO_EFUSE field at debug register 0x1 read back 0x8031 instead of
0x8052. The vendor SDK uses register 0x180 for that setting, and which
address is correct is still open.

The remaining gap is ANA_DAC_FILTER. Its read right after the reset
returned 0x0000 in all six boots. I have no later read without an
earlier write to compare it with, so a transient value remains
possible. The existing config_init() path makes the same read with no
settle guarantee either; how long after the reset it runs depends only
on when the MAC attaches the PHY.

George, or anyone with IPQ5018 boards: do you have empirical data
showing that the GE PHY needs time after ARES before these accesses?
If so, I will add a wait based on it.

Thanks,
Yongzhao Chen