Re: [PATCH v2] drivers/crypto: Mark QCE as BROKEN

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jul 23, 2026 at 02:44:27AM -0700, Bartosz Golaszewski wrote:
> On Wed, 22 Jul 2026 18:20:40 +0200, Eric Biggers <ebiggers@kernel.org> said:
> > On Wed, Jul 22, 2026 at 01:33:51AM -0700, Bartosz Golaszewski wrote:
> >> > Also, what can the current driver do that cannot be done better using
> >> > software crypto?  I understand that you have future plans to add more
> >> > features to the driver, but those are not relevant to this discussion.
> >> >
> >>
> >> We can offload crypto operations to the QCE saving CPU cycles but more
> >> importantly, the QCE provides HW based isolation which some vendors care
> >> about.
> >
> > Do you have any concrete proof of anyone using this with a specific
> > Linux kernel feature and actually getting a benefit from it?
> >
> 
> I'm not required to produce a proof of Qualcomm's clients using it. That's
> never been a requirement to keep a driver in mainline. I'm saying that Qualcomm
> wants to keep it and I've stepped up to fix and maintain it, which is what I'm
> doing.
> 
> But yes, I know about companies that do use this driver as is for whatever
> reasons. I'm not sure I can mention them so I won't.

I know that it's enabled in the defconfig and Qualcomm's BSP, so some
people have the module loaded on their systems.  That doesn't count as
use, let alone it being useful.

I'm not asking for a client name or any confidential information.  This
is a technical discussion, and I'm asking for proof that this driver can
actually provide a benefit for any specific Linux kernel feature over
the widely used and well-vetted alternatives (ICE and ARMv8 CE).

"We want this upstream for reasons that we refuse to disclose" is never
a reason for adding (or keeping) code in Linux.  There has to be a
technical justification.

Meanwhile, the strong technical arguments in favor of removal or marking
it BROKEN that have been presented remain unaddressed.

- Eric