From: Vladimir Oltean <olteanv@gmail.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Marek Behún" <kabel@kernel.org>, "Rob Herring" <robh@kernel.org>,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
"Arınç ÜNAL" <arinc.unal@arinc9.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
Date: Sun, 4 Dec 2022 20:59:24 +0200 [thread overview]
Message-ID: <20221204185924.a4q6cifhpyxaur6f@skbuf> (raw)
In-Reply-To: <20221202193552.vehqk6u53n36zxwl@pali>
Hi Pali,
On Fri, Dec 02, 2022 at 08:35:52PM +0100, Pali Rohár wrote:
> On Thursday 01 December 2022 17:44:00 Rob Herring wrote:
> > On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> > > I was told by Marek (CCed) that DSA port connected to CPU should have
> > > label "cpu" and not "cpu<number>". Modern way for specifying CPU port is
> > > by defining reference to network device, which there is already (&enet1
> > > and &enet0). So that change just "fixed" incorrect naming cpu0 and cpu1.
> > >
> > > So probably linux kernel does not need label = "cpu" in DTS anymore. But
> > > this is not the reason to remove this property. Linux kernel does not
> > > use lot of other nodes and properties too... Device tree should describe
> > > hardware and not its usage in Linux. "label" property is valid in device
> > > tree and it exactly describes what or where is this node connected. And
> > > it may be used for other systems.
> > >
> > > So I do not see a point in removing "label" properties from turris1x.dts
> > > file, nor from any other dts file.
> >
> > Well, it seems like a bit of an abuse of 'label' to me. 'label' should
> > be aligned with a sticker or other identifier identifying something to a
> > human. Software should never care what the value of 'label' is.
>
> But it already does. "label" property is used for setting (initial)
> network interface name for DSA drivers. And you can try to call e.g.
> git grep '"cpu"' net/dsa drivers/net/dsa to see that cpu is still
> present on some dsa places (probably relict or backward compatibility
> before eth reference).
Can you try to eliminate the word "probably" from the information you
transmit and be specific about when did the DSA binding parse or require
the 'label = "cpu"' property for CPU ports in any way?
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Rob Herring" <robh@kernel.org>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Arınç ÜNAL" <arinc.unal@arinc9.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
"Marek Behún" <kabel@kernel.org>
Subject: Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
Date: Sun, 4 Dec 2022 20:59:24 +0200 [thread overview]
Message-ID: <20221204185924.a4q6cifhpyxaur6f@skbuf> (raw)
In-Reply-To: <20221202193552.vehqk6u53n36zxwl@pali>
Hi Pali,
On Fri, Dec 02, 2022 at 08:35:52PM +0100, Pali Rohár wrote:
> On Thursday 01 December 2022 17:44:00 Rob Herring wrote:
> > On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> > > I was told by Marek (CCed) that DSA port connected to CPU should have
> > > label "cpu" and not "cpu<number>". Modern way for specifying CPU port is
> > > by defining reference to network device, which there is already (&enet1
> > > and &enet0). So that change just "fixed" incorrect naming cpu0 and cpu1.
> > >
> > > So probably linux kernel does not need label = "cpu" in DTS anymore. But
> > > this is not the reason to remove this property. Linux kernel does not
> > > use lot of other nodes and properties too... Device tree should describe
> > > hardware and not its usage in Linux. "label" property is valid in device
> > > tree and it exactly describes what or where is this node connected. And
> > > it may be used for other systems.
> > >
> > > So I do not see a point in removing "label" properties from turris1x.dts
> > > file, nor from any other dts file.
> >
> > Well, it seems like a bit of an abuse of 'label' to me. 'label' should
> > be aligned with a sticker or other identifier identifying something to a
> > human. Software should never care what the value of 'label' is.
>
> But it already does. "label" property is used for setting (initial)
> network interface name for DSA drivers. And you can try to call e.g.
> git grep '"cpu"' net/dsa drivers/net/dsa to see that cpu is still
> present on some dsa places (probably relict or backward compatibility
> before eth reference).
Can you try to eliminate the word "probably" from the information you
transmit and be specific about when did the DSA binding parse or require
the 'label = "cpu"' property for CPU ports in any way?
next prev parent reply other threads:[~2022-12-04 19:00 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 14:10 [PATCH 0/5] remove label = "cpu" from DSA dt-binding Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` [PATCH 1/5] dt-bindings: net: qca,ar71xx: remove label = "cpu" from examples Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 23:46 ` Rob Herring
2022-12-01 23:46 ` Rob Herring
2022-12-01 23:46 ` Rob Herring
2022-12-01 23:46 ` Rob Herring
2022-11-30 14:10 ` [PATCH 2/5] arm: dts: remove label = "cpu" from DSA dt-binding Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:51 ` Geert Uytterhoeven
2022-11-30 14:51 ` Geert Uytterhoeven
2022-11-30 14:51 ` Geert Uytterhoeven
2022-11-30 14:51 ` Geert Uytterhoeven
2022-12-01 6:20 ` Oleksij Rempel
2022-12-01 6:20 ` Oleksij Rempel
2022-12-01 6:20 ` Oleksij Rempel
2022-12-01 6:20 ` Oleksij Rempel
2022-12-01 22:34 ` Bjorn Andersson
2022-12-01 22:34 ` Bjorn Andersson
2022-12-01 22:34 ` Bjorn Andersson
2022-12-01 22:34 ` Bjorn Andersson
2022-12-04 21:31 ` Linus Walleij
2022-12-04 21:31 ` Linus Walleij
2022-12-04 21:31 ` Linus Walleij
2022-12-04 21:31 ` Linus Walleij
2022-12-05 20:10 ` Jernej Škrabec
2022-12-05 20:10 ` Jernej Škrabec
2022-12-05 20:10 ` Jernej Škrabec
2022-11-30 14:10 ` [PATCH 3/5] arm64: " Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 18:40 ` Heiko Stübner
2022-11-30 18:40 ` Heiko Stübner
2022-11-30 18:40 ` Heiko Stübner
2022-11-30 18:40 ` Heiko Stübner
2022-11-30 14:10 ` [PATCH 4/5] mips: " Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-12-01 6:04 ` Sergio Paracuellos
2022-12-01 6:04 ` Sergio Paracuellos
2022-12-01 6:04 ` Sergio Paracuellos
2022-12-01 6:04 ` Sergio Paracuellos
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 6:13 ` Oleksij Rempel
2022-12-01 10:53 ` Thomas Bogendoerfer
2022-12-01 10:53 ` Thomas Bogendoerfer
2022-12-01 10:53 ` Thomas Bogendoerfer
2022-12-01 10:53 ` Thomas Bogendoerfer
2022-11-30 14:10 ` [PATCH 5/5] powerpc: " Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-11-30 14:10 ` Arınç ÜNAL
2022-12-01 10:40 ` Michael Ellerman
2022-12-01 10:40 ` Michael Ellerman
2022-12-01 17:39 ` Pali Rohár
2022-12-01 17:39 ` Pali Rohár
2022-12-01 23:44 ` Rob Herring
2022-12-01 23:44 ` Rob Herring
2022-12-02 19:35 ` Pali Rohár
2022-12-02 19:35 ` Pali Rohár
2022-12-04 18:59 ` Vladimir Oltean [this message]
2022-12-04 18:59 ` Vladimir Oltean
2022-12-05 19:15 ` Arınç ÜNAL
2022-12-05 19:15 ` Arınç ÜNAL
2022-12-07 13:13 ` Vladimir Oltean
2022-12-07 13:13 ` Vladimir Oltean
2022-11-30 15:55 ` [PATCH 0/5] " Andrew Lunn
2022-11-30 15:55 ` Andrew Lunn
2022-11-30 15:55 ` Andrew Lunn
2022-11-30 15:55 ` Andrew Lunn
2022-11-30 17:22 ` Arınç ÜNAL
2022-11-30 17:22 ` Arınç ÜNAL
2022-11-30 17:22 ` Arınç ÜNAL
2022-11-30 17:22 ` Arınç ÜNAL
2022-12-01 10:42 ` Michael Ellerman
2022-12-01 10:42 ` Michael Ellerman
2022-12-01 10:42 ` Michael Ellerman
2022-12-01 10:42 ` Michael Ellerman
2022-12-01 11:37 ` Arınç ÜNAL
2022-12-01 11:37 ` Arınç ÜNAL
2022-12-01 11:37 ` Arınç ÜNAL
2022-12-01 11:37 ` Arınç ÜNAL
2022-12-01 9:14 ` Arınç ÜNAL
2022-12-01 9:14 ` Arınç ÜNAL
2022-12-01 9:14 ` Arınç ÜNAL
2022-12-01 9:14 ` Arınç ÜNAL
2022-12-02 4:10 ` patchwork-bot+netdevbpf
2022-12-02 4:10 ` patchwork-bot+netdevbpf
2022-12-02 4:10 ` patchwork-bot+netdevbpf
2022-12-02 4:10 ` patchwork-bot+netdevbpf
-- strict thread matches above, loose matches on Subject: below --
2022-11-30 0:34 Arınç ÜNAL
2022-11-30 0:34 ` [PATCH 5/5] powerpc: dts: " Arınç ÜNAL
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=20221204185924.a4q6cifhpyxaur6f@skbuf \
--to=olteanv@gmail.com \
--cc=arinc.unal@arinc9.com \
--cc=devicetree@vger.kernel.org \
--cc=kabel@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=pali@kernel.org \
--cc=robh@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.