[net-next,v3,0/5] net: stmmac: Add support for Allwinner A733 GMAC210

The A733 GMAC210 is a DesignWare MAC 5.20 with an Allwinner glue close to
the A523 GMAC200 already supported by dwmac-sun55i, but with a few
significant differences:

 * The glue configuration registers are a dedicated MMIO region of the
   controller instead of a syscon register.
 * That region is in the AHB reset domain, so the AHB reset must be
   released before the configuration is written. The configuration
   is sampled by the dwmac when the other reset is deasserted.
 * The DMA channels have their own interrupt lines.
 * A PTP reference clock and an AHB reset are needed.
 * The controllers do not require a power domain (AFAIK).
 * The TX clock delay value is 5 bits wide instead of 3, split over 2
   register fields, and both TX and RX delays use a 180ps step.

The DT changes for the A733 and the Cubie A7A board are not part of this
series and will be sent separately through the sunxi tree.

Tested on a Cubie A7A, RGMII with a MAXIO external PHY on GMAC0.

Problems found while testing (none impacting this driver directly):
 * Unstable EEE/LPI: If the device stays in LPI mode long enough, the
   link sometimes (but not always) goes down, coming back up when the
   device exits LPI mode. This is apparently due to the PHY; the vendor
   driver disables this feature. The solution is to use genphy with the
   eee-broken-* DT properties or wait for the upcoming mainline driver:
   https://lore.kernel.org/all/MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com
 * Tx-delay: The vendor kernel ships with a Tx delay of 2.16ns. It may seem
   to work at first but breaks under heavy load. The vendor kernel is
   configured for an external RGMII clock, which cannot work on the A7A:
   the 125MHz input and 25MHz reference output are not wired to the PHY.
   It was most likely not tested on this board. A 1.62ns Tx delay works
   well.

DT example is available here (gated on CCU and pinctrl mainline support
currently):
https://github.com/jbrun3t/linux/commit/aa6f3a5ce4cd6e09ff9be1828915bfe8e87c57df

Maxime, I've tried adding a new init callback as you suggested but it
did not work out. The config needs to be written before the 'stmmaceth'
reset is deasserted to be properly sampled, but it can only be written
once the 'ahb' reset is deasserted. A new callback would not help.
However, tweaking the stmmac platform data as I did in v2 is not
necessary since the reset is shared. I've corrected that.

Changes in v3:
- Split the driver changes into preparatory patches and the A733 addition
- Use a 180ps TX and RX delay step on the A733, allowing up to 5580ps
- Release the shared AHB reset before writing the glue registers instead of
  taking over the stmmaceth reset from the stmmac core
- Link to v2: https://patch.msgid.link/20260910-allwinner-a733-gmac-support-v2-0-4f4a1e520c23@baylibre.com

Changes in v2:
- No driver change since RFC, just more tests.
- Rebase on net-next/main - proper prefix added
- Link to v1: https://patch.msgid.link/20260731-allwinner-a733-gmac-support-v1-0-d0a8732bfa82@baylibre.com

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Jerome Brunet (5):
      dt-bindings: net: sun8i-emac: Add A733 GMAC210 compatible
      net: stmmac: sun55i: Add per-compatible match data
      net: stmmac: sun55i: Make the delay step configurable
      net: stmmac: sun55i: Support TX delay extension bits
      net: stmmac: sun55i: Add support for Allwinner A733 GMAC210

 .../bindings/net/allwinner,sun8i-a83t-emac.yaml    | 142 ++++++++++++++--
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun55i.c | 184 +++++++++++++++++----
 2 files changed, 276 insertions(+), 50 deletions(-)
---
base-commit: 944ae66642b726bd6b25ae71b1e9ff88a0e0bdb0
change-id: 20260731-allwinner-a733-gmac-support-163bde10c152

Best regards,
--  
Jerome
  

>  * Tx-delay: The vendor kernel ships with a Tx delay of 2.16ns. It may seem
>    to work at first but breaks under heavy load. The vendor kernel is
>    configured for an external RGMII clock, which cannot work on the A7A:
>    the 125MHz input and 25MHz reference output are not wired to the PHY.
>    It was most likely not tested on this board. A 1.62ns Tx delay works
>    well.
> 
> DT example is available here (gated on CCU and pinctrl mainline support
> currently):
> https://github.com/jbrun3t/linux/commit/aa6f3a5ce4cd6e09ff9be1828915bfe8e87c57df

