Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hi Mohd,

On 8/31/26 10:33, Mohd Ayaan Anwar wrote:
> Hi Andrew,
> 
> On Tue, Jun 16, 2026 at 10:02:51PM +0530, Mohd Ayaan Anwar wrote:
>> On Mon, Jun 15, 2026 at 06:48:55PM +0200, Andrew Lunn wrote:
>>>>> I'm curious how this works at the moment? Do no boards make use of
>>>>> RGMII ID? Are all current boards broken?
>>>>
>>>> Searching through the DTS, I found that we have two boards using "rgmii"
>>>> (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
>>>> "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
>>>
>>> So this causes problems. We cannot break existing boards, yet it would
>>> be good to fix the current broken behaviour.
>>
>> I am trying to track down the sa8155-adp and sa8540p-ride boards. The
>> EMAC on QCS404 is extremely similar to QCS615 Ride [0], and I got that
>> board to work with this series (with RGMII ID mode). So I am fairly
>> confident that QCS404 would not break (if its even booting up with the
>> upstream kernel currently). Also, I think we could change the phy-mode
>> for QCS404 to "rgmii-id" from "rgmii" if these fixes go in.
>>
>>> It could be the best way forward is that you issue a warning when
>>> "rgmii" is found and pass rgmii-id to the PHY. And you also change the
>>> two boards to use rgmii-id. Lets think about the rgmii-txid case once
>>> we better understand it.
>>>
>>
>> As Konrad mentioned, it would be great to know if we can test out these
>> boards. Looking at the different versions of the ETHQOS programming
>> guide, stopping MAC side delay should be as simple as what we are doing
>> in this commit. But whether the two boards work directly with the
>> default PHY delays is unknown.
>>
> 
> So I did find the sa8540p-ride board but have so far been unsuccessful
> in getting it to boot. While that goes on, I would like to proceed with
> a series to fix RGMII on qcom-ethqos due to the following reasons:
> 
>  1. All versions of programming guides give a programming sequence for
>  MAC-side delay or PHY-side delay. There is no concept of "rgmii-txid".
> 
>  2. I also found some downstream code that was using "rgmii" phy-mode to
>  program MAC-side delays on the sa8540p-ride board. So it looks like
>  "rgmii-txid" was a workaround to enable ethernet while support for
>  this board was being upstreamed.
> 
>  3. I have been able to test this patch on a variety of boards now,
>  including:
>      - Shikra CQ/IQ variants (with the TI DP83867 PHY)
>      - QCS615 Ride (with the Micrel KSZ9031 PHY)
>      - Talos EVK (again with the Micrel KSZ9031 PHY)
>      - Talos Lyra (with the TI DP83867 PHY)
>  These platforms cover the two RGMII configurations that Qualcomm has
>  typically deployed.

I've been able to get my hands on a qualcomm devkit for ipq8064 :

Compex WPQ864 6A02, has the IPQ8064 connected to a QCA8337 switch
through both the ports, one using RGMII (no ID), and one with SGMII.

The DT is downstream, in OpenWRT :

https://git.openwrt.org/openwrt/openwrt/tree/target/linux/ipq806x/dts/qcom-ipq8064-ap148.dts#n198

happy to help in some testing as well if needed, this board is going
in my CI for stmmac stuff.

> 
> With this in mind, I was thinking of breaking up this patch series into
> separate ones to solve one problem at a time:
> 
>  1. Introduce support for "rgmii-id" using PHY-side delays rather than
>  MAC-provided delays. Also, issue a warning if any other phy-mode is
>  being used.
> 
>  2. Fix the DTS of the existing boards to use "rgmii-id".
> 
>  3. Once the DTS is fixed, remove the now-unused code handling non
>  RGMII-ID cases. This should also allow us to remove the whole
>  ethqos_emac_por code since it wouldn't be needed for RGMII-ID.

I'm wondering if we should add some temporary very loud warning for
boards that use "rgmii" before changing this, or even just keep the
actual "rgmii" behaviour which inserts the delays, as there seems to
be lots of such users...

This is going to be quite the breaking change.

> 
>  4. Add support for regulator voting in the DP83867 driver, mirroring
>  what Daniel Thompson/ Alex Elder did for QCA8081 [1]. This will help
>  in adding support for the Shikra/Talos Lyra boards which need the
>  supply for the PHY to be explicitly enabled.
> 
>  5. Support for Shikra can be added once these changes are in.
> 
> Does this plan sound reasonable? Thanks.
> 
> 	Ayaan
> ---
> [1] https://lore.kernel.org/netdev/20260605010022.968612-3-elder@riscstar.com/
> 

Maxime