Re: [PATCH] crypto: qce - Replace with stub driver

On 31/07/2026 20:31, Demi Marie Obenour wrote:
> On 7/31/26 05:06, Krzysztof Kozlowski wrote:
>> On 31/07/2026 07:08, Eric Biggers wrote:
>>> None of the algorithms the QCE driver registers with the crypto API are
>>> even close to being useful.  They're massively outperformed by the
>>
>> The amount of patches you send towards removal of QCE is really
>> stunning. Or rather worrying. This is like third approach or so.
>>
>> Your previous approaches received valid feedback, including even fixes
>> and committment of new maintainer.
>>
>> But you even complained that it does receive fixes! [1]
>>
>> We removed the driver temporarily from typical configurations, so no one
>> will be affected, by whatever is found now and not yet fixed. Still not
>> enough! For you this was reason to remove the driver (AGAIN!) [2]
> 
> A stub driver needs to be added for power management reasons.  It turns
> out that if there is no driver, power consumption is very high.
> 
>> This is beyond comprehension and very unpleasant, because you actively
>> work against the community with this approach.
> 
> I trust that Bartosz can fix the driver with enough work.  However,
> even if the QCE driver had never had a single bug, it would still not
> be worth using.  Its performance is so poor that one should always
> use CPU-based crypto instead.  In the default configuration, that is
> in fact what happens.
> 
> The QCE's algorithm implementations only provide a way people can
> misconfigure their systems and ruin their performance.  There are
> debug options that also severely harm performance, but they have
> legitimate uses during development.  The current QCE driver doesn't.
> 
> I have no problem with a driver for the QCE that does something actually
> useful.  While there are disagreements about whether restricted media
> processing is a feature or an anti-feature, my view is that it is
> better for it to be implemented upstream than in an out-of-tree driver.
> However, the driver as it currently exists does not implement this.
> 
> I expect that such a driver would not use the crypto API at all.
> Instead, I suspect it would use dmabufs for source and destination
> buffers and integrate with the secure world firmware in some way.
> That means that the driver doesn't belong under drivers/crypto.
> 
> These are the reasons I submitted a patch to mark the driver as BROKEN,
> which Herbert Xu has since accepted.

And Bartosz and other people committed to work on this by improving,
fixing and in the long term providing you with the actual important user
of this. All this was already said.

And then after having all these discussions Eric sends AGAIN patch to
remove the driver. How many times this will have to be discussed the
same way? If we now reach agreement the driver stays, next month again
there will be a patch to remove it? And then one more month again?

The driver is marked as BROKEN, thus absolutely NO ONE is affected by
any issues the driver has.

It's some personal vendetta to keep coming after that - unimportant now
- driver.

Best regards,
Krzysztof