Re: [PATCH] crypto: qce - Remove driver

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1785 bytes --]

On 7/30/26 07:15, Konrad Dybcio wrote:
> On 7/29/26 7:18 PM, Eric Biggers wrote:
>> On Wed, Jul 29, 2026 at 06:55:20PM +0200, Konrad Dybcio wrote:
>>>>> Unfortunately removing it drains way more battery, because the buses
>>>>> never hit sync_state and are kept at their maximum frequencies:
>>>>>
>>>>> [   18.021823] qnoc-glymur interconnect-1: sync_state() pending due to 1dfa000.crypto
>>>>> [   18.029605] qnoc-glymur 16e0000.interconnect: sync_state() pending due to 1dfa000.crypto
>>>>>
>>>>> (it transiently also pins DRAM and friends to max-freq which absolutely
>>>>> kills battery life)
>>>>
>>>> Isn't that easily fixable by marking the node as "disabled" in the
>>>> device tree, or even just deleting it entirely?
>>>
>>> Avoided? Yes. Fixed? No. The DT is valid but Linux can't deal with it
>>> [since the driver is gone]
>>
>> If needed we can keep a stub driver that just disables power and doesn't
>> register anything with the crypto API.  I can send a patch that does
>> that.
> 
> I believe we (are going to) need something like that in the kernel
> for similar cases, however I'd rather see this driver kept/reinstated
> for the reasons Bartosz is arguing

What about removing all of the code that actually does cryptography?
The problem isn't that the driver can't be fixed, but that:

1. It requires additional maintenance, and not just by the driver
   maintainer.

2. Even if the driver never needed maintenance, the QCE is so slow,
   and the driver overhead so great, that the features currently
   exposed by the driver should never be used.

As Eric pointed out, the future use-cases Bartosz mentions should be
implemented by a driver that isn't in drivers/crypto.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]