linux-kernel - Re: [PATCH v3 11/50] dt-bindings: crypto: add sam9x7 in Atmel TDES

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: <adeed0b2-e09b-78cf-ebfd-08d3949ca9ea@microchip.com>
Date:   Mon, 21 Aug 2023 10:41:59 +0200
From:   Nicolas Ferre <nicolas.ferre@...rochip.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Tudor Ambarus <tudor.ambarus@...aro.org>,
        <Varshini.Rajendran@...rochip.com>, <herbert@...dor.apana.org.au>,
        <davem@...emloft.net>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <alexandre.belloni@...tlin.com>, <claudiu.beznea@...rochip.com>,
        <linux-crypto@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 11/50] dt-bindings: crypto: add sam9x7 in Atmel TDES

Hi Tudor, all,

On 19/08/2023 at 16:34, Krzysztof Kozlowski wrote:
> On 10/08/2023 09:22, Tudor Ambarus wrote:
>>
>> On 8/10/23 06:38, Varshini.Rajendran@...rochip.com wrote:
>>>> On 7/28/23 11:24, Varshini Rajendran wrote:
>>>>> Add DT bindings for atmel TDES.
>>>> NACK. The atmel crypto drivers check the version at runtime and
>>>> fill a capabilities structure based on the version identified.
>>>> There's a single compatible regardless of the version of the IP
>>>> used until now, why do you want to change it?
>>>>
>>> Hi Tudor,
>>
>> Hi,
>>
>>> I am aware that there is no change in the crypto IP used. This patch is

Actually, recent history showed us that it's not only the IP itself but 
its integration into final product that could have an influence on the 
behavior.

>>> to add a SoC specific compatible as expected by writing-bindings
>>> guideline. Maybe a bit more explanation in the commit description might
>>> do the trick.
>>>
>>
>> So you add a compatible that will never be used just to comply with
>> the writing bindings guideline?
> 
> How do you know that it is never going to be used? The guideline asks
> for this on purpose, so any future quirks or incompatibilities can be
> easily addressed.

In this recent case, having a an adapted compatibility string is an 
added value.

And yes, I changed my mind and would like to be systematic now with 
at91/microchip DT compatibility strings. Our long history and big legacy 
in arm-soc is sometimes difficult to handle, but we're moving little by 
little to comply with guidelines.

My conclusion is that Varshini's addition is the way to go.

Best regards,
   Nicolas