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

[Neeli, Srinivas]

On 3/5/2026 5:16 PM, Neeli, Srinivas wrote:
> Hi Andrew,
>
> On 2/20/2026 7:06 PM, Andrew Lunn wrote:
>> On Fri, Feb 20, 2026 at 12:59:16PM +0000, Neeli, Srinivas wrote:
>>> [AMD Official Use Only - AMD Internal Distribution Only]
>> Sorry, i'm not part of AMD...
>>
>>>> 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.
>> Despite not being part of AMD, this part is important.
>>
>> I don't care about how the RFC works, i want to know how the hardware
>> works, to ensure you have the correct choice of DSA vs pure switchdev.
>>
>> Take the example of running Spanning Tree Protocol. The bridge needs
>> to send the BPDU out a specific port. What mechanism is used to do
>> that? It also needs to know which port a BPDU ingressed.
>>
>>     Andrew
>
>
> Hi Andrew,
>
> I would like to briefly share an overview of our TSN switch 
> capabilities and seek your guidance on the most appropriate Linux 
> framework for the driver implementation specifically whether switchdev 
> or DSA would be the better fit.
>
> TSN Switch Capabilities
> -----------------------
> Our TSN subsystem supports the following IEEE TSN clauses:
>
> IEEE 802.1Qbv – Time-Aware Shaper (scheduled traffic using gate control)
> IEEE 802.1Qbu / IEEE 802.3br – Frame preemption
> IEEE 802.1Qci – Per-Stream Filtering and Policing (PSFP), including: 
> SDU-based filtering and Meter-based policing
> IEEE 802.1CB – Frame Replication and Elimination for Reliability (FRER)
> IEEE 802.1AS / IEEE 1588 – Time synchronization (PTP / gPTP)
>
> Hardware Architecture Overview
> ------------------------------
> The switch consists of three ports:
>
> Port 0: Connected to the CPU (control/endpoint port)
> Port 1: Connected to MAC1
> Port 2: Connected to MAC2
>
> MAC1 and MAC2 are capable of transmitting and receiving PTP packets, 
> with received packets stored in internal BRAM. They will not be 
> forwarded by switch to the internal endpoint (EP) and MAC network 
> drivers xmit's and receives the PTP frames.
> The switch forwards frames based on VLAN port membership and the CAM 
> entries and switch supports TSN features such as CBS, Qci (PSFP) and 
> 802.1CB (FRER) through hardware configuration.
> The CPU is intended to operate purely in the control plane and is not 
> part of the forwarding data path.
>
> Thank you very much for your time and guidance. Please let us know if 
> any additional details would be helpful.
>
>
> Best regards,
> Neeli Srinivas
>
Hi Andrew,

Based on the feedback so far, I am planning to proceed with a switchdev 
based implementation for the next RFC series, as this appears to be a 
better fit with the Linux networking model.
Please let me know if you have any concerns with this approach. If this 
direction is acceptable, I will share the next version of the RFC series 
accordingly.
Thank you for your guidance.

Best regards,
Neeli Srinivas