[PATCH V6 0/3] arm64: dts: qcom: Monaco: Enable SDHCI storage support

[PATCH V6 0/3] arm64: dts: qcom: Monaco: Enable SDHCI storage support

[Monish Chunara]

Respected Maintainers,

This is v6 of the Monaco SDHCI storage support series.

Changes in v6:
- Propagate Reviewed-by tags (Konrad)
- Rebase the changes on latest tip.
- Link to v5: https://lore.kernel.org/all/20260826112456.482982-1-monish.chunara@oss.qualcomm.com/

Changes in v5:
- Rearrange the Makefile entries in alphabetical order. (sashiko-bot)
- Rebase the changes on latest tip.
- Link to v4: https://lore.kernel.org/all/20260716142445.2767955-1-monish.chunara@oss.qualcomm.com/

Changes in v4:
- Remove the redundant regulator node - vreg_s2s, which is already defined in
  base file via another merged patch. (sashiko-bot)
- Update the base monaco-evk.dts file to make it storage-agnostic by removing
  conflicting eMMC specific properties. (sashiko-bot)
- Link to v3: https://lore.kernel.org/all/20260701081715.2580329-1-monish.chunara@oss.qualcomm.com/

Changes in v3:
- Update the patch to handle the supports-cqe property for monaco-monza-som
  platform which also extends the monaco SoC DT.
- Link to v2: https://lore.kernel.org/all/20260616130347.3096034-1-monish.chunara@oss.qualcomm.com/

Changes in v2:
- Avoids using the reference to direct supplies as dummy
- Updates the eMMC overlay to remove the static UFS host disablement and
  vreg_l8a voltage override, allowing DT-fixup to manage the UFS-eMMC mutual
  exclusion dynamically for flexible UFS/eMMC configurations.
- Link to v1: https://lore.kernel.org/all/20260227105055.2364348-1-monish.chunara@oss.qualcomm.com/

Validated on Qualcomm Monaco EVK with both SD card and eMMC modules.


Monish Chunara (3):
  arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT
  arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay
  arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay

 arch/arm64/boot/dts/qcom/Makefile             |  8 +++
 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso | 27 +++++++
 .../boot/dts/qcom/monaco-evk-sd-card.dtso     | 72 +++++++++++++++++++
 arch/arm64/boot/dts/qcom/monaco-evk.dts       | 11 ---
 .../arm64/boot/dts/qcom/monaco-monza-som.dtsi |  1 +
 arch/arm64/boot/dts/qcom/monaco.dtsi          |  1 -
 arch/arm64/boot/dts/qcom/qcs8300-ride.dts     |  1 +
 7 files changed, 109 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso

-- 
2.34.1

[PATCH V6 1/3] arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT

[Monish Chunara]

The Monaco SoC SDHC controller supports both eMMC and SD cards. However,
the 'supports-cqe' property (Command Queue Engine) is specific to eMMC
and conflicts with SD card operation.

Remove 'supports-cqe' from the SoC device tree to ensure compatibility
with SD cards. Simultaneously, add the property explicitly to the
qcs8300-ride and monaco-monza-som board device tree, as this board uses
the controller in eMMC mode.

This ensures the SoC definition remains generic while enabling features
correctly at the board level.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco-monza-som.dtsi | 1 +
 arch/arm64/boot/dts/qcom/monaco.dtsi           | 1 -
 arch/arm64/boot/dts/qcom/qcs8300-ride.dts      | 1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/monaco-monza-som.dtsi b/arch/arm64/boot/dts/qcom/monaco-monza-som.dtsi
