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

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

Hi James

On 11.10.2026 09:20, James Clark wrote:
> On Sat, Oct 10, 2026 at 10:18 PM Nicolai Buchwitz <nb@tipi-net.de> 
> 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