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

[Gavin Gao]

Hi all,

Thanks for the review and the pointers.

I agree that my original approach was wrong: on RK3576 the 25 MHz
reference clock is provided by the CRU and consumed by the external PHY,
so neither the dwmac-rk driver nor the dwmac binding should manage it.

I will drop this series.

Jiaxing has already posted the right PHY-side approach for Motorcomm
YT8531:

  https://lore.kernel.org/all/20260719034555.3623003-1-gahing@gahingwoo.com/

My board uses a Motorcomm YT8521, so I will coordinate there and test
the same optional PHY clock handling for YT8521 on PicoCOM RK3576 ACP.

Thanks,
Gavin



On Mon, Jul 27, 2026 at 3:19 PM Alexey Charkov <alchark at gmail.com> wrote:

> Hi Maxime,
>
> On Mon, Jul 27, 2026 at 11:11 AM Maxime Chevallier
> <maxime.chevallier at bootlin.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://st-md-mailman.stormreply.com/pipermail/linux-stm32/attachments/20260727/6326ac9c/attachment.html>