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

On jeu. 24 sept. 2026 at 18:02, Andrew Lunn [off-list ref] wrote:

quoted

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

Yep.

quoted

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.

quoted

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.

quoted

quoted

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

-- 
Jerome