Re: [PATCH] crypto: qce - Replace with stub driver
Bartosz Golaszewski <[email protected]> Fri, 31 Jul 2026 00:42:39 -0700
| Newsgroups | org.kernel.vger.linux-crypto,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAMRc=MeBzj9xqTP09rnVBQFPqSj-TDt5U8mtr8vN7NDJk-tY6A@mail.gmail.com> |
On Fri, 31 Jul 2026 07:08:38 +0200, Eric Biggers <[email protected]> said: > None of the algorithms the QCE driver registers with the crypto API are > even close to being useful. They're massively outperformed by the > CPU-based crypto (even actually using far more CPU cycles than the > CPU-based crypto, due to the massive driver overhead), don't provide any > security benefits over the CPU-based crypto, and have various other > issues. They're also unrelated to the Inline Crypto Engine which works > far better and is what is actually being used these days. > > Due to the major performance problems people experienced when > accidentally using this driver, the algorithms were already demoted to > below the priority of ARMv8 CE in the crypto API several years ago. > Regardless of priority, these algorithms also aren't compatible with the > most common uses of in-kernel crypto; for example, they don't support > dm-crypt because they allocate memory, and they don't support IPsec > since they take a mutex which isn't compatible with softirq context. > > It's time to move on and just drop this obsolete functionality entirely. > > However, the driver does serve one purpose which is to bind to the > devicetree node and allow the interconnects to scale down (though even > that part is broken, as it holds static interconnect bandwidth votes). > > Thus, clear out the crypto functionality, leaving just a stub driver > that drops the interconnection bandwidth votes to zero. > > Tested on the SM8650 HDK. > > Signed-off-by: Eric Biggers <[email protected]> > --- I'll be on vacation for most of August so my lack of responses won't mean I no longer care, only that I'm disconnected. Let me just leave this here for completness: Nacked-by: Bartosz Golaszewski <[email protected]> I don't understand why the push to fast track the removal of this driver now, when there's clearly an effort to get it fixed from the vendor itself. I've also never seen a driver for an IP on a supported platform being removed from mainline linux. Thanks, Bartosz