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

[Nicolai Buchwitz]

Hi James

On 11.10.2026 09:20, James Clark wrote:
> On Sat, Oct 10, 2026 at 10:18 PM Nicolai Buchwitz <nb@xxxxxxxxxxx> 
> wrote:
> > I dug a bit deeper on a CM4: AFAIU the MDC runs off the GISB clock,
> > which the firmware sets to 200 MHz (CPRMAN 0x1d8, PLLD_PER 750 MHz /
> > 3.75). Bumping that divider to 4.0 at runtime moves the MDIO busy time
> > by exactly the same ratio, so that's the one. The 250 MHz you have in
> > mind is genet250 / genet125, the RGMII side, a different generator.
> >
> > So instead of a fixed clock or a compatible match this could just be
> > BCM2711_CLOCK_GISB in clk-bcm2835 (critical, firmware owns it) and
> > clocks = <&clocks BCM2711_CLOCK_GISB> on the mdio node. I can send 
> > that
> > if it helps.

I've put together 3 patches, which do the clock plumbing:
https://github.com/nbuchwitz/linux/commits/devel/bcm2711-gisb-clk/

If we agree that this approach makes sense and Florian has verified that
my experimental findings match the actual implementation (+ naming), I
can send to the clk / stblinux people.

> Thank you very much for looking into this. I think this would solve
> the problem from my end.
>
> Let me just confirm how I would need to adapt my patch with that fix:
> in the pdata branch of the probe, I would call devm_clk_get_optional
> to find the clock on the mdio node, falling back to pdata->clk. I
> would still add the chip-specific compatible string because the number
> of MDC periods has only been measured on that specific hardware.

In the unimac patch you would only need clk_get_rate() and can gate
write_sts() on it. Not sure about pdata->clk though: bcmgenet passes
its "enet" MAC clock there, which isn't necessarily the MDC reference.
If write_sts() only trusts a clock on the mdio node itself, you don't
need the compatible either.

Cheers
Nicolai