[PATCH v10 0/6] mmc: core: Keep the card powered across suspend when firmware needs it live

[PATCH v10 0/6] mmc: core: Keep the card powered across suspend when firmware needs it live

[Ulf Hansson]

Background: on brcmstb boards with a Kioxia 016G01 eMMC, firmware accesses the
card directly during resume from Suspend-to-DRAM, before the kernel's own
resume path runs, in order to load boot code using hard wired logic that is not
field updatable. The card needs to stay powered and responsive for that access
to succeed, and since it is never power-cycled, it also needs to be reset
before the kernel reuses it after resume.

Changes in v10:
	- To help out with the implementation I offered my help to try to move
	this forward.
	- The DT patches are good to go so I included them from the previous
	versions.
	- Patch 3 to 6 are new, but based on the work done by Kamal Dasu.
	- This is completely untested from my side, please help to test it.

Kind regards
Ulf Hansson


Kamal Dasu (2):
  dt-bindings: mmc: Extend keep-power-in-suspend beyond SDIO
  dt-bindings: mmc: Add reset-card-at-resume property

Ulf Hansson (4):
  mmc: core: Add option to keep an eMMC powered on at system suspend
  mmc: core: Split sdio_set_host_pm_flags()
  mmc: core: Move reset functions for eMMC
  mmc: core: Add support for resetting an eMMC at system resume

 .../bindings/mmc/mmc-controller-common.yaml   | 10 +-
 drivers/mmc/core/core.c                       |  9 ++
 drivers/mmc/core/core.h                       |  1 +
 drivers/mmc/core/host.c                       | 10 ++
 drivers/mmc/core/mmc.c                        | 95 ++++++++++++-------
 drivers/mmc/core/sdio_io.c                    |  7 +-
 include/linux/mmc/host.h                      |  1 +
 7 files changed, 92 insertions(+), 41 deletions(-)

-- 
2.43.0

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

