Re: [PATCH v10 1/6] dt-bindings: mmc: Extend keep-power-in-suspend beyond SDIO

[Ulf Hansson]

On Wed, Oct 28, 2026 at 1:37 AM Shawn Lin <shawn.lin@xxxxxxxxx> wrote:
>
> 在 2026/10/28 星期三 3:46, Ulf Hansson 写道:
> > On Tue, Oct 27, 2026 at 4:02 PM Shawn Lin <shawn.lin@xxxxxxxxx> wrote:
> >>
> >> Hi
> >>
> >> 在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> >>> From: Kamal Dasu <kamal.dasu@xxxxxxxxxxxx>
> >>>
> >>> keep-power-in-suspend is currently documented as SDIO-only, but the
> >>> requirement it describes -- preserving card power across a
> >>> suspend/resume cycle -- applies just as well to any card type. Drop
> >>> the SDIO-only restriction so eMMC and SD platforms can use it too.
> >>>
> >>
> >> I don't see how SD could use it from the following patches. Perhaps we
> >> should still be more strict here to say SDIO and eMMC only, unless
> >> SD part is implemented later.
> >
> > I didn't have the bandwidth to implement this for SD at this very
> > moment, but the idea is to add it for SD too.
> >
>
> SDIO devices have a clear wake-on-host requirement, so keeping power on
> is reasonable. eMMC and SD are passively accessed devices, making this a
> pseudo-requirement under system freeze conditions until Broadcom chips
> changed the situation for eMMC.
>
> However, for the SD part, I doubt such a need exists. It would require
> dedicated ROM code support, and unlike eMMC, SD is not used as primary
> storage. Worse still, unlike eMMC and SDIO devices which are soldered
> down, vendors typically have an AVL to certify board-mounted components,
> while SD cards can be freely swapped. The compatibility of off-the-shelf
> SD cards is relatively poor, so I question whether there is a real-world
> scenario for SD cards here. If there is no such scenario, this is dead
> code.
>
> > That said, I was also thinking that maybe it would make sense to add a
> > sysfs node to allow the behavior to be controlled by userspace.
> > Thoughts?
> >
>
> Sure, regarding the sysfs node you mentioned, we already have
> mmc_caps2_set() exposed to userspace, and we can add
> MMC_CAP2_RESET_AT_RESUME support there

The reason for the proposed user space node is not to control
MMC_CAP2_RESET_AT_RESUME. That is a different story, specific to
Broadcom platforms at this point.

Instead it was solely about allowing user space to keep the eMMC and
SD card powered on during system suspend. Which may be useful for
other reasons. Like, internal garbage collect and suspend/resume
latency.

[...]

Kind regards
Uffe