[PATCH 4/8] dt-bindings: Add Tegra264 clock and reset definitions

[Thierry Reding]

On Thu, May 08, 2025 at 09:49:12AM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2025 09:46, Thierry Reding wrote:
> > On Thu, May 08, 2025 at 09:40:38AM +0200, Krzysztof Kozlowski wrote:
> >> On 08/05/2025 09:39, Krzysztof Kozlowski wrote:
> >>> On 07/05/2025 16:37, Thierry Reding wrote:
> >>>> From: Thierry Reding <treding at nvidia.com>
> >>>>
> >>>> Signed-off-by: Thierry Reding <treding at nvidia.com>
> >>>
> >>> Missing commit msg
> >>>
> >>>> ---
> >>>>  include/dt-bindings/clock/tegra264-clock.h | 9 +++++++++
> >>>>  include/dt-bindings/reset/tegra264-reset.h | 7 +++++++
> >>>>  2 files changed, 16 insertions(+)
> >>>>  create mode 100644 include/dt-bindings/clock/tegra264-clock.h
> >>>>  create mode 100644 include/dt-bindings/reset/tegra264-reset.h
> >>>
> >>>
> >>> Filename equal to the compatible. That's the standard convention for all
> >>> the headers since some years.
> >>
> >> Huh, I cannot find the binding in this patchset. Where is the actual
> >> binding added?
> > 
> > The bindings for this are in
> > 
> >   Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> 
> There is no tegra264 in that binding.

That's part of an earlier series I sent out (and linked to from the
cover letter). It's here:

	https://lore.kernel.org/linux-tegra/20250506133118.1011777-1-thierry.reding@gmail.com/T/#m96bb396b352659581a9e71a4610c51e6ab4d5b6a

> The header always goes with the binding and the drivers.
> 
> > 
> > There's no 1:1 mapping to a compatible for this because BPMP is many
> > things. It's a clock provider, a reset provider, a power domain
> 
> Sure, that's fine.
> 
> > provider. These definitions reflect the IDs assigned by the BPMP ABI
> > and we've used this structure ever since this was introduced back in
> > 2016.
> > 
> > I don't think changing the convention for this is a net advantage.
> 
> Headers still should match the compatible one way or another. Can be
> nvidia,tegra264.h
> (because -clock is redundant and you do not want to use the actual
> compatible)

I get it. You want consistency. But what about consistency with earlier
chip generations? Do you want me to go and rename all of these files?

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/992ad24f/attachment.sig>