[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.

Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 .../devicetree/bindings/mmc/mmc-controller-common.yaml          | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 8b9b3b036129..2fc8e06d5ec9 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -301,7 +301,7 @@ properties:
   keep-power-in-suspend:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-      SDIO only. Preserves card power during a suspend/resume cycle.
+      Preserves card power during a suspend/resume cycle.
 
   wakeup-source:
     $ref: /schemas/types.yaml#/definitions/flag
-- 
2.43.0

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

[Shawn Lin]

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.

> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>   .../devicetree/bindings/mmc/mmc-controller-common.yaml          | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> index 8b9b3b036129..2fc8e06d5ec9 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> @@ -301,7 +301,7 @@ properties:
>     keep-power-in-suspend:
>       $ref: /schemas/types.yaml#/definitions/flag
>       description:
> -      SDIO only. Preserves card power during a suspend/resume cycle.
> +      Preserves card power during a suspend/resume cycle.
>   
>     wakeup-source:
>       $ref: /schemas/types.yaml#/definitions/flag

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

[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.

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?

>
> > Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> >   .../devicetree/bindings/mmc/mmc-controller-common.yaml          | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> > index 8b9b3b036129..2fc8e06d5ec9 100644
> > --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
> > @@ -301,7 +301,7 @@ properties:
> >     keep-power-in-suspend:
> >       $ref: /schemas/types.yaml#/definitions/flag
> >       description:
> > -      SDIO only. Preserves card power during a suspend/resume cycle.
> > +      Preserves card power during a suspend/resume cycle.
> >
> >     wakeup-source:
> >       $ref: /schemas/types.yaml#/definitions/flag
>

Kind regards
Uffe

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

[Shawn Lin]

在 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

>>
>>> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> ---
>>>    .../devicetree/bindings/mmc/mmc-controller-common.yaml          | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>>> index 8b9b3b036129..2fc8e06d5ec9 100644
>>> --- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>>> @@ -301,7 +301,7 @@ properties:
>>>      keep-power-in-suspend:
>>>        $ref: /schemas/types.yaml#/definitions/flag
>>>        description:
>>> -      SDIO only. Preserves card power during a suspend/resume cycle.
>>> +      Preserves card power during a suspend/resume cycle.
>>>
>>>      wakeup-source:
>>>        $ref: /schemas/types.yaml#/definitions/flag
>>
> 
> Kind regards
> Uffe

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@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.

[...]

Kind regards
Uffe

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

[Shawn Lin]

在 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

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

[Krzysztof Kozlowski]

On 27/10/2026 15:40, Ulf Hansson wrote:
> 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.
> 
> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Incomplete DCO.

Best regards,
Krzysztof

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

[Ulf Hansson]

On Tue, Oct 27, 2026 at 4:33 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 27/10/2026 15:40, Ulf Hansson wrote:
> > 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.
> >
> > Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Incomplete DCO.

Sorry, I should have explicitly stated that I will leave that to Kamal
to contribute on top.

Kind regards
Uffe

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

[Kamal Dasu]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

On Tue, Oct 27, 2026 at 3:48 PM Ulf Hansson
<ulf.hansson@oss.qualcomm.com> wrote:
>
> On Tue, Oct 27, 2026 at 4:33 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On 27/10/2026 15:40, Ulf Hansson wrote:
> > > 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.
> > >
> > > Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >
> > 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.

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.

Kamal

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5461 bytes --]

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@broadcom.com> wrote:
>
> On Tue, Oct 27, 2026 at 3:48 PM Ulf Hansson
> <ulf.hansson@oss.qualcomm.com> wrote:
> >
> > On Tue, Oct 27, 2026 at 4:33 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > On 27/10/2026 15:40, Ulf Hansson wrote:
> > > > 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.
> > > >
> > > > Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > >
> > > 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

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@broadcom.com> wrote:
>
> On Tue, Oct 27, 2026 at 3:48 PM Ulf Hansson
> <ulf.hansson@oss.qualcomm.com> wrote:
> >
> > On Tue, Oct 27, 2026 at 4:33 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > On 27/10/2026 15:40, Ulf Hansson wrote:
> > > > 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.
> > > >
> > > > Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> > > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > >
> > > 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?

Okay, I leave this to be managed by you. Please re-spin the whole
series, to address the minor comments/fixes so we can get this queued
for v7.5.

>
> 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.
>
> 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.

Ack, let's have a look at the changes for SD later on, on top.

Kind regards
Uffe

[PATCH v10 2/6] dt-bindings: mmc: Add reset-card-at-resume property

[Ulf Hansson]

From: Kamal Dasu <kamal.dasu@broadcom.com>

On some platforms, firmware or other hardware accesses the card
during suspend/resume, before the kernel's own resume path has run,
leaving the card in a state the kernel can no longer assume it knows.
Add a flag property so such boards can tell the mmc core the card
needs to be reset before it can be used again.

This is expected to be paired with keep-power-in-suspend on boards
whose firmware needs the card to stay powered and live throughout
suspend: since the card is never power-cycled, nothing else would
force it back to a known state on resume.

Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 .../devicetree/bindings/mmc/mmc-controller-common.yaml    | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
index 2fc8e06d5ec9..c824b95f2ae2 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
@@ -303,6 +303,13 @@ properties:
     description:
       Preserves card power during a suspend/resume cycle.
 
+  reset-card-at-resume:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      The HW/FW may have accessed the card during suspend/resume,
+      leaving it in an unknown state. Hence, before the card can be
+      used, it must be reset.
+
   wakeup-source:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
@@ -371,5 +378,6 @@ patternProperties:
 dependencies:
   cd-debounce-delay-ms: [ cd-gpios ]
   fixed-emmc-driver-type: [ non-removable ]
+  reset-card-at-resume: [ keep-power-in-suspend ]
 
 additionalProperties: true
-- 
2.43.0

Re: [PATCH v10 2/6] dt-bindings: mmc: Add reset-card-at-resume property

[Krzysztof Kozlowski]

On 27/10/2026 15:40, Ulf Hansson wrote:
> From: Kamal Dasu <kamal.dasu@broadcom.com>
> 
> On some platforms, firmware or other hardware accesses the card
> during suspend/resume, before the kernel's own resume path has run,
> leaving the card in a state the kernel can no longer assume it knows.
> Add a flag property so such boards can tell the mmc core the card
> needs to be reset before it can be used again.
> 
> This is expected to be paired with keep-power-in-suspend on boards
> whose firmware needs the card to stay powered and live throughout
> suspend: since the card is never power-cycled, nothing else would
> force it back to a known state on resume.
> 
> Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Incomplete DCO, missing DT list, so not checked by automation.


Please kindly resend and include all necessary To/Cc entries.

Best regards,
Krzysztof

[PATCH v10 3/6] mmc: core: Add option to keep an eMMC powered on at system suspend

[Ulf Hansson]

The DT property keep-power-in-suspend, allows us to specify whether the
platform is capable of keeping the power to the card during system suspend.
Up until now, this has been restricted to be used for SDIO cards only, but
let's add the initial support to allow this for eMMC too.

Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
---
 drivers/mmc/core/mmc.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index a02b04938e1a..c936272bcd81 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -38,6 +38,7 @@ enum mmc_poweroff_type {
 	MMC_POWEROFF_SHUTDOWN,
 	MMC_POWEROFF_UNDERVOLTAGE,
 	MMC_POWEROFF_UNBIND,
+	MMC_NO_POWEROFF_SUSPEND,
 };
 
 static const unsigned int tran_exp[] = {
@@ -2157,6 +2158,15 @@ static int _mmc_suspend(struct mmc_host *host, enum mmc_poweroff_type pm_type)
 			goto out;
 	}
 
+	if (pm_type == MMC_NO_POWEROFF_SUSPEND) {
+		if (host->retune_period) {
+			mmc_retune_timer_stop(host);
+			mmc_retune_needed(host);
+		}
+		mmc_card_set_suspended(host->card);
+		goto out;
+	}
+
 	if (mmc_card_can_poweroff_notify(host->card) &&
 	    mmc_host_can_poweroff_notify(host, pm_type))
 		err = mmc_poweroff_notify(host->card, notify_type);
@@ -2193,9 +2203,15 @@ static void mmc_remove(struct mmc_host *host)
  */
 static int mmc_suspend(struct mmc_host *host)
 {
+	enum mmc_poweroff_type pm_type = MMC_POWEROFF_SUSPEND;
 	int err;
 
-	err = _mmc_suspend(host, MMC_POWEROFF_SUSPEND);
+	if (mmc_card_keep_power(host)) {
+		pm_runtime_resume(&host->card->dev);
+		pm_type = MMC_NO_POWEROFF_SUSPEND;
+	}
+
+	err = _mmc_suspend(host, pm_type);
 	if (!err) {
 		pm_runtime_disable(&host->card->dev);
 		pm_runtime_set_suspended(&host->card->dev);
@@ -2260,7 +2276,13 @@ static int mmc_shutdown(struct mmc_host *host)
  */
 static int mmc_resume(struct mmc_host *host)
 {
+	if (mmc_card_keep_power(host)) {
+		pm_runtime_set_active(&host->card->dev);
+		mmc_card_clr_suspended(host->card);
+	}
+
 	pm_runtime_enable(&host->card->dev);
+	host->pm_flags &= ~MMC_PM_KEEP_POWER;
 	return 0;
 }
 
-- 
2.43.0

Re: [PATCH v10 3/6] mmc: core: Add option to keep an eMMC powered on at system suspend

[Shawn Lin]

在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> The DT property keep-power-in-suspend, allows us to specify whether the
> platform is capable of keeping the power to the card during system suspend.
> Up until now, this has been restricted to be used for SDIO cards only, but
> let's add the initial support to allow this for eMMC too.
> 

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

> Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> ---
>   drivers/mmc/core/mmc.c | 24 +++++++++++++++++++++++-
>   1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index a02b04938e1a..c936272bcd81 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -38,6 +38,7 @@ enum mmc_poweroff_type {
>   	MMC_POWEROFF_SHUTDOWN,
>   	MMC_POWEROFF_UNDERVOLTAGE,
>   	MMC_POWEROFF_UNBIND,
> +	MMC_NO_POWEROFF_SUSPEND,
>   };
>   
>   static const unsigned int tran_exp[] = {
> @@ -2157,6 +2158,15 @@ static int _mmc_suspend(struct mmc_host *host, enum mmc_poweroff_type pm_type)
>   			goto out;
>   	}
>   
> +	if (pm_type == MMC_NO_POWEROFF_SUSPEND) {
> +		if (host->retune_period) {
> +			mmc_retune_timer_stop(host);
> +			mmc_retune_needed(host);
> +		}
> +		mmc_card_set_suspended(host->card);
> +		goto out;
> +	}
> +
>   	if (mmc_card_can_poweroff_notify(host->card) &&
>   	    mmc_host_can_poweroff_notify(host, pm_type))
>   		err = mmc_poweroff_notify(host->card, notify_type);
> @@ -2193,9 +2203,15 @@ static void mmc_remove(struct mmc_host *host)
>    */
>   static int mmc_suspend(struct mmc_host *host)
>   {
> +	enum mmc_poweroff_type pm_type = MMC_POWEROFF_SUSPEND;
>   	int err;
>   
> -	err = _mmc_suspend(host, MMC_POWEROFF_SUSPEND);
> +	if (mmc_card_keep_power(host)) {
> +		pm_runtime_resume(&host->card->dev);
> +		pm_type = MMC_NO_POWEROFF_SUSPEND;
> +	}
> +
> +	err = _mmc_suspend(host, pm_type);
>   	if (!err) {
>   		pm_runtime_disable(&host->card->dev);
>   		pm_runtime_set_suspended(&host->card->dev);
> @@ -2260,7 +2276,13 @@ static int mmc_shutdown(struct mmc_host *host)
>    */
>   static int mmc_resume(struct mmc_host *host)
>   {
> +	if (mmc_card_keep_power(host)) {
> +		pm_runtime_set_active(&host->card->dev);
> +		mmc_card_clr_suspended(host->card);
> +	}
> +
>   	pm_runtime_enable(&host->card->dev);
> +	host->pm_flags &= ~MMC_PM_KEEP_POWER;
>   	return 0;
>   }
>   

[PATCH v10 4/6] mmc: core: Split sdio_set_host_pm_flags()

[Ulf Hansson]

To prepare for a subsequent change, let's split up sdio_set_host_pm_flags()
allowing the second part of it to be used as an internal function for the
core.

Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
---
 drivers/mmc/core/core.c    | 9 +++++++++
 drivers/mmc/core/core.h    | 1 +
 drivers/mmc/core/sdio_io.c | 7 +------
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 677e445dc48c..49c0494932cc 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1422,6 +1422,15 @@ int mmc_handle_undervoltage(struct mmc_host *host)
 	return host->bus_ops->handle_undervoltage(host);
 }
 
+int mmc_set_host_pm_flags(struct mmc_host *host, mmc_pm_flag_t flags)
+{
+	if (flags & ~host->pm_caps)
+		return -EINVAL;
+
+	host->pm_flags |= flags;
+	return 0;
+}
+
 /*
  * Assign a mmc bus handler to a host. Only one bus handler may control a
  * host at any given time.
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 9be2875608ce..d3a2ff00b18f 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -64,6 +64,7 @@ int mmc_handle_undervoltage(struct mmc_host *host);
 void mmc_regulator_register_undervoltage_notifier(struct mmc_host *host);
 void mmc_regulator_unregister_undervoltage_notifier(struct mmc_host *host);
 void mmc_undervoltage_workfn(struct work_struct *work);
+int mmc_set_host_pm_flags(struct mmc_host *host, mmc_pm_flag_t flags);
 
 static inline void mmc_delay(unsigned int ms)
 {
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 12716ec0e35d..99f857514b63 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -726,12 +726,7 @@ int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags)
 
 	host = func->card->host;
 
-	if (flags & ~host->pm_caps)
-		return -EINVAL;
-
-	/* function suspend methods are serialized, hence no lock needed */
-	host->pm_flags |= flags;
-	return 0;
+	return mmc_set_host_pm_flags(host, flags);
 }
 EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
 
-- 
2.43.0

Re: [PATCH v10 4/6] mmc: core: Split sdio_set_host_pm_flags()

[Shawn Lin]

Hi Ulf,

在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> To prepare for a subsequent change, let's split up sdio_set_host_pm_flags()
> allowing the second part of it to be used as an internal function for the
> core.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> ---
>   drivers/mmc/core/core.c    | 9 +++++++++
>   drivers/mmc/core/core.h    | 1 +
>   drivers/mmc/core/sdio_io.c | 7 +------
>   3 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 677e445dc48c..49c0494932cc 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1422,6 +1422,15 @@ int mmc_handle_undervoltage(struct mmc_host *host)
>   	return host->bus_ops->handle_undervoltage(host);
>   }
>   
> +int mmc_set_host_pm_flags(struct mmc_host *host, mmc_pm_flag_t flags)
> +{
> +	if (flags & ~host->pm_caps)
> +		return -EINVAL;
> +
> +	host->pm_flags |= flags;
> +	return 0;
> +}
> +
>   /*
>    * Assign a mmc bus handler to a host. Only one bus handler may control a
>    * host at any given time.
> diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> index 9be2875608ce..d3a2ff00b18f 100644
> --- a/drivers/mmc/core/core.h
> +++ b/drivers/mmc/core/core.h
> @@ -64,6 +64,7 @@ int mmc_handle_undervoltage(struct mmc_host *host);
>   void mmc_regulator_register_undervoltage_notifier(struct mmc_host *host);
>   void mmc_regulator_unregister_undervoltage_notifier(struct mmc_host *host);
>   void mmc_undervoltage_workfn(struct work_struct *work);
> +int mmc_set_host_pm_flags(struct mmc_host *host, mmc_pm_flag_t flags);
>   
>   static inline void mmc_delay(unsigned int ms)
>   {
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> index 12716ec0e35d..99f857514b63 100644
> --- a/drivers/mmc/core/sdio_io.c
> +++ b/drivers/mmc/core/sdio_io.c
> @@ -726,12 +726,7 @@ int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags)
>   
>   	host = func->card->host;
>   
> -	if (flags & ~host->pm_caps)
> -		return -EINVAL;
> -
> -	/* function suspend methods are serialized, hence no lock needed */

This is an API for sdio function driver, should we preserve this commet 
here?

> -	host->pm_flags |= flags;
> -	return 0;
> +	return mmc_set_host_pm_flags(host, flags);
>   }
>   EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
>   

Re: [PATCH v10 4/6] mmc: core: Split sdio_set_host_pm_flags()

[Ulf Hansson]

On Tue, Oct 27, 2026 at 4:13 PM Shawn Lin <shawn.lin@linux.dev> wrote:
>
> Hi Ulf,
>
> 在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> > To prepare for a subsequent change, let's split up sdio_set_host_pm_flags()
> > allowing the second part of it to be used as an internal function for the
> > core.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> > ---
> >   drivers/mmc/core/core.c    | 9 +++++++++
> >   drivers/mmc/core/core.h    | 1 +
> >   drivers/mmc/core/sdio_io.c | 7 +------
> >   3 files changed, 11 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 677e445dc48c..49c0494932cc 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -1422,6 +1422,15 @@ int mmc_handle_undervoltage(struct mmc_host *host)
> >       return host->bus_ops->handle_undervoltage(host);
> >   }
> >
> > +int mmc_set_host_pm_flags(struct mmc_host *host, mmc_pm_flag_t flags)
> > +{
> > +     if (flags & ~host->pm_caps)
> > +             return -EINVAL;
> > +
> > +     host->pm_flags |= flags;
> > +     return 0;
> > +}
> > +
> >   /*
> >    * Assign a mmc bus handler to a host. Only one bus handler may control a
> >    * host at any given time.
> > diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
> > index 9be2875608ce..d3a2ff00b18f 100644
> > --- a/drivers/mmc/core/core.h
> > +++ b/drivers/mmc/core/core.h
> > @@ -64,6 +64,7 @@ int mmc_handle_undervoltage(struct mmc_host *host);
> >   void mmc_regulator_register_undervoltage_notifier(struct mmc_host *host);
> >   void mmc_regulator_unregister_undervoltage_notifier(struct mmc_host *host);
> >   void mmc_undervoltage_workfn(struct work_struct *work);
> > +int mmc_set_host_pm_flags(struct mmc_host *host, mmc_pm_flag_t flags);
> >
> >   static inline void mmc_delay(unsigned int ms)
> >   {
> > diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> > index 12716ec0e35d..99f857514b63 100644
> > --- a/drivers/mmc/core/sdio_io.c
> > +++ b/drivers/mmc/core/sdio_io.c
> > @@ -726,12 +726,7 @@ int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags)
> >
> >       host = func->card->host;
> >
> > -     if (flags & ~host->pm_caps)
> > -             return -EINVAL;
> > -
> > -     /* function suspend methods are serialized, hence no lock needed */
>
> This is an API for sdio function driver, should we preserve this commet
> here?

