Re: [PATCH] mmc: sdhci-msm: Add quirk to disable CQE for ICE legacy mode

[Adrian Hunter <adrian.hunter@intel.com>]

On 07/01/2026 13:55, Md Sadre Alam wrote:
> HI,
> 
> On 1/5/2026 8:31 PM, Adrian Hunter wrote:
>> On 24/12/2025 12:10, 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.
>>
>> Can't the driver simply opt-out by not setting MMC_CAP2_CQE?
> Correct. This change is intended for the case where both host and device supports CMDQ, but the host explicitly wants to disable CMDQ and want to use the Inline Crypto Engine (ICE) in legacy way.Simply clearing MMC_CAP2_CQE would bypass CMDQ, but it would also bypass ICE as well.

Did you try it?  Looks to me like removing MMC_CAP2_CQE is all that is needed since "mmc: sdhci-msm: Enable ICE for CQE-capable controllers with non-CQE cards"