Re: [PATCH v3 4/8] net: stmmac: dwmac-meson8b: apply the RGMII delays the T7 way

[Lucas Tanure <tanure@linux.com>]

On 10/10/2026 22:49, Martin Blumenstingl wrote:
> Hi Lucas,
> 
> $subject caught my eye because I didn't understand why there's a "T7
> way" for adding RGMII delays since we should be following a standard.
> Patch 8/8 in this series documents the standard. Can you please find a
> more suitable $subject for this patch?

Ok.
> 
> On Sat, Oct 10, 2026 at 12:59 PM Lucas Tanure <tanure@linux.com> wrote:
> [...]
>>   static int meson8b_init_rgmii_delays(struct meson8b_dwmac *dwmac)
>>   {
>>          u32 tx_dly_config, rx_adj_config, cfg_rxclk_dly, delay_config;
>> @@ -411,32 +455,34 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
>>          dwmac->dev = &pdev->dev;
>>          dwmac->phy_mode = plat_dat->phy_interface;
>>
>> -       /* use 2ns as fallback since this value was previously hardcoded */
>> -       if (of_property_read_u32(pdev->dev.of_node, "amlogic,tx-delay-ns",
>> -                                &dwmac->tx_delay_ns))
>> -               dwmac->tx_delay_ns = 2;
> The 2ns default value in case "amlogic,tx-delay-ns" is absent hasn't
> been necessary since commit 093d23db4fff ("ARM64: dts: amlogic: add
> the ethernet TX delay configuration").
> That commit is part of v4.12. So boards using RGMII and a .dtb without
> that property haven't been updated in more than 9 years.
Ok, so for v4 the code is moved probe into the function only the older 
SoCs use, so it is isolated there and the T7 path never sees it. We can 
drop it future patch.

> 
> [...]
>> -       ret = meson8b_init_rgmii_delays(dwmac);
>> +       if (dwmac->data->mac_applies_dt_delays)
>> +               ret = meson_dwmac_init_dt_delays(dwmac, plat_dat);
>> +       else
>> +               ret = meson8b_init_rgmii_delays(dwmac);
>  From the discussion in v2 I couldn't understand the overall way forward.
> I get that new compatible strings should not rely on old, incorrect
> behavior. But what's the path forward for the other SoCs?
> 
> [...]
>>   static const struct meson8b_dwmac_data meson_t7_dwmac_data = {
>>          .set_phy_mode = meson_axg_set_phy_mode,
>> -       .has_prg_eth1_rgmii_rx_delay = true,
>>          .has_pipeline_clk = true,
>> +       .mac_applies_dt_delays = true,
> This should be a callback function pointer (apply_delays or similar,
> to match set_phy_mode) unless there's a way to make older SoCs also
> follow the "correct" RGMII delay specification.

Agreed. V4 will do it.>
> 
> Best regards,
> Martin
Thanks
Lucas