Sure! But rather than preserve, we can move it to the new
mmc_set_host_pm_flags() function as it applies there too.

>
> > -     host->pm_flags |= flags;
> > -     return 0;
> > +     return mmc_set_host_pm_flags(host, flags);
> >   }
> >   EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
> >
>

Kind regards
Uffe

[PATCH v10 5/6] mmc: core: Move reset functions for eMMC

[Ulf Hansson]

To prepare for a subsequent change and to simplify review, let's move the
function for resetting the eMMC card a few lines up in the file.

Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
---
 drivers/mmc/core/mmc.c | 66 +++++++++++++++++++++---------------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index c936272bcd81..d4bf0f25bd74 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -2271,6 +2271,39 @@ static int mmc_shutdown(struct mmc_host *host)
 	return err;
 }
 
+static bool mmc_card_can_reset(struct mmc_card *card)
+{
+	u8 rst_n_function;
+
+	rst_n_function = card->ext_csd.rst_n_function;
+	return ((rst_n_function & EXT_CSD_RST_N_EN_MASK) == EXT_CSD_RST_N_ENABLED);
+}
+
+static int _mmc_hw_reset(struct mmc_host *host)
+{
+	struct mmc_card *card = host->card;
+
+	/*
+	 * In the case of recovery, we can't expect flushing the cache to work
+	 * always, but we have a go and ignore errors.
+	 */
+	_mmc_flush_cache(host);
+
+	if ((host->caps & MMC_CAP_HW_RESET) && host->ops->card_hw_reset &&
+	     mmc_card_can_reset(card)) {
+		/* If the card accept RST_n signal, send it. */
+		mmc_set_clock(host, host->f_init);
+		host->ops->card_hw_reset(host);
+		/* Set initial state and call mmc_set_ios */
+		mmc_set_initial_state(host);
+	} else {
+		/* Do a brute force power cycle */
+		mmc_power_cycle(host, card->ocr);
+		mmc_pwrseq_reset(host);
+	}
+	return mmc_init_card(host, card->ocr, card);
+}
+
 /*
  * Callback for resume.
  */
