[PATCH 0/3] arm64: dts: qcom: eliza: Left-over review fixes

[PATCH 0/3] arm64: dts: qcom: eliza: Left-over review fixes

[Abel Vesa]

Some review comments were not addressed before the initial Eliza
devicetree support was merged. This series addresses the remaining
issues.

The changes are split into three patches:
- one patch with coding style cleanups
- one functional fix for GCC/CX power domain handling
- one functional fix disabling UFS MCQ mode

The MCQ mode was enabled during review in anticipation of driver
support, which did not materialize in time.

Bjorn, feel free to squash as appropriate, since the original commit
is currently only in your tree.

Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Abel Vesa (3):
      arm64: dts: qcom: eliza: Coding style clean-ups
      arm64: dts: qcom: eliza: Add CX power domain to GCC
      arm64: dts: qcom: eliza: Disable UFS MCQ mode

 arch/arm64/boot/dts/qcom/eliza.dtsi | 35 +++++++++++++++++++----------------
 1 file changed, 19 insertions(+), 16 deletions(-)
---
base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
change-id: 20260322-eliza-base-dt-fixes-6b93dd26c697

Best regards,
--  
Abel Vesa <abel.vesa@oss.qualcomm.com>

[PATCH 1/3] arm64: dts: qcom: eliza: Coding style clean-ups

[Abel Vesa]

Some coding style issues were raised during review but the devicetree
was merged meanwhile. Address them here.

These changes are non-functional.

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 | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 190f10a77d74..5dc3aede6842 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -686,7 +686,7 @@ pcie_noc: interconnect@16c0000 {
 			reg = <0x0 0x016c0000 0x0 0x11400>;
 			qcom,bcm-voters = <&apps_bcm_voter>;
 			clocks = <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
-				<&gcc GCC_CFG_NOC_PCIE_ANOC_AHB_CLK>;
+				 <&gcc GCC_CFG_NOC_PCIE_ANOC_AHB_CLK>;
 			#interconnect-cells = <2>;
 		};
 
