linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org,
	Shawn Guo <shawnguo@kernel.org>, Li Yang <leoyang.li@nxp.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH devicetree] arm64: dts: ls1028a-rdb: add more ethernet aliases
Date: Tue, 06 Sep 2022 00:17:29 +0200	[thread overview]
Message-ID: <d00682d7e7aec2f979236338e7b3a688@walle.cc> (raw)
In-Reply-To: <20220905212458.1549179-1-vladimir.oltean@nxp.com>

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@walle.cc/

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@nxp.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-09-05 22:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 21:24 [PATCH devicetree] arm64: dts: ls1028a-rdb: add more ethernet aliases Vladimir Oltean
2022-09-05 22:17 ` Michael Walle [this message]
2022-09-05 23:54   ` Vladimir Oltean
2022-09-06  8:10     ` Michael Walle
2022-09-06 10:05       ` Vladimir Oltean
2022-09-07  8:56         ` Michael Walle
2022-09-07 13:07           ` Vladimir Oltean
2022-09-12  9:26 ` Shawn Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d00682d7e7aec2f979236338e7b3a688@walle.cc \
    --to=michael@walle.cc \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).