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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c4eef659-a4df-4856-5d87-cb699de67fed@quicinc.com>
Date: Mon, 29 Dec 2025 11:27:48 +0530
From: Md Sadre Alam <quic_mdalam@...cinc.com>
To: Eric Biggers <ebiggers@...nel.org>
CC: <adrian.hunter@...el.com>, <quic_asutoshd@...cinc.com>,
        <ulf.hansson@...aro.org>, <linux-mmc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH] mmc: sdhci-msm: Add quirk to disable CQE for ICE legacy
 mode

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@...cinc.com>
> 
> 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.