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

[Chaoyi Chen]

On 7/27/2026 3:14 PM, Alexey Charkov wrote:
> Hi Gavin,
> 
> On Mon, Jul 27, 2026 at 6:10 AM Gavin Gao <attinagaoxu@xxxxxxxxx> 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.
>>
>> Gavin Gao (3):
>>   dt-bindings: net: rockchip-dwmac: Add 25M refout clock
>>   arm64: dts: rockchip: Add RK3576 GMAC 25M refout clocks
>>   net: stmmac: dwmac-rk: Enable RGMII 25M refout clock
>>
>>  .../bindings/net/rockchip-dwmac.yaml          |  1 +
>>  arch/arm64/boot/dts/rockchip/rk3576.dtsi      |  8 ++---
>>  .../net/ethernet/stmicro/stmmac/dwmac-rk.c    | 33 ++++++++++++++++++-
>>  3 files changed, 37 insertions(+), 5 deletions(-)
> 
> Can you please try something like this [1] instead?
> 
> [1] https://lore.kernel.org/linux-rockchip/20260719034555.3623003-1-gahing@xxxxxxxxxxxxx/
> 
> The GMAC on RK3576 neither produces nor consumes the clock. CRU is the
> producer, and PHY is the consumer. So the GMAC driver shouldn't be the
> one to enable it, nor should the dwmac binding have anything to do
> with it.
> 
> Have a look at how other boards already upstream handle this. For
> example, the RK3576 EVB1 uses a similar arrangement but with a
> different PHY.

Yep, we had a similar fix, but it was rejected. Please see how RK3576 EVB1 does it:

https://lore.kernel.org/all/20250910-rk3576-evb-network-v1-1-68ed4df272a2@xxxxxxxxxxxxx/


-- 
Best, 
Chaoyi