Thread (12 messages) 12 messages, 4 authors, 2023-08-21

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

flat view

From: Tudor Ambarus <tudor.ambarus@linaro.org>
Date: 2023-08-21 09:54:43
Also in: linux-crypto, linux-devicetree, lkml


On 8/21/23 09:41, Nicolas Ferre wrote:
Hi Tudor, all,
Hi,
On 19/08/2023 at 16:34, Krzysztof Kozlowski wrote:
quoted
On 10/08/2023 09:22, Tudor Ambarus wrote:
quoted
On 8/10/23 06:38, Varshini.Rajendran@microchip.com wrote:
quoted
quoted
On 7/28/23 11:24, Varshini Rajendran wrote:
quoted
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,
quoted
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.
quoted
quoted
quoted
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
quoted
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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help