@@ -2319,39 +2352,6 @@ static int mmc_runtime_resume(struct mmc_host *host)
 	return 0;
 }
 
-static bool mmc_card_can_reset(struct mmc_card *card)
-{
-	u8 rst_n_function;
-
-	rst_n_function = card->ext_csd.rst_n_function;
-	return ((rst_n_function & EXT_CSD_RST_N_EN_MASK) == EXT_CSD_RST_N_ENABLED);
-}
-
-static int _mmc_hw_reset(struct mmc_host *host)
-{
-	struct mmc_card *card = host->card;
-
-	/*
-	 * In the case of recovery, we can't expect flushing the cache to work
-	 * always, but we have a go and ignore errors.
-	 */
-	_mmc_flush_cache(host);
-
-	if ((host->caps & MMC_CAP_HW_RESET) && host->ops->card_hw_reset &&
-	     mmc_card_can_reset(card)) {
-		/* If the card accept RST_n signal, send it. */
-		mmc_set_clock(host, host->f_init);
-		host->ops->card_hw_reset(host);
-		/* Set initial state and call mmc_set_ios */
-		mmc_set_initial_state(host);
-	} else {
-		/* Do a brute force power cycle */
-		mmc_power_cycle(host, card->ocr);
-		mmc_pwrseq_reset(host);
-	}
-	return mmc_init_card(host, card->ocr, card);
-}
-
 /**
  * _mmc_handle_undervoltage - Handle an undervoltage event for MMC/eMMC devices
  * @host: MMC host structure
-- 
2.43.0

Re: [PATCH v10 5/6] mmc: core: Move reset functions for eMMC

[Shawn Lin]

在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> To prepare for a subsequent change and to simplify review, let's move the
> function for resetting the eMMC card a few lines up in the file.
> 

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

> Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> ---
>   drivers/mmc/core/mmc.c | 66 +++++++++++++++++++++---------------------
>   1 file changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index c936272bcd81..d4bf0f25bd74 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -2271,6 +2271,39 @@ static int mmc_shutdown(struct mmc_host *host)
>   	return err;
>   }
>   
> +static bool mmc_card_can_reset(struct mmc_card *card)
> +{
> +	u8 rst_n_function;
> +
> +	rst_n_function = card->ext_csd.rst_n_function;
> +	return ((rst_n_function & EXT_CSD_RST_N_EN_MASK) == EXT_CSD_RST_N_ENABLED);
> +}
> +
> +static int _mmc_hw_reset(struct mmc_host *host)
> +{
> +	struct mmc_card *card = host->card;
> +
> +	/*
> +	 * In the case of recovery, we can't expect flushing the cache to work
> +	 * always, but we have a go and ignore errors.
> +	 */
> +	_mmc_flush_cache(host);
> +
> +	if ((host->caps & MMC_CAP_HW_RESET) && host->ops->card_hw_reset &&
> +	     mmc_card_can_reset(card)) {
> +		/* If the card accept RST_n signal, send it. */
> +		mmc_set_clock(host, host->f_init);
> +		host->ops->card_hw_reset(host);
> +		/* Set initial state and call mmc_set_ios */
> +		mmc_set_initial_state(host);
> +	} else {
> +		/* Do a brute force power cycle */
> +		mmc_power_cycle(host, card->ocr);
> +		mmc_pwrseq_reset(host);
> +	}
> +	return mmc_init_card(host, card->ocr, card);
> +}
> +
>   /*
>    * Callback for resume.
>    */
> @@ -2319,39 +2352,6 @@ static int mmc_runtime_resume(struct mmc_host *host)
>   	return 0;
>   }
>   
> -static bool mmc_card_can_reset(struct mmc_card *card)
> -{
> -	u8 rst_n_function;
> -
> -	rst_n_function = card->ext_csd.rst_n_function;
> -	return ((rst_n_function & EXT_CSD_RST_N_EN_MASK) == EXT_CSD_RST_N_ENABLED);
> -}
> -
> -static int _mmc_hw_reset(struct mmc_host *host)
> -{
> -	struct mmc_card *card = host->card;
> -
> -	/*
> -	 * In the case of recovery, we can't expect flushing the cache to work
> -	 * always, but we have a go and ignore errors.
> -	 */
> -	_mmc_flush_cache(host);
> -
> -	if ((host->caps & MMC_CAP_HW_RESET) && host->ops->card_hw_reset &&
> -	     mmc_card_can_reset(card)) {
> -		/* If the card accept RST_n signal, send it. */
> -		mmc_set_clock(host, host->f_init);
> -		host->ops->card_hw_reset(host);
> -		/* Set initial state and call mmc_set_ios */
> -		mmc_set_initial_state(host);
> -	} else {
> -		/* Do a brute force power cycle */
> -		mmc_power_cycle(host, card->ocr);
> -		mmc_pwrseq_reset(host);
> -	}
> -	return mmc_init_card(host, card->ocr, card);
> -}
> -
>   /**
>    * _mmc_handle_undervoltage - Handle an undervoltage event for MMC/eMMC devices
>    * @host: MMC host structure

[PATCH v10 6/6] mmc: core: Add support for resetting an eMMC at system resume

[Ulf Hansson]

The DT property reset-card-at-resume specifies that we need to make a reset
of an eMMC card at system resume, assuming it also has stayed powered on
during system suspend.

To implement support for this, let's start by parsing for the new DT
property and set the new bit MMC_CAP2_RESET_AT_RESUME if it's found. Based
on the property, we must also set MMC_PM_KEEP_POWER in the pm_flags for the
host, to keep the eMMC powered on during system suspend.

Finally, to manage the actual reset during system resume, let's extend
mmc_resume() to support the needed behaviour.

Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
---
 drivers/mmc/core/host.c  | 10 ++++++++++
 drivers/mmc/core/mmc.c   |  5 +++++
 include/linux/mmc/host.h |  1 +
 3 files changed, 16 insertions(+)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 8e9e61839198..e3daf4026cba 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -48,6 +48,14 @@ static int mmc_host_class_prepare(struct device *dev)
 	if (host->bus_ops->pre_suspend)
 		return host->bus_ops->pre_suspend(host);
 
+	/*
+	 * If it's required to make a reset of the card at system resume, this
+	 * indirectly also means that we must keep the card powered on during
+	 * system suspend.
+	 */
+	if (host->caps2 & MMC_CAP2_RESET_AT_RESUME)
+		return mmc_set_host_pm_flags(host, MMC_PM_KEEP_POWER);
+
 	return 0;
 }
 
