Re: [PATCH] crypto: qce - Remove driver
Konrad Dybcio <[email protected]> Thu, 30 Jul 2026 13:15:35 +0200
| Newsgroups | org.kernel.vger.linux-crypto,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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