<div dir="ltr"><div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif;background-color:transparent">Hi all,</span></div><pre><code>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:

  <a href="https://lore.kernel.org/all/20260719034555.3623003-1-gahing@gahingwoo.com/">https://lore.kernel.org/all/20260719034555.3623003-1-gahing@gahingwoo.com/</a>

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</code></pre></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2026 at 3:19 PM Alexey Charkov <<a href="mailto:alchark@gmail.com">alchark@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Maxime,<br>
<br>
On Mon, Jul 27, 2026 at 11:11 AM Maxime Chevallier<br>
<<a href="mailto:maxime.chevallier@bootlin.com" target="_blank">maxime.chevallier@bootlin.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On 7/27/26 04:10, Gavin Gao wrote:<br>
> > Hi,<br>
> ><br>
> > Some Rockchip GMAC instances can provide a 25 MHz reference clock output<br>
> > for an external RGMII PHY. Boards already describe the MAC clock direction<br>
> > with clock_in_out = "output", but the dwmac-rk driver does not currently<br>
> > request or enable the corresponding 25 MHz reference output clock.<br>
> ><br>
> > On RK3576, this means the REFCLKO25M_GMACx_OUT clock may be disabled by<br>
> > the common clock framework as unused, even though the board expects the<br>
> > GMAC block to provide the PHY reference clock.<br>
> ><br>
> > This series adds an optional "clk_mac_25m_refout" clock name to the<br>
> > Rockchip DWMAC binding, wires it up for RK3576 GMAC0/GMAC1, and enables<br>
> > it from the dwmac-rk driver when the MAC is configured for RGMII output<br>
> > clock mode.<br>
> ><br>
> > The clock remains optional, so existing device trees and SoCs are not<br>
> > affected.<br>
> ><br>
> > Tested on a PicoCOM RK3576 ACP board with a Motorcomm YT8521 PHY.<br>
> > The GMAC 25 MHz reference clock output remains active and Ethernet works.<br>
><br>
> I have a feeling this is using the common clock framework backwards. The<br>
> MAC in this case is a clock provider yet it uses the consumer API.<br>
><br>
> Shouldn't the MAC instead register a new clock, as a provider, for the ref<br>
> out ? The PHY device would then need to get/prepare/enable that clock.<br>
<br>
The clock name is a misnomer frankly. It's configured in the CRU and<br>
muxed to the output pin via IO registers, so it has little to do with<br>
the GMAC itself - rather it's SoC wide. It's already exposed by the<br>
SoC clock drivers, so nothing to be done in drivers/net/ethernet.<br>
<br>
Looks like Motorcomm PHY drivers don't request the clock though, thus<br>
we're seeing a second nearly identical attempt within the same<br>
development cycle to shoehorn clock enablement into the GMAC driver<br>
and binding, where it doesn't belong.<br>
<br>
Best regards,<br>
Alexey<br>
</blockquote></div>