From: Rob Herring <robh@kernel.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Jon Hunter <jonathanh@nvidia.com>,
linux-tegra@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions
Date: Wed, 14 May 2025 14:31:25 -0500 [thread overview]
Message-ID: <20250514193125.GA2845766-robh@kernel.org> (raw)
In-Reply-To: <prjmur3ih7kbf2hapdzp4vtbt5cd3coophsm24d2liykosvuda@nwxbvabp2m2m>
On Thu, May 08, 2025 at 11:09:12AM +0200, Thierry Reding wrote:
> On Thu, May 08, 2025 at 10:45:29AM +0200, Krzysztof Kozlowski wrote:
> > On 08/05/2025 10:02, Thierry Reding wrote:
> > >>
> > >>
> > >>> how much more you'd like me to make it based on that. Do you expect me
> > >>> to add the nvidia, prefix? In that case it would be inconsistent with
> > >>> all of the 8 other Tegra MC includes that we have in that directory.
> > >>
> > >>
> > >> Same story as for every other case, why this would be different? All of
> > >> them - amlogic, mediatek, samsung, qcom, every soc - move to new style
> > >> since some years, why this one should be different?
> > >
> > > Because we've used exactly this naming convention for more than a
> > > decade. I get that it's nice to have consistency, but do you really want
> > > me to go and churn all of these files just so we can add a vendor-prefix
> > > and drop a redundant suffix?
> > No, I want new files. Look:
> > 1. Some time ago tegra-1.h was added.
> > 2. Someone spotted that there was tegra-1.h, so added now tegra-2.h.
> > 3. Now this is a pattern so of course next person, even if asked to use
> > vendor prefix, will not, right? Because it would break the pattern. So
> > we have tegra-3.h
> > 4. tegra.4 - no vendor prefix, because you have already three cases.
> > 5. You see where I am going?
> >
> > All of above - amlogic, mediatek, samsung, qcom - had decade of such
> > convention. I asked to changed, they used the same argument as you
> > ("decade") and then changed.
> >
> > Why this is different case than decade in amlogic, mediatek, samsung and
> > qcom?
>
> It's a matter of principle. One convention is as good as another. There
> are no clear advantages of one over another. It's pointless and frankly
> there are more important things than changing filenames that everybody
> has been okay with for the last 10 years.
The issue is one convention is consistent for you and only you, the
other is consistent for *everyone*. And then we'll have someone argue
they are just following the same convention as Tegra...
If you had several drivers and add a new one, would you argue that the
new one should follow the conventions of the old drivers rather than
current conventions? No, you wouldn't.
Rob
next prev parent reply other threads:[~2025-05-14 19:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 14:37 [PATCH 0/8] Add more Tegra264 support Thierry Reding
2025-05-07 14:37 ` [PATCH 1/8] dt-bindings: dma: Add Tegra264 compatible string Thierry Reding
2025-05-14 19:32 ` Rob Herring
2025-05-07 14:37 ` [PATCH 2/8] dt-bindings: rtc: tegra: Document Tegra264 RTC Thierry Reding
2025-05-14 19:32 ` Rob Herring (Arm)
2025-05-07 14:37 ` [PATCH 3/8] dt-bindings: tegra: Document P3971-0089+P3834-0008 Platform Thierry Reding
2025-05-14 19:32 ` Rob Herring (Arm)
2025-05-07 14:37 ` [PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions Thierry Reding
2025-05-08 7:39 ` Krzysztof Kozlowski
2025-05-08 7:40 ` Krzysztof Kozlowski
2025-05-08 7:46 ` Thierry Reding
2025-05-08 7:49 ` Krzysztof Kozlowski
2025-05-08 7:59 ` Thierry Reding
2025-05-08 8:51 ` Krzysztof Kozlowski
2025-05-08 8:58 ` Thierry Reding
2025-05-08 7:40 ` Krzysztof Kozlowski
2025-05-08 7:53 ` Thierry Reding
2025-05-08 8:42 ` Krzysztof Kozlowski
2025-05-08 9:04 ` Thierry Reding
2025-05-07 14:37 ` [PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions Thierry Reding
2025-05-08 5:48 ` Krzysztof Kozlowski
2025-05-08 7:31 ` Thierry Reding
2025-05-08 7:37 ` Krzysztof Kozlowski
2025-05-08 8:02 ` Thierry Reding
2025-05-08 8:45 ` Krzysztof Kozlowski
2025-05-08 9:09 ` Thierry Reding
2025-05-14 19:31 ` Rob Herring [this message]
2025-05-07 14:38 ` [PATCH 6/8] arm64: tegra: Add Tegra264 support Thierry Reding
2025-05-07 14:38 ` [PATCH 7/8] arm64: tegra: Add p3971-0089+p3834-0008 support Thierry Reding
2025-05-07 14:38 ` [PATCH 8/8] arm64: defconfig: Enable Tegra241 and Tegra264 Thierry Reding
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=20250514193125.GA2845766-robh@kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@gmail.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).