From: Yao Zi <me@ziyao.cc>
To: Heiko Stuebner <heiko@sntech.de>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: Yao Zi <me@ziyao.cc>,
netdev@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Problematic understanding of phy-mode in Rockchip DWMAC driver
Date: Fri, 13 Feb 2026 18:26:44 +0000 [thread overview]
Message-ID: <aY9s5PXP4zZ7R6fa@pie> (raw)
Hi folks,
I was looking through the RGMII delay setup logic found in
rk_gmac_powerup() of dwmac-rk.c, and found its behavior is strange,
switch (bsp_priv->phy_iface) {
case PHY_INTERFACE_MODE_RGMII:
dev_info(dev, "init for RGMII\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv,
bsp_priv->tx_delay,
bsp_priv->rx_delay);
break;
case PHY_INTERFACE_MODE_RGMII_ID:
dev_info(dev, "init for RGMII_ID\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv, 0, 0);
break;
case PHY_INTERFACE_MODE_RGMII_RXID:
dev_info(dev, "init for RGMII_RXID\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv,
bsp_priv->tx_delay, 0);
break;
case PHY_INTERFACE_MODE_RGMII_TXID:
dev_info(dev, "init for RGMII_TXID\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv,
0, bsp_priv->rx_delay);
break;
case PHY_INTERFACE_MODE_RMII:
dev_info(dev, "init for RMII\n");
if (bsp_priv->ops->set_to_rmii)
bsp_priv->ops->set_to_rmii(bsp_priv);
break;
default:
dev_err(dev, "NO interface defined!\n");
}
I don't think dwmac-rk.c does any fixup for phy_interface, so the MAC
driver always connects the PHY with unmodified phy-mode.
ethernet-controller.yaml states,
> # Device Tree describes hardware, and in this case, it describes the
> # PCB between the MAC and the PHY, if the PCB implements delays or
> # not.
So let's assume this is true for Rockchip's DWMAC glue, then the
driver's behavior could be summarized as,
phy-mode PCB delay Rockchip MAC delay PHY delay[1]
rgmii TX & RX TX & RX TX & RX
rgmii-id None None TX & RX
rgmii-rxid TX TX RX
rgmii-txid RX RX TX
[1]: if available
where only the "rgmii-id" case makes sense. Other cases come with 2ns
delays added more than once, and would cause broken link.
It looks like dwmac-rk.c considers "phy-mode" to represent MAC's delay
configuration. If so, the table would look like,
phy-mode PCB delay Rockchip MAC delay PHY delay[1]
rgmii N/A TX & RX None
rgmii-id N/A None TX & RX
rgmii-txid N/A TX RX
rgmii-rxid N/A RX TX
all cases have the necessary 2ns delay provided for both TX and RX
signals, however on-PCB delays made by traces couldn't be described
at all. This idea is also proved by comments in Rockchip devicetrees,
for example, rk3576-roc-pc.dts,
&gmac0 {
...
/* Use rgmii-rxid mode to disable rx delay inside Soc */
phy-mode = "rgmii-rxid";
};
It seems for Rockchip DWMAC driver, "phy-mode" doesn't follow the
generic definition. Should we annotate in rockchip-dwmac.yaml to mention
the different usage of the property, or update both the driver and
devicetrees to align with ethernet-controller.yaml? The later would
break compatibility with existing devicetrees since there are already 15
instances of "rgmii-rxid" found in arch/arm64/boot/dts/rockchip, but
luckily most boards make use of "rgmii-id".
I only did a brief search in lore but find no related discussion, please
point out if there has already been messages around it, thanks.
Best regards,
Yao Zi
WARNING: multiple messages have this Message-ID (diff)
From: Yao Zi <me@ziyao.cc>
To: Heiko Stuebner <heiko@sntech.de>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: Yao Zi <me@ziyao.cc>,
netdev@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Subject: Problematic understanding of phy-mode in Rockchip DWMAC driver
Date: Fri, 13 Feb 2026 18:26:44 +0000 [thread overview]
Message-ID: <aY9s5PXP4zZ7R6fa@pie> (raw)
Hi folks,
I was looking through the RGMII delay setup logic found in
rk_gmac_powerup() of dwmac-rk.c, and found its behavior is strange,
switch (bsp_priv->phy_iface) {
case PHY_INTERFACE_MODE_RGMII:
dev_info(dev, "init for RGMII\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv,
bsp_priv->tx_delay,
bsp_priv->rx_delay);
break;
case PHY_INTERFACE_MODE_RGMII_ID:
dev_info(dev, "init for RGMII_ID\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv, 0, 0);
break;
case PHY_INTERFACE_MODE_RGMII_RXID:
dev_info(dev, "init for RGMII_RXID\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv,
bsp_priv->tx_delay, 0);
break;
case PHY_INTERFACE_MODE_RGMII_TXID:
dev_info(dev, "init for RGMII_TXID\n");
if (bsp_priv->ops->set_to_rgmii)
bsp_priv->ops->set_to_rgmii(bsp_priv,
0, bsp_priv->rx_delay);
break;
case PHY_INTERFACE_MODE_RMII:
dev_info(dev, "init for RMII\n");
if (bsp_priv->ops->set_to_rmii)
bsp_priv->ops->set_to_rmii(bsp_priv);
break;
default:
dev_err(dev, "NO interface defined!\n");
}
I don't think dwmac-rk.c does any fixup for phy_interface, so the MAC
driver always connects the PHY with unmodified phy-mode.
ethernet-controller.yaml states,
> # Device Tree describes hardware, and in this case, it describes the
> # PCB between the MAC and the PHY, if the PCB implements delays or
> # not.
So let's assume this is true for Rockchip's DWMAC glue, then the
driver's behavior could be summarized as,
phy-mode PCB delay Rockchip MAC delay PHY delay[1]
rgmii TX & RX TX & RX TX & RX
rgmii-id None None TX & RX
rgmii-rxid TX TX RX
rgmii-txid RX RX TX
[1]: if available
where only the "rgmii-id" case makes sense. Other cases come with 2ns
delays added more than once, and would cause broken link.
It looks like dwmac-rk.c considers "phy-mode" to represent MAC's delay
configuration. If so, the table would look like,
phy-mode PCB delay Rockchip MAC delay PHY delay[1]
rgmii N/A TX & RX None
rgmii-id N/A None TX & RX
rgmii-txid N/A TX RX
rgmii-rxid N/A RX TX
all cases have the necessary 2ns delay provided for both TX and RX
signals, however on-PCB delays made by traces couldn't be described
at all. This idea is also proved by comments in Rockchip devicetrees,
for example, rk3576-roc-pc.dts,
&gmac0 {
...
/* Use rgmii-rxid mode to disable rx delay inside Soc */
phy-mode = "rgmii-rxid";
};
It seems for Rockchip DWMAC driver, "phy-mode" doesn't follow the
generic definition. Should we annotate in rockchip-dwmac.yaml to mention
the different usage of the property, or update both the driver and
devicetrees to align with ethernet-controller.yaml? The later would
break compatibility with existing devicetrees since there are already 15
instances of "rgmii-rxid" found in arch/arm64/boot/dts/rockchip, but
luckily most boards make use of "rgmii-id".
I only did a brief search in lore but find no related discussion, please
point out if there has already been messages around it, thanks.
Best regards,
Yao Zi
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next reply other threads:[~2026-02-13 18:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 18:26 Yao Zi [this message]
2026-02-13 18:26 ` Problematic understanding of phy-mode in Rockchip DWMAC driver Yao Zi
2026-02-13 18:47 ` Russell King (Oracle)
2026-02-13 18:47 ` Russell King (Oracle)
2026-02-14 16:50 ` Andrew Lunn
2026-02-14 16:50 ` Andrew Lunn
2026-02-14 19:02 ` Russell King (Oracle)
2026-02-14 19:02 ` Russell King (Oracle)
2026-02-16 1:57 ` Andrew Lunn
2026-02-16 1:57 ` Andrew Lunn
2026-02-16 15:00 ` Russell King (Oracle)
2026-02-16 15:00 ` Russell King (Oracle)
2026-02-16 17:21 ` Diederik de Haas
2026-02-16 17:21 ` Diederik de Haas
2026-02-24 2:08 ` Chaoyi Chen
2026-02-24 2:08 ` Chaoyi Chen
2026-02-16 4:44 ` Yao Zi
2026-02-16 4:44 ` Yao Zi
2026-02-16 15:48 ` Andrew Lunn
2026-02-16 15:48 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aY9s5PXP4zZ7R6fa@pie \
--to=me@ziyao.cc \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=heiko@sntech.de \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.