[U-Boot] [RFC PATCH v3 0/3] Felix Eth switch driver and questions on DSA switches
Alexandru Marginean
alexm.osslist at gmail.com
Fri Nov 15 17:27:36 UTC 2019
Hi Bin,
On 11/15/2019 3:32 PM, Bin Meng wrote:
> Hi Alex,
>
> On Fri, Nov 15, 2019 at 8:57 PM Alex Marginean
> <alexandru.marginean at nxp.com> wrote:
>>
>> The driver sets up the switch during probe making external and internal ports
>> available to use. It does not support direct I/O through these switch ports
>> in this version, instead ENETC ethernet interfaces that are internally linked to
>> the switch can be used after the switch is set up.
>>
>
> Thanks for the efforts!
>
>> This is where the RFC part comes in. Both the switch as a device and its ports
>> are probed as ethernet devices. That's handy as accessors to connect to the PHY
>> can be used on switch ports, but otherwise they are useless as the user can't
>> ping to these interfaces directly. We're not running STP in U-Boot either, so
>> turning on the switch is a problem if there are loops in the network.
>> The Linux driver for this piece of HW is now moving under DSA and this leads to
>> my question. Does anyone here think that DSA support is something useful in
>> U-Boot?
>>
>> DSA is described here:
>> https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
>>
>> From the doc:
>>
>> Summarized, this is basically how DSA looks like from a network device
>> perspective:
>>
>>
>> |---------------------------
>> | CPU network device (eth0)|
>> ----------------------------
>> | <tag added by switch |
>> | |
>> | |
>> | tag added by CPU> |
>> |--------------------------------------------|
>> | Switch driver |
>> |--------------------------------------------|
>> || || ||
>> |-------| |-------| |-------|
>> | sw0p0 | | sw0p1 | | sw0p2 |
>> |-------| |-------| |-------|
>>
>>
>> If we do DSA in U-Boot we would use the same bindings as in Linux. The switch
>
> From the perspective of reusing the same bindings as Linux, yes, I
> would like to see the same DSA support in U-Boot :)
Even without DSA and depending on the driver the Linux DT could work for
U-Boot as well. It's just that that DSA specific properties would be
ignored and the behavior in U-Boot could be different than the one in
Linux, depending on what exactly the driver does. The behavior part is
more likely to be a problem for users, not the binding itself.
In this driver we enable hardware switching which is fine in most cases
and allows tftp on any port, but can cause problems with network loops
since we don't run STP. Another U-Boot switch driver I looked at
doesn't have the network loop problem, but only works on port 0.
I think I'll give it a shot at prototyping some basic DSA support for
U-Boot, some of these differences in behavior can be quite annoying and
sooner or later they could cause problems.
Thanks!
Alex
>
>> would be associated with a master network device which is a regular ethernet,
>> this is part of the DSA binding in Linux.
>> Whenever the user pings through swp0pN in background that would _start swp0pN,
>> the switch port connected to the master network device and the master network
>> device (eth0 in the picture above). Any frames sent through a switch port would
>> have the DSA tag inserted and then actually sent though the mater network
>> device. Similarly for Rx, polling swp0pN would in fact poll on the master
>> network device and for any frame received the DSA code would check and remove
>> the DSA tag.
>> Switching between switch ports would be by default disabled.
>> This kind of switch drivers should go under a new class, DSA or ETH_DSA, or
>> something along those lines.
>>
>> I'd like to get some feedback from networking people on this list, if adding DSA
>> support in U-Boot is something that could be useful, or the existing support is
>> good enough. Currently U-Boot does support a few switches either as PHYs or
>> as ETH devices with various limitations. Feel free to share any thoughts on
>> this topic.
>>
>> With these patches applied the switch on LS1028A looks like this:
>>
>> => dm tree
>> Class Index Probed Driver Name
>> -----------------------------------------------------------
>> ....
>> pci 2 [ + ] pci_generic_ecam |-- pcie at 1f0000000
>> eth 1 [ + ] enetc_eth | |-- enetc-0
>> eth 2 [ + ] enetc_eth | |-- enetc-1
>> eth 3 [ + ] enetc_eth | |-- enetc-2
>> mdio 5 [ + ] enetc_mdio | |-- emdio-3
>> pci_generi 0 [ ] pci_generic_drv | |-- pci_3:0.4
>> eth 4 [ + ] felix_ethsw | |-- felix_ethsw
>> eth 6 [ + ] felix-port | | |-- port at 0
>> eth 7 [ + ] felix-port | | |-- port at 1
>> eth 8 [ + ] felix-port | | |-- port at 2
>> eth 9 [ + ] felix-port | | |-- port at 3
>> eth 10 [ + ] felix-port | | |-- port at 4
>> eth 11 [ + ] felix-port | | `-- port at 5
>> eth 5 [ + ] enetc_eth | |-- enetc-6
>> pci_generi 1 [ ] pci_generic_drv | `-- pci_3:1f.0
>>
>> => mdio list
>> felix_ethsw:
>> emdio-3:
>> mdio at 50:
>> 0 - Aquantia AQR412 <--> port at 0
>> 1 - Aquantia AQR412 <--> port at 1
>> 2 - Aquantia AQR412 <--> port at 2
>> 3 - Aquantia AQR412 <--> port at 3
>> mdio at 00:
>> 5 - AR8035 <--> enetc-1
>> mdio at 40:
>> 2 - Aquantia AQR112 <--> enetc-0
>> mdio at 60:
>> mdio at 70:
>>
>> Any feedback is welcome, of course
>>
>>
>> This patch set replaces this v2 series:
>> https://patchwork.ozlabs.org/project/uboot/list/?series=126977&state=*
>> and depends on:
>> https://patchwork.ozlabs.org/project/uboot/list/?series=142858
>> https://patchwork.ozlabs.org/project/uboot/list/?series=142879
>>
>> Thank you!
>
> Regards,
> Bin
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
More information about the U-Boot
mailing list