Re: [PATCH net-next 5/5] net: mdio: bcm-unimac: implement timestamped MDIO writes

[Florian Fainelli <florian.fainelli@broadcom.com>]

On 10/9/26 07:35, 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 start, then add the time
> from the command start until the MDC edge that clocks the last data
> bit, calculated from the reference clock rate and the configured MDC
> divider.
> 
> On BCM2711 that edge comes 64 MDC periods after the command start, on
> average. This was measured on a Raspberry Pi CM4 with its BCM54210PE
> PHY. The PHY's PHC was read with PTP_SYS_OFFSET_EXTENDED while the MDC
> divider was switched between 9 and 39 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 64 periods was under 10 ns.
> The MDC divider appears to run freely: the PHC offsets spread evenly
> over one MDC period at each divider. So use 63.5 and 64.5 periods as
> the lower and upper bounds of the delay.
> 
> Use a 200 MHz reference rate for BCM2711 GENET, whose clock is not
> described in DT.
> 
> Signed-off-by: James Clark <jjc@jclark.com>
> Assisted-by: LLM
> ---
> When there is no clock, unimac_mdio_clk_set() assumes a 250 MHz
> reference rate, and no in-tree DT gives GENET or UniMAC a clock. For
> BCM2711 I have no documentation of the reference rate or of the clock
> that supplies it, but MDIO busy times measured at several MDC dividers
> fit a rate of 200 MHz. This patch checks the parent's compatible string,
> which is unsatisfactory. I would prefer to get the rate from DT, and
> would welcome suggestions for the right DT description.

You can, and should define a chip-specific compatible string for the 
MDIO contorller node. We have one for 2711 already for GENET 
(brcm,bcm2711-genet-v5), so you could define brcm,bcm2711-genet-mdio-v5

The clock frequency is fixed, so you could also provide a fixed clock to 
ensure that the clock frequency is derived correctly. I will check the 
actual clocking because 200MHz sounds odd to me, since the RGMII 
interface does require 125MHz and therefore a 250MHz source makes that easy.
-- 
Florian