Re: [PATCH net-next 0/3] net: stmmac: dwmac-rk: add RK3576 GMAC 25M refout support

Hi Maxime,

On Mon, Jul 27, 2026 at 11:11 AM Maxime Chevallier
<[email protected]> wrote:
>
> Hi,
>
> On 7/27/26 04:10, Gavin Gao wrote:
> > Hi,
> >
> > Some Rockchip GMAC instances can provide a 25 MHz reference clock output
> > for an external RGMII PHY. Boards already describe the MAC clock direction
> > with clock_in_out = "output", but the dwmac-rk driver does not currently
> > request or enable the corresponding 25 MHz reference output clock.
> >
> > On RK3576, this means the REFCLKO25M_GMACx_OUT clock may be disabled by
> > the common clock framework as unused, even though the board expects the
> > GMAC block to provide the PHY reference clock.
> >
> > This series adds an optional "clk_mac_25m_refout" clock name to the
> > Rockchip DWMAC binding, wires it up for RK3576 GMAC0/GMAC1, and enables
> > it from the dwmac-rk driver when the MAC is configured for RGMII output
> > clock mode.
> >
> > The clock remains optional, so existing device trees and SoCs are not
> > affected.
> >
> > Tested on a PicoCOM RK3576 ACP board with a Motorcomm YT8521 PHY.
> > The GMAC 25 MHz reference clock output remains active and Ethernet works.
>
> I have a feeling this is using the common clock framework backwards. The
> MAC in this case is a clock provider yet it uses the consumer API.
>
> Shouldn't the MAC instead register a new clock, as a provider, for the ref
> out ? The PHY device would then need to get/prepare/enable that clock.

The clock name is a misnomer frankly. It's configured in the CRU and
muxed to the output pin via IO registers, so it has little to do with
the GMAC itself - rather it's SoC wide. It's already exposed by the
SoC clock drivers, so nothing to be done in drivers/net/ethernet.

Looks like Motorcomm PHY drivers don't request the clock though, thus
we're seeing a second nearly identical attempt within the same
development cycle to shoehorn clock enablement into the GMAC driver
and binding, where it doesn't belong.

Best regards,
Alexey

_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip