Hi,

The DUAL-EMAC patch series for Megabit Industrial Communication Sub-system
(ICSSM), which provides the foundational support for Ethernet functionality
over PRU-ICSS on the TI SOCs (AM335x, AM437x, and AM57x), was merged into
net-next recently [1].

This patch series enhances the PRU-ICSSM Ethernet driver to support
RSTP SWITCH mode, which has been implemented based on "switchdev" and
interacts with "mstp daemon" to support Rapid Spanning Tree Protocol
(RSTP) as well.

Once the RSTP SWITCH mode is enabled, forwarding of Ethernet packets using
either the traditional store-and-forward mechanism or via cut-through is
offloaded to the two PRU based Ethernet interfaces available within the
ICSSM. The firmware running on the PRU inspects the STP port states and
performs multiple checks before forwarding a packet. This improves the
overall system performance and significantly reduces the packet forwarding
latency.

Protocol switching from dual EMAC to RSTP SWITCH mode can be done as follows.

Assuming eth2 and eth3 are the two physical ports of the ICSS2 instance:

>> brctl addbr br0
>> ip maddr add 01:80:c2:00:00:00 dev br0
>> ip link set dev br0 address $(cat /sys/class/net/eth2/address)
>> brctl addif br0 eth2
>> brctl addif br0 eth3
>> mstpd
>> brctl stp br0 on
>> mstpctl setforcevers br0 rstp
>> ip link set dev br0 up

To revert back to the default dual EMAC mode, the steps are as follows:

>> ip link set dev br0 down
>> brctl delif br0 eth2
>> brctl delif br0 eth3
>> brctl delbr br0

The patches presented in this series have gone through the patch verification
tools and no warnings or errors are reported.

Sample test logs obtained from AM33x, AM43x and AM57x verifying the
functionality on Linux next kernel are available here:

