[PATCH] mmc: mmci: stm32: handle mmc power up

[PATCH] mmc: mmci: stm32: handle mmc power up

[Marek Vasut]

From: Christophe Kerello <christophe.kerello@foss.st.com>

Manage MMC POWER UP state like MMC POWER OFF state. In case of low
power use cases, it will avoid random initialization timeout. This
fixes a failure to switch DDR52 eMMC to 8 bit mode due to -EILSEQ
returned from mmc_get_ext_csd() in mmc_compare_ext_csds() called
from mmc_select_bus_width() after Standby1 suspend/resume cycle.

Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Christophe Kerello <christophe.kerello@foss.st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Ulf Hansson <ulfh@kernel.org>
Cc: kernel@dh-electronics.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
---
Marek: Update commit message
---
 drivers/mmc/host/mmci_stm32_sdmmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
index 9dc51859c2e51..659a5040729e9 100644
--- a/drivers/mmc/host/mmci_stm32_sdmmc.c
+++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
@@ -368,7 +368,8 @@ static void mmci_sdmmc_set_pwrreg(struct mmci_host *host, unsigned int pwr)
 	if (dlyb && dlyb->ops->set_input_ck)
 		dlyb->ops->set_input_ck(dlyb);
 
-	if (ios.power_mode == MMC_POWER_OFF) {
+	if (ios.power_mode == MMC_POWER_OFF ||
+	    ios.power_mode == MMC_POWER_UP) {
 		/* Only a reset could power-off sdmmc */
 		reset_control_assert(host->rst);
 		udelay(2);
-- 
2.53.0

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Ulf Hansson]

On Fri, Oct 30, 2026 at 10:54 PM Marek Vasut <marex@nabladev.com> wrote:
>
> From: Christophe Kerello <christophe.kerello@foss.st.com>
>
> Manage MMC POWER UP state like MMC POWER OFF state. In case of low
> power use cases, it will avoid random initialization timeout. This
> fixes a failure to switch DDR52 eMMC to 8 bit mode due to -EILSEQ
> returned from mmc_get_ext_csd() in mmc_compare_ext_csds() called
> from mmc_select_bus_width() after Standby1 suspend/resume cycle.
>
> Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
> Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> Cc: Christophe Kerello <christophe.kerello@foss.st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Ulf Hansson <ulfh@kernel.org>
> Cc: kernel@dh-electronics.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mmc@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> ---
> Marek: Update commit message
> ---
>  drivers/mmc/host/mmci_stm32_sdmmc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
> index 9dc51859c2e51..659a5040729e9 100644
> --- a/drivers/mmc/host/mmci_stm32_sdmmc.c
> +++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
> @@ -368,7 +368,8 @@ static void mmci_sdmmc_set_pwrreg(struct mmci_host *host, unsigned int pwr)
>         if (dlyb && dlyb->ops->set_input_ck)
>                 dlyb->ops->set_input_ck(dlyb);
>
> -       if (ios.power_mode == MMC_POWER_OFF) {
> +       if (ios.power_mode == MMC_POWER_OFF ||
> +           ios.power_mode == MMC_POWER_UP) {
>                 /* Only a reset could power-off sdmmc */
>                 reset_control_assert(host->rst);
>                 udelay(2);

What exactly will this reset?

Kind regards
Uffe

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Marek Vasut]

On 11/10/26 2:32 PM, Ulf Hansson wrote:
> On Fri, Oct 30, 2026 at 10:54 PM Marek Vasut <marex@nabladev.com> wrote:
>>
>> From: Christophe Kerello <christophe.kerello@foss.st.com>
>>
>> Manage MMC POWER UP state like MMC POWER OFF state. In case of low
>> power use cases, it will avoid random initialization timeout. This
>> fixes a failure to switch DDR52 eMMC to 8 bit mode due to -EILSEQ
>> returned from mmc_get_ext_csd() in mmc_compare_ext_csds() called
>> from mmc_select_bus_width() after Standby1 suspend/resume cycle.
>>
>> Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
>> Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
>> Signed-off-by: Marek Vasut <marex@nabladev.com>
>> ---
>> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
>> Cc: Christophe Kerello <christophe.kerello@foss.st.com>
>> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Cc: Ulf Hansson <ulfh@kernel.org>
>> Cc: kernel@dh-electronics.com
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-mmc@vger.kernel.org
>> Cc: linux-stm32@st-md-mailman.stormreply.com
>> ---
>> Marek: Update commit message
>> ---
>>   drivers/mmc/host/mmci_stm32_sdmmc.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
>> index 9dc51859c2e51..659a5040729e9 100644
>> --- a/drivers/mmc/host/mmci_stm32_sdmmc.c
>> +++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
>> @@ -368,7 +368,8 @@ static void mmci_sdmmc_set_pwrreg(struct mmci_host *host, unsigned int pwr)
>>          if (dlyb && dlyb->ops->set_input_ck)
>>                  dlyb->ops->set_input_ck(dlyb);
>>
>> -       if (ios.power_mode == MMC_POWER_OFF) {
>> +       if (ios.power_mode == MMC_POWER_OFF ||
>> +           ios.power_mode == MMC_POWER_UP) {
>>                  /* Only a reset could power-off sdmmc */
>>                  reset_control_assert(host->rst);
>>                  udelay(2);
> 
> What exactly will this reset?
The controller.

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Ulf Hansson]

On Wed, Nov 11, 2026 at 5:14 AM Marek Vasut <marex@nabladev.com> wrote:
>
> On 11/10/26 2:32 PM, Ulf Hansson wrote:
> > On Fri, Oct 30, 2026 at 10:54 PM Marek Vasut <marex@nabladev.com> wrote:
> >>
> >> From: Christophe Kerello <christophe.kerello@foss.st.com>
> >>
> >> Manage MMC POWER UP state like MMC POWER OFF state. In case of low
> >> power use cases, it will avoid random initialization timeout. This
> >> fixes a failure to switch DDR52 eMMC to 8 bit mode due to -EILSEQ
> >> returned from mmc_get_ext_csd() in mmc_compare_ext_csds() called
> >> from mmc_select_bus_width() after Standby1 suspend/resume cycle.
> >>
> >> Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
> >> Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
> >> Signed-off-by: Marek Vasut <marex@nabladev.com>
> >> ---
> >> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> >> Cc: Christophe Kerello <christophe.kerello@foss.st.com>
> >> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> >> Cc: Ulf Hansson <ulfh@kernel.org>
> >> Cc: kernel@dh-electronics.com
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-mmc@vger.kernel.org
> >> Cc: linux-stm32@st-md-mailman.stormreply.com
> >> ---
> >> Marek: Update commit message
> >> ---
> >>   drivers/mmc/host/mmci_stm32_sdmmc.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
> >> index 9dc51859c2e51..659a5040729e9 100644
> >> --- a/drivers/mmc/host/mmci_stm32_sdmmc.c
> >> +++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
> >> @@ -368,7 +368,8 @@ static void mmci_sdmmc_set_pwrreg(struct mmci_host *host, unsigned int pwr)
> >>          if (dlyb && dlyb->ops->set_input_ck)
> >>                  dlyb->ops->set_input_ck(dlyb);
> >>
> >> -       if (ios.power_mode == MMC_POWER_OFF) {
> >> +       if (ios.power_mode == MMC_POWER_OFF ||
> >> +           ios.power_mode == MMC_POWER_UP) {
> >>                  /* Only a reset could power-off sdmmc */
> >>                  reset_control_assert(host->rst);
> >>                  udelay(2);
> >
> > What exactly will this reset?
> The controller.

Okay, I see.

In that case, this reset also makes us reset preceding updates to any
other registers, for example the clock register. I would not recommend
doing that here, but perhaps there is no better option.

If I may I suggest an alternative solution, perhaps we can manage this
in the ->runtime_resume() callback instead. If the power_mode ==
MMC_POWER_OFF, perhaps do this reset there instead? Would that work?

Anothing thing that caught my eyes was the MCI_STM32_PWR_CYC bit that
gets written at MMC_POWER_OFF. This bit becomes cached in
host->pwr_reg, hence it's also rewritten at MMC_POWER_ON. Is that
intentional?

Kind regards
Uffe

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Marek Vasut]

On 11/11/26 12:45 PM, Ulf Hansson wrote:

Hello Ulf,

>>>> -       if (ios.power_mode == MMC_POWER_OFF) {
>>>> +       if (ios.power_mode == MMC_POWER_OFF ||
>>>> +           ios.power_mode == MMC_POWER_UP) {
>>>>                   /* Only a reset could power-off sdmmc */
>>>>                   reset_control_assert(host->rst);
>>>>                   udelay(2);
>>>
>>> What exactly will this reset?
>> The controller.
> 
> Okay, I see.
> 
> In that case, this reset also makes us reset preceding updates to any
> other registers, for example the clock register. I would not recommend
> doing that here, but perhaps there is no better option.

Does that pose a problem in the MMC_POWER_OFF/UP state ? I agree this 
would pose a problem in the MMC_POWER_ON state, but here the card is not ON.

> If I may I suggest an alternative solution, perhaps we can manage this
> in the ->runtime_resume() callback instead. If the power_mode ==
> MMC_POWER_OFF, perhaps do this reset there instead? Would that work?
> 
> Anothing thing that caught my eyes was the MCI_STM32_PWR_CYC bit that
> gets written at MMC_POWER_OFF. This bit becomes cached in
> host->pwr_reg, hence it's also rewritten at MMC_POWER_ON. Is that
> intentional?
I _think_ so, this seems to be used to power cycle the card.

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Ulf Hansson]

On Thu, Nov 12, 2026 at 7:26 AM Marek Vasut <marex@nabladev.com> wrote:
>
> On 11/11/26 12:45 PM, Ulf Hansson wrote:
>
> Hello Ulf,
>
> >>>> -       if (ios.power_mode == MMC_POWER_OFF) {
> >>>> +       if (ios.power_mode == MMC_POWER_OFF ||
> >>>> +           ios.power_mode == MMC_POWER_UP) {
> >>>>                   /* Only a reset could power-off sdmmc */
> >>>>                   reset_control_assert(host->rst);
> >>>>                   udelay(2);
> >>>
> >>> What exactly will this reset?
> >> The controller.
> >
> > Okay, I see.
> >
> > In that case, this reset also makes us reset preceding updates to any
> > other registers, for example the clock register. I would not recommend
> > doing that here, but perhaps there is no better option.
>
> Does that pose a problem in the MMC_POWER_OFF/UP state ? I agree this
> would pose a problem in the MMC_POWER_ON state, but here the card is not ON.

I think it is a problem, yes. If you have a closer look at what
happens in mmci_set_ios(), I think you will agree.

>
> > If I may I suggest an alternative solution, perhaps we can manage this
> > in the ->runtime_resume() callback instead. If the power_mode ==
> > MMC_POWER_OFF, perhaps do this reset there instead? Would that work?

Can you try this?

> >
> > Anothing thing that caught my eyes was the MCI_STM32_PWR_CYC bit that
> > gets written at MMC_POWER_OFF. This bit becomes cached in
> > host->pwr_reg, hence it's also rewritten at MMC_POWER_ON. Is that
> > intentional?
> I _think_ so, this seems to be used to power cycle the card.

Well, we are not power-cycling the card at MMC_POWER_ON, we are turning it on.

Seems like we could use some support from the ST guys to understand this better.

Kind regards
Uffe

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Christophe KERELLO]

Hello Ulf,

On 11/13/26 12:46, Ulf Hansson wrote:
> On Thu, Nov 12, 2026 at 7:26 AM Marek Vasut <marex@nabladev.com> wrote:
>> On 11/11/26 12:45 PM, Ulf Hansson wrote:
>>
>> Hello Ulf,
>>
>>>>>> -       if (ios.power_mode == MMC_POWER_OFF) {
>>>>>> +       if (ios.power_mode == MMC_POWER_OFF ||
>>>>>> +           ios.power_mode == MMC_POWER_UP) {
>>>>>>                    /* Only a reset could power-off sdmmc */
>>>>>>                    reset_control_assert(host->rst);
>>>>>>                    udelay(2);
>>>>> What exactly will this reset?
>>>> The controller.
>>> Okay, I see.
>>>
>>> In that case, this reset also makes us reset preceding updates to any
>>> other registers, for example the clock register. I would not recommend
>>> doing that here, but perhaps there is no better option.
>> Does that pose a problem in the MMC_POWER_OFF/UP state ? I agree this
>> would pose a problem in the MMC_POWER_ON state, but here the card is not ON.
> I think it is a problem, yes. If you have a closer look at what
> happens in mmci_set_ios(), I think you will agree.
>
>>> If I may I suggest an alternative solution, perhaps we can manage this
>>> in the ->runtime_resume() callback instead. If the power_mode ==
>>> MMC_POWER_OFF, perhaps do this reset there instead? Would that work?
> Can you try this?

I have sent a new patch based on your proposal:
https://lore.kernel.org/linux-mmc/20261113-fix-resume-reset-v1-1-115b3da5764d@foss.st.com/

It works fine on my side.

Hi Marek,
Could you also test it on your board to confirm that it fixes the issue 
you reported?

Regards,
Christophe Kerello.

>
>>> Anothing thing that caught my eyes was the MCI_STM32_PWR_CYC bit that
>>> gets written at MMC_POWER_OFF. This bit becomes cached in
>>> host->pwr_reg, hence it's also rewritten at MMC_POWER_ON. Is that
>>> intentional?
>> I _think_ so, this seems to be used to power cycle the card.
> Well, we are not power-cycling the card at MMC_POWER_ON, we are turning it on.
>
> Seems like we could use some support from the ST guys to understand this better.
>
> Kind regards
> Uffe

Re: [PATCH] mmc: mmci: stm32: handle mmc power up

[Marek Vasut]

On 11/13/26 5:53 PM, Christophe KERELLO wrote:
> Hello Ulf,
> 
> On 11/13/26 12:46, Ulf Hansson wrote:
>> On Thu, Nov 12, 2026 at 7:26 AM Marek Vasut <marex@nabladev.com> wrote:
>>> On 11/11/26 12:45 PM, Ulf Hansson wrote:
>>>
>>> Hello Ulf,
>>>
>>>>>>> -       if (ios.power_mode == MMC_POWER_OFF) {
>>>>>>> +       if (ios.power_mode == MMC_POWER_OFF ||
>>>>>>> +           ios.power_mode == MMC_POWER_UP) {
>>>>>>>                    /* Only a reset could power-off sdmmc */
>>>>>>>                    reset_control_assert(host->rst);
>>>>>>>                    udelay(2);
>>>>>> What exactly will this reset?
>>>>> The controller.
>>>> Okay, I see.
>>>>
>>>> In that case, this reset also makes us reset preceding updates to any
>>>> other registers, for example the clock register. I would not recommend
>>>> doing that here, but perhaps there is no better option.
>>> Does that pose a problem in the MMC_POWER_OFF/UP state ? I agree this
>>> would pose a problem in the MMC_POWER_ON state, but here the card is 
>>> not ON.
>> I think it is a problem, yes. If you have a closer look at what
>> happens in mmci_set_ios(), I think you will agree.
>>
>>>> If I may I suggest an alternative solution, perhaps we can manage this
>>>> in the ->runtime_resume() callback instead. If the power_mode ==
>>>> MMC_POWER_OFF, perhaps do this reset there instead? Would that work?
>> Can you try this?
> 
> I have sent a new patch based on your proposal:
> https://lore.kernel.org/linux-mmc/20261113-fix-resume-reset- 
> v1-1-115b3da5764d@foss.st.com/
> 
> It works fine on my side.
> 
> Hi Marek,
> Could you also test it on your board to confirm that it fixes the issue 
> you reported?
This works too, thanks .