&gmac0 {
	phy-mode = "rgmii-id";
	phy-handle = <&ext_rgmii0_phy>;
	phy-supply = <&reg_swout1>;
	pinctrl-names = "default";
	pinctrl-0 = <&gmac0_pins>;

	tx-internal-delay-ps = <1620>;
	rx-internal-delay-ps = <1800>;

Something does not seem correct here. rgmii-id means the PHY is adding
2ns of delay. The MAC is adding an additional 1.6 to 1.8 ns. The total
is way too big when the standard says 2ns.

Is the PHY adding 2ns?

	Andrew
  

>  * Unstable EEE/LPI: If the device stays in LPI mode long enough, the
>    link sometimes (but not always) goes down, coming back up when the
>    device exits LPI mode. This is apparently due to the PHY; the vendor
>    driver disables this feature. The solution is to use genphy with the
>    eee-broken-* DT properties or wait for the upcoming mainline driver:
>    https://lore.kernel.org/all/MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com

Looking at this code, it totally ignores the interface mode. So you
have no idea what RGMII delays it is adding. When this driver gets
fixed before being merged, your DT fragment will likely break.

       Andrew
  

On jeu. 24 sept. 2026 at 00:19, Andrew Lunn <andrew@lunn.ch> wrote:

>>  * Unstable EEE/LPI: If the device stays in LPI mode long enough, the
>>    link sometimes (but not always) goes down, coming back up when the
>>    device exits LPI mode. This is apparently due to the PHY; the vendor
>>    driver disables this feature. The solution is to use genphy with the
>>    eee-broken-* DT properties or wait for the upcoming mainline driver:
>>    https://lore.kernel.org/all/MN0PR19MB609154F210DF84DCB29D3696ACC62@MN0PR19MB6091.namprd19.prod.outlook.com
>
> Looking at this code, it totally ignores the interface mode. So you
> have no idea what RGMII delays it is adding. When this driver gets
> fixed before being merged, your DT fragment will likely break.

Thanks for pointing this out Andrew.

I've changed the phy-mode to plain rgmii which seems more in line with
what the PHY actually does.

>
>        Andrew
  

> I've changed the phy-mode to plain rgmii which seems more in line with
> what the PHY actually does.

No, it is much messier than that.

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

rgmii-id is very likely to be correct, if you were using a sane PHY.

But this PHY is going to cause you lots of problems.

    Andrew
  

On jeu. 24 sept. 2026 at 14:54, Andrew Lunn <andrew@lunn.ch> wrote:

>> I've changed the phy-mode to plain rgmii which seems more in line with
>> what the PHY actually does.
>
> No, it is much messier than that.
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
>
> rgmii-id is very likely to be correct, if you were using a sane PHY.

It is not the PCB doing the delays so rgmii-id it is (in DT) - got it.

I dunno what is sane or not, but the allwinner dwmac drivers do set some
delays. sun8i-dwmac and sun55i-dwmac do so, even before this change.

If I understand correctly :

"""
When the MAC implements the delay, it must ensure that the PHY does not
also implement the same delay. So it must modify the phy-mode it passes
to the PHY, removing the delay it has added. Failure to remove the delay
will result in a non-functioning link
"""

IOW when the gmac has *-internal-delay-ps set and honors them, it should
also amend phymode seen by PHY to make sure it does not add its own
delays, should it ever be fixed ?

>
> But this PHY is going to cause you lots of problems.

We don't get to choose I'm afraid :)

>
>     Andrew
>
  

> It is not the PCB doing the delays so rgmii-id it is (in DT) - got it.

Yep.

> 
> I dunno what is sane or not, but the allwinner dwmac drivers do set some
> delays. sun8i-dwmac and sun55i-dwmac do so, even before this change.

As the document i linked to says, doing small tuning delays is
fine. We strongly prefer the PHY does the 2ns delay, if it can.

> If I understand correctly :
> 
> """
> When the MAC implements the delay, it must ensure that the PHY does not
> also implement the same delay. So it must modify the phy-mode it passes
> to the PHY, removing the delay it has added. Failure to remove the delay
> will result in a non-functioning link
> """
> 
> IOW when the gmac has *-internal-delay-ps set and honors them, it should
> also amend phymode seen by PHY to make sure it does not add its own
> delays, should it ever be fixed ?

