Re: [PATCH net-next 0/5] net: mdio: add timestamped MDIO writes for PHY gettimex64

[James Clark]

On Fri, Oct 9, 2026 at 9:35 PM James Clark <jjc@xxxxxxxxxx> wrote:

>  Some PHYs have a PTP hardware clock (PHC) that is
> read over MDIO and sometimes multiple MDIO transfers are needed to read
> the clock.
...
> This series introduces a new MDIO operation that allows PHY drivers to
> ask MDIO bus drivers to compute a bracket for the completion of an MDIO
> write transfer.

I have just become aware of an earlier discussion of a similar
problem, in 2019, about the PHC of mv88e6xxx switches:

https://lore.kernel.org/all/20190805082642.12873-1-hubert.feurstein@xxxxxxxx/

In the relevant respects the situation is the same as with the BCM
PHY: the PHC is read over MDIO with several transfers, and one write
fixes the moment at which the clock is sampled. Richard and Andrew
suggested taking the system timestamps in the MDIO bus driver, around
that write, and Hubert Feurstein posted a series implementing this:

v1: https://lore.kernel.org/r/20190816163157.25314-1-h.feurstein@xxxxxxxxx
v2: https://lore.kernel.org/r/20190819172827.9550-1-hubert.feurstein@xxxxxxxx
v3: https://lore.kernel.org/r/20190820084833.6019-1-hubert.feurstein@xxxxxxxx

Like Hubert's v2 and v3, this series shifts the timestamps to allow
for the time the transfer takes. The discussion of that raised some
points, two of which this series already addresses. First, the meaning
of the timestamps returned by the MDIO core operation is clear: they
bound the end of the MDIO write transfer. Second, the bus driver uses
a lower and an upper bound on the transfer time, including the
preamble, which have been measured on hardware. The lower and upper
timestamps taken around the start of the transfer are shifted
separately, so that the returned bounds are guaranteed to contain the
end of the transfer.

The third point is the delay between the end of the transfer and the
device acting on the write, which I raised in the notes to patch 2. I
am making end-to-end measurements to establish a bound for this delay,
and I plan that in v2, in the absence of definitive data from
Broadcom, the PHY driver will shift post_ts by that bound.

This series also differs in having a write_sts operation, rather than
an sts pointer in struct mii_bus. This allows the bus driver to
compute the transfer time bounds at each call, from the same divider
and clock rate that it uses to set the MDC speed. Unlike Andrew's
suggestion, there is no fallback in the core, because a bus driver's
write may return before the transfer has completed.

The earlier discussion also raised interrupts arriving between the
timestamps and the write, and the latency of the posted write. In this
series, the bus drivers take the timestamps with local interrupts
disabled, and flush the posted write before taking the upper
timestamp.

James