[Interface up Testing](https://gist.github.com/ParvathiPudi/ee90d6f7778f01660eec714d128ee224)

[Ping Testing](https://gist.github.com/ParvathiPudi/ea7fc58da454b9c1d15517f84a502ae2)

[Iperf Testing](https://gist.github.com/ParvathiPudi/505d8c6e9de231098215c59b66dee20b)

[1] https://lore.kernel.org/all/20250912104741.528721-1-parvathi@couthit.com/

Thanks and Regards,
Parvathi.

Roger Quadros (3):
  net: ti: icssm-prueth: Adds helper functions to configure and maintain
    FDB
  net: ti: icssm-prueth: Adds switchdev support for icssm_prueth driver
  net: ti: icssm-prueth: Adds support for ICSSM RSTP switch

 drivers/net/ethernet/ti/Makefile              |   2 +-
 drivers/net/ethernet/ti/icssm/icssm_prueth.c  | 554 +++++++++-
 drivers/net/ethernet/ti/icssm/icssm_prueth.h  |  27 +-
 .../ethernet/ti/icssm/icssm_prueth_fdb_tbl.h  |  66 ++
 .../ethernet/ti/icssm/icssm_prueth_switch.c   | 999 ++++++++++++++++++
 .../ethernet/ti/icssm/icssm_prueth_switch.h   |  37 +
 drivers/net/ethernet/ti/icssm/icssm_switch.h  |  82 ++
 .../net/ethernet/ti/icssm/icssm_switchdev.c   | 332 ++++++
 .../net/ethernet/ti/icssm/icssm_switchdev.h   |  13 +
 .../ti/icssm/icssm_vlan_mcast_filter_mmap.h   | 120 +++
 10 files changed, 2209 insertions(+), 23 deletions(-)
 create mode 100644 drivers/net/ethernet/ti/icssm/icssm_prueth_fdb_tbl.h
 create mode 100644 drivers/net/ethernet/ti/icssm/icssm_prueth_switch.c
 create mode 100644 drivers/net/ethernet/ti/icssm/icssm_prueth_switch.h
 create mode 100644 drivers/net/ethernet/ti/icssm/icssm_switchdev.c
 create mode 100644 drivers/net/ethernet/ti/icssm/icssm_switchdev.h
 create mode 100644 drivers/net/ethernet/ti/icssm/icssm_vlan_mcast_filter_mmap.h

-- 
2.43.0

On Thu, Sep 25, 2025 at 07:32:09PM +0530, Parvathi Pudi wrote:
> Hi,
> 
> The DUAL-EMAC patch series for Megabit Industrial Communication Sub-system
> (ICSSM), which provides the foundational support for Ethernet functionality
> over PRU-ICSS on the TI SOCs (AM335x, AM437x, and AM57x), was merged into
> net-next recently [1].
> 
> This patch series enhances the PRU-ICSSM Ethernet driver to support
> RSTP SWITCH mode, which has been implemented based on "switchdev" and
> interacts with "mstp daemon" to support Rapid Spanning Tree Protocol
> (RSTP) as well.

Is there anything in this patchset which is specific to RSTP? In
general, there is no difference between STP and RSTP. STP is generally
done in the kernel as part of the kernel bridge code. RSTP does it in
user space. But the hardware driver does not care if it is STP or
RSTP, it is the same API to the layer above.

	Andrew

Hi,

> On Thu, Sep 25, 2025 at 07:32:09PM +0530, Parvathi Pudi wrote:
>> Hi,
>> 
>> The DUAL-EMAC patch series for Megabit Industrial Communication Sub-system
>> (ICSSM), which provides the foundational support for Ethernet functionality
>> over PRU-ICSS on the TI SOCs (AM335x, AM437x, and AM57x), was merged into
>> net-next recently [1].
>> 
>> This patch series enhances the PRU-ICSSM Ethernet driver to support
>> RSTP SWITCH mode, which has been implemented based on "switchdev" and
>> interacts with "mstp daemon" to support Rapid Spanning Tree Protocol
>> (RSTP) as well.
> 
> Is there anything in this patchset which is specific to RSTP? In
> general, there is no difference between STP and RSTP. STP is generally
> done in the kernel as part of the kernel bridge code. RSTP does it in
> user space. But the hardware driver does not care if it is STP or
> RSTP, it is the same API to the layer above.
> 
> 	Andrew

No, this patch-set applies to both STP and RSTP. The driver and firmware
responds to the port-state transitions and FDB operations through the
standard Linux switchdev/bridge interfaces, with no STP/RSTP related
logic executed in driver/firmware.

We referred to RSTP in the commit message as it is our primary use case
and it implies support for STP as well.


Thanks and Regards,
Parvathi.

> No, this patch-set applies to both STP and RSTP. The driver and firmware
> responds to the port-state transitions and FDB operations through the
> standard Linux switchdev/bridge interfaces, with no STP/RSTP related
> logic executed in driver/firmware.
> 
> We referred to RSTP in the commit message as it is our primary use case
> and it implies support for STP as well.

I would not say RSTP implied STP, because the higher level
implementation is very different. You need to know the low level
details to understand they use the same driver API.

Please generalise the commit messages, mention STP as well as RSTP.

Thanks
	Andrew

Hi,

>> No, this patch-set applies to both STP and RSTP. The driver and firmware
>> responds to the port-state transitions and FDB operations through the
>> standard Linux switchdev/bridge interfaces, with no STP/RSTP related
>> logic executed in driver/firmware.
>> 
>> We referred to RSTP in the commit message as it is our primary use case
>> and it implies support for STP as well.
> 
> I would not say RSTP implied STP, because the higher level
> implementation is very different. You need to know the low level
> details to understand they use the same driver API.
> 
> Please generalise the commit messages, mention STP as well as RSTP.
> 
> Thanks
> 	Andrew

Understood, we will update the commit message in the next version.


Thanks and Regards,
Parvathi.