[PATCH 2/3] dt-bindings: crypto: Convert Atmel TDES to yaml
Tudor.Ambarus at microchip.com
Tudor.Ambarus at microchip.com
Mon Feb 7 20:04:38 PST 2022
Hi, Krzysztof,
On 2/7/22 18:04, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 07/02/2022 04:24, Tudor Ambarus wrote:
>> Convert Atmel TDES documentation to yaml format. With the conversion the
>> clock and clock-names properties are made mandatory. The driver returns
>> -EINVAL if "tdes_clk" is not found, reflect that in the bindings and make
>> the clock and clock-names properties mandatory. Update the example to
>> better describe how one should define the dt node.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus at microchip.com>
>> ---
>> .../bindings/crypto/atmel,tdes.yaml | 63 +++++++++++++++++++
>> .../bindings/crypto/atmel-crypto.txt | 23 -------
>> 2 files changed, 63 insertions(+), 23 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/crypto/atmel,tdes.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/atmel,tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,tdes.yaml
>> new file mode 100644
>> index 000000000000..7efa5e4acaa1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/atmel,tdes.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/crypto/atmel,tdes.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Atmel Triple Data Encryption Standard (TDES) HW cryptographic accelerator
>> +
>> +maintainers:
>> + - Tudor Ambarus <tudor.ambarus at microchip.com>
>> +
>> +properties:
>> + compatible:
>> + const: atmel,at91sam9g46-tdes
>> +
>
> Same comments as for patch 1 plus one new (also applying to previous
> one). You named the file quite generic "atmel,tdes" or "atmel,aes", but
> what if something newer comes for at91? Maybe name it instead
> "atmel,at91sam9-aes"?
>
For historical reasons, the atmel-{aes,tdes,sha} drivers use their own
fixed compatible. The differentiation between the versions of the same IP
and their capabilities is done at run-time, by interrogating a version
register. Thus I expect that no new compatible will be added for neither of
these IPs.
Cheers,
ta
> Best regards,
> Krzysztof
More information about the linux-arm-kernel
mailing list