From: Rob Herring <robh@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Marek Behún" <kabel@kernel.org>,
devicetree@vger.kernel.org, "Arınç ÜNAL" <arinc.unal@arinc9.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
Date: Thu, 1 Dec 2022 17:44:00 -0600 [thread overview]
Message-ID: <20221201234400.GA1692656-robh@kernel.org> (raw)
In-Reply-To: <20221201173902.zrtpeq4mkk3i3vpk@pali>
On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> On Thursday 01 December 2022 21:40:03 Michael Ellerman wrote:
> > Arınç ÜNAL <arinc.unal@arinc9.com> writes:
> > > This is not used by the DSA dt-binding, so remove it from all devicetrees.
> > >
> > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > ---
> > > arch/powerpc/boot/dts/turris1x.dts | 2 --
> > > 1 file changed, 2 deletions(-)
> >
> > Adding Pali to Cc.
> >
> > These were only recently updated in commit:
> >
> > 8bf056f57f1d ("powerpc: dts: turris1x.dts: Fix labels in DSA cpu port nodes")
> >
> > Which said:
> >
> > DSA cpu port node has to be marked with "cpu" label.
> >
> > But if the binding doesn't use them then I'm confused why they needed to
> > be updated.
> >
> > cheers
>
> 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.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "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: Thu, 1 Dec 2022 17:44:00 -0600 [thread overview]
Message-ID: <20221201234400.GA1692656-robh@kernel.org> (raw)
In-Reply-To: <20221201173902.zrtpeq4mkk3i3vpk@pali>
On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> On Thursday 01 December 2022 21:40:03 Michael Ellerman wrote:
> > Arınç ÜNAL <arinc.unal@arinc9.com> writes:
> > > This is not used by the DSA dt-binding, so remove it from all devicetrees.
> > >
> > > Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> > > ---
> > > arch/powerpc/boot/dts/turris1x.dts | 2 --
> > > 1 file changed, 2 deletions(-)
> >
> > Adding Pali to Cc.
> >
> > These were only recently updated in commit:
> >
> > 8bf056f57f1d ("powerpc: dts: turris1x.dts: Fix labels in DSA cpu port nodes")
> >
> > Which said:
> >
> > DSA cpu port node has to be marked with "cpu" label.
> >
> > But if the binding doesn't use them then I'm confused why they needed to
> > be updated.
> >
> > cheers
>
> 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.
Rob
next prev parent reply other threads:[~2022-12-01 23:44 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 [this message]
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
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=20221201234400.GA1692656-robh@kernel.org \
--to=robh@kernel.org \
--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 \
/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.