[RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC

[Florian Fainelli]

On 11/27/2020 4:33 PM, Lukasz Majewski wrote:
>> So why use DSA at all? What benefit does it bring you? Why not do the
>> entire switch configuration from within FEC, or a separate driver very
>> closely related to it?
> 
> Mine rationale to use DSA and FEC:
> - Make as little changes to FEC as possible

Which is entirely possible if you stick to Vladimir suggestions of
exporting services for the MTIP switch driver.

> 
> - Provide separate driver to allow programming FDB, MDB, VLAN setup.
>   This seems straightforward as MTIP has separate memory region (from
>   FEC) for switch configuration, statistics, learning, static table
>   programming. What is even more bizarre FEC and MTIP have the same 8
>   registers (with different base address and +4 offset :-) ) as
>   interface to handle DMA0 transfers.

OK, not sure how that is relevant here? The register organization should
never ever dictate how to pick a particular subsystem.

> 
> - According to MTIP description from NXP documentation, there is a
>   separate register for frame forwarding, so it _shall_ also fit into
>   DSA.

And yet it does not, Vladimir went into great length into explaining
what makes the MTIP + dual FEC different here and why it does not
qualify for DSA. Basically any time you have DMA + integrated switch
tightly coupled you have what we have coined a "pure switchdev" wrapper.

> 
> 
> For me it would be enough to have:
> 
> - lan{12} - so I could enable/disable it on demand (control when switch
>   ports are passing or not packets).
> 
> - Use standard net tools (like bridge) to setup FDB/MDB, vlan 
> 
> - Read statistics from MTIP ports (all of them)
> 
> - I can use lan1 (bridged or not) to send data outside. It would be
>   also correct to use eth0.

You know you can do that without having DSA, right? Look at mlxsw, look
at rocker. You can call multiple times register_netdevice() with custom
network devices that behave differently whether HW bridging offload is
offered or not, whether the switch is declared in Device Tree or not.

> 
> I'm for the most pragmatic (and simple) solution, which fulfill above
> requirements.

The most pragmatic solution is to implement switchdev operations to
offer HW bridging offload, VLAN programming, FDB/MDB programming.

It seems to me that you are trying to look for a framework to avoid
doing a bit of middle layer work between switchdev and the FEC driver
and that is not setting you for success.
-- 
Florian