All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
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".

  reply	other threads:[~2022-09-07 13:08 UTC|newest]

Thread overview: 16+ 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 21:24 ` Vladimir Oltean
2022-09-05 22:17 ` Michael Walle
2022-09-05 22:17   ` Michael Walle
2022-09-05 23:54   ` Vladimir Oltean
2022-09-05 23:54     ` Vladimir Oltean
2022-09-06  8:10     ` Michael Walle
2022-09-06  8:10       ` Michael Walle
2022-09-06 10:05       ` Vladimir Oltean
2022-09-06 10:05         ` Vladimir Oltean
2022-09-07  8:56         ` Michael Walle
2022-09-07  8:56           ` Michael Walle
2022-09-07 13:07           ` Vladimir Oltean [this message]
2022-09-07 13:07             ` Vladimir Oltean
2022-09-12  9:26 ` Shawn Guo
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.