@@ -375,6 +383,8 @@ int mmc_of_parse(struct mmc_host *host)
 		host->pm_caps |= MMC_PM_KEEP_POWER;
 	if (device_property_read_bool(dev, "wakeup-source"))
 		host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+	if (device_property_read_bool(dev, "reset-card-at-resume"))
+		host->caps2 |= MMC_CAP2_RESET_AT_RESUME;
 	if (device_property_read_bool(dev, "mmc-ddr-3_3v"))
 		host->caps |= MMC_CAP_3_3V_DDR;
 	if (device_property_read_bool(dev, "mmc-ddr-1_8v"))
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index d4bf0f25bd74..908d5cad304b 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -2315,6 +2315,11 @@ static int mmc_resume(struct mmc_host *host)
 	}
 
 	pm_runtime_enable(&host->card->dev);
+
+	if (mmc_card_keep_power(host) &&
+	    host->caps2 & MMC_CAP2_RESET_AT_RESUME)
+		_mmc_hw_reset(host);
+
 	host->pm_flags &= ~MMC_PM_KEEP_POWER;
 	return 0;
 }
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 032c018650e0..552873da7987 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -430,6 +430,7 @@ struct mmc_host {
 	u32			caps2;		/* More host capabilities */
 
 #define MMC_CAP2_BOOTPART_NOACC	(1 << 0)	/* Boot partition no access */
+#define MMC_CAP2_RESET_AT_RESUME (1 << 1)	/* Reset the card at system resume */
 #define MMC_CAP2_FULL_PWR_CYCLE	(1 << 2)	/* Can do full power cycle */
 #define MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND (1 << 3) /* Can do full power cycle in suspend */
 #define MMC_CAP2_HS200_1_8V_SDR	(1 << 5)        /* can support */
-- 
2.43.0

Re: [PATCH v10 6/6] mmc: core: Add support for resetting an eMMC at system resume

[Shawn Lin]

在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> The DT property reset-card-at-resume specifies that we need to make a reset
> of an eMMC card at system resume, assuming it also has stayed powered on
> during system suspend.
> 
> To implement support for this, let's start by parsing for the new DT
> property and set the new bit MMC_CAP2_RESET_AT_RESUME if it's found. Based
> on the property, we must also set MMC_PM_KEEP_POWER in the pm_flags for the
> host, to keep the eMMC powered on during system suspend.
> 
> Finally, to manage the actual reset during system resume, let's extend
> mmc_resume() to support the needed behaviour.
> 

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

> Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> ---
>   drivers/mmc/core/host.c  | 10 ++++++++++
>   drivers/mmc/core/mmc.c   |  5 +++++
>   include/linux/mmc/host.h |  1 +
>   3 files changed, 16 insertions(+)
> 
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 8e9e61839198..e3daf4026cba 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -48,6 +48,14 @@ static int mmc_host_class_prepare(struct device *dev)
>   	if (host->bus_ops->pre_suspend)
>   		return host->bus_ops->pre_suspend(host);
>   
> +	/*
> +	 * If it's required to make a reset of the card at system resume, this
> +	 * indirectly also means that we must keep the card powered on during
> +	 * system suspend.
> +	 */
> +	if (host->caps2 & MMC_CAP2_RESET_AT_RESUME)
> +		return mmc_set_host_pm_flags(host, MMC_PM_KEEP_POWER);
> +
>   	return 0;
>   }
>   
> @@ -375,6 +383,8 @@ int mmc_of_parse(struct mmc_host *host)
>   		host->pm_caps |= MMC_PM_KEEP_POWER;
>   	if (device_property_read_bool(dev, "wakeup-source"))
>   		host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
> +	if (device_property_read_bool(dev, "reset-card-at-resume"))
> +		host->caps2 |= MMC_CAP2_RESET_AT_RESUME;
>   	if (device_property_read_bool(dev, "mmc-ddr-3_3v"))
>   		host->caps |= MMC_CAP_3_3V_DDR;
>   	if (device_property_read_bool(dev, "mmc-ddr-1_8v"))
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index d4bf0f25bd74..908d5cad304b 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -2315,6 +2315,11 @@ static int mmc_resume(struct mmc_host *host)
>   	}
>   
>   	pm_runtime_enable(&host->card->dev);
> +
> +	if (mmc_card_keep_power(host) &&
> +	    host->caps2 & MMC_CAP2_RESET_AT_RESUME)
> +		_mmc_hw_reset(host);
> +
>   	host->pm_flags &= ~MMC_PM_KEEP_POWER;
>   	return 0;
>   }
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 032c018650e0..552873da7987 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -430,6 +430,7 @@ struct mmc_host {
>   	u32			caps2;		/* More host capabilities */
>   
>   #define MMC_CAP2_BOOTPART_NOACC	(1 << 0)	/* Boot partition no access */
> +#define MMC_CAP2_RESET_AT_RESUME (1 << 1)	/* Reset the card at system resume */
>   #define MMC_CAP2_FULL_PWR_CYCLE	(1 << 2)	/* Can do full power cycle */
>   #define MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND (1 << 3) /* Can do full power cycle in suspend */
>   #define MMC_CAP2_HS200_1_8V_SDR	(1 << 5)        /* can support */

Re: [PATCH v10 6/6] mmc: core: Add support for resetting an eMMC at system resume

[Kamal Dasu]

[-- Attachment #1: Type: text/plain, Size: 5126 bytes --]

On Tue, Oct 27, 2026 at 11:21 AM Shawn Lin <shawn.lin@linux.dev> wrote:
>
> 在 2026/10/27 星期二 22:40, Ulf Hansson 写道:
> > The DT property reset-card-at-resume specifies that we need to make a reset
> > of an eMMC card at system resume, assuming it also has stayed powered on
> > during system suspend.
> >
> > To implement support for this, let's start by parsing for the new DT
> > property and set the new bit MMC_CAP2_RESET_AT_RESUME if it's found. Based
> > on the property, we must also set MMC_PM_KEEP_POWER in the pm_flags for the
> > host, to keep the eMMC powered on during system suspend.
> >
> > Finally, to manage the actual reset during system resume, let's extend
> > mmc_resume() to support the needed behaviour.
> >
>
> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> > Signed-off-by: Ulf Hansson <ulf.hansson@oss.qualcomm.com>
> > ---
> >   drivers/mmc/core/host.c  | 10 ++++++++++
> >   drivers/mmc/core/mmc.c   |  5 +++++
> >   include/linux/mmc/host.h |  1 +
> >   3 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> > index 8e9e61839198..e3daf4026cba 100644
> > --- a/drivers/mmc/core/host.c
> > +++ b/drivers/mmc/core/host.c
> > @@ -48,6 +48,14 @@ static int mmc_host_class_prepare(struct device *dev)
> >       if (host->bus_ops->pre_suspend)
> >               return host->bus_ops->pre_suspend(host);
> >
> > +     /*
> > +      * If it's required to make a reset of the card at system resume, this
> > +      * indirectly also means that we must keep the card powered on during
> > +      * system suspend.
> > +      */
> > +     if (host->caps2 & MMC_CAP2_RESET_AT_RESUME)
> > +             return mmc_set_host_pm_flags(host, MMC_PM_KEEP_POWER);
> > +
> >       return 0;
> >   }
> >
> > @@ -375,6 +383,8 @@ int mmc_of_parse(struct mmc_host *host)
> >               host->pm_caps |= MMC_PM_KEEP_POWER;
> >       if (device_property_read_bool(dev, "wakeup-source"))
> >               host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
> > +     if (device_property_read_bool(dev, "reset-card-at-resume"))
> > +             host->caps2 |= MMC_CAP2_RESET_AT_RESUME;
> >       if (device_property_read_bool(dev, "mmc-ddr-3_3v"))
> >               host->caps |= MMC_CAP_3_3V_DDR;
> >       if (device_property_read_bool(dev, "mmc-ddr-1_8v"))
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index d4bf0f25bd74..908d5cad304b 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -2315,6 +2315,11 @@ static int mmc_resume(struct mmc_host *host)
> >       }
> >
> >       pm_runtime_enable(&host->card->dev);
> > +
> > +     if (mmc_card_keep_power(host) &&
> > +         host->caps2 & MMC_CAP2_RESET_AT_RESUME)
> > +             _mmc_hw_reset(host);
> > +
> >       host->pm_flags &= ~MMC_PM_KEEP_POWER;
> >       return 0;
> >   }
> > diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> > index 032c018650e0..552873da7987 100644
> > --- a/include/linux/mmc/host.h
> > +++ b/include/linux/mmc/host.h
> > @@ -430,6 +430,7 @@ struct mmc_host {
> >       u32                     caps2;          /* More host capabilities */
> >
> >   #define MMC_CAP2_BOOTPART_NOACC     (1 << 0)        /* Boot partition no access */
> > +#define MMC_CAP2_RESET_AT_RESUME (1 << 1)    /* Reset the card at system resume */
> >   #define MMC_CAP2_FULL_PWR_CYCLE     (1 << 2)        /* Can do full power cycle */
> >   #define MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND (1 << 3) /* Can do full power cycle in suspend */
> >   #define MMC_CAP2_HS200_1_8V_SDR     (1 << 5)        /* can support */
>

Hi Ulf,

While testing this series I get a burst of WARN_ON(!host->claimed)
backtraces at system resume (29 of them) when both properties are set:

  WARNING: drivers/mmc/core/core.c:351 at mmc_start_request+0xd0/0xe8
  Call trace:
   mmc_start_request+0xd0/0xe8
   mmc_wait_for_req+0x70/0xf8
   mmc_wait_for_cmd+0x7c/0xb8
   __mmc_switch+0xec/0x258
   mmc_init_card+0x14f0/0x1cc0
   _mmc_hw_reset+0x68/0xa8
   mmc_resume+0x80/0xa8
   mmc_bus_resume+0x2c/0x80
   dpm_run_callback+0x6c/0x280

  WARNING: drivers/mmc/core/core.c:637 at mmc_wait_for_cmd+0xa0/0xb8
   (same path, via __mmc_send_status and __mmc_switch)

_mmc_hw_reset() ends up in mmc_init_card(), which sends commands and
requires the host to be claimed. mmc_resume() calls it without
claiming, unlike _mmc_resume() and the callers of mmc_hw_reset(). The
reset does complete, but it runs unserialized against other users of
the host.

This fixes it for me, with no warnings left:

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -2317,8 +2317,11 @@ static int mmc_resume(struct mmc_host *host)
  pm_runtime_enable(&host->card->dev);

  if (mmc_card_keep_power(host) &&
-     host->caps2 & MMC_CAP2_RESET_AT_RESUME)
+     host->caps2 & MMC_CAP2_RESET_AT_RESUME) {
+ mmc_claim_host(host);
  _mmc_hw_reset(host);
+ mmc_release_host(host);
+ }

  host->pm_flags &= ~MMC_PM_KEEP_POWER;
  return 0;


