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/driv...
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.