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

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

[Varshini Rajendran]

Add DT bindings for atmel TDES.

Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
 .../devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml  | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
index 3d6ed24b1b00..6a441f79efea 100644
--- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
+++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
@@ -12,7 +12,11 @@ maintainers:
 
 properties:
   compatible:
-    const: atmel,at91sam9g46-tdes
+    oneOf:
+      - const: atmel,at91sam9g46-tdes
+      - items:
+          - const: microchip,sam9x7-tdes
+          - const: atmel,at91sam9g46-tdes
 
   reg:
     maxItems: 1
-- 
2.25.1

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

[Tudor Ambarus]

Hi,

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?

Please describe what motivated you to write this patch. Some people
can't take seriously a patch if it misses a proper description and
they just ignore it. Maybe it is worth re-reading:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes

Cheers,
ta
> 
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> ---
>  .../devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml  | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
> index 3d6ed24b1b00..6a441f79efea 100644
> --- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
> +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
> @@ -12,7 +12,11 @@ maintainers:
>  
>  properties:
>    compatible:
> -    const: atmel,at91sam9g46-tdes
> +    oneOf:
> +      - const: atmel,at91sam9g46-tdes
> +      - items:
> +          - const: microchip,sam9x7-tdes
> +          - const: atmel,at91sam9g46-tdes
>  
>    reg:
>      maxItems: 1

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

[Varshini.Rajendran]

On 28/07/23 4:47 pm, Tudor Ambarus wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi,
> 
> 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,

I am aware that there is no change in the crypto IP used. This patch is 
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.

> Please describe what motivated you to write this patch. Some people
> can't take seriously a patch if it misses a proper description and
> they just ignore it. Maybe it is worth re-reading:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
> 
> Cheers,
> ta
>>
>> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
>> ---
>>   .../devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml  | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> index 3d6ed24b1b00..6a441f79efea 100644
>> --- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> @@ -12,7 +12,11 @@ maintainers:
>>
>>   properties:
>>     compatible:
>> -    const: atmel,at91sam9g46-tdes
>> +    oneOf:
>> +      - const: atmel,at91sam9g46-tdes
>> +      - items:
>> +          - const: microchip,sam9x7-tdes
>> +          - const: atmel,at91sam9g46-tdes
>>
>>     reg:
>>       maxItems: 1

-- 
Thanks and Regards,
Varshini Rajendran.

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

[Tudor Ambarus]

On 8/10/23 06:38, Varshini.Rajendran@microchip.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 
> 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?

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

[Krzysztof Kozlowski]

On 10/08/2023 09:22, Tudor Ambarus wrote:
> 
> 
> On 8/10/23 06:38, Varshini.Rajendran@microchip.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 
>> 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.

Best regards,
Krzysztof

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

[Nicolas Ferre]

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@microchip.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

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

[Tudor Ambarus]

On 8/21/23 09:41, Nicolas Ferre wrote:
> Hi Tudor, all,
> 
Hi,

> 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@microchip.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

See
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/tree/drivers/crypto/atmel-tdes.c?h=at91-dt#n1120

>> 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.

Ok, fine by me. Then it would be good if one adds compatibles for the
previous SoCs as well and add a comment in the drivers that inform
readers that the atmel_*_get_cap() methods are used as backup where
"atmel,at91sam9g46-" compatibles are used. You'll then have all the
previous SoCs have their own dedicated compatibles which will have
"atmel,at91sam9g46-" compatible as backup, and "sam9x7" will be the
first that will not need the "atmel,at91sam9g46-" backup compatible.
In the drivers you'll have 2 flavors of identifying the IP caps, the
first one that backups to atmel_*_get_cap(), and a second one where
of_device_id data will suffice.

If the commit message described how the driver will handle the new
compatible, Varshini would have spared us of all these emails exchanged.
Varshini, please update the commit message in the next iteration and
describe how the driver will handle the new compatible.

Cheers,
ta

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

