linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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


  reply	other threads:[~2025-05-14 19:47 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).