RE: [RFC PATCH 4/8] xilinx: tsn: Add Ethernet MAC (EMAC) and MDIO support to the TSN driver

[Public]

Hi,

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>
Sent: Friday, February 20, 2026 8:43 PM
To: Neeli, Srinivas <srinivas.neeli@amd.com>
Cc: andrew+netdev@lunn.ch; davem@davemloft.net;
edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Simek,
Michal [off-list ref]; robh@kernel.org; krzk+dt@kernel.org;
conor+dt@kernel.org; richardcochran@gmail.com; netdev@vger.kernel.org;
linux-kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; git (AMD-Xilinx) [off-list ref]
Subject: Re: [RFC PATCH 4/8] xilinx: tsn: Add Ethernet MAC (EMAC) and MDIO
support to the TSN driver

quoted

+#define TSN_EMMC_LINKSPEED_10              0x0        /* 10 Mbit */

If the MAC cannot do 10Mbps, why have this?

quoted

+static int emac_open(struct net_device *ndev) {
+   struct tsn_emac *emac = netdev_priv(ndev);
+   struct phy_device *phydev = NULL;
+
+   if (emac->phy_node) {
+           phydev = of_phy_connect(emac->ndev, emac->phy_node,
+                                   tsn_adjust_link_tsn,
+                                   emac->phy_flags,
+                                   emac->phy_mode);
+           if (!phydev)
+                   dev_err(emac->common->dev, "of_phy_connect()

failed\n");

quoted

+           else
+                   phy_start(phydev);
+   }

Somewhere around here, i would expect you to tell phylib the MAC cannot do
10Mbps. You don't want the PHY offering those speeds for autoneg, otherwise
it might actually negotiate 10Mbps.

I also think you should be using phylink, not phylib. But we first need to finish
the discussion about DSA vs pure switchdev. If this ends up being a DSA driver,
you will be using phylink anywhere. If it is a pure switchdev driver, i would still
recommend using phylink, you are less likely to get things wrong, because the
API is better designed.

    Andrew

Thank you for the detailed feedback.

I agree with your comments. I plan to rework this driver to use the phylink framework instead of phylib, as it is a better fit and avoids getting these details wrong.

In the next revision, I will also address the 10 Mbps handling and ensure that unsupported link modes are properly constrained, so they are not advertised or negotiated.
Thanks for the guidance.


Thanks
Neeli Srinivas