Regards
Kamal

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5461 bytes --]

Re: [PATCH v10 0/6] mmc: core: Keep the card powered across suspend when firmware needs it live

[Kamal Dasu]

[-- Attachment #1: Type: text/plain, Size: 3237 bytes --]

On Tue, Oct 27, 2026 at 10:41 AM Ulf Hansson
<ulf.hansson@oss.qualcomm.com> wrote:
>
> Background: on brcmstb boards with a Kioxia 016G01 eMMC, firmware accesses the
> card directly during resume from Suspend-to-DRAM, before the kernel's own
> resume path runs, in order to load boot code using hard wired logic that is not
> field updatable. The card needs to stay powered and responsive for that access
> to succeed, and since it is never power-cycled, it also needs to be reset
> before the kernel reuses it after resume.
>
> Changes in v10:
>         - To help out with the implementation I offered my help to try to move
>         this forward.
>         - The DT patches are good to go so I included them from the previous
>         versions.
>         - Patch 3 to 6 are new, but based on the work done by Kamal Dasu.
>         - This is completely untested from my side, please help to test it.
>
> Kind regards
> Ulf Hansson
>
>
> Kamal Dasu (2):
>   dt-bindings: mmc: Extend keep-power-in-suspend beyond SDIO
>   dt-bindings: mmc: Add reset-card-at-resume property
>
> Ulf Hansson (4):
>   mmc: core: Add option to keep an eMMC powered on at system suspend
>   mmc: core: Split sdio_set_host_pm_flags()
>   mmc: core: Move reset functions for eMMC
>   mmc: core: Add support for resetting an eMMC at system resume
>
>  .../bindings/mmc/mmc-controller-common.yaml   | 10 +-
>  drivers/mmc/core/core.c                       |  9 ++
>  drivers/mmc/core/core.h                       |  1 +
>  drivers/mmc/core/host.c                       | 10 ++
>  drivers/mmc/core/mmc.c                        | 95 ++++++++++++-------
>  drivers/mmc/core/sdio_io.c                    |  7 +-
>  include/linux/mmc/host.h                      |  1 +
>  7 files changed, 92 insertions(+), 41 deletions(-)
>
> --
> 2.43.0
>

Hi Ulf,

Test results for this series on a Broadcom STB board with the Kioxia
016G01 eMMC,
which reproduces the problem during S3 suspend/resume with two DT variables:

  keep-power-in-suspend  reset-card-at-resume  Result
                            no                     no
  enters suspend, board resets

      at resume
                            yes                    no
  enters suspend, board resets

       at resume
                            no                     yes
  suspend aborts, -EINVAL
                            yes                    yes
  s3 suspend/resume works

Changes applied to Kernel: v7.3 + 7.4 merge window (linus/master
d135ab453a74) with this
series, plus the one-line fix I'm sending in reply to patch 6/6
(details in my reply to that patch):
mmc_resume() calls _mmc_hw_reset() without claiming the host, which
triggers WARN_ON(!host->claimed) for every command sent during the
reset. Claiming the host around the reset removes the warnings..

The -EINVAL in the third row comes from mmc_host_class_prepare(), since
MMC_PM_KEEP_POWER is not in pm_caps without keep-power-in-suspend.

In the working case I also checked the md5sum of the first 5 MiB of
/dev/mmcblk1 before and after suspend, and it is unchanged.

With the fix applied:
Tested-by: Kamal Dasu <kamal.dasu@broadcom.com>

Regards

Kamal

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5461 bytes --]

