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

[Alexandru Marginean <alexm.osslist@gmail.com>]

On 12/1/2019 5:17 AM, Florian Fainelli wrote:
> 
> 
> 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@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.
> 

It is, I don't disagree with that.  My argument is DSA-like binding 
isn't enforced in kernel tree for non-DSA switches (is it?) and allowing 
U-Boot to use existing kernel DTs for non-DSA switches is a good thing.

Binding aside I still think DSA should be a class of its own in U-Boot. 
There are differences in the API between DSA ports and Eth devices and 
DSA uclass has the code dealing with master Eth, which is useless for 
non-DSA.  I think this way the code and the interface to the drivers is 
simpler and more clear.

Alex