You need to differentiate between small fine tuning delays, and the
2ns delay required by the RGMII standard. If the MAC is just doing
fine tuning, you need to still pass PHY_INTERFACE_MODE_RGMII_ID so the
PHY adds the 2ns delay. If the MAC is adding a big delay, you need to
pass PHY_INTERFACE_MODE_RGMII to the PHY.

If you have the schematics, it would be good to confirm the strapping
on the PHY, and add a comment in the DTS file about what is going on
here.

The other option i hinted at was use phy-mode = 'na'. I'm still
considering this, it has some advantages.

The problem with passing PHY_INTERFACE_MODE_RGMII or
PHY_INTERFACE_MODE_RGMII_ID to the PHY is we have no way of knowing if
the hardware is honouring it. It appears the board you are working on
does the opposite of what we would prefer. I guess there are going to
be other similar boards, but are they going to get a similar level of
review and the issues spotted? Are they going to end up passing the
wrong PHY_INTERFACE_MODE_RGMII value to the PHY?

By making the PHY reject PHY_INTERFACE_MODE_RGMII* it makes it very
clear something odd is going on here, and care needs to be taken. It
will be very much in your face for DT writers, so they are more likely
to get it correct.

And if in the future we do find out how to control the PHY delays in
software, boards using phy-mode = 'na' are safe, no change. Other
boards which got passed review could well break. Been there, done
that, don't want to repeat it.

> > But this PHY is going to cause you lots of problems.
> 
> We don't get to choose I'm afraid :)

Yes, you have just the first victim.

It would be nice if somebody reached out to the vendor and asked if:

Can the RGMII delays be configured in software?

if not:

Can the RGMII delay strapping be seen in software?

If we know the strapping we can at least return EOPNOTSUPP if the
requested does not match what the hardware is doing, and we get a
clear indication of a problem.

    Andrew
  

On jeu. 24 sept. 2026 at 18:02, Andrew Lunn <andrew@lunn.ch> wrote:

>> It is not the PCB doing the delays so rgmii-id it is (in DT) - got it.
>
> Yep.
>
>> 
>> I dunno what is sane or not, but the allwinner dwmac drivers do set some
>> delays. sun8i-dwmac and sun55i-dwmac do so, even before this change.
>
> As the document i linked to says, doing small tuning delays is
> fine. We strongly prefer the PHY does the 2ns delay, if it can.

Understood.

>
>> If I understand correctly :
>> 
>> """
>> When the MAC implements the delay, it must ensure that the PHY does not
>> also implement the same delay. So it must modify the phy-mode it passes
>> to the PHY, removing the delay it has added. Failure to remove the delay
>> will result in a non-functioning link
>> """
>> 
>> IOW when the gmac has *-internal-delay-ps set and honors them, it should
>> also amend phymode seen by PHY to make sure it does not add its own
>> delays, should it ever be fixed ?
>
> You need to differentiate between small fine tuning delays, and the
> 2ns delay required by the RGMII standard. If the MAC is just doing
> fine tuning, you need to still pass PHY_INTERFACE_MODE_RGMII_ID so the
> PHY adds the 2ns delay. If the MAC is adding a big delay, you need to
> pass PHY_INTERFACE_MODE_RGMII to the PHY.

The PHY is one concern but the series here does not really address this
topic. DTS and board specific concerns will come later.

It is really just the MAC. So, how does the MAC is supposed to
make the decision to amend the PHY mode ? is there a threshold you'd
like to recommend for this differentiation ? 

>
> If you have the schematics, it would be good to confirm the strapping
> on the PHY, and add a comment in the DTS file about what is going on
> here.
>
> The other option i hinted at was use phy-mode = 'na'. I'm still
> considering this, it has some advantages.
>
> The problem with passing PHY_INTERFACE_MODE_RGMII or
> PHY_INTERFACE_MODE_RGMII_ID to the PHY is we have no way of knowing if
> the hardware is honouring it. It appears the board you are working on
> does the opposite of what we would prefer. I guess there are going to
> be other similar boards, but are they going to get a similar level of
> review and the issues spotted? Are they going to end up passing the
> wrong PHY_INTERFACE_MODE_RGMII value to the PHY?
>
> By making the PHY reject PHY_INTERFACE_MODE_RGMII* it makes it very
> clear something odd is going on here, and care needs to be taken. It
> will be very much in your face for DT writers, so they are more likely
> to get it correct.

