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

[Paolo Abeni <pabeni@redhat.com>]

On 10/18/26 12:02, James Clark wrote:
> PTP_SYS_OFFSET_EXTENDED uses gettimex64 to bracket each PHC read with
> system clock reads. 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 leads to brackets in the tens of microseconds.
> Applications that synchronize the system clock from the PHC typically
> use the midpoint of the bracket as the system time of the PHC reading.
> With multiple transfers, the midpoint of the bracket is typically far
> from the time when the PHC reading actually occurred.
> 
> For example, using PTP_SYS_OFFSET_EXTENDED on the Raspberry Pi CM5 to
> synchronize the system clock from the BCM54210PE PHY PHC leads to the
> system clock being 32 µs ahead of the PHC. On the CM4, it is about 7 µs.
> (The difference is because the MDIO clock frequency is higher on the
> CM4: 10 MHz as opposed to 2.08 MHz on the CM5.) The brackets are about
> 74 µs on the CM5 and 42 µs on the CM4. In comparison, the MAC PHC
> on the CM5 has brackets of about 1 µs.
> 
> This series introduces a new MDIO operation, write_sts, that allows a
> PHY driver to ask the MDIO bus driver for system timestamps bounding
> the completion of a clause 22 MDIO write transfer. A bus driver
> computes them by shifting the timestamps taken around the start of the
> transfer by bounds on its duration, worked out from the MDC period and
> the length of the frame. The series:
> 
> - adds a timekeeping function to scale a CLOCK_MONOTONIC_RAW duration
>    by a clock's frequency;
> - adds ptp helpers that use it to shift system timestamps;
> - adds the operation to the MDIO core;
> - makes bcm-phy-ptp use the operation for the write that triggers the
>    capture of the PHC time, allowing 350 ns for the PHY to capture it;
> - implements the operation for macb, with tighter bounds on RP1, where
>    its timing has been measured;
> - implements it for UniMAC, when the mdio node has a clock giving the
>    MDC reference rate. On BCM2711 that is the GISB clock, which Nicolai
>    Buchwitz is adding to clk-bcm2835 [1]. Until then BCM2711 does not
>    get write_sts, and nothing changes.
> 
> The effect of this series is to reduce PTP_SYS_OFFSET_EXTENDED brackets
> from 74 µs to about 1.5 µs on the CM5, and from 42 µs to about 1.0 µs
> on the CM4. The synchronization error drops from 32 µs to about 0.1 µs
> on the CM5, and from 7 µs to about 60 ns on the CM4.
> 
> There was an earlier proposal addressing a similar problem, in 2019, for
> the PHC of mv88e6xxx switches [2]. 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 [3][4][5].
> 
> 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,
> which this series 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. 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. Third, the PHY driver gives a bound on the delay
> between the end of the transfer and the PHY acting on the write, which
> the MDIO core adds to the upper timestamp.
> 
> 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.
> 
> SPI introduced a similar facility to allow a device driver to obtain
> timestamp bounds from the bus controller in commit 79591b7db21d ("spi:
> Add a PTP system timestamp to the transfer structure").
> 
> This series implements the operation for only one PHY driver. But I
> surveyed other PHY drivers and identified at least two for which this
> operation could be implemented: micrel (specifically LAN8814) and
> dp83640, although they would need updating to use gettimex64 first.
> 
> The measurements come from the method described in patch 4/6, with
> ppsbias (https://github.com/jclark/ppsbias) timing the PPS on the GPIO.
> On the CM5 this is consistent with an independent check: with the MAC's
> PHC synchronized by PTP to an external grandmaster, and the system clock
> synchronized from it, the system clock and the PHY's PHC read with
> PTP_SYS_OFFSET_EXTENDED agree to within about 0.15 µs.
> 
> Changes in v2:
> - Improved measurement method (described in 4/6), which measures the
>    synchronization error more precisely
> - New timekeeping patch (1/6), so that the ptp helpers (2/6) scale the
>    shift by the selected clock's current frequency
> - Patches reordered: the ptp helpers (was 3/5) now come before the mdio
>    core (was 1/5), which uses them
> - mdio core (3/6): sts required, clause 22 stated, and frame-length
>    constants for the bus drivers (Andrew); an event delay added to the
>    upper bound; the wait and its 1 ms cap explained (Andrew)
> - bcm-phy-ptp (4/6): a 350 ns bound on the PHY's capture delay, found by
>    measurement
> - macb (5/6): wider bounds unless the MAC starts the frame with the
>    command write, as RP1 does; the MDC rate recorded when the divisor is
>    chosen (Théo)
> - UniMAC (6/6): the reference rate from a clock on the mdio node
>    (Florian, Nicolai); a suppressed preamble allowed (Andrew)
> - v1: https://lore.kernel.org/netdev/20261009143506.2507607-1-jjc@jclark.com/
> 
> [1] https://lore.kernel.org/netdev/41c32f5a6f38ec9df8a79ce896912fb9@tipi-net.de/
> [2] https://lore.kernel.org/all/20190805082642.12873-1-hubert.feurstein@vahle.at/
> [3] https://lore.kernel.org/r/20190816163157.25314-1-h.feurstein@gmail.com
> [4] https://lore.kernel.org/r/20190819172827.9550-1-hubert.feurstein@vahle.at
> [5] https://lore.kernel.org/r/20190820084833.6019-1-hubert.feurstein@vahle.at
We are wrapping-up the net-next PR for 7.4, and I would like an explicit
ack from subsystems and possibly from device maintainers, which are not coming
very soon.

Please repost after the merge window,

Thanks.

Paolo