[PATCH 5/8] dt-bindings: memory: Add Tegra264 definitions

[Thierry Reding]

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.

But then again, I guess you're the boss, and I'm not going to change
your mind, so renaming these files is what I'll go do.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250508/95405826/attachment.sig>