[PATCH] crypto: qce - Replace with stub driver

[Eric Biggers]

On Tue, Aug 11, 2026 at 08:42:55AM -0500, Bartosz Golaszewski wrote:
> On Sat, 1 Aug 2026 19:12:42 +0200, Eric Biggers <ebiggers at kernel.org> 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.

That isn't a very practical viewpoint for the in-kernel crypto use
cases, where performance tends to be critical and users will do a lot to
get even a few percent improvement, let alone 10000%!  But as Demi and I
have explained, even if the performance aspect is ignored the driver
still isn't worth it, for multiple other reasons.

Also, you did give saving CPU cycles as a reason earlier
(https://lore.kernel.org/linux-crypto/CAMRc=Me55rUmjjR+ZzdWd2ss9JJMZzJch0zKd4GqONBjCzFMYQ@mail.gmail.com/).
That's one of the reasons I actually tested it and responded to that.
It sounds like you've now walked back your claim.  So great, we seem to
be on the same page regarding that point now.

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

We definitely do if the drivers are not useful or appropriate for
inclusion in the kernel, though the policy varies by subsystem.  Even
just last month an entire filesystem got dropped despite someone wanting
to maintain it.

- Eric