RE: [RFC PATCH 0/8] xilinx: tsn: Add TSN Endpoint Ethernet MAC driver support

["Neeli, Srinivas" <srinivas.neeli@amd.com>]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Thursday, February 19, 2026 10:13 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 <michal.simek@amd.com>; 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) <git@amd.com>
> Subject: Re: [RFC PATCH 0/8] xilinx: tsn: Add TSN Endpoint Ethernet MAC
> driver support
>
> On Thu, Feb 19, 2026 at 11:19:03AM +0530, Srinivas Neeli wrote:
> > Introduce a new network driver for the AMD LogiCORE 100M/1G TSN
> > Subsystem IP, also known as the TSN Endpoint Ethernet MAC, which
> > implements IEEE 802.1 Time-Sensitive Networking (TSN) features for
> > deterministic and low-latency Ethernet communication in real-time and
> > industrial automation use cases.
> >
> > IP Core Overview:
> > The AMD LogiCORE 100M/1G TSN Subsystem IP solution (named as TSN
> Endpoint
> > Ethernet MAC IP in the IP catalog) implements IEEE 802.1 Time Sensitive
> > Networking (TSN) Standards and provides a low latency Bridged Endpoint or
> > Endpoint only solutions.
>
> So an Endpoint only solution is not connected to the switch? It
> outputs RGMII, can have a PHY connected to it, and so is a single
> netdev interface? You would typically use this in a client?
>
> But you can also instantiate the same MAC multiple times, connected to
> an Ethernet switch? That would be the bridged endpoint?
>

Yes, that understanding is correct.
In Endpoint only configuration, the TSN Endpoint is connected Ethernet MAC and operates as a standalone MAC, connected via GMII/RGMII to a PHY,
and is exposed to Linux as a single netdev, similar to a conventional Ethernet controller.
In Bridged Endpoint (Switch Endpoint), two ports connects to the network and one port connects to an internal Endpoint.
The internal endpoint connects to the CPU and external ports connect to PHYs.

> > The bridged endpoint solution consists of a 3-port
> > switch that connects to an endpoint including Linux software drivers. For
> > Bridged Endpoint (Switch Endpoint), two ports connects to the network and
> > one port connects to an internal Endpoint.
>
> To the host, does the internal endpoint just look like a standard
> netdev?

Yes. From the host’s perspective, the internal endpoint is exposed as a standard Linux netdev.

>
> What i'm trying to do is get an answer to: Is this a DSA switch, or a
> pure switchdev switch. If the host sees a netdev which is connected to
> a port of the switch, it is probably a DSA switch. If the host only
> sees the user ports, it is probably a pure switchdev switch.
>

We are planning to implement a pure switchdev framework for the switch, as PTP packets are sent directly from
the netdev interfaces that represent the external network ports.
Please let me know your thoughts or suggestions if you feel a different approach would be more appropriate.

> > It supports the use of
> > GMII/RGMII interfaces connecting to a physical-side interface (PHY) chip
> > with full duplex 100 Mb/s and 1 Gb/s operations.
>
> No 10Mbps support?
Yes, that is correct. The current TSN Endpoint Ethernet MAC supports 100 Mb/s and 1 Gb/s full‑duplex modes only. 10 Mb/s operation is not supported by the underlying hardware IP.

>
> > - Provides feature rich Ethernet Switch that caters to various network
> >   needs
> >     * 3-port Switch (2-external, 1-internal)
> >     * Programmable cut-through and store-forward operations
> >     * 4-port Switch (2-external, 2-internal) extension through
> >           'Endpoint Extension' and 'Endpoint Packet Switching' features
>
> Why not N-ports? Is it really set to 3 or 4? It cannot be synthesised
> for 5, 8?
>

The number of ports is fixed by the IP configuration. The standard TSN Subsystem IP supports 3 port operation (2 external + 1 internal),
with an optional extension to 4 ports using endpoint extension features.
Arbitrary N‑port synthesis (for example 5 or 8 ports) is not supported.


> > Sample hardware architecture diagram for Bidge End Point like below:
> >
> >              +------------------+
> >              |      MCDMA       |
> >              +---------+--------+
> >                     Q0---Q7
> >                        |
> >           +------------------------------------------------------------ +
> >           |            |     TSN sub system(Bridge End Point)       |
> >           |            |                                                |
> >           |     +------+----+  Port 0   +-----------------------+       |
> >           |     |  EndPoint |<--------->|       TSN Switch      |       |
> >           |     |    (EP)   |           +----+-------------+----+       |
> >           |     +-----------+                |             |            |
> >           |                                  |             |            |
> >           |                              Port 1         Port 2          |
> >           |                                  |             |            |
> >           |                            +-----------+  +-----------+     |
> >           |                            |  MAC-1    |  |  MAC-2    |     |
> >           |                            |  (ETH1)   |  |  (ETH2)   |     |
> >           |                            +-----+-----+  +-----+-----+     |
> >       |                                  |              |           |
> >           |                              |              |           |
> >           +-------------------------------------------------------------+
> >                                              |              |
> >                                           RGMII           RGMII
> >                                              |              |
> >                                       +-----------+  +-----------+
> >                                       |  PHY1     |  |  PHY2     |
> >                                       | (Port 0)  |  | (Port 2)  |
> >                                       +-----------+  +-----------+
> >
>
> So how does the host send a frame out Port 2? Is there an extra header
> on the frame sent by EndPoint, which the switch interprets?
>

In this RFC, I configured all switch ports in forward mode. As a result, when a frame is sent from the internal endpoint, it is flooded to both external ports.
To forward packets to a specific port instead of flooding, either static switch CAM entries need to be configured or address learning should be enabled so the switch can learn CAM entries dynamically.


> FYI: Seems like PHY1 (port 0) is a typO.
>
Here, PHY1 (port 0) and PHY2 (port 2) represent the external daughter card ports that I connected to the IP for testing.
I realize this representation may be confusing, so I will remove these port references to avoid any confusion.

> > - During driver initialization, all switch ports (Endpoint, MAC1, MAC2)
> >   are configured into the Forwarding state to enable data flow across the
> >   fabric.
>
> Which is wrong. The Linux model is that switch ports are just
> netdevs. You configure them just like every other netdev in the
> system. Newly created netdevs are standalone. They only allow frames
> to pass between the wire and the host. If you want them to L2 forwards
> frames between ports you need to add them to a bridge.
>
>       Andrew
Currently, I have validated the behavior using forward mode. Based on the feedback, I will implement the required switch configuration changes in the next patch series.

Thanks
Neeli Srinivas