From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandru Marginean Date: Mon, 2 Dec 2019 13:59:44 +0100 Subject: [U-Boot] [PATCH v2 1/6] net: introduce DSA class for Ethernet switches In-Reply-To: References: <20191125155316.12744-1-alexandru.marginean@nxp.com> <20191125155316.12744-2-alexandru.marginean@nxp.com> <5d1f12ae-ff6d-60a9-f64e-18f1fbb5f1fc@gmail.com> Message-ID: <2a80edb4-ebe7-ce60-1fa1-1389e7e7d545@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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 >>> 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