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

[Shawn Lin <shawn.lin@linux.dev>]

在 2026/10/28 星期三 18:43, Ulf Hansson 写道:
> On Wed, Oct 28, 2026 at 1:37 AM Shawn Lin <shawn.lin@linux.dev> wrote:
>>
>> 在 2026/10/28 星期三 3:46, Ulf Hansson 写道:
>>> On Tue, Oct 27, 2026 at 4:02 PM Shawn Lin <shawn.lin@linux.dev> wrote:
>>>>
>>>> Hi
>>>>
>>>> 在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
>>>>> From: Kamal Dasu <kamal.dasu@broadcom.com>
>>>>>
>>>>> 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.
> 

I got your point now, it sounds reasonable.

> [...]
> 
> Kind regards
> Uffe