Re: [PATCH v10 0/6] mmc: core: Keep the card powered across suspend when firmware needs it live

[Ulf Hansson]

On Tue, Oct 27, 2026 at 8:53 PM Kamal Dasu <kamal.dasu@broadcom.com> wrote:
>
> On Tue, Oct 27, 2026 at 10:41 AM Ulf Hansson
> <ulf.hansson@oss.qualcomm.com> wrote:
> >
> > Background: on brcmstb boards with a Kioxia 016G01 eMMC, firmware accesses the
> > card directly during resume from Suspend-to-DRAM, before the kernel's own
> > resume path runs, in order to load boot code using hard wired logic that is not
> > field updatable. The card needs to stay powered and responsive for that access
> > to succeed, and since it is never power-cycled, it also needs to be reset
> > before the kernel reuses it after resume.
> >
> > Changes in v10:
> >         - To help out with the implementation I offered my help to try to move
> >         this forward.
> >         - The DT patches are good to go so I included them from the previous
> >         versions.
> >         - Patch 3 to 6 are new, but based on the work done by Kamal Dasu.
> >         - This is completely untested from my side, please help to test it.
> >
> > Kind regards
> > Ulf Hansson
> >
> >
> > Kamal Dasu (2):
> >   dt-bindings: mmc: Extend keep-power-in-suspend beyond SDIO
> >   dt-bindings: mmc: Add reset-card-at-resume property
> >
> > Ulf Hansson (4):
> >   mmc: core: Add option to keep an eMMC powered on at system suspend
> >   mmc: core: Split sdio_set_host_pm_flags()
> >   mmc: core: Move reset functions for eMMC
> >   mmc: core: Add support for resetting an eMMC at system resume
> >
> >  .../bindings/mmc/mmc-controller-common.yaml   | 10 +-
> >  drivers/mmc/core/core.c                       |  9 ++
> >  drivers/mmc/core/core.h                       |  1 +
> >  drivers/mmc/core/host.c                       | 10 ++
> >  drivers/mmc/core/mmc.c                        | 95 ++++++++++++-------
> >  drivers/mmc/core/sdio_io.c                    |  7 +-
> >  include/linux/mmc/host.h                      |  1 +
> >  7 files changed, 92 insertions(+), 41 deletions(-)
> >
> > --
> > 2.43.0
> >
>
> Hi Ulf,
>
> Test results for this series on a Broadcom STB board with the Kioxia
> 016G01 eMMC,
> which reproduces the problem during S3 suspend/resume with two DT variables:
>
>   keep-power-in-suspend  reset-card-at-resume  Result
>                             no                     no
>   enters suspend, board resets
>
>       at resume
>                             yes                    no
>   enters suspend, board resets
>
>        at resume
>                             no                     yes
>   suspend aborts, -EINVAL
>                             yes                    yes
>   s3 suspend/resume works
>
> Changes applied to Kernel: v7.3 + 7.4 merge window (linus/master
> d135ab453a74) with this
> series, plus the one-line fix I'm sending in reply to patch 6/6
> (details in my reply to that patch):
> mmc_resume() calls _mmc_hw_reset() without claiming the host, which
> triggers WARN_ON(!host->claimed) for every command sent during the
> reset. Claiming the host around the reset removes the warnings..
>
> The -EINVAL in the third row comes from mmc_host_class_prepare(), since
> MMC_PM_KEEP_POWER is not in pm_caps without keep-power-in-suspend.

Yes, that was actually intentional as we can't allow the system to
suspend in this configuration, as we may not wake up correctly, right?

Although, perhaps we should also log a warning earlier during the
probe of the host, when we are parsing the DT properties for it. To
upfront say something isn't correct.

>
> In the working case I also checked the md5sum of the first 5 MiB of
> /dev/mmcblk1 before and after suspend, and it is unchanged.
>
> With the fix applied:
> Tested-by: Kamal Dasu <kamal.dasu@broadcom.com>

Thanks and thanks for the fix on top!

>
> Regards
>
> Kamal

I will send a new version shortly to address the comments and needed fixes.

Kind regards
Uffe