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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The SD card overlay fails to remove conflicting eMMC properties (`no-sd` and `non-removable`) inherited from the base device tree, rendering the SD controller non-functional.
- [Medium] The overlay configures 1.8V regulator states and high-speed OPPs for UHS-I, but explicitly disables 1.8V support via `no-1-8-v`, rendering the high-speed configurations unreachable.
--

Note: The format of this review is altered to provide a free-form summary
of the findings rather than inline quotes due to recitation restrictions.

commit 8700d2dd7b89a43576ae3f5ad283ea9e832db05a
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>

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

The monaco EVK board supports either eMMC or SD-card, but only one
can be active at a time. This enables the SDHCI for SD Card support
via a device tree overlay.

[Severity: High]
In arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso, the overlay modifies
the &sdhc_1 node by adding no-mmc and cd-gpios, but it doesn't explicitly
delete the conflicting properties inherited from the base device tree.

Since device tree overlays merge nodes and do not implicitly overwrite
boolean properties, does this resulting merged node contain both no-sd
(from the base) and no-mmc (from the overlay)?

If both properties are present, will the MMC subsystem set both
MMC_CAP2_NO_SD and MMC_CAP2_NO_MMC flags and refuse to initialize any
card? Additionally, won't leaving the non-removable property from the
base tree intact cause mmc_of_parse() to bypass requesting the newly
added cd-gpios?

Should this overlay explicitly use /delete-property/ no-sd; and 
/delete-property/ non-removable; to clear the base configuration?

[Severity: Medium]
Also in arch/arm64/boot/dts/qcom/monaco-evk-sd-card.dtso, the &sdhc_1
node is configured with the no-1-8-v property. However, the overlay
configures vreg_sdc with a 1.8V state (states = <1800000 1>) and sets up
sdhc1_opp_table with opp-100000000 and opp-202000000, which correspond
to SDR50 and SDR104 modes requiring 1.8V.

Does setting no-1-8-v force the MMC core to disable UHS capabilities and
artificially restrict the SD card to 50MHz?

If the board genuinely supports 1.8V, should the no-1-8-v property be
removed? Alternatively, if the board cannot support 1.8V, should the
unused 1.8V regulator configurations and high-speed OPP additions be
dropped to avoid contradictory configurations?

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