Re: [PATCH 3/4] arm64: dts: qcom: Add SD Card support for Glymur SoC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `resets` hardware reset property for the `sdhc_2` node
--

commit 3328d962d23c195e0ded6a5fa736fc357bc968ef
Author: Monish Chunara <monish.chunara@oss.qualcomm.com>

arm64: dts: qcom: Add SD Card support for Glymur SoC

This commit adds support for the SD card on the Glymur SoC and enables
the required pinctrl configurations.

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index 20b49af7298e9..0989fe39e7ef7 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
[ ... ]
> @@ -3927,6 +3927,57 @@ lpass_ag_noc: interconnect@7e40000 {
>  			#interconnect-cells = <2>;
>  		};
>  
> +		sdhc_2: mmc@8804000 {
> +			compatible = "qcom,glymur-sdhci", "qcom,sdhci-msm-v5";
> +

[Severity: Medium]
Should this node include the resets = <&gcc GCC_SDCC2_BCR>; property?

The SDHCI-MSM driver typically uses the core_reset (fetched via the resets
device tree property) to explicitly reset the SDHC hardware block during probe,
ensuring it is in a clean and known state.

Although the driver requests the reset as optional, omitting it means the
kernel cannot reset the controller. Could this lead to unpredictable controller
behavior or probe failures if the bootloader leaves the block in an
inconsistent state?

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