We do need the information that the link is RGMII (not RMII or GMII) to
setup the MAC properly though. Aside from that, It is all fine by me.

>
> And if in the future we do find out how to control the PHY delays in
> software, boards using phy-mode = 'na' are safe, no change. Other
> boards which got passed review could well break. Been there, done
> that, don't want to repeat it.
>
>> > But this PHY is going to cause you lots of problems.
>> 
>> We don't get to choose I'm afraid :)
>
> Yes, you have just the first victim.
>
> It would be nice if somebody reached out to the vendor and asked if:
>
> Can the RGMII delays be configured in software?
>
> if not:
>
> Can the RGMII delay strapping be seen in software?
>
> If we know the strapping we can at least return EOPNOTSUPP if the
> requested does not match what the hardware is doing, and we get a
> clear indication of a problem.

I'll try to reach out, just in case. I have the schematics but without
the PHY doc, it does not help much.

Just to get back on topic, The problems you mention here are more PHY ones
when net support lands from this board in DT (I'll remember to Cc you of
that one when it comes)

For the MAC part here (and its bindings) it does not change anything,
unless I'm missing something. This series just adds support for a
another MAC variant in an existing driver.

>
>     Andrew
  

> > You need to differentiate between small fine tuning delays, and the
> > 2ns delay required by the RGMII standard. If the MAC is just doing
> > fine tuning, you need to still pass PHY_INTERFACE_MODE_RGMII_ID so the
> > PHY adds the 2ns delay. If the MAC is adding a big delay, you need to
> > pass PHY_INTERFACE_MODE_RGMII to the PHY.
> 
> The PHY is one concern but the series here does not really address this
> topic. DTS and board specific concerns will come later.

They are all interconnected. When phy-mode says 'rgmii-id', it is the
MAC/PHY pair which needs to decide who adds the delay. If the phy-mode
is 'na', how does the MAC know it needs to use RGMII, not MII, as you
said.

We need to keep the big picture in mind, otherwise you could go down a
dead end, and a dead end which makes backwards compatibility really
messy.

> It is really just the MAC. So, how does the MAC is supposed to
> make the decision to amend the PHY mode ? is there a threshold you'd
> like to recommend for this differentiation ? 

This is the first time we have had this condition. So it has not
really been thought about too much. Maybe 1ns. That is the middle of
the 2ns required by RGMII.

> I'll try to reach out, just in case. I have the schematics but without
> the PHY doc, it does not help much.

>From that i assume you missed the other emails. Somebody from ARM give
a link to the data sheet. It documents the strapping. Search for the
patch adding the PHY driver, it is in that thread.

	Andrew
  

On ven. 25 sept. 2026 at 21:45, Andrew Lunn <andrew@lunn.ch> wrote:

>> > You need to differentiate between small fine tuning delays, and the
>> > 2ns delay required by the RGMII standard. If the MAC is just doing
>> > fine tuning, you need to still pass PHY_INTERFACE_MODE_RGMII_ID so the
>> > PHY adds the 2ns delay. If the MAC is adding a big delay, you need to
>> > pass PHY_INTERFACE_MODE_RGMII to the PHY.
>> 
>> The PHY is one concern but the series here does not really address this
>> topic. DTS and board specific concerns will come later.
>
> They are all interconnected. When phy-mode says 'rgmii-id', it is the
> MAC/PHY pair which needs to decide who adds the delay. If the phy-mode
> is 'na', how does the MAC know it needs to use RGMII, not MII, as you
> said.
>
> We need to keep the big picture in mind, otherwise you could go down a
> dead end, and a dead end which makes backwards compatibility really
> messy.

I agree with you with on all this. I understand this particular MAC/PHY
combo is sparking this discussion, Let's sort this out properly, no
rush.

I'm merely pointing out that the problem is not introduced by the code
submited here. Other MAC can set delays, Other MACs would need to handle
mis-behaving PHY too.

>
>> It is really just the MAC. So, how does the MAC is supposed to
>> make the decision to amend the PHY mode ? is there a threshold you'd
>> like to recommend for this differentiation ? 
>
> This is the first time we have had this condition. So it has not
> really been thought about too much. Maybe 1ns. That is the middle of
> the 2ns required by RGMII.
>
>> I'll try to reach out, just in case. I have the schematics but without
>> the PHY doc, it does not help much.
>
> From that i assume you missed the other emails. Somebody from ARM give
> a link to the data sheet. It documents the strapping. Search for the
> patch adding the PHY driver, it is in that thread.
>

