Re: [PATCH] crypto: qce - Replace with stub driver

[Bartosz Golaszewski]

On Sat, 1 Aug 2026 19:12:42 +0200, Eric Biggers <ebiggers@xxxxxxxxxx> said:

> Well, that again brings us back to the core issue which is the actual
> current functionality of the driver, which is to register crypto_ahash,
> crypto_skcipher, and crypto_aead algorithms with the crypto API.
>
> It isn't useful functionality, but rather just a footgun that allows
> users to misconfigure their systems, an issue I've seen happen multiple
> times.  CPU-based implementations of *every one* of those algorithms
> already exist.  On a typical SoC that has this hardware, the CPU-based
> implementations are ~50x faster as shown in tests.  Pending patches make
> the difference even greater at ~100x.  And the CPU-based implementations
> actually use significantly less CPU time, as well.  There seems to be no
> path forward for significantly fixing this issue, either.
>

You've repeated your point about performance several times. Nobody ever said
you're wrong. Performance is not the only reason for choosing one provider over
another.

> An alternative we could consider is dropping the cra_priority further,
> to further decrease the chance that these algorithms are used.  But I
> feel it's hard to justify why they're there at all, if the rationale for
> keeping them is "we made sure that no one can actually use them, so they
> can't be causing problems anymore"...
>

No, the rationale has never been this. FWIW it can be that it's used for
testing of the crypto module on a supported platform and that is already
enough of a reason to keep it upstream.

As I've said before: we don't just drop maintained drivers from linux.

Herbert: it's been a while, would you mind chiming in and deciding one way
or the other, as Greg seems to have deferred to your judgement?

Thanks,
Bartosz