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

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jul 23, 2026 at 07:17:19AM -0700, Eric Biggers wrote:
> 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.

FYI, I took some time to take a closer look at this driver, and I found
a bunch more bugs:

- https://lore.kernel.org/linux-crypto/20260723183438.GB93534@quark/
- https://lore.kernel.org/linux-crypto/20260723192514.GA110634@quark/
- https://lore.kernel.org/linux-crypto/20260723202704.GB110634@quark/
- https://lore.kernel.org/linux-crypto/20260723205342.GC110634@quark/

Overall, I think this demotion is extraordinarily well justified.

The pending fixes for some bugs don't change the big picture.  In fact,
the introduction of BAM locking seems likely to exacerbate the
performance issues.

It would not be responsible to defer to the hardware vendor here.  The
community has a responsibility to uphold high technical standards,
especially for cryptography.

- Eric