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

[Nicolai Buchwitz <nb@tipi-net.de>]

Hi James

On 12.10.2026 02:54, James Clark wrote:

> [...]

> Sashiko wanted write_sts limited to BCM2711 because the 63.5 to 64.5
> window has only been measured on BCM2711 and we don't have evidence
> that it applies elsewhere. If it doesn't, then we could potentially
> violate what PTP_SYS_OFFSET_EXTENDED promises. I think one could argue
> that this is too conservative: clause 22 specifies 64 bits and the
> 63.5 to 64.5 range falls out of that given a free-running MDC and some
> other reasonable assumptions. Andrew made a similar point on 4/5
> (https://lore.kernel.org/netdev/c136b0ad-6d7e-4695-b988-55eb37550d01@lunn.ch/).
> Florian said he wanted a compatible string but I am not sure whether
> because of this or because of the clock. In any case, I am happy to do
> it whichever way you and Florian decide.

I'd drop the compatible. Gating on a clock on the mdio node is BCM2711
only in-tree anyway, and as Andrew said on 4/5, 64 bits is clause 22.
Florian can still shout when he confirms the clock name :)

> In the probe, I believe I still need to add a call to
> devm_clk_get_optional() in the pdata branch, which is used when GENET
> creates the UniMAC device. At the moment this branch does priv->clk =
> pdata->clk, so it would not pick up the new GISB clock from the mdio
> node. I think this new clock would live alongside the existing
> pdata->clk: the write_sts rate would come from the mdio node clock,
> but pdata->clk would be used for gating. I was not planning for this
> series to make clk_set use the new GISB clock.

Fine, I can do that as a follow-up together with Andrew's 2.5 MHz
default once the clock is in.

> [...]

Thanks,
Nicolai