Am 2022-09-05 23:24, schrieb Vladimir Oltean:
Commit "arm64: dts: ls1028a: enable swp5 and eno3 for all boards" which
Shawn declared as applied, but for which I can't find a sha1sum, has
enabled a new Ethernet port on the LS1028A-RDB (&enetc_port3), but
U-Boot, which passes a MAC address to Linux' device tree through the
/aliases node, fails to do this for this newly enabled port.
Fix that by adding more ethernet aliases in the only
backwards-compatible way possible: at the end of the current list.
And since it is possible to very easily convert either swp4 or swp5 to
DSA user ports now (which have a MAC address of their own), using these
U-Boot commands:
=> fdt addr $fdt_addr_r
=> fdt rm /soc/pcie@1f0000000/ethernet-switch@0,5/ports/port@4 ethernet
it would be good if those DSA user ports (swp4, swp5) gained a valid
MAC
address from U-Boot as well. In order for that to work properly,
provision two more ethernet aliases for &mscc_felix_port{4,5} as well.
First, let me say, I'm fine with this patch. But I'm not sure,
how many MAC addresses are actually reserved on your
RDB/QDS boards? I guess, they being evaluation boards you
don't care? ;)
On the Kontron sl28 boards we reserve just 8 and that is
already a lot for a board with max 6 out facing ports. 4 of
these ports used to be a switch, so in theory it should work
with 3 MAC addresses, right? Or even just 2 if there is no
need to terminate any traffic on the switch interfaces.
Anyway, do we really need so many addresses? What are the
configurations here? For what is the address of the
internal ports used?
Let's say we are in the "port extender mode" and use the
second internal port as an actual switch port, that would
then be:
2x external enetc
1x internal enetc
4x external switch ports in port extender mode
Which makes 7 addresses. The internal enetc port doesn't
really make sense in a port extender mode, because there
is no switching going on. So uhm, 6 addresses are the
maximum?
This is the MAC address distribution for now on the
sl28 boards:
https://lore.kernel.org/linux-devicetree/20220901221857.2600340-19-michael@xxxxxxxx/
Please tell me if I'm missing something here.
-michael
The resulting ordering is slightly unusual, but to me looks more
natural
than eno0, eno2, swp0, swp1, swp2, swp3, eno3, swp4, swp5.
Signed-off-by: Vladimir Oltean <vladimir.oltean@xxxxxxx>
