Re: [PATCH net] net: renesas: rswitch: fix forwarding offload statemachine

DSA switches handle the CPU port in a few different ways:

* They do address learning, so learn what MAC addresses are in the
   direction of the CPU from the traffic sent by the CPU.

rswitch does not support hardware learning on CPU port.

To make use of L2 forwarding to CPU port, one has to add destinations to MAC table manually.

* All frames with a destination MAC address not in the address
   translation unit get sent to the CPU. This is sometimes implicit,
   the CPU is included in the flood for unknown MAC addresses, or there
   is an explicit bit to enable this.  The software bridge will then
   handle the frame. The reply, if there is one, should then trigger
   address learning.

rswitch does not do anything implicitly, each frame is processed by trying in order:
- match it against "streams" in L3 table,
- match it against destination addresses in L2 table,
- match it against VLAN table (VLAN id only),
- try port-based forwarding (i.e. common rule for anything coming from particular ingress port)

At each of this level, it is possible to configure one or several destinations to forward frame to.
Flooding can be implemented e.g. by configuring "port based" for each port to forward to all other 
ports, so if a frame is matched at earlier stages then it is processed per what is defined there, and if 
not then it is flooded.

* The switch driver taps into the events the software bridge issues as
   it does address learning. This allows the switch to setup its
   address translation tables to mirror the software switch.

For rswitch there is no easy way to sync hardware-learned L2 entries to software.
There are no notifications of hardware updates.

Options are:
- either periodically scan hardware table, or
- disable hardware learning at all and send any unknown frames to software bridge, so it learns, and 
then handle notifications about that and manually update hardware table.

The existing implementation does not try to sync sw and hw tables at all.

The overall result is that having just one switch port in the bridge
is no different to having multiple switch ports in the bridge.

In my original driver, I enabled L2 forwarding only when at least two ports have been participating.
I don't see rationale for doing differently on this hardware.
But Renesas can have a different view on this.

Nikita