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

[Thierry Reding]

On Thu, May 08, 2025 at 09:37:27AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:31, Thierry Reding wrote:
> > On Thu, May 08, 2025 at 07:48:22AM +0200, Krzysztof Kozlowski wrote:
> >> On 07/05/2025 16:37, Thierry Reding wrote:
> >>> From: Thierry Reding <treding at nvidia.com>
> >>>
> >>> This doesn't currently contain any stream ID or memory client ID
> >>> definitions, but they will be added in subsquent patches.
> >>>
> >>> Signed-off-by: Thierry Reding <treding at nvidia.com>
> >>
> >> <form letter>
> >> Please use scripts/get_maintainers.pl to get a list of necessary people
> >> and lists to CC (and consider --no-git-fallback argument, so you will
> >> not CC people just because they made one commit years ago). It might
> >> happen, that command when run on an older kernel, gives you outdated
> >> entries. Therefore please be sure you base your patches on recent Linux
> >> kernel.
> >>
> >> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> >> people, so fix your workflow. Tools might also fail if you work on some
> >> ancient tree (don't, instead use mainline) or work on fork of kernel
> >> (don't, instead use mainline). Just use b4 and everything should be
> >> fine, although remember about `b4 prep --auto-to-cc` if you added new
> >> patches to the patchset.
> >> </form letter>
> > 
> > get_maintainers.pl lists 13 people and 7 lists. That's *way* too many
> > recipients for something as trivial as this series, in my opinion, so I
> > tend to curate the list of recipients manually. I guess I went a bit
> > overboard and should've at least listed all DT maintainers explicitly.
> 
> 
> Usually that's a sign you combine too many subsystems into one patchset,
> so the solution is to split, not remove maintainers/lists from CC.

This is literally only DT bindings, includes and DT files. These can't
be split apart any further without causing other objections.

> 
> > 
> >>> ---
> >>>  include/dt-bindings/memory/tegra264-mc.h | 13 +++++++++++++
> >>
> >> Filename based on compatible.
> > 
> > The compatible string for this is nvidia,tegra264-mc, so I don't know
> 
> 
> so nvidia,tegra264-mc.h
> 
> 
> > 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?

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/98e1d9f8/attachment.sig>