linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Michael Walle <michael@walle.cc>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Shawn Guo <shawnguo@kernel.org>, Leo Li <leoyang.li@nxp.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH devicetree] arm64: dts: ls1028a-rdb: add more ethernet aliases
Date: Wed, 7 Sep 2022 13:07:30 +0000	[thread overview]
Message-ID: <20220907130729.whphxfmcp7odwkkf@skbuf> (raw)
In-Reply-To: <eaa92fcc134df14714f9d14635e551a1@walle.cc>

On Wed, Sep 07, 2022 at 10:56:37AM +0200, Michael Walle wrote:
> > > I think we are on the same track here. I was ignoring any VFs for now.
> > > So I guess, what I'm still missing here is why enet#2 and enet#3 (or
> > > even swp4 and swp5) would need a non-random MAC address. Except from
> > > your example above. Considering the usecase where swp0..3 is one bridge
> > > with eno2 and eno3 being the CPU ports. Then I'd only need a unique
> > > MAC address for eno0, eno1 and swp0, correct?
> > 
> > Don't say "unique MAC address for swp0", since swp0's MAC address is not
> > unique, you probably mean to say "a MAC address which will be shared by
> > swp0-swp3".
> 
> That I actually don't understand. I have the following addresses after
> booting:
> 
> # ip link
> ..
> 4: gbe0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
> default qlen 1000
>     link/ether 00:a0:a5:5c:6b:62 brd ff:ff:ff:ff:ff:ff
>     inet 172.16.1.2/24 scope global gbe0
>        valid_lft forever preferred_lft forever
>     inet6 fe80::2a0:a5ff:fe5c:6b62/64 scope link
>        valid_lft forever preferred_lft forever
> 5: gbe1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
> qlen 1000
>     link/ether 00:a0:a5:5c:6b:63 brd ff:ff:ff:ff:ff:ff
> 6: eno2: <BROADCAST,MULTICAST> mtu 1504 qdisc noop state DOWN group default
> qlen 1000
>     link/ether 8e:6c:20:8a:ab:52 brd ff:ff:ff:ff:ff:ff
> 7: eno3: <BROADCAST,MULTICAST> mtu 1504 qdisc noop state DOWN group default
> qlen 1000
>     link/ether c6:fd:b1:88:3c:36 brd ff:ff:ff:ff:ff:ff
> 8: swp0@eno2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
>     link/ether 00:a0:a5:5c:6b:66 brd ff:ff:ff:ff:ff:ff
> 9: swp1@eno2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
>     link/ether 00:a0:a5:5c:6b:67 brd ff:ff:ff:ff:ff:ff
> 10: swp2@eno2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
>     link/ether 00:a0:a5:5c:6b:68 brd ff:ff:ff:ff:ff:ff
> 11: swp3@eno2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
> group default qlen 1000
>     link/ether 00:a0:a5:5c:6b:69 brd ff:ff:ff:ff:ff:ff
> 
> gbe0 is eno0 and gbe1 is eno1. So in my case they are unique.
> 
> When adding all the ports to a bridge, the bridge gets the lowest MAC.
> 
> # ip link add name br0 type bridge
> # ip link set swp0 master br0
> # ip link set swp1 master br0
> # ip link set swp2 master br0
> # ip link set swp3 master br0
> 
> 12: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> group default qlen 1000
>     link/ether 00:a0:a5:5c:6b:66 brd ff:ff:ff:ff:ff:ff
> 
> Is that what you mean with "a MAC address which will be shared by
> swp0-swp3"?

No, what I'm trying is only to reformulate what you've said, "Then I'd
only need a unique MAC address for eno0, eno1 and swp0". My understanding
of what you mean by "unique address for swp0" is that the addresses for
swp1-swp3 don't matter (hence they can be set to the same address as swp0)
since there will be a bridge that serves as the IP termination point,
with its own MAC address, inherited from the first bridge port, swp0.
But this makes it improper to call it a "unique address for swp0".
_______________________________________________
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-07 13:08 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
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 [this message]
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=20220907130729.whphxfmcp7odwkkf@skbuf \
    --to=vladimir.oltean@nxp.com \
    --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=michael@walle.cc \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    /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).