index 36af1ad2105d..a489932c7b1d 100644
--- a/arch/arm64/boot/dts/qcom/monaco-monza-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco-monza-som.dtsi
@@ -275,6 +275,7 @@ &sdhc_1 {
 	mmc-hs400-1_8v;
 	mmc-hs400-enhanced-strobe;
 
+	supports-cqe;
 	no-sd;
 	no-sdio;
 	non-removable;
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 35fbee63d4c6..591ad233f90e 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -4843,7 +4843,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 			qcom,dll-config = <0x000f64ee>;
 			qcom,ddr-config = <0x80040868>;
 			bus-width = <8>;
-			supports-cqe;
 			dma-coherent;
 
 			qcom,ice = <&sdhc_ice>;
diff --git a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
index be850a23472f..54770aa7376d 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs8300-ride.dts
@@ -721,6 +721,7 @@ &sdhc_1 {
 	vmmc-supply = <&vreg_l8a>;
 	vqmmc-supply = <&vreg_s4a>;
 
+	supports-cqe;
 	non-removable;
 	no-sd;
 	no-sdio;
-- 
2.34.1

[PATCH V6 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay

[Monish Chunara]

The monaco EVK board supports either eMMC or SD-card, but only one can
be active at a time.

Make the base monaco-evk.dtsi storage-agnostic by removing eMMC-specific
configuration from it. This allows storage media selection to be handled
through device tree overlays.

Introduce an SD card overlay that enables the SD Host Controller
Interface (SDHCI) for SD-based storage on the monaco EVK board.

Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile             |  4 ++
 .../boot/dts/qcom/monaco-evk-sd-card.dtso     | 72 +++++++++++++++++++
 arch/arm64/boot/dts/qcom/monaco-evk.dts       | 11 ---
 3 files changed, 76 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 88230c4e00ea..1c5b2e95cb9d 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -82,6 +82,10 @@ dtb-$(CONFIG_ARCH_QCOM)	+= monaco-ac-evk-ifp-mezzanine.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk-el2.dtb
 monaco-evk-ifp-mezzanine-dtbs	:= monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk-ifp-mezzanine.dtb
+
+monaco-evk-sd-card-dtbs := monaco-evk.dtb monaco-evk-sd-card.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-sd-card.dtb
+
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-alcatel-idol347.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
new file mode 100644
index 000000000000..bc4ea12587a2
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+        vmmc_sdc: regulator-mmc-sdc {
+                compatible = "regulator-fixed";
+
+                regulator-name = "vmmc_sdc";
+                regulator-min-microvolt = <2950000>;
+                regulator-max-microvolt = <2950000>;
+        };
+
+        vreg_sdc: regulator-sdc {
+		compatible = "regulator-gpio";
+
+		regulator-name = "vreg_sdc";
+		regulator-type = "voltage";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <2950000>;
+
+		gpios = <&expander1 7 GPIO_ACTIVE_HIGH>;
+		states = <1800000 1>, <2950000 0>;
+
+		startup-delay-us = <100>;
+        };
+};
+
+&sdhc_1 {
+	vmmc-supply = <&vmmc_sdc>;
+	vqmmc-supply = <&vreg_sdc>;
+
+	pinctrl-0 = <&sdc1_state_on>, <&sd_cd>;
+	pinctrl-1 = <&sdc1_state_off>, <&sd_cd>;
+	pinctrl-names = "default", "sleep";
+
+	cap-sd-highspeed;
+	no-1-8-v;
+
+	bus-width = <4>;
+	cd-gpios = <&tlmm 11 GPIO_ACTIVE_LOW>;
+	no-mmc;
+	no-sdio;
+
+	status = "okay";
+};
+
+&sdhc1_opp_table {
+	opp-100000000 {
+		opp-hz = /bits/ 64 <100000000>;
+		required-opps = <&rpmhpd_opp_low_svs>;
+	};
+
+	opp-202000000 {
+		opp-hz = /bits/ 64 <202000000>;
+		required-opps = <&rpmhpd_opp_svs_l1>;
+	};
+};
+
+&tlmm {
+        sd_cd: sd-cd-state {
+                pins = "gpio11";
+                function = "gpio";
+                bias-pull-up;
+        };
+};
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
index 539c9c80a808..4c30dd110832 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
@@ -744,17 +744,6 @@ &remoteproc_gpdsp {
 	status = "okay";
 };
 
-&sdhc_1 {
-	vmmc-supply = <&vreg_l8a>;
-	vqmmc-supply = <&vreg_s2s>;
-
-	no-sd;
-	no-sdio;
-	non-removable;
-
-	status = "okay";
-};
-
 &serdes0 {
 	vdda-0p9-supply = <&vreg_l4a>;
 	vdda-1p2-supply = <&vreg_l5a>;
-- 
2.34.1

[PATCH V6 3/3] arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay

[Monish Chunara]

Enable the SDHCI controller for eMMC functionality on the Monaco EVK
using a device tree overlay.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile             |  4 +++
 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso | 27 +++++++++++++++++++
 2 files changed, 31 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 1c5b2e95cb9d..3563ccbe771d 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -80,6 +80,10 @@ monaco-ac-evk-ifp-mezzanine-dtbs	:= monaco-ac-evk.dtb monaco-evk-ifp-mezzanine.d
 dtb-$(CONFIG_ARCH_QCOM)	+= monaco-ac-evk-ifp-mezzanine.dtb
 
 dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk-el2.dtb
+
+monaco-evk-emmc-dtbs := monaco-evk.dtb monaco-evk-emmc.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-emmc.dtb
+
 monaco-evk-ifp-mezzanine-dtbs	:= monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk-ifp-mezzanine.dtb
 
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
new file mode 100644
index 000000000000..6454efc03ddb
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-emmc.dtso
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+&sdhc_1 {
+	vmmc-supply = <&vreg_l8a>;
+	vqmmc-supply = <&vreg_s2s>;
+
+	supports-cqe;
+
+	pinctrl-0 = <&sdc1_state_on>;
+	pinctrl-1 = <&sdc1_state_off>;
+
+	pinctrl-names = "default", "sleep";
+
+	non-removable;
+
+	bus-width = <8>;
+	no-sd;
+	no-sdio;
+
+	status = "okay";
+};
-- 
2.34.1

Re: [PATCH V6 1/3] arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: monaco: missing supports-cqe on sdhc_1 in monaco-ac-evk.dts
--

commit 5c417a101ec7d48bcf62abc40a54fc7490862bc8
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>

arm64: dts: qcom: monaco: Move eMMC CQE support from SoC to board DT

This commit removes the supports-cqe property from the shared SoC sdhc_1 node
in monaco.dtsi to avoid conflicts with SD card operation, and adds it
explicitly to the qcs8300-ride.dts and monaco-monza-som.dtsi board device
trees.

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 35fbee63d4c65..591ad233f90eb 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -4843,7 +4843,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>  			qcom,dll-config = <0x000f64ee>;
>  			qcom,ddr-config = <0x80040868>;
>  			bus-width = <8>;
> -			supports-cqe;

[Severity: Medium]
Should supports-cqe also be added to &sdhc_1 in
arch/arm64/boot/dts/qcom/monaco-ac-evk.dts?

While the follow-up patches in this series ("arm64: dts: qcom: monaco-evk:
Enable SDHCI for SD Card via overlay" and "arm64: dts: qcom: monaco-evk: Add
SDHCI support for eMMC via overlay") move &sdhc_1 out of monaco-evk.dts into
monaco-evk-emmc.dtso with supports-cqe, monaco-ac-evk.dts is not updated in
the series.

monaco-ac-evk.dts includes monaco.dtsi and enables &sdhc_1 directly in fixed
1.8V eMMC mode:

arch/arm64/boot/dts/qcom/monaco-ac-evk.dts:
&sdhc_1 {
	vmmc-supply = <&vreg_l8a>;
	vqmmc-supply = <&vreg_s2s>;

	no-sd;
	no-sdio;
	non-removable;

	status = "okay";
};

Without supports-cqe on &sdhc_1 in monaco-ac-evk.dts, sdhci_msm_probe() in
drivers/mmc/host/sdhci-msm.c takes the non-CQE path:

	if (of_property_read_bool(node, "supports-cqe"))
		ret = sdhci_msm_cqe_add_host(host, pdev);
	else
		ret = sdhci_add_host(host);

Wouldn't removing supports-cqe from monaco.dtsi without adding it to
monaco-ac-evk.dts cause sdhci_msm_probe() to skip sdhci_msm_cqe_add_host()
and sdhci_msm_ice_init(), disabling both CQE and inline encryption (qcom,ice)
on the Monaco-AC EVK board?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105101955.3732723-1-monish.chunara@oss.qualcomm.com?part=1

Re: [PATCH V6 3/3] arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] arm64: dts: qcom: root node syntax in monaco-evk-sd-card.dtso drops regulators
- [Medium] arm64: dts: qcom: missing supports-cqe on sdhc_1 in monaco-ac-evk.dts
- [Medium] arm64: dts: qcom: invalid and duplicate OPPs in monaco-evk-sd-card.dtso
--

commit 55ce3aa0fb14b29f7953daf1505d7c18f0d799da
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>

arm64: dts: qcom: monaco-evk: Add SDHCI support for eMMC via overlay

This series moves the eMMC supports-cqe property from the Monaco SoC device
tree to the board level and switches Monaco EVK SDHCI storage selection between
SD card and eMMC to device tree overlays.

> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> new file mode 100644
> index 0000000000000..bc4ea12587a2e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> @@ -0,0 +1,72 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +        vmmc_sdc: regulator-mmc-sdc {
> +                compatible = "regulator-fixed";
> +
> +                regulator-name = "vmmc_sdc";
> +                regulator-min-microvolt = <2950000>;
> +                regulator-max-microvolt = <2950000>;
> +        };
> +
> +        vreg_sdc: regulator-sdc {
> +		compatible = "regulator-gpio";
> +
> +		regulator-name = "vreg_sdc";
> +		regulator-type = "voltage";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <2950000>;
> +
> +		gpios = <&expander1 7 GPIO_ACTIVE_HIGH>;
> +		states = <1800000 1>, <2950000 0>;
> +
> +		startup-delay-us = <100>;
> +        };
> +};
> +
> +&sdhc_1 {
> +	vmmc-supply = <&vmmc_sdc>;
> +	vqmmc-supply = <&vreg_sdc>;

[Severity: High]
Should the root node in monaco-evk-sd-card.dtso use &{/} { ... }; instead of
/ { ... };?

In a /plugin/; device tree overlay, defining nodes under / { ... }; places
regulator-mmc-sdc and regulator-sdc directly under the root of the compiled
.dtbo rather than wrapping them in a fragment node with an __overlay__ child.

When fdt_overlay_apply() -> overlay_merge() in scripts/dtc/libfdt/fdt_overlay.c
(or init_overlay_changeset() in drivers/of/overlay.c) merges the overlay:

	fdt_for_each_subnode(fragment, fdto, 0) {
		overlay = fdt_subnode_offset(fdto, fragment, "__overlay__");
		if (overlay == -FDT_ERR_NOTFOUND)
			continue;

both regulator nodes are skipped and omitted from the merged DTB, while
vmmc-supply and vqmmc-supply in sdhc_1 are left pointing at phandles that do
not exist in the merged tree. When sdhci_msm_probe() -> sdhci_setup_host() ->
mmc_regulator_get_supply() runs, resolving both supplies fails with -ENODEV.

[ ... ]

> +&sdhc1_opp_table {
> +	opp-100000000 {
> +		opp-hz = /bits/ 64 <100000000>;
> +		required-opps = <&rpmhpd_opp_low_svs>;
> +	};
> +
> +	opp-202000000 {
> +		opp-hz = /bits/ 64 <202000000>;
> +		required-opps = <&rpmhpd_opp_svs_l1>;
> +	};
> +};

[Severity: Medium]
Is this override of sdhc1_opp_table intended for sdhc_1 on Monaco?

In arch/arm64/boot/dts/qcom/monaco.dtsi, sdhc1_opp_table already defines:

			sdhc1_opp_table: opp-table {
				compatible = "operating-points-v2";

				opp-50000000 {
					opp-hz = /bits/ 64 <50000000>;
					required-opps = <&rpmhpd_opp_low_svs>;
				};

				opp-100000000 {
					opp-hz = /bits/ 64 <100000000>;
					required-opps = <&rpmhpd_opp_svs>;
				};

				opp-200000000 {
					opp-hz = /bits/ 64 <200000000>;
					required-opps = <&rpmhpd_opp_svs_l1>;
				};

				opp-384000000 {
					opp-hz = /bits/ 64 <384000000>;
					required-opps = <&rpmhpd_opp_nom>;
				};
			};

And in drivers/clk/qcom/gcc-qcs8300.c, ftbl_gcc_sdcc1_apps_clk_src supports
50 MHz, 100 MHz, 192 MHz, and 384 MHz, with no 202 MHz entry.

Because overlay_apply_node() merges new subnodes without removing existing
ones, applying monaco-evk-sd-card.dtso leaves opp-200000000 and opp-384000000
in sdhc1_opp_table alongside the new opp-202000000 node, while also lowering
the 100 MHz required-opps vote from rpmhpd_opp_svs to rpmhpd_opp_low_svs.

[ ... ]

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 35fbee63d4c65..591ad233f90eb 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -4843,7 +4843,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>  			qcom,dll-config = <0x000f64ee>;
>  			qcom,ddr-config = <0x80040868>;
>  			bus-width = <8>;
> -			supports-cqe;
>  			dma-coherent;

[Severity: Medium]
Should arch/arm64/boot/dts/qcom/monaco-ac-evk.dts also have supports-cqe added
to &sdhc_1?

monaco-ac-evk.dts includes monaco.dtsi and enables sdhc_1 for non-removable
eMMC:

&sdhc_1 {
	vmmc-supply = <&vreg_l8a>;
	vqmmc-supply = <&vreg_s2s>;

	no-sd;
	no-sdio;
	non-removable;

	status = "okay";
};

In drivers/mmc/host/sdhci-msm.c, sdhci_msm_probe() checks for supports-cqe:

	if (of_property_read_bool(node, "supports-cqe"))
		ret = sdhci_msm_cqe_add_host(host, pdev);
	else
		ret = sdhci_add_host(host);

Removing supports-cqe from monaco.dtsi without adding it to monaco-ac-evk.dts
causes sdhci_msm_probe() to skip sdhci_msm_cqe_add_host() (and
sdhci_msm_ice_init() called from within it), disabling CQE and ICE on
Monaco-AC EVK.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105101955.3732723-1-monish.chunara@oss.qualcomm.com?part=3

Re: [PATCH V6 2/3] arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] arm64: dts: qcom: monaco-evk-sd-card: invalid root syntax drops regulators
- [Medium] arm64: dts: qcom: contradictory no-1-8-v property in monaco-evk-sd-card.dtso
- [Low] arm64: dts: qcom: monaco-evk: invalid sdhc1_opp_table overrides in SD overlay
--

commit 6648a626b1d62a283e700d9a648c1b8158385e14
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>

arm64: dts: qcom: monaco-evk: Enable SDHCI for SD Card via overlay

This commit removes the eMMC-specific sdhc_1 configuration from the base
monaco-evk.dts and introduces the monaco-evk-sd-card.dtso overlay to
configure sdhc_1 for SD card storage.

> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> new file mode 100644
> index 0000000000000..bc4ea12587a2e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso
> @@ -0,0 +1,72 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +        vmmc_sdc: regulator-mmc-sdc {
> +                compatible = "regulator-fixed";
> +
> +                regulator-name = "vmmc_sdc";
> +                regulator-min-microvolt = <2950000>;
> +                regulator-max-microvolt = <2950000>;
> +        };
> +
> +        vreg_sdc: regulator-sdc {
> +		compatible = "regulator-gpio";
> +
> +		regulator-name = "vreg_sdc";
> +		regulator-type = "voltage";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <2950000>;
> +
> +		gpios = <&expander1 7 GPIO_ACTIVE_HIGH>;
> +		states = <1800000 1>, <2950000 0>;
> +
> +		startup-delay-us = <100>;
> +        };
> +};

[Severity: High]
Should this root node block use &{/} instead of / (like
monaco-evk-ifp-mezzanine.dtso does)?

In a /plugin/; overlay, dtc places child nodes defined under / { ... };
directly at the root of the .dtbo blob rather than wrapping them inside a
fragment@N node with an __overlay__ subnode.

When fdt_overlay_apply() merges monaco-evk-sd-card.dtbo into
monaco-evk.dtb, overlay_merge() in scripts/dtc/libfdt/fdt_overlay.c skips
any top-level subnode that lacks an __overlay__ subnode:

	fdt_for_each_subnode(fragment, fdto, 0) {
		int overlay;
		int target;

		overlay = fdt_subnode_offset(fdto, fragment, "__overlay__");
		if (overlay == -FDT_ERR_NOTFOUND)
			continue;

Similarly, init_overlay_changeset() in drivers/of/overlay.c ignores
top-level nodes without an __overlay__ child when applying overlays at
runtime.

As a result, both regulator-mmc-sdc (vmmc_sdc) and regulator-sdc
(vreg_sdc) are silently dropped from the merged device tree, while
vmmc-supply and vqmmc-supply in &sdhc_1 are rewritten to dangling phandles
that cause regulator lookup to fail in
sdhci_msm_probe() -> sdhci_msm_register_vreg() ->
mmc_regulator_get_supply() -> of_get_regulator().

> +
> +&sdhc_1 {
> +	vmmc-supply = <&vmmc_sdc>;
> +	vqmmc-supply = <&vreg_sdc>;
> +
> +	pinctrl-0 = <&sdc1_state_on>, <&sd_cd>;
> +	pinctrl-1 = <&sdc1_state_off>, <&sd_cd>;
> +	pinctrl-names = "default", "sleep";
> +
> +	cap-sd-highspeed;
> +	no-1-8-v;

[Severity: Medium]
As reported by Sashiko on v3 [1], is no-1-8-v intended here?

The overlay defines a 1.8V state on the vreg_sdc GPIO regulator for
vqmmc-supply:

	states = <1800000 1>, <2950000 0>;

and also adds 100 MHz and 202 MHz OPPs to &sdhc1_opp_table for UHS-I
modes.

However, setting no-1-8-v on &sdhc_1 causes
sdhci_msm_probe() -> sdhci_get_of_property() -> sdhci_get_property() to
set SDHCI_QUIRK2_NO_1_8_V, which in sdhci_setup_host() clears
SDHCI_SUPPORT_SDR104, SDHCI_SUPPORT_SDR50, SDHCI_SUPPORT_DDR50, and
MMC_CAP_UHS. That prevents 1.8V signaling switches in mmc_sd_init_card(),
caps the SD card at 50 MHz High-Speed mode, and leaves the 1.8V regulator
state and higher-frequency OPPs unused.

> +
> +	bus-width = <4>;
> +	cd-gpios = <&tlmm 11 GPIO_ACTIVE_LOW>;
> +	no-mmc;
> +	no-sdio;
> +
> +	status = "okay";
> +};
> +
> +&sdhc1_opp_table {
> +	opp-100000000 {
> +		opp-hz = /bits/ 64 <100000000>;
> +		required-opps = <&rpmhpd_opp_low_svs>;
> +	};
> +
> +	opp-202000000 {
> +		opp-hz = /bits/ 64 <202000000>;
> +		required-opps = <&rpmhpd_opp_svs_l1>;
> +	};
> +};

[Severity: Low]
As reported by Sashiko on v4 [2], why does this board overlay modify
&sdhc1_opp_table?

In arch/arm64/boot/dts/qcom/monaco.dtsi, sdhc1_opp_table already defines:

	sdhc1_opp_table: opp-table {
		compatible = "operating-points-v2";

		opp-50000000 {
			opp-hz = /bits/ 64 <50000000>;
			required-opps = <&rpmhpd_opp_low_svs>;
		};

		opp-100000000 {
			opp-hz = /bits/ 64 <100000000>;
			required-opps = <&rpmhpd_opp_svs>;
		};

		opp-200000000 {
			opp-hz = /bits/ 64 <200000000>;
			required-opps = <&rpmhpd_opp_svs_l1>;
		};

		opp-384000000 {
			opp-hz = /bits/ 64 <384000000>;
			required-opps = <&rpmhpd_opp_nom>;
		};
	};

And in drivers/clk/qcom/gcc-qcs8300.c, ftbl_gcc_sdcc1_apps_clk_src (which
uses clk_rcg2_floor_ops) only provides 100 MHz, 192 MHz, and 384 MHz at
the top end, with no 202 MHz entry:

	static const struct freq_tbl ftbl_gcc_sdcc1_apps_clk_src[] = {
		...
		F(50000000, P_GCC_GPLL0_OUT_EVEN, 6, 0, 0),
		F(100000000, P_GCC_GPLL0_OUT_EVEN, 3, 0, 0),
		F(192000000, P_GCC_GPLL9_OUT_MAIN, 4, 0, 0),
		F(384000000, P_GCC_GPLL9_OUT_MAIN, 2, 0, 0),
		{ }
	};

Because device tree overlays merge child nodes without removing existing
ones, &sdhc1_opp_table in monaco-evk-sd-card.dtso lowers the SoC-defined
voltage corner for opp-100000000 from rpmhpd_opp_svs to
rpmhpd_opp_low_svs, leaves opp-200000000 and opp-384000000 in place, and
adds opp-202000000.

When dev_pm_opp_set_rate() calls clk_round_rate() and looks up the ceiling
OPP via _find_freq_ceil(), any 200-208 MHz request rounds down to
192000000 Hz and always matches the existing opp-200000000 entry before
opp-202000000, while sdhci_msm_probe() calling
dev_pm_opp_set_rate(&pdev->dev, INT_MAX) still selects opp-384000000.

[1] https://lore.kernel.org/r/20260701083148.0F8341F00A3A@smtp.kernel.org
[2] https://lore.kernel.org/r/20260716144010.1DC4F1F000E9@smtp.kernel.org

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105101955.3732723-1-monish.chunara@oss.qualcomm.com?part=2