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: <3f76ff03-963d-fff8-b512-abce447da7d0@amd.com>
Date:   Wed, 19 Jul 2023 08:23:22 +0200
From:   Michal Simek <michal.simek@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        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 7/18/23 20:01, Krzysztof Kozlowski wrote:
> 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.

I did small grepping over Linux (reset only) and I found that all of these files 
are not used by any driver/code. They are included in binding document or dt files.
Based on your description above they all are candidates for removing from 
include/dt-bindings/reset/.
On the other hand that files could be used in different projects out of Linux 
where that values could be used by a driver/code.

What to do with it? Should we remove it, deprecate it or just keep it and not to 
add new one? I just want to know how to properly handle it.

Thanks,
Michal

altr,rst-mgr-a10.h
altr,rst-mgr.h
altr,rst-mgr-s10.h
amlogic,meson8b-reset.h
amlogic,meson-a1-reset.h
amlogic,meson-axg-reset.h
amlogic,meson-g12a-audio-reset.h
amlogic,meson-g12a-reset.h
amlogic,meson-gxbb-reset.h
amlogic,meson-s4-reset.h
bcm6318-reset.h
bcm63268-reset.h
bcm6328-reset.h
bcm6358-reset.h
bcm6362-reset.h
bcm6368-reset.h
bitmain,bm1880-reset.h
hisi,hi6220-resets.h
imx8ulp-pcc-reset.h
mediatek,mt6735-wdt.h
mt2701-resets.h
mt7622-reset.h
mt7629-resets.h
mt8135-resets.h
mt8173-resets.h
nuvoton,npcm7xx-reset.h
oxsemi,ox810se.h
oxsemi,ox820.h
realtek,rtd1195.h
realtek,rtd1295.h
snps,hsdk-reset.h
stericsson,db8500-prcc-reset.h
stm32mp13-resets.h
stm32mp1-resets.h
sunplus,sp7021-reset.h
tegra186-reset.h
tegra194-reset.h
tegra234-reset.h
xlnx-versal-resets.h
xlnx-zynqmp-resets.h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