@@ -722,7 +722,6 @@ ufs_mem_phy: phy@1d80000 {
 			clocks = <&rpmhcc RPMH_CXO_CLK>,
 				 <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
 				 <&tcsr TCSR_UFS_CLKREF_EN>;
-
 			clock-names = "ref",
 				      "ref_aux",
 				      "qref";
@@ -912,10 +911,12 @@ pdc: interrupt-controller@b220000 {
 		spmi: arbiter@c400000 {
 			compatible = "qcom,eliza-spmi-pmic-arb",
 				     "qcom,x1e80100-spmi-pmic-arb";
-			reg = <0 0x0c400000 0 0x3000>,
-			      <0 0x0c500000 0 0x400000>,
-			      <0 0x0c440000 0 0x80000>;
-			reg-names = "core", "chnls", "obsrvr";
+			reg = <0x0 0x0c400000 0x0 0x3000>,
+			      <0x0 0x0c500000 0x0 0x400000>,
+			      <0x0 0x0c440000 0x0 0x80000>;
+			reg-names = "core",
+				    "chnls",
+				    "obsrvr";
 
 			qcom,ee = <0>;
 			qcom,channel = <0>;
@@ -925,9 +926,10 @@ spmi: arbiter@c400000 {
 			ranges;
 
 			spmi_bus0: spmi@c42d000 {
-				reg = <0 0x0c42d000 0 0x4000>,
-				      <0 0x0c4c0000 0 0x10000>;
-				reg-names = "cnfg", "intr";
+				reg = <0x0 0x0c42d000 0x0 0x4000>,
+				      <0x0 0x0c4c0000 0x0 0x10000>;
+				reg-names = "cnfg",
+					    "intr";
 
 				interrupt-names = "periph_irq";
 				interrupts-extended = <&pdc 1 IRQ_TYPE_LEVEL_HIGH>;
@@ -939,9 +941,10 @@ spmi_bus0: spmi@c42d000 {
 			};
 
 			spmi_bus1: spmi@c432000 {
-				reg = <0 0x0c432000 0 0x4000>,
-				      <0 0x0c4d0000 0 0x10000>;
-				reg-names = "cnfg", "intr";
+				reg = <0x0 0x0c432000 0x0 0x4000>,
+				      <0x0 0x0c4d0000 0x0 0x10000>;
+				reg-names = "cnfg",
+					    "intr";
 
 				interrupt-names = "periph_irq";
 				interrupts-extended = <&pdc 3 IRQ_TYPE_LEVEL_HIGH>;

-- 
2.48.1

Re: [PATCH 1/3] arm64: dts: qcom: eliza: Coding style clean-ups

[Dmitry Baryshkov]

On Sun, Mar 22, 2026 at 06:08:19PM +0200, Abel Vesa wrote:
> Some coding style issues were raised during review but the devicetree
> was merged meanwhile. Address them here.
> 
> These changes are non-functional.
> 
> 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 | 27 +++++++++++++++------------
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 1/3] arm64: dts: qcom: eliza: Coding style clean-ups

[Konrad Dybcio]

On 3/22/26 5:08 PM, Abel Vesa wrote:
> Some coding style issues were raised during review but the devicetree
> was merged meanwhile. Address them here.
> 
> These changes are non-functional.
> 
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Abel Vesa]

Recent discussions off-list highlighted that the GCC should vote for the
RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
aggregate the correct load for the CX rail, potentially leading to voltage
drops and system instability.

Add the missing power-domains property to associate GCC with RPMHPD_CX.

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 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 5dc3aede6842..fab603cd8e42 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -617,6 +617,8 @@ gcc: clock-controller@100000 {
 				 <&ufs_mem_phy 2>,
 				 <0>;
 
+			power-domains = <&rpmhpd RPMHPD_CX>;
+
 			#clock-cells = <1>;
 			#reset-cells = <1>;
 			#power-domain-cells = <1>;

-- 
2.48.1

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Dmitry Baryshkov]

On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> aggregate the correct load for the CX rail, potentially leading to voltage
> drops and system instability.

Should we add it on other platforms too?

> 
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
> 
> 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 | 2 ++
>  1 file changed, 2 insertions(+)
> 

-- 
With best wishes
Dmitry

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Konrad Dybcio]

On 3/22/26 6:51 PM, Dmitry Baryshkov wrote:
> On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
>> Recent discussions off-list highlighted that the GCC should vote for the
>> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
>> aggregate the correct load for the CX rail, potentially leading to voltage
>> drops and system instability.
> 
> Should we add it on other platforms too?

Things generally work better when powered on

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Abel Vesa]

On 26-03-23 11:50:37, Konrad Dybcio wrote:
> On 3/22/26 6:51 PM, Dmitry Baryshkov wrote:
> > On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> >> Recent discussions off-list highlighted that the GCC should vote for the
> >> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> >> aggregate the correct load for the CX rail, potentially leading to voltage
> >> drops and system instability.
> > 
> > Should we add it on other platforms too?
> 
> Things generally work better when powered on

Yep, definitely.

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Dmitry Baryshkov]

On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> aggregate the correct load for the CX rail, potentially leading to voltage
> drops and system instability.
> 
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
> 
> 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 | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Konrad Dybcio]

On 3/22/26 5:08 PM, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> aggregate the correct load for the CX rail, potentially leading to voltage
> drops and system instability.
> 
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
> 
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Bjorn Andersson]

On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms.

Your commit message should describe the problem that the patch is trying
to solve, not the story about how the patch came to be.

> Without this, RPMh may not aggregate the correct load for the CX rail,

"may not"?

In what case will it aggregate the client votes cast on the GDSCs
aggregate to anything without the power-domains property?

> potentially leading to voltage
> drops and system instability.
> 
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
> 

I think the commit message should be something like:

"""
Unless CX is declared the power-domain of GCC votes (power and
performance) on the GDSCs provided by GCC will not propagate to the CX,
which might result in under-voltage conditions.

Add the missing power-domains property to associate GCC with RPMHPD_CX.
"""

Regards,
Bjorn

> 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 | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 5dc3aede6842..fab603cd8e42 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -617,6 +617,8 @@ gcc: clock-controller@100000 {
>  				 <&ufs_mem_phy 2>,
>  				 <0>;
>  
> +			power-domains = <&rpmhpd RPMHPD_CX>;
> +
>  			#clock-cells = <1>;
>  			#reset-cells = <1>;
>  			#power-domain-cells = <1>;
> 
> -- 
> 2.48.1
> 

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Abel Vesa]

