A few days back I wrote about upstream Linux kernel developers marking the Qualcomm crypto accelerator driver as "broken" and "harmful" due to its slow performance, history of bugs, and other limitations. Now this Qualcomm Crypto Engine "QCE" driver might be removed outright from the Linux kernel source tree after discovering it's even worse than anticipated.

Linux kernel crypto expert Eric Biggers of Google is looking to remove the Qualcomm QCE driver outright and just not simply gate it behind the "BROKEN" Kconfig knob. The motivating factor now is that it's bee found that QCE is ~48x slower than the ARMv8 Crypto Extensions (ARMv8 CE) that are more aligned with proper Linux kernel use. Not only is QCE ~48x slower, but it also led to "actually consumes significantly *more* CPU cycles than doing the hashing directly on the CPU."

In which case assuming the findings are accurate completely make this driver a dud.

This kernel mailing list thread provides more details:

"sha256-lib (i.e. ARMv8 CE):

Wall-clock elapsed time: 0.10s
CPU time used: 0.10s
CPU time spent in hardirq context: 0.00s
CPU time spent in softirq context: 0.00s

sha256-qce:

Wall-clock elapsed time: 10.76s
CPU time used: 5.14s
CPU time spent in hardirq context: 0.77s
CPU time spent in softirq context: 2.31s

So sha256-qce is over 100 times slower and uses over 50 times more CPU than ARMv8 CE, over half of that in hardirq or softirq context.

This was even worse than what I got last time I tried this! So I tried rolling back your BAM locking patches:

Wall-clock elapsed time: 4.85s
CPU time used: 2.78s
CPU time spent in hardirq context: 0.55s
CPU time spent in softirq context: 0.94s

That's more in line with what I measured last time I tried this, but still atrocious. It's still far more CPU time used than just doing the hashing on the CPU, and much of it spent in hardirq and softirq contexts. The BAM locking just makes it even worse."

So with this patch sent out yesterday on the mailing list, Eric Biggers is proposing that all 3.5k lines of code making up the QCE driver simply be removed from the kernel. That kernel mailing list thread has led to some back and forth with at least one kernel developer wanting to keep the driver around and maintain it. But with the limited use of the driver at present, the discussion roped in Greg Kroah-Hartman for guidance and the discussion is ongoing over the feasibility of keeping this driver in the kernel or not. We'll see what happens.