This series adds support for switch-mode for ICSSG driver. This series
also introduces helper APIs to configure firmware maintained FDB
(Forwarding Database) and VLAN tables. These APIs are later used by ICSSG
driver in switch mode.
Now the driver will boot by default in dual EMAC mode. When first ICSSG
interface is added to bridge driver will still be in EMAC mode. As soon as
second ICSSG interface is added to same bridge, switch-mode will be
enabled and switch firmwares will be loaded to PRU cores. The driver will
remain in dual EMAC mode if ICSSG interfaces are added to two different
bridges or if two differnet interfaces (One ICSSG, one other) is added to
the same bridge. We'll only enable is_switch_mode flag when two ICSSG
interfaces are added to same bridge.
We start in dual MAC mode. Let's say lan0 and lan1 are ICSSG interfaces
ip link add name br0 type bridge
ip link set lan0 master br0
At this point, we get a CHANGEUPPER event. Only one port is a member of
the bridge, so we will still be in dual MAC mode.
ip link set lan1 master br0
We get a second CHANGEUPPER event, the secind interface lan1 is also ICSSG
interface so we will set the is_switch_mode flag and when interfaces are
brought up again, ICSSG switch firmwares will be loaded to PRU Cores.
There are some other cases to consider as well.
ip link add name br0 type bridge
ip link add name br1 type bridge
ip link set lan0 master br0
ip link set ppp0 master br0
Here we are adding lan0 (ICSSG) and ppp0 (non ICSSG) to same bridge, as
they both are not ICSSG, we will still be running in dual EMAC mode.
ip link set lan1 master br1
ip link set vpn0 master br1
Here we are adding lan1 (ICSSG) and vpn0 (non ICSSG) to same bridge, as
they both are not ICSSG, we will still be running in dual EMAC mode.
This is v2 of the series [1]. It addresses commenst made on v1 [1].
Changes from v1 to v2:
*) Removed TAPRIO support patch from this series.
*) Stopped using devlink for enabling switch-mode as suggested by Andrew L
*) Added read_poll_timeout() in patch 1 / 3 as suggested by Andrew L.
[1] https://lore.kernel.org/all/[email protected]/
Thanks and Regards,
Md Danish Anwar
MD Danish Anwar (3):
net: ti: icssg-prueth: Add helper functions to configure FDB
net: ti: icssg-switch: Add switchdev based driver for ethernet switch
support
net: ti: icssg-prueth: Add support for ICSSG switch firmware
drivers/net/ethernet/ti/Kconfig | 1 +
drivers/net/ethernet/ti/Makefile | 3 +-
drivers/net/ethernet/ti/icssg/icssg_config.c | 324 +++++++++++-
drivers/net/ethernet/ti/icssg/icssg_config.h | 26 +
drivers/net/ethernet/ti/icssg/icssg_prueth.c | 199 +++++++-
drivers/net/ethernet/ti/icssg/icssg_prueth.h | 36 ++
.../net/ethernet/ti/icssg/icssg_switchdev.c | 478 ++++++++++++++++++
.../net/ethernet/ti/icssg/icssg_switchdev.h | 13 +
8 files changed, 1067 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/ethernet/ti/icssg/icssg_switchdev.c
create mode 100644 drivers/net/ethernet/ti/icssg/icssg_switchdev.h
--
2.34.1
On Thu, Jan 18, 2024 at 12:40:02PM +0530, MD Danish Anwar wrote:
> This series adds support for switch-mode for ICSSG driver. This series
> also introduces helper APIs to configure firmware maintained FDB
> (Forwarding Database) and VLAN tables. These APIs are later used by ICSSG
> driver in switch mode.
>
> Now the driver will boot by default in dual EMAC mode. When first ICSSG
> interface is added to bridge driver will still be in EMAC mode. As soon as
> second ICSSG interface is added to same bridge, switch-mode will be
> enabled and switch firmwares will be loaded to PRU cores. The driver will
> remain in dual EMAC mode if ICSSG interfaces are added to two different
> bridges or if two differnet interfaces (One ICSSG, one other) is added to
> the same bridge. We'll only enable is_switch_mode flag when two ICSSG
> interfaces are added to same bridge.
>
> We start in dual MAC mode. Let's say lan0 and lan1 are ICSSG interfaces
>
> ip link add name br0 type bridge
> ip link set lan0 master br0
>
> At this point, we get a CHANGEUPPER event. Only one port is a member of
> the bridge, so we will still be in dual MAC mode.
>
> ip link set lan1 master br0
>
> We get a second CHANGEUPPER event, the secind interface lan1 is also ICSSG
> interface so we will set the is_switch_mode flag and when interfaces are
> brought up again, ICSSG switch firmwares will be loaded to PRU Cores.
>
> There are some other cases to consider as well.
>
> ip link add name br0 type bridge
> ip link add name br1 type bridge
>
> ip link set lan0 master br0
> ip link set ppp0 master br0
>
> Here we are adding lan0 (ICSSG) and ppp0 (non ICSSG) to same bridge, as
> they both are not ICSSG, we will still be running in dual EMAC mode.
>
> ip link set lan1 master br1
> ip link set vpn0 master br1
>
> Here we are adding lan1 (ICSSG) and vpn0 (non ICSSG) to same bridge, as
> they both are not ICSSG, we will still be running in dual EMAC mode.
This is going in the right direction, thanks for the changes.
What features does the dual EMAC firmware support which the switch
firmware does not?
If such features are in use, you should not reload firmware to the
switch firmware, since it will break whatever has been
configured. Keep with bridging in software.
Similarly, what features are supported by both firmwares? Does feature
configuration survive a firmware reload? Or is it necessary to pass
all the configuration to the firmware again?
Andrew
On 18/01/24 7:31 pm, Andrew Lunn wrote:
> On Thu, Jan 18, 2024 at 12:40:02PM +0530, MD Danish Anwar wrote:
>> This series adds support for switch-mode for ICSSG driver. This series
>> also introduces helper APIs to configure firmware maintained FDB
>> (Forwarding Database) and VLAN tables. These APIs are later used by ICSSG
>> driver in switch mode.
>>
>> Now the driver will boot by default in dual EMAC mode. When first ICSSG
>> interface is added to bridge driver will still be in EMAC mode. As soon as
>> second ICSSG interface is added to same bridge, switch-mode will be
>> enabled and switch firmwares will be loaded to PRU cores. The driver will
>> remain in dual EMAC mode if ICSSG interfaces are added to two different
>> bridges or if two differnet interfaces (One ICSSG, one other) is added to
>> the same bridge. We'll only enable is_switch_mode flag when two ICSSG
>> interfaces are added to same bridge.
>>
>> We start in dual MAC mode. Let's say lan0 and lan1 are ICSSG interfaces
>>
>> ip link add name br0 type bridge
>> ip link set lan0 master br0
>>
>> At this point, we get a CHANGEUPPER event. Only one port is a member of
>> the bridge, so we will still be in dual MAC mode.
>>
>> ip link set lan1 master br0
>>
>> We get a second CHANGEUPPER event, the secind interface lan1 is also ICSSG
>> interface so we will set the is_switch_mode flag and when interfaces are
>> brought up again, ICSSG switch firmwares will be loaded to PRU Cores.
>>
>> There are some other cases to consider as well.
>>
>> ip link add name br0 type bridge
>> ip link add name br1 type bridge
>>
>> ip link set lan0 master br0
>> ip link set ppp0 master br0
>>
>> Here we are adding lan0 (ICSSG) and ppp0 (non ICSSG) to same bridge, as
>> they both are not ICSSG, we will still be running in dual EMAC mode.
>>
>> ip link set lan1 master br1
>> ip link set vpn0 master br1
>>
>> Here we are adding lan1 (ICSSG) and vpn0 (non ICSSG) to same bridge, as
>> they both are not ICSSG, we will still be running in dual EMAC mode.
>
> This is going in the right direction, thanks for the changes.
>
> What features does the dual EMAC firmware support which the switch
> firmware does not?
>
Feature wise, there is no major feature that EMAC firmware supports and
switch firmware doesn't.
The major difference between EMAC and switch firmware is that switch
firmware can do forwarding between ports which EMAC firmware can't. Data
is directly forwarded to DMA in dual EMAC mode. Whereas switch firmware
forwards the data to DMA as well as the other port depending upon the
configured rules. The forwarding path between one port to other is not
present in dual EMAC firmware. There are additional checks in switch
firmware to decide forwarding which also results in consuming extra cpu
cycle.
In dual EMAC mode, data is directly forwarded to DMA and a lot of checks
are removed resulting in less cpu cycle consumption.
> If such features are in use, you should not reload firmware to the
> switch firmware, since it will break whatever has been
> configured. Keep with bridging in software.
>
There are no such features so I think it's safe to reload the switch
firmware when two ICSSG interfaces are added to the same bridge.
> Similarly, what features are supported by both firmwares? Does feature
> configuration survive a firmware reload? Or is it necessary to pass
> all the configuration to the firmware again?
>
Some configurations doesn't need to be passed again. Any changes to MSMC
will still be valid after firmware reload. But FDB, r30 commands will be
lost and will be needed to reconfigured. So all FDB entries and r30
commands will need to be run again.
> Andrew
--
Thanks and Regards,
Danish