Re: [PATCH v3 8/8] dt-bindings: net: ethernet-controller: tabulate who adds the RGMII delays

On 10/10/2026 23:37, Martin Blumenstingl wrote:

Hi Andrew, Hi Lucas,

On Sat, Oct 10, 2026 at 12:59 PM Lucas Tanure [off-list ref] wrote:
[...]

quoted

+#   phy-mode    tx-internal-delay-ps  rx-internal-delay-ps  TX delay    RX delay
+#   rgmii       -                     -                     PCB trace   PCB trace
+#   rgmii-id    -                     -                     PHY         PHY
+#   rgmii-id    present               -                     MAC         PHY
+#   rgmii-id    -                     present               PHY         MAC
+#   rgmii-id    present               present               MAC         MAC
+#   rgmii-txid  -                     -                     PHY         PCB trace
+#   rgmii-txid  present               -                     MAC         PCB trace
+#   rgmii-rxid  -                     -                     PCB trace   PHY
+#   rgmii-rxid  -                     present               PCB trace   MAC

We have some boards where the PCB traces result in part (1200ps) of
the delay needed for RGMII (2000ps).
The remainder (800ps) has to be added by either PHY or MAC: the
(RTL8211F) PHY can only generate 0 or 2000ps delay so the MAC has to
take over.
For the three boards I have in mind, please see $ git grep
rx-internal-delay-ps arch/arm64/boot/dts/amlogic/

quoted

+# A property for a clock the PCB already delays is not in this table.

Can you please explain this sentence (I'm not a native English speaker)?
How I interpret the sentence: The PCB may add delays but those are
implicit and not part of the {rx,tx}-internal-delay-ps properties. If
the delays added by the PCB don't cover the full 2ns requirement then
either MAC or PHY need to add the remainder, see fine-tuning below.

quoted

+# It is either the fine tuning described next, or a mistake the MAC
+# should report as a fatal error.

How can I differentiate between "fine tuning" and "mistake"?


Best regards,
Martin

The patch is wrong. It assumes a present property moves the 2ns from
the PHY to the MAC, and Andrew's reply on patch 4 says it does not.
I am dropping it in v4.

thanks
Lucas