the MAC is not capable of generating an RX delay (at least as far as I know).

So that immediately means rgmii is invalid as a phy-mode, since the
documentation implies the MAC needs to add RX delay.

it's mostly "broken" (high TX packet loss, slow TX speeds) for the two
supported boards with an RGMII PHY (meson8b-odroidc1.dts and
meson8m2-mxiii-plus.dts)
examples on the many ways it was broken will follow - feel free to
skip this part

That is actually good. If it never worked, we don't need to worry
about breaking it! We can spend our time getting this correct, and not
have to worry about backwards compatibility, etc.

quoted

What we normally say is make the MAC add no delays, and pass the
correct configuration to the PHY so it adds the delay. But due to the
strapping pin on the rtl8211f, we are in a bit of a grey area. I would
suggest the MAC adds no delay, phy-mode is set to rmgii-id, the PHY
driver adds TX delay in software, we assume the strapping pin is set
to add RX delay, and we add a big fat comment in the DT.

For the Micrel PHY, we do the same, plus add the vendor properties to
configure the clock skew.

But as i said, we are in a bit of a grey area. We can consider other
options, but everything needs to be self consistent, between what the
MAC is doing, what the PHY is doing, and what phy-mode is set to in
DT.

do you think it's worth the effort to get clarification from Realtek
on the RX delay behavior (and whether there's a register to control
it)?

You can ask. There are also datasheet here:

http://files.pine64.org/doc/datasheet/rock64/RTL8211F-CG-Realtek.pdf
https://datasheet.lcsc.com/szlcsc/1909021205_Realtek-Semicon-RTL8211F-CG_C187932.pdf

It looks like both RX and TX delay can be controlled via
strapping. But the register for controlling the TX delay is not
documented.

you mentioned that there was breakage earlier this year, so I'm not sure anymore
(that leaves me thinking: asking them is still useful to get out of
this grey area)

It was an Atheros PHY with breakage.

If we can fully control the RX and TX delays, that would be great. It
would also be useful if there was a way to determine how the PHY has
been strapped. If we cannot fully control the delays but we can find
out what delays it is using, we can check the requested configuration
against the strapped configuration, and warn if they are different.

    Andrew