On 26-03-23 21:15:12, Bjorn Andersson wrote:
> On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> > Recent discussions off-list highlighted that the GCC should vote for the
> > RPMh CX power domain on Qualcomm platforms.
> 
> Your commit message should describe the problem that the patch is trying
> to solve, not the story about how the patch came to be.

Sure. Will fix.

> 
> > Without this, RPMh may not aggregate the correct load for the CX rail,
> 
> "may not"?
> 
> In what case will it aggregate the client votes cast on the GDSCs
> aggregate to anything without the power-domains property?

So my understanding was that RPMh firmware aggregates votes
internally as it knows the actual parent-child relationship and we were
supposed to replicate that exactly in kernel for reliability purposes.

Meaning, in theory it should know to aggregate proper load for the CX
based on GDSCs voting, it's just that it isn't always a sure thing.

Maybe I missunderstood it though.

> 
> > potentially leading to voltage
> > drops and system instability.
> > 
> > Add the missing power-domains property to associate GCC with RPMHPD_CX.
> > 
> 
> I think the commit message should be something like:
> 
> """
> Unless CX is declared the power-domain of GCC votes (power and
> performance) on the GDSCs provided by GCC will not propagate to the CX,
> which might result in under-voltage conditions.
> 
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
> """

Sure, will respin with this commit message.

Thanks for reviewing.

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Konrad Dybcio]

On 3/24/26 2:45 PM, Abel Vesa wrote:
> On 26-03-23 21:15:12, Bjorn Andersson wrote:
>> On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
>>> Recent discussions off-list highlighted that the GCC should vote for the
>>> RPMh CX power domain on Qualcomm platforms.
>>
>> Your commit message should describe the problem that the patch is trying
>> to solve, not the story about how the patch came to be.
> 
> Sure. Will fix.
> 
>>
>>> Without this, RPMh may not aggregate the correct load for the CX rail,
>>
>> "may not"?
>>
>> In what case will it aggregate the client votes cast on the GDSCs
>> aggregate to anything without the power-domains property?
> 
> So my understanding was that RPMh firmware aggregates votes
> internally as it knows the actual parent-child relationship and we were
> supposed to replicate that exactly in kernel for reliability purposes.
> 
> Meaning, in theory it should know to aggregate proper load for the CX
> based on GDSCs voting, it's just that it isn't always a sure thing.
> 
> Maybe I missunderstood it though.

GDSCs are fancy on/off switches

RPMH votes must be carried out manually and in the kernel that's via
RPMHPD/RPMHCC/ICC

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: eliza: Add CX power domain to GCC

[Abel Vesa]

On 26-03-24 16:14:34, Konrad Dybcio wrote:
> On 3/24/26 2:45 PM, Abel Vesa wrote:
> > On 26-03-23 21:15:12, Bjorn Andersson wrote:
> >> On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> >>> Recent discussions off-list highlighted that the GCC should vote for the
> >>> RPMh CX power domain on Qualcomm platforms.
> >>
> >> Your commit message should describe the problem that the patch is trying
> >> to solve, not the story about how the patch came to be.
> > 
> > Sure. Will fix.
> > 
> >>
> >>> Without this, RPMh may not aggregate the correct load for the CX rail,
> >>
> >> "may not"?
> >>
> >> In what case will it aggregate the client votes cast on the GDSCs
> >> aggregate to anything without the power-domains property?
> > 
> > So my understanding was that RPMh firmware aggregates votes
> > internally as it knows the actual parent-child relationship and we were
> > supposed to replicate that exactly in kernel for reliability purposes.
> > 
> > Meaning, in theory it should know to aggregate proper load for the CX
> > based on GDSCs voting, it's just that it isn't always a sure thing.
> > 
> > Maybe I missunderstood it though.
> 
> GDSCs are fancy on/off switches
> 
> RPMH votes must be carried out manually and in the kernel that's via
> RPMHPD/RPMHCC/ICC

Right. Thanks.

[PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Abel Vesa]

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

Re: [PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Krzysztof Kozlowski]

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

Re: [PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Abel Vesa]

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.

Re: [PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Konrad Dybcio]

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>;
>  
> 

Re: [PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Abel Vesa]

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?

Re: [PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Nitin Rawat]

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

Re: [PATCH 3/3] arm64: dts: qcom: eliza: Disable UFS MCQ mode

[Abel Vesa]

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.