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

[Neeli, Srinivas]

[Public]

Hi,

> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Friday, February 20, 2026 8:43 PM
> To: Neeli, Srinivas <srinivas.neeli at amd.com>
> Cc: andrew+netdev at lunn.ch; davem at davemloft.net;
> edumazet at google.com; kuba at kernel.org; pabeni at redhat.com; Simek,
> Michal <michal.simek at amd.com>; robh at kernel.org; krzk+dt at kernel.org;
> conor+dt at kernel.org; richardcochran at gmail.com; netdev at vger.kernel.org;
> linux-kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; git (AMD-Xilinx) <git at amd.com>
> Subject: Re: [RFC PATCH 4/8] xilinx: tsn: Add Ethernet MAC (EMAC) and MDIO
> support to the TSN driver
>
> > +#define TSN_EMMC_LINKSPEED_10              0x0        /* 10 Mbit */
>
> If the MAC cannot do 10Mbps, why have this?
>
> > +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");
> > +           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