The UFS MCQ mode is currently not functional in the driver. Eliza is
the first platform enabling it, which results in UFS failures at runtime
with errors such as:
ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4
ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00
The failures occur when accessing the UFS device, while the controller
and PHY initialize correctly.
Disable MCQ mode by removing the corresponding register range. This can
be reverted once MCQ support is fixed in the driver.
Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index fab603cd8e42..60a3c861a5c0 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -743,10 +743,8 @@ ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,eliza-ufshc",
"qcom,ufshc",
"jedec,ufs-2.0";
- reg = <0x0 0x01d84000 0x0 0x3000>,
- <0x0 0x01da0000 0x0 0x15000>;
- reg-names = "std",
- "mcq";
+ reg = <0x0 0x01d84000 0x0 0x3000>;
+ reg-names = "std";
interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
--
2.48.1
On 26-03-22 18:08:21, Abel Vesa wrote: > The UFS MCQ mode is currently not functional in the driver. Eliza is > the first platform enabling it, which results in UFS failures at runtime > with errors such as: > > ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4 > ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00 > > The failures occur when accessing the UFS device, while the controller > and PHY initialize correctly. > > Disable MCQ mode by removing the corresponding register range. This can > be reverted once MCQ support is fixed in the driver. Nitin, care to comment?
On 3/23/2026 11:33 PM, Abel Vesa wrote: > On 26-03-22 18:08:21, Abel Vesa wrote: >> The UFS MCQ mode is currently not functional in the driver. Eliza is >> the first platform enabling it, which results in UFS failures at runtime >> with errors such as: >> >> ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4 >> ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00 >> >> The failures occur when accessing the UFS device, while the controller >> and PHY initialize correctly. >> >> Disable MCQ mode by removing the corresponding register range. This can >> be reverted once MCQ support is fixed in the driver. > > Nitin, care to comment? Hi Abel, Validated MCQ on SM8750 and SM8650 now with ESI both enabled and disabled, and it is working as expected with no errors observed. Mounting, read/write operations, and runtime suspend/resume were validated successfully. will post the MCQ enablement device tree changes for these targets tomorrow. It appears that some changes may be missing on Eliza, which will need to be debugged separately. Regards, Nitin
On 26-03-23 23:46:04, Nitin Rawat wrote: > > > On 3/23/2026 11:33 PM, Abel Vesa wrote: > > On 26-03-22 18:08:21, Abel Vesa wrote: > > > The UFS MCQ mode is currently not functional in the driver. Eliza is > > > the first platform enabling it, which results in UFS failures at runtime > > > with errors such as: > > > > > > ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4 > > > ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00 > > > > > > The failures occur when accessing the UFS device, while the controller > > > and PHY initialize correctly. > > > > > > Disable MCQ mode by removing the corresponding register range. This can > > > be reverted once MCQ support is fixed in the driver. > > > > Nitin, care to comment? > > Hi Abel, > > Validated MCQ on SM8750 and SM8650 now with ESI both enabled and disabled, > and it is working as expected with no errors observed. Mounting, read/write > operations, and runtime suspend/resume were validated successfully. will > post the MCQ enablement device tree changes for these targets tomorrow. > > It appears that some changes may be missing on Eliza, which will need to be > debugged separately. So, after a quick debugging session with help Nitin, it has been concluded that the problem is not in the UFS MCQ driver implementation but rather the GCC clock needs to enable FORCE_MEM_CORE_ON for the GCC_UFS_PHY_AXI_CLK as well, as per MCQ related documentation. Will send a patch to fix the GCC driver instead. So this patch can be dropped. As a separate issue, Eliza DT UFS node is missing: msi-parent = <&gic_its 0x60>; So I'll respin the series with a patch that does this instead. Thanks Nitin helping with this.
On 3/22/26 5:08 PM, Abel Vesa wrote:
> The UFS MCQ mode is currently not functional in the driver. Eliza is
> the first platform enabling it, which results in UFS failures at runtime
> with errors such as:
>
> ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4
> ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00
>
> The failures occur when accessing the UFS device, while the controller
> and PHY initialize correctly.
>
> Disable MCQ mode by removing the corresponding register range. This can
> be reverted once MCQ support is fixed in the driver.
>
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
+Mani any idea?
Konrad
> arch/arm64/boot/dts/qcom/eliza.dtsi | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index fab603cd8e42..60a3c861a5c0 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -743,10 +743,8 @@ ufs_mem_hc: ufshc@1d84000 {
> compatible = "qcom,eliza-ufshc",
> "qcom,ufshc",
> "jedec,ufs-2.0";
> - reg = <0x0 0x01d84000 0x0 0x3000>,
> - <0x0 0x01da0000 0x0 0x15000>;
> - reg-names = "std",
> - "mcq";
> + reg = <0x0 0x01d84000 0x0 0x3000>;
> + reg-names = "std";
>
> interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
>
>
On 22/03/2026 17:08, Abel Vesa wrote:
> The UFS MCQ mode is currently not functional in the driver. Eliza is
> the first platform enabling it, which results in UFS failures at runtime
> with errors such as:
>
> ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4
> ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00
>
> The failures occur when accessing the UFS device, while the controller
> and PHY initialize correctly.
>
> Disable MCQ mode by removing the corresponding register range. This can
> be reverted once MCQ support is fixed in the driver.
>
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
MCQ should be disabled in the driver, not via DTS. You have specific
eliza compatible for exactly this purpose.
Best regards,
Krzysztof
On 26-03-22 20:43:01, Krzysztof Kozlowski wrote:
> On 22/03/2026 17:08, Abel Vesa wrote:
> > The UFS MCQ mode is currently not functional in the driver. Eliza is
> > the first platform enabling it, which results in UFS failures at runtime
> > with errors such as:
> >
> > ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 4
> > ufs_device_wlun 0:0:0:49488: tag#4 CDB: opcode=0x1b 1b 00 00 00 10 00
> >
> > The failures occur when accessing the UFS device, while the controller
> > and PHY initialize correctly.
> >
> > Disable MCQ mode by removing the corresponding register range. This can
> > be reverted once MCQ support is fixed in the driver.
> >
> > Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/eliza.dtsi | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
>
> MCQ should be disabled in the driver, not via DTS. You have specific
> eliza compatible for exactly this purpose.
Actually, MCQ support is working, See my reply to Nitin. there is an issue
with the GCC driver for which I'll send a patch soon.
© 2016 - 2026 Red Hat, Inc.