Re: [PATCH 0/3] arm64: dts: qcom: monaco: Enable SDHCI storage support

[Dmitry Baryshkov]

On Mon, Mar 02, 2026 at 08:35:06PM +0530, Monish Chunara wrote:
> On Mon, Mar 02, 2026 at 04:47:41PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Mar 02, 2026 at 08:07:23PM +0530, Monish Chunara wrote:
> > > On Fri, Feb 27, 2026 at 10:05:32PM +0200, Dmitry Baryshkov wrote:
> > > > On Fri, Feb 27, 2026 at 04:20:52PM +0530, Monish Chunara wrote:
> > > > > This series enables SDHCI storage support for both SD Card and eMMC on the
> > > > > Qualcomm Monaco EVK platform.
> > > > > 
> > > > > The Monaco SoC shares the SDHCI controller between SD Card and eMMC use
> > > > > cases. Previously, the common SoC dtsi unconditionally enabled the
> > > > > 'supports-cqe' property. This causes regression for SD cards, resulting
> > > > > in timeouts and initialization failures during the probe sequence, as
> > > > > the driver attempts to enable Command Queueing (CQE) logic incompatible
> > > > > with the SD protocol.
> > > > > 
> > > > > To resolve this and enable full storage support, this series:
> > > > > 
> > > > > 1. Moves the 'supports-cqe' property out of the common SoC dtsi. It is
> > > > >    now only enabled in the specific eMMC configuration where it is
> > > > >    supported.
> > > > > 2. Adds a device tree overlay to enable SD Card support (SDR/DDR modes).
> > > > > 3. Adds a device tree overlay to enable eMMC support. This configuration
> > > > >    also explicitly disables the UFS controller to prevent power leakage,
> > > > >    as the VCC regulator is shared between the UFS and eMMC rails on this
> > > > >    platform.
> > > > > 
> > > > > 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
> > > > 
> > > > You are adding two overlays. But what does it mean? Does EVK has no uSD
> > > > / eMMC at all, having both attachable via some kind of mezzanine? Is one
> > > > of them attachable? Or are both cases present onboard with the correct
> > > > one being selected by the DIP switch?
> > > > 
> > > 
> > > The monaco EVK has both storage devices present onboard and the desired one is
> > > selected via a DIP switch. The overlay selection logic would be based on a
> > > fitImage metadata entry that gets populated at UEFI level by determining the
> > > currently selected storage device (eMMC/SD) on the device.
> > > 
> > > Hence, this approach becomes robust to enable the user for using either of the
> > > two mediums, without any additional requirement of reflashing any images.
> > 
> > You are answering a different question :-)
> > 
> > Let me formulate my question as a review comment:
> > - identify the default DIP switch position
> > - squash corresponding dtso into the dts
> > - leave only the default dts and non-default dtso to be applied by UEFI
> >   if necessary.
> > 
> 
> Thanks for clarifying. 
> 
> Default switch position is on eMMC on Monaco EVK. But as mentioned in the other
> thread, there are a few boolean (flag) properties like 'no-sd', that conflicts
> with SD card use case and cannot be deleted in an overlay file as
> /delete-property/ cannot be used. Also cd-gpio and regulators used for SD card
> would be redundant for eMMC.
> 
> And similarly 'no-mmc' added by default would be inappropriate for eMMC. This
> being the reason, two separate overlays were added.

This only means one thing to me: UEFI mechanism needs to be changed from
applying the dtso into directly modifying the FDT in the DT_FIXUP protocol.

There are three options which needs to be removed this way:
- supported-cqe
- non-removable
- no-sd

> 
> Regards,
> Monish

-- 
With best wishes
Dmitry