Re: [PATCH net-next 4/5] net: macb: implement timestamped MDIO writes

[Andrew Lunn]

On Sun, Oct 11, 2026 at 11:23:54AM +0200, Théo Lebrun wrote:
> Hello James,
> 
> On Fri Oct 9, 2026 at 4:35 PM CEST, James Clark wrote:
> > Implement write_sts to provide system timestamp bounds for completion
> > of an MDIO write. This enables tighter system timestamp bounds in PHY
> > implementations of gettimex64.
> >
> > Take system timestamps around the command register write, then add
> > the time from the command write until the MDC edge that clocks the
> > last data bit, calculated from the peripheral clock rate and the
> > configured MDC divider.
> >
> > On RP1 that edge comes 63.5 MDC periods after the command write. This
> > was measured on a Raspberry Pi CM5 with its BCM54210PE PHY. The PHY's
> > PHC was read with PTP_SYS_OFFSET_EXTENDED while the MDC divisor was
> > switched between 48 and 128 through /dev/mem. Any error in the number
> > of periods would make the PHC offset jump at each switch. After
> > compensating for drift, the jump with 63.5 periods was under 2 ns.
> > The MDC divider does not appear to run freely: the spread of the PHC
> > offsets did not change with the divisor.
> >
> > Signed-off-by: James Clark <jjc@xxxxxxxxxx>
> > Assisted-by: LLM
> > ---
> > The 63.5-period delay has been measured only on RP1, but the code
> > assumes it holds for all MACB and GEM variants. I am not sure whether
> > that is a reasonable assumption; if not, write_sts could be enabled
> > only for RP1.
> 
> I'm invoking my colleague @Maxime to get his opinion. What impacts the
> MDIO write_c22 duration and how likely is it that this duration varies
> (1) on the same MAC+PHY combo, (2) with a different PHY or (3) with a
> different MACB revision?

Putting the bits onto the bus should be a fixed time. It is just a big
shift register, which is clocked at bus speed. There is no clock
stretching, no ACK from the PHY, etc.

What will introduce jitter is everything before the write hits the
register. There are mutex which can be contended, because of other
users on the bus, etc.

> Sashiko makes an interesting point with PCLK that might change over
> time, giving an example (which I've not checked) where it would be
> derived from the CPU clk which might change with cpufreq.

Care would have to be taken here. IEEE 802.3 specifies the maximum bus
speed is 2.5Mhz. I hope cpufreq can only make the clock slower, not
faster, otherwise the MDIO bus is breaking the standard.

> I'm wondering if we could do better than a hardcoded delay? For example
> we could busy-wait for NSR.IDLE inside the prets/postts region, but
> that implies at least 25µs with IRQs disabled. Or we could do a few
> measurements at init to sample our platform delay?

> It doesn't solve the PCLK changing issue, but it solves the hardcoded
> 63.5 value.

Each C22 MDIO bus transaction is 64 bits. It is defined in the
standard. So hard coding this value is fine. But it should be made
generic, it should be the same for all implementations, all that
changes is the bus speed.

	Andrew