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

[Ulf Hansson]

On Tue, Oct 27, 2026 at 9:31 PM Kamal Dasu <kamal.dasu@xxxxxxxxxxxx> wrote:
>
> On Tue, Oct 27, 2026 at 3:48 PM Ulf Hansson
> <ulf.hansson@xxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Oct 27, 2026 at 4:33 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > >
> > > On 27/10/2026 15:40, Ulf Hansson wrote:
> > > > 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.
> > > >
> > > > Signed-off-by: Kamal Dasu <kamal.dasu@xxxxxxxxxxxx>
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxxxxx>
> > >
> > > Incomplete DCO.
> >
> > Sorry, I should have explicitly stated that I will leave that to Kamal
> > to contribute on top.
> >
> > Kind regards
> > Uffe
>
> Hi Uffe,
>
> No problem. I'll resend the two dt-bindings patches myself with the DCO
> fixed and the DT list on Cc. Do you want them as a separate two-patch
> series on top of your patches 3-6, or should I post the whole series
> as v11?
>
> On the SD wording, since you plan to add SD support too, I'll keep the
> description as it is, unless Shawn or Krzysztof object.
>
> > 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?
>
> For this board the requirement is fixed hardware behaviour. Firmware
> reads the card at every S3 resume, so the card has to stay powered and
> be reset each time. Without both DT properties the board enters suspend
> and then resets at resume, so I think the DT properties are the right
> way to describe it.

Yes, that part is clear and user space should not be allowed to
override that requirement.

>
> A sysfs knob could make sense where it is a policy choice, for example
> on SD. If it is added, I think it should not be possible to turn it off
> when reset-card-at-resume is set in DT, since that would bring the
> board back to the failing case. I would prefer to keep it out of this
> series and add it separately when SD support is added.

As stated above, the reset-card-at-resume requirement it brings with
it, must not be overridden by user space.

The reason why it could make sense to allow an eMMC and SD card to
stay powered on during system suspend is primarily for two reasons.
*) It allows internal garbage collection to happen in the eMMC/SD
card. Meaning that the card should be able to perform better later on.
*) System suspend/resume latencies may decrease.

Of course, this all comes with draining more energy, so it would need
to be carefully used.

Kind regards
Uffe