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.margin...@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@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@0
eth 7 [ + ] felix-port | | |-- port@1
eth 8 [ + ] felix-port | | |-- port@2
eth 9 [ + ] felix-port | | |-- port@3
eth 10 [ + ] felix-port | | |-- port@4
eth 11 [ + ] felix-port | | `-- port@5
eth 5 [ + ] enetc_eth | |-- enetc-6
pci_generi 1 [ ] pci_generic_drv | `-- pci_3:1f.0
=> mdio list
felix_ethsw:
emdio-3:
mdio@50:
0 - Aquantia AQR412 <--> port@0
1 - Aquantia AQR412 <--> port@1
2 - Aquantia AQR412 <--> port@2
3 - Aquantia AQR412 <--> port@3
mdio@00:
5 - AR8035 <--> enetc-1
mdio@40:
2 - Aquantia AQR112 <--> enetc-0
mdio@60:
mdio@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@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
