[U-Boot] [PATCH v2 1/6] net: introduce DSA class for Ethernet switches

[Florian Fainelli]

On 11/30/2019 6:21 PM, Alexandru Marginean wrote:
> Hi Joe,
> 
> On 11/30/2019 1:56 AM, Joe Hershberger wrote:
>> Hi Alex,
>>
>> On Mon, Nov 25, 2019 at 9:54 AM Alex Marginean
>> <alexandru.marginean at nxp.com> wrote:
>>>
>>> DSA stands for Distributed Switch Architecture and it covers switches
>>> that
>>> are connected to the CPU through an Ethernet link and generally use
>>> frame
>>> tags to pass information about the source/destination ports to/from CPU.
>>> Front panel ports are presented as regular ethernet devices in U-Boot
>>> and
>>> they are expected to support the typical networking commands.
>>> DSA switches may be cascaded, DSA class code does not currently support
>>> this.
>>
>> Is it expected to eventually retrofit the other switch drivers that we
>> have in U-Boot to use this?
> 
> For now I would like to at least make sure that the uclass code allows
> that to happen.  Longer term yes, it would be nice to get existing
> drivers converted.  This is applicable to switches that rely on a master
> Eth device for I/O.  The list should include switches that use DSA in
> kernel, of course:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa
> 
> 
> Some of these are under PHYs in U-Boot right now (like b53, mv88exxx),
> hooked up to the master Eth.  This works, but comes with limitations,
> like this in b53 driver:
>  * The configuration determines which PHY ports to activate using the
>  * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
> Having these drivers converted should come with some benefits:
> - their DT nodes would be in sync with the kernel DSA bindings,
> - users would have some run-time control over the switch ports used for
> I/O,
> - driving PHYs of front panel ports comes more naturally with these
> ports being registered as eth devices.
> 
> There are other switches which don't fall under DSA, those that present
> some sort of direct I/O interface to the CPU and don't rely on a master
> Eth device.  These switched may not follow DSA bindings, since they are
> not technically DSA.  For them we could either have a more generic Eth
> switch class or just let the drivers register the switch device or the
> ports on the switch as Eth devices.

The Device Tree binding for DSA is actually fairly generic within the
'ports' container node, if you omit the ethernet phandle, this still
allows you to describe a multi-port Ethernet switch with the data path
being contained solely within the switch node and not spread across a
DSA master and a discrete switch. At least, this could be a starting point.
-- 
Florian