Re: [PATCH] crypto: qce - Remove driver

[Bartosz Golaszewski]

On Fri, Jul 24, 2026 at 10:42 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jul 24, 2026 at 12:36:24AM -0700, Bartosz Golaszewski wrote:
> > I'm against removing this driver but I have a kernel driver policy question
> > before I start arguing the case: If I say that I do use this driver and that
> > I volunteer to maintain it and had already started sending out fixes, can
> > Eric still force its removal? Because in this case I can name a whole lot of
> > drivers that I deem useless that we still keep around.
>
> But you aren't using it if it is marked as BROKEN.  If that's not the
> case, and it is not broken, well why is it marked that way?
>

It was marked as BROKEN only a couple of days ago (it hasn't been
released as BROKEN in any upstream tag yet) despite my NAK, making
myself the maintainer for this driver and having sent the first set of
fixes addressing crypto self-tests failures. There's a bit more
context here. :)

> > The alg priority of this driver has been decreased below that of ARM CE and
> > since CRYPTO_ALG_KERN_DRIVER_ONLY it can no longer be used accidentally by
> > user-space either.
>
> If it can't be used, then again, who is using it?  We can't have ONLY
> out of tree users for code that is in the kernel.  We HAVE to have
> in-kernel users for it to stick around.
>

It can't be used *accidentally*. It can still be used by in-kernel
users if you bump its priority via netlink.

> > Even if in practice the driver is used for testing purposes - does this warrant
> > its removal?
>
> testing purposes of what exactly if there is no in-kernel code that
> calls this thing?
>

Of several of the crypto accelerator IP's functionalities. But that's
just an example. We do use it - I was just asking if if we use a
kernel module to test HW functionality of an IP - is this enough of a
reason to keep its driver, not taking into account things like FIPS
140/3 certifications, etc.

Bartosz