[Krzysztof Kozlowski]

On 21/08/2023 11:54, Tudor Ambarus wrote:
>>>>> 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
> 
> See
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/tree/drivers/crypto/atmel-tdes.c?h=at91-dt#n1120

What's there? One compatible? How does it prove that it will not be
used? It only proves that currently it is not used... And anyway this is
just one implementation in one system. How can you possibly know all
other possible implementations (other bootloaders/firmwares/systems)?
One cannot. The guideline is there for specific reason.



> 
>>> 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.
> 
> Ok, fine by me. Then it would be good if one adds compatibles for the
> previous SoCs as well and add a comment in the drivers that inform
> readers that the atmel_*_get_cap() methods are used as backup where
> "atmel,at91sam9g46-" compatibles are used. You'll then have all the
> previous SoCs have their own dedicated compatibles which will have
> "atmel,at91sam9g46-" compatible as backup, and "sam9x7" will be the
> first that will not need the "atmel,at91sam9g46-" backup compatible.
> In the drivers you'll have 2 flavors of identifying the IP caps, the
> first one that backups to atmel_*_get_cap(), and a second one where
> of_device_id data will suffice.
> 
> If the commit message described how the driver will handle the new
> compatible, Varshini would have spared us of all these emails exchanged.

The driver does not have to handle the new compatible, because it is
independent question. Although if you meant to explicitly say that
device is compatible in commit msg, although it is obvious from the
patch, then sure.

> Varshini, please update the commit message in the next iteration and
> describe how the driver will handle the new compatible.

Best regards,
Krzysztof

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

[Tudor Ambarus]

On 8/21/23 13:10, Krzysztof Kozlowski wrote:
> On 21/08/2023 11:54, Tudor Ambarus wrote:
>>>>>> 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
>>
>> See
>> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/tree/drivers/crypto/atmel-tdes.c?h=at91-dt#n1120
> 
> What's there? One compatible? How does it prove that it will not be
> used? It only proves that currently it is not used... And anyway this is

Correct, as of now the compatible was not used to determine the hw caps,
the capabilities were retrieved by checking at runtime a version
register. I'm against adding a compatible that will not be used, in this
particular case, defining "microchip,sam9x7-tdes" in the driver but
still solely relying on the runtime version register interrogation.
Unfortunately the commit message does not reveal any intention and from
there these emails changed. Maybe it's just a matter of personal
preference, so I'll stop commenting on this.

> just one implementation in one system. How can you possibly know all
> other possible implementations (other bootloaders/firmwares/systems)?
> One cannot. The guideline is there for specific reason.
> 

I didn't say the guideline is wrong, I just tried to understand how this
particular case is handled.
> 
> 
>>
>>>> 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.
>>
>> Ok, fine by me. Then it would be good if one adds compatibles for the
>> previous SoCs as well and add a comment in the drivers that inform
>> readers that the atmel_*_get_cap() methods are used as backup where
>> "atmel,at91sam9g46-" compatibles are used. You'll then have all the
>> previous SoCs have their own dedicated compatibles which will have
>> "atmel,at91sam9g46-" compatible as backup, and "sam9x7" will be the
>> first that will not need the "atmel,at91sam9g46-" backup compatible.
>> In the drivers you'll have 2 flavors of identifying the IP caps, the
>> first one that backups to atmel_*_get_cap(), and a second one where
>> of_device_id data will suffice.
>>
>> If the commit message described how the driver will handle the new
>> compatible, Varshini would have spared us of all these emails exchanged.
> 
> The driver does not have to handle the new compatible, because it is
> independent question. Although if you meant to explicitly say that

As you wish. I retrieve my NACK.

Cheers,
ta
> device is compatible in commit msg, although it is obvious from the
> patch, then sure.
> 
>> Varshini, please update the commit message in the next iteration and
>> describe how the driver will handle the new compatible.
> 
> Best regards,
> Krzysztof
> 

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

