Re: [PATCH] crypto: qce - Remove driver

[Eric Biggers]

On Wed, Jul 29, 2026 at 10:02:27AM +0200, Konrad Dybcio wrote:
> On 7/28/26 5:22 PM, Eric Biggers wrote:
> > On Fri, Jul 24, 2026 at 08:51:44AM -0700, Eric Biggers wrote:
> >> It is consuming a lot of the community's time to help maintain,
> >> including dealing with LLM-found bugs, with no clear benefit to anyone.
> >> Even considering *just today* we can see someone sent a bug fix:
> >> https://lore.kernel.org/linux-crypto/20260724081537.191992-2-thorsten.blum@xxxxxxxxx/
> > 
> > Another example:
> > https://lore.kernel.org/linux-crypto/d5de5a55-eb35-4ad5-8d53-12e188e156cb@xxxxxxxxxxxxxxxx/
> > 
> >> It definitely *was* causing problems before it was disabled via the
> >> crypto priority system (which made it unused in the kernel) and dropped
> >> it from AF_ALG (which removed most of the unprivileged attack surface).
> >> When anyone accidentally used it, it caused at least a huge performance
> >> problem, and sometimes other problems too like filesystem hangs.  It was
> >> an issue for years.
> > 
> > This actually seems to have been an overly-optimistic characterization!
> > As per
> > https://lore.kernel.org/linux-crypto/d5de5a55-eb35-4ad5-8d53-12e188e156cb@xxxxxxxxxxxxxxxx/
> > this driver drains the battery on every system with the module loaded,
> > even when no crypto requests are actually sent to it.
> 
> Unfortunately removing it drains way more battery, because the buses
> never hit sync_state and are kept at their maximum frequencies:
> 
> [   18.021823] qnoc-glymur interconnect-1: sync_state() pending due to 1dfa000.crypto
> [   18.029605] qnoc-glymur 16e0000.interconnect: sync_state() pending due to 1dfa000.crypto
> 
> (it transiently also pins DRAM and friends to max-freq which absolutely
> kills battery life)

Isn't that easily fixable by marking the node as "disabled" in the
device tree, or even just deleting it entirely?

- Eric