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

Krzysztof Kozlowski krzk at kernel.org
Thu May 8 00:49:12 PDT 2025


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.

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)


Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list