Thread (19 messages) 19 messages, 3 authors, 2025-08-21

Re: [PATCH v4 2/6] net: stmmac: Inverse the phy-mode definition

From: Andrew Lunn <andrew@lunn.ch>
Date: 2025-08-21 03:33:34
Also in: linux-arm-msm, linux-devicetree, lkml, netdev

On Thu, Aug 21, 2025 at 10:22:05AM +0800, Yijie Yang wrote:

On 2025-08-20 00:20, Andrew Lunn wrote:
quoted
quoted
  static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
  {
  	struct device *dev = &ethqos->pdev->dev;
-	int phase_shift;
+	int phase_shift = 0;
  	int loopback;
  	/* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
-	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
-	    ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
-		phase_shift = 0;
-	else
+	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID)
  		phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
Does this one setting control both RX and TX delays? The hardware
cannot support 2ns delay on TX, but 0ns on RX? Or 2ns on RX but 0ns on
TX?
This setting is only for Tx delay. Rx delays are taken care separately with
DLL delays.
If this is only for Tx delays, why is it also not used for
PHY_INTERFACE_MODE_RGMII_TXID?

It is simpler to just let the PHY add the delays, the PHY drivers get
this right, are well tested, and just work. MAC drivers often get
delays wrong.

	Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help