Re: [PATCH] mmc: sdhci-msm: Add quirk to disable CQE for ICE legacy mode
From: Md Sadre Alam
Date: Mon Dec 29 2025 - 00:58:21 EST
Hi,
On 12/29/2025 1:50 AM, Eric Biggers wrote:
On Wed, Dec 24, 2025 at 03:40:50PM +0530, Md Sadre Alam wrote:
Some hosts require Inline Crypto Engine (ICE) to operate in legacy mode
instead of Command Queue Engine (CQE) mode for platform-specific
requirements or compatibility reasons. Introduce a host-level quirk
`host_disable_cqe` to forcefully disable CQE negotiation and allow ICE
to function through the legacy request path.
When the device tree omits the "supports-cqe" property, the driver sets
`host_disable_cqe = true` and avoids enabling MMC_CAP2_CQE during card
initialization. This ensures that even CQE-capable hardware falls back
to legacy SDHCI request handling. A minimal `cqhci_disable_ops` is
provided with `.cqe_enable = cqhci_host_disable` returning -EINVAL to
force the fallback. Other ops are left NULL for safe defaults.
For builds without CONFIG_MMC_CRYPTO, the driver uses standard
sdhci_add_host() to avoid unnecessary CQE infrastructure initialization.
This allows platforms to forcefully opt out of CQE usage and ensure ICE
operates reliably in legacy mode, providing stable crypto operations
without command queuing complexity.
Signed-off-by: Md Sadre Alam <quic_mdalam@xxxxxxxxxxx>
I'm confused. If CQE isn't supported by the hardware, surely it would
make more sense for the driver to not advertise the host as being
CQE-capable at all? This patch seems to introduce an ambiguous middle
ground, where the host is CQE-capable but not really.
The hardware supports CQE: both the SDHCI‑MSM controller and the eMMC
device are CQE‑capable.
The issue arises because the ICE driver is tightly coupled with the CMDQ
(CQE) driver code, creating a dependency.
If the host forcefully disables CMDQ, ICE becomes unusable under the
current design.
This patch allows ICE to remain functional via the legacy SDHCI path
even when CMDQ is explicitly disabled by the host.
Thanks,
Alam.