Re: [PATCH] crypto: qce - Remove driver

[Bartosz Golaszewski]

On Fri, 24 Jul 2026 17:51:44 +0200, Eric Biggers <ebiggers@xxxxxxxxxx> said:
> 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 <ebiggers@xxxxxxxxxx> 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/20260724081537.191992-2-thorsten.blum@xxxxxxxxx/
>

I volunteered to provide that time. What's wrong with said bug-fix?

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

Ok, feel free to remove it from arm64 defconfig, you can add:

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>

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

This goes against the linux philosophy of encouraging the upstreaming of
drivers. This driver is a nice testing ground for the BAM pipe locking which
can't be easily tested on NAND but which will eventually become useful for it.

Is disabling it in defconfig an acceptable compromise?

Bartosz