[Krzysztof Kozlowski]

On 21/08/2023 15:00, Tudor Ambarus wrote:
> 
> 
> On 8/21/23 13:10, Krzysztof Kozlowski wrote:
>> On 21/08/2023 11:54, Tudor Ambarus wrote:
>>>>>>> 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
>>>
>>> See
>>> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git/tree/drivers/crypto/atmel-tdes.c?h=at91-dt#n1120
>>
>> What's there? One compatible? How does it prove that it will not be
>> used? It only proves that currently it is not used... And anyway this is
> 
> Correct, as of now the compatible was not used to determine the hw caps,
> the capabilities were retrieved by checking at runtime a version
> register. I'm against adding a compatible that will not be used, in this
> particular case, defining "microchip,sam9x7-tdes" in the driver but
> still solely relying on the runtime version register interrogation.
> Unfortunately the commit message does not reveal any intention and from
> there these emails changed. Maybe it's just a matter of personal
> preference, so I'll stop commenting on this.

Hm, thanks for bringing this up, indeed it looks a bit redundant to have
additional compatible strings if HW can identify itself. In such case,
pretty often a generic compatible in the driver and DTS could do... but:

1. Adding specific compatibles for such case would have sense to be able
to validate differences between DTS (like clocks, resets and power domains).

2. Reading HW revision might require enabling clocks which might differ
per variant, thus driver still might need to match according to some
compatibles. After that matching, driver can get necessary clocks,
enable them and read the HW version/revision. There is an example for this:
Documentation/devicetree/bindings/cache/qcom,llcc.yaml
drivers/soc/qcom/llcc-qcom.c
We have there version of the block but clocks and register layout
differ, thus we must have device-specific compatibles.

> 
>> just one implementation in one system. How can you possibly know all
>> other possible implementations (other bootloaders/firmwares/systems)?
>> One cannot. The guideline is there for specific reason.
>>
> 
> I didn't say the guideline is wrong, I just tried to understand how this
> particular case is handled.
>>

Best regards,
Krzysztof

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

[Nicolas Ferre]

On 28/07/2023 at 12:24, Varshini Rajendran wrote:
> Add DT bindings for atmel TDES.
> 
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>

Following my answer to the email thread:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>

Thanks, best regards,
   Nicolas

> ---
>   .../devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml  | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
> index 3d6ed24b1b00..6a441f79efea 100644
> --- a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
> +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
> @@ -12,7 +12,11 @@ maintainers:
>   
>   properties:
>     compatible:
> -    const: atmel,at91sam9g46-tdes
> +    oneOf:
> +      - const: atmel,at91sam9g46-tdes
> +      - items:
> +          - const: microchip,sam9x7-tdes
> +          - const: atmel,at91sam9g46-tdes
>   
>     reg:
>       maxItems: 1

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

[Tudor Ambarus]

On 8/21/23 09:59, Nicolas Ferre wrote:
> On 28/07/2023 at 12:24, Varshini Rajendran wrote:
>> Add DT bindings for atmel TDES.

this commit message is way too succinct and hides the complexity that's
needed in the driver

>>
>> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> 
> Following my answer to the email thread:
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> 
> Thanks, best regards,
>   Nicolas
> 
>> ---
>>   .../devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml  | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> index 3d6ed24b1b00..6a441f79efea 100644
>> ---
>> a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> +++
>> b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml
>> @@ -12,7 +12,11 @@ maintainers:
>>     properties:
>>     compatible:
>> -    const: atmel,at91sam9g46-tdes
>> +    oneOf:
>> +      - const: atmel,at91sam9g46-tdes
>> +      - items:
>> +          - const: microchip,sam9x7-tdes
>> +          - const: atmel,at91sam9g46-tdes

why do you backup to "atmel,at91sam9g46-tdes"? Simply relying on
"microchip,sam9x7-tdes" and its of_device_id data should be enough.


>>       reg:
>>       maxItems: 1
>