linux-kernel - Re: [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem

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: <730eec7e-deb2-2d04-6ba9-132a41ebed58@linaro.org>
Date:   Thu, 20 Oct 2022 08:48:47 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Patrick DELAUNAY <patrick.delaunay@...s.st.com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Fabrice Gasnier <fabrice.gasnier@...s.st.com>
Cc:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for
 stm32-romem

On 19/10/2022 13:23, Patrick DELAUNAY wrote:
> Hi,
> 
> On 10/18/22 03:56, Krzysztof Kozlowski wrote:
>> On 14/10/2022 11:23, Patrick Delaunay wrote:
>>> Add a new compatible for stm32mp13 support.
>>>
>>> Signed-off-by: Patrick Delaunay <patrick.delaunay@...s.st.com>
>>> ---
>>>
>>>   Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
>>> index 448a2678dc62..16f4cad2fa55 100644
>>> --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
>>> +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml
>>> @@ -22,6 +22,7 @@ properties:
>>>     compatible:
>>>       enum:
>>>         - st,stm32f4-otp
>>> +      - st,stm32mp13-bsec
>>>         - st,stm32mp15-bsec
>> According to usage in DTS (separate patch for some reason), the devices
>> are compatible, so please describe them like that.
> 
> 
> I push the separate patch "ARM: dts: stm32mp13: fix compatible for BSEC"
> 
> It is a advice of my colleagues: send an update of device tree
> 
> only when the binding modification is acked.

That's not correct advice - only for few cases it's valid (when
subsystem maintainer wants to take entire patchset, so there should be
no DTS inside). We want to see the bindings and its usage, so one of:
1. the same patchset
2. if two patchsets, then cross linked to each other with URLs to
lore.kernel.org. I see DTS had link but not this one.

Driver changes also must be sent together with the bindings. Since there
are no driver changes here, it means for us the devices are compatible
from Linux point of view.

> 
> 
> Sorry for disturbance, I can sent a V2 with the 2 patches.
> 
> 
> The STM32MP15 and STM32MP13 don't use the same version of the BSEC device,
> 
> and the driver need to handle it.
> 
> 
> In these 2 patches:
> 
> - [PATCH] dt-bindings: nvmem: add new stm32mp13 compatible for stm32-romem
> 
> - [PATCH] ARM: dts: stm32mp13: fix compatible for BSEC
> 
> 
> I fix a error for BSEC node in the initial patch to support STM32MP13x,

The question is then whether device was working before or not. If it was
working, you fix one error but break DTS usage on any system which does
not have updated driver (so BSD, u-boot, other firmware, other Linux
kernel versions).

If it was not working, then it's okay, but such case was not explained
in DTS patch, I think.

> 
> the DTS "stm32mp131.dtsi" should not used/accepted with the a BSEC node 
> using
> 
> the compatible "st,stm32mp15-bsec" in commit 1da8779c0029 ("ARM: dts: 
> stm32: add STM32MP13 SoCs support")
> 
> 
> It is a preliminary step to add support of STM32MP13x in STM32 ROMEM driver.
> 
> 
> I don't indicate these patches as "Fixes:" to avoid a dts check issue
> 
> if only the DTS patch was backported.
> 
> 
> Today it not blocking for STM32MP13x users because this SoC is not yet 
> available for customers
> 
> and it is only used internally on the ST Microelectronics board 
> STM32MP135F-DK.

DTS patch says nothing about it...

> 
> 
> Nobody (except STMicroelectronics) use this SoC  STM32MP13x with the 
> current DTS / Linux version.
> 
> 
> Moreover, by default, the STM32 ROMEM driver in not activated in any 
> defconfig,

Independent issue.

> 
> I prepare a other patch to activated it by default in arm_multiv7_defconfig.
> 
> but I am waiting this DTS correction to avoid to probe the stm32 romen 
> driver with STM32MP15
> 
> configuration on STM32MP13x SoC.
> 
> 
> I think is a good time to update this DTS error before the SoC availability,
> 
> agreed with SoC Maintainer, Alexandre Torgue, even if this patch breaks 
> surrent users
> 
> of STM32MP13x DTS (but it is only internals user STMicroelectronics 
> until now).
> 
> 
> but perhaps you prefer a other solution ?

With that explanation it is fine, but the DTS commit was not mentioning
explanation.

> 
> add Fixes in the DTS patch ?
> 
> + Fixes: 1da8779c0029 ("ARM: dts: stm32: add STM32MP13 SoCs support")
> 
> or
> 
> 
>          bsec: efuse@...05000 {
>              compatible = "st,stm32mp13-bsec", "st,stm32mp15-bsec";


Depends whether devices are compatible or not.

Best regards,
Krzysztof