Re: [PATCH RESEND v4] mmc: Avoid reprogram all keys to Inline Crypto Engine for MMC runtime suspend resume
Eric Biggers <[email protected]> Thu, 23 Jul 2026 23:01:04 +0000
| Newsgroups | org.kernel.vger.linux-mmc,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, May 29, 2026 at 04:05:52PM +0530, Neeraj Soni wrote: > Yes for cold boot this is true and Crypto reprogram is not needed. This patch addreses the use cases like > runtime suspend resume, deep sleep / Quick boot (DS/QB) and suspend to disk (aka hibernation) use cases > where the runtime context is preserved either in dynamic memory (DS/QB) or in secondry memory (hibernation). > This is tested internally on SAR1250P chipset for hibernation and DS/QB. But sdhci_msm_gcc_reset() is called only from the driver probe function (sdhci_msm_probe()), before MMC_CAP2_CRYPTO is set. So Jie's comment is correct: the new key reprogramming path is dead code. And as per the following comment, key reprogramming is still needed in some cases (https://lore.kernel.org/linux-mmc/[email protected]/). So doesn't this patch break the sdhci-msm driver? I'm also skeptical of the following change, which seems unrelated to the rest of the patch: > -#ifdef CONFIG_MMC_CRYPTO > #define MMC_CAP2_CRYPTO (1 << 27) /* Host supports inline encryption */ > -#else > -#define MMC_CAP2_CRYPTO 0 > -#endif Because of that, mtk-sd sets MMC_CAP2_CRYPTO even when CONFIG_MMC_CRYPTO=n. That makes CQHCI_CRYPTO_GENERAL_ENABLE be used even when CONFIG_MMC_CRYPTO=n. - Eric