Re: [PATCH] crypto: qce - Remove driver

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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

> This is an interesting twist though, because it means the claim that
> people can just disable this driver in their kconfig to avoid the
> problems in it (which is being used as justification for keeping it) is
> actually false as well.  As well as the claim that adding the node to
> the DT file is "just describing the hardware" and has no impact.
> 
> This would also imply that no driver using this sync_state mechanism can
> ever be completely removed from Linux, ever, which seems odd.

Linux has always worked around various firmware peculiarities, so
I guess we're just continuing the tradition! :P

Konrad