linux-kernel - Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET reset driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a12286d2-f929-ed6d-c0f2-4dad5ce6b388@linaro.org>
Date:   Tue, 18 Jul 2023 20:01:35 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Michal Simek <michal.simek@....com>,
        Conor Dooley <conor@...nel.org>,
        Piyush Mehta <piyush.mehta@....com>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, p.zabel@...gutronix.de,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        git@....com
Subject: Re: [PATCH 1/2] dt-bindings: reset: Updated binding for Versal-NET
 reset driver

On 18/07/2023 16:30, Michal Simek wrote:
>>>
>>> Please correct me if I am wrong. Description about ID should be removed from
>>> commit message because it is not necessary. And
>>> include/dt-bindings/reset/xlnx-versal-net-resets.h
>>> should be added when we merge also DT for versal-net SOC.
>>
>> No, the binding header is needed only if driver is using it. Adding DTS
>> will not change that - still no kernel driver users. No benefits of such
>> binding. If there are no users and no benefits - don't make it a binding.
> 
> But header in board folder should be fine like these.
> arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> arch/arm64/boot/dts/mediatek/mt8516-pinfunc.h
> arch/arm64/boot/dts/mediatek/mt8167-pinfunc.h
> arch/arm64/boot/dts/mediatek/mt8173-pinfunc.h
> arch/arm64/boot/dts/exynos/exynos-pinctrl.h
> arch/arm64/boot/dts/freescale/imx8mq-pinfunc.h
> arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h
> arch/arm64/boot/dts/freescale/imx8mn-pinfunc.h
> arch/arm64/boot/dts/freescale/imx93-pinfunc.h
> arch/arm64/boot/dts/freescale/imx8ulp-pinfunc.h
> arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
> arch/arm64/boot/dts/tesla/fsd-pinctrl.h

Yes. If you want to store some constants (register values, firmware
magic numbers) and use in DTS, this is the way to go. Most (or all) of
examples above are for register values.

Best regards,
Krzysztof