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.margin...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to