Re: [PATCH] crypto: qce - Remove driver

On Fri, Jul 24, 2026 at 05:25:46PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 24, 2026 at 08:09:32AM -0700, Eric Biggers wrote:
> > On Fri, Jul 24, 2026 at 05:04:46PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 24, 2026 at 02:47:48PM +0000, Bartosz Golaszewski wrote:
> > > > On Fri, 24 Jul 2026 16:14:14 +0200, Eric Biggers <[email protected]> said:
> > > > >
> > > > > And with the defaults QCE is *never* used.
> > > > >
> > > > 
> > > > It's almost EOD here and I'm going to disconnect for the weekend but I just
> > > > wanted to say before I leave: this has never been a reason for an aggresive
> > > > removal of any driver. We remove drivers when we stop supporting entire
> > > > platforms, not mostly unused drivers on actively *supported* platforms where
> > > > they can still be used for experimentation and testing. I'm fine with dropping
> > > > this from arm64 defconfig but with fixes, the BROKEN tag should be removed
> > > > and I definitely object to removing it from the tree. How many people still
> > > > use greybus? Should we drop it from the kernel too? And I'm saying it as
> > > > a project ARA alumni. :)
> > > 
> > > I agree, if someone is willing to maintain it, and there are actual
> > > in-kernel uses of it (meaning not just a stand-alone library that can
> > > never be called either by userspace or hardware), it should stay.
> > 
> > What would we be considering the in-kernel uses to be, then?  Just
> > wiring it up to the framework is enough, regardless of actual use?
> 
> I was meaning that we just don't want to have code lying around that is
> impossible to use.
> 
> I'll defer to the subsystem maintainer if they want to remove it or not
> here, as that's their call, not mine.
> 
> But really, if someone wants to maintain it, no matter how slow it might
> be, I don't see the harm in keeping it if it's not causing any other
> problems.

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/[email protected]/

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.

If the justification for keeping it is that it is disabled anyway, then
I hope there's not going to be a contradictory push to enable it again.

I don't think we should keep crypto drivers around just for
"experimentation and testing".

- Eric