Re: [PATCH 0/3] crypto: caam/qi2 - algorithm priority configurable

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Sep 28, 2026 at 04:01:02PM +0200, Vincent Jardin via B4 Relay wrote:
> dpaa2_caam registers its skcipher, aead and ahash algorithms at a fixed
> priority above the ARMv8 Crypto Extensions, so on DPAA2 SoCs
> every in-kernel consumers of AES, SHA or GCM use the SEC.
> 
> Patch 1 adds dpaa2_caam.priority module parameter
> Patch 2 doc fsl,qi2-crypto-priority property on the SEC node
> Patch 3 reads it at probe, the module parameter takes precedence
> 
> Signed-off-by: Vincent Jardin <vjardin@free.fr>

Is there *any* real-world use case in which these caamalg_qi2.c
algorithms are worth using?  This looks like another one of those
problematic drivers pushed by the hardware vendor as a checkbox feature.
Just doing the crypto on the CPU is almost always much faster and more
reliable.

As shown by your other patch
(https://lore.kernel.org/linux-crypto/20260928-for-upstream-caam-qi-plain-keylen-v1-1-6edb56649cf9@free.fr/)
it also seems that this driver has been critically broken for the last
year, with it being unable to set keys.  Evidently, no one has tested or
used it in the last year until now.

It also has the usual anti-patterns like supporting MD5 and DES.

I really don't see the point.  Why do people put themselves through
these issues at all?  It seems this functionality should just be
disabled everywhere, without putting policy in the device tree which as
has been noted many times isn't the right place for it.

- Eric