Thanks for the heads up. So if I'm reading the doc correctly the PHY
adds 2ns
 * on RX if there a 4.7k pull-up on RXD0
 * on TX if there a 4.7k pull-up on RXD1

The schematics for the board are available here [1]

* 4.7k pull-up on RXD0: so we should have 2ns Rx from the PHY
* 4.7k pull-down on RXD1: no idea what this does. Presumably no delay ?

I've cross-checked the HW, the resistors are actually fitted as the
schematic says they are.

With the HW setup, the MAC setup that works for me remains

	tx-internal-delay-ps = <1620>;
	rx-internal-delay-ps = <1800>;

I know it is not aligned with what it expected but still.

I've tried with
 * rx-internal-delay-ps = <0>. No Rx.
 * tx-internal-delay-ps at 1800ps, it still works with some TCP retries here and
   there on iperf3. 1980ps stalls after just a few packets.

[1]: https://dl.radxa.com/cubie/a7a/docs/hw/radxa_cubie_a7a_v1.10_schematic.pdf

> 	Andrew
  

> Thanks for the heads up. So if I'm reading the doc correctly the PHY
> adds 2ns
>  * on RX if there a 4.7k pull-up on RXD0
>  * on TX if there a 4.7k pull-up on RXD1
> 
> The schematics for the board are available here [1]
> 
> * 4.7k pull-up on RXD0: so we should have 2ns Rx from the PHY
> * 4.7k pull-down on RXD1: no idea what this does. Presumably no delay ?
> 
> I've cross-checked the HW, the resistors are actually fitted as the
> schematic says they are.
> 
> With the HW setup, the MAC setup that works for me remains
> 
> 	tx-internal-delay-ps = <1620>;
> 	rx-internal-delay-ps = <1800>;

These values suggests there are delays on both Rx an Tx.

> 
> I know it is not aligned with what it expected but still.

I'm flexible, if in the end this is what is required, that is fine. It
will need a comment explaining why it is needed, why the guidelines
are not being followed.

Where i have real problems is with developers who don't respect what
the guidelines say, even when their hardware could do what is
asked. They just do the minimum to make it work, and call it done.

The comment is then important, because i don't want developers using
this as an excuse not to do the correct thing.

     Andrew
  

On mar. 29 sept. 2026 at 18:10, Andrew Lunn <andrew@lunn.ch> wrote:

>> Thanks for the heads up. So if I'm reading the doc correctly the PHY
>> adds 2ns
>>  * on RX if there a 4.7k pull-up on RXD0
>>  * on TX if there a 4.7k pull-up on RXD1
>> 
>> The schematics for the board are available here [1]
>> 
>> * 4.7k pull-up on RXD0: so we should have 2ns Rx from the PHY
>> * 4.7k pull-down on RXD1: no idea what this does. Presumably no delay ?
>> 
>> I've cross-checked the HW, the resistors are actually fitted as the
>> schematic says they are.
>> 
>> With the HW setup, the MAC setup that works for me remains
>> 
>> 	tx-internal-delay-ps = <1620>;
>> 	rx-internal-delay-ps = <1800>;
>
> These values suggests there are delays on both Rx an Tx.

I did not mean to suggest :)

To be clear, we have no control over the PHY delay.
The strapping/doc says the PHY provide 2ns on Rx, none on Tx (presumably)

But I must add 1.62ns on Tx and 1.8ns on Rx through the MAC for the link
to work properly (the values above).

I don't have an explanation for this. I assume the PHY actually adds no
delay, maybe the strapping implementation is broken. Maybe the PCB the
already adds a little delay which is why the MAC just need to add a
little less than 2ns.

>
>> 
>> I know it is not aligned with what it expected but still.
>
> I'm flexible, if in the end this is what is required, that is fine. It
> will need a comment explaining why it is needed, why the guidelines
> are not being followed.
>
> Where i have real problems is with developers who don't respect what
> the guidelines say, even when their hardware could do what is
> asked. They just do the minimum to make it work, and call it done.
>
> The comment is then important, because i don't want developers using
> this as an excuse not to do the correct thing.

Sure, no problem. I'll add a comment in DT when I'll submit it,
explaining what we have found regarding the PHY strapping and effects.

>
>      Andrew