[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