Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

[Florian Fainelli]

On 4/13/26 11:05, Florian Fainelli wrote:
> The Kioxia 016G01 eMMC device does not exit SLEEP mode when sending CMD0
> which prevents the system from properly resuming from S3 warm boot where
> the eMMC is necessary to pull in the boot components.
> 
> Add a quirk which prevents that specific device model from entering
> SLEEP mode. There are no differences in the power consumption observed.
> 
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>

Any feedback on this?
-- 
Florian

Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

[Oleksij Rempel]

Hi Florian,

On Wed, May 06, 2026 at 09:49:46AM -0700, Florian Fainelli wrote:
> On 4/13/26 11:05, Florian Fainelli wrote:
> > The Kioxia 016G01 eMMC device does not exit SLEEP mode when sending CMD0
> > which prevents the system from properly resuming from S3 warm boot where
> > the eMMC is necessary to pull in the boot components.
> > 
> > Add a quirk which prevents that specific device model from entering
> > SLEEP mode. There are no differences in the power consumption observed.
> > 
> > Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> 
> Any feedback on this?

Hm, can the sleep call be executed before mmcblk driver is loaded?
For example by under-voltage signal? In this case the quirk will not
be applied. May be better to put this quirk in mmc_ext_csd_fixups[]?

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

[Ulf Hansson]

On Mon, 13 Apr 2026 at 20:06, Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
>
> The Kioxia 016G01 eMMC device does not exit SLEEP mode when sending CMD0
> which prevents the system from properly resuming from S3 warm boot where
> the eMMC is necessary to pull in the boot components.

Is the bug confirmed by Kioxia?

If not, can you explain a bit more what is actually happening during
system resume?

>
> Add a quirk which prevents that specific device model from entering
> SLEEP mode. There are no differences in the power consumption observed.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>

Kind regards
Uffe

> ---
>  drivers/mmc/core/mmc.c    | 3 ++-
>  drivers/mmc/core/quirks.h | 7 +++++++
>  include/linux/mmc/card.h  | 1 +
>  3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 7c86efb1044a..8471115f7fc9 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1958,7 +1958,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>
>  static bool mmc_card_can_sleep(struct mmc_card *card)
>  {
> -       return card->ext_csd.rev >= 3;
> +       return card->ext_csd.rev >= 3 &&
> +              !(card->quirks & MMC_QUIRK_BROKEN_SLEEP);
>  }
>
>  static int mmc_sleep_busy_cb(void *cb_data, bool *busy)
> diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> index c417ed34c057..dc6badf740f3 100644
> --- a/drivers/mmc/core/quirks.h
> +++ b/drivers/mmc/core/quirks.h
> @@ -153,6 +153,13 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = {
>         MMC_FIXUP("M62704", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
>                   MMC_QUIRK_TRIM_BROKEN),
>
> +       /*
> +        * Some Kioxia eMMC devices will not go into boot mode on CMD0 arg
> +        * after going into SLEEP state.
> +        */
> +       MMC_FIXUP("016G01", CID_MANFID_TOSHIBA, 0x0100, add_quirk_mmc,
> +                 MMC_QUIRK_BROKEN_SLEEP),
> +
>         END_FIXUP
>  };
>
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index e9e964c20e53..3812e9e79541 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -329,6 +329,7 @@ struct mmc_card {
>  #define MMC_QUIRK_BROKEN_CACHE_FLUSH   (1<<16) /* Don't flush cache until the write has occurred */
>  #define MMC_QUIRK_BROKEN_SD_POWEROFF_NOTIFY    (1<<17) /* Disable broken SD poweroff notify support */
>  #define MMC_QUIRK_NO_UHS_DDR50_TUNING  (1<<18) /* Disable DDR50 tuning */
> +#define MMC_QUIRK_BROKEN_SLEEP         (1<<19) /* Broken sleep mode */
>
>         bool                    written_flag;   /* Indicates eMMC has been written since power on */
>         bool                    reenable_cmdq;  /* Re-enable Command Queue */
> --
> 2.43.0
>
>

Re: [PATCH] mmc: core: Kioxia 016G01 does not enter boot mode after SLEEP

[Florian Fainelli]

On 5/11/26 07:18, Ulf Hansson wrote:
> On Mon, 13 Apr 2026 at 20:06, Florian Fainelli
> <florian.fainelli@broadcom.com> wrote:
>>
>> The Kioxia 016G01 eMMC device does not exit SLEEP mode when sending CMD0
>> which prevents the system from properly resuming from S3 warm boot where
>> the eMMC is necessary to pull in the boot components.
> 
> Is the bug confirmed by Kioxia?

We've been going back and forth with them without much progress as far 
as a resolution goes. Since there was no progress and I would like to 
get this included in downstream kernels at some point, this was submitted.

> 
> If not, can you explain a bit more what is actually happening during
> system resume?

Upon entering Suspend-to-DRAM, the eMMC will be put into sleep mode. 
When our systems resume, one of our hardware cores driving the eMMC (HIF 
block) in command mode will send a CMD0 command for the eMMC device to 
exit SLEEP mode. The Kioxia 016G01 device takes 10ms rather than the 
tSLEEP_EXIT value of 1ms which is advertised and so our HIF block does 
not see the Boot ACK pattern in time and does not service the read 
request from the processor that wanted to read from eMMC, we get a reset 
of the system, rather than continue booting.

When SLEEP is not enabled, the eMMC device responds within tSLEEP_EXIT 
as advertised and we don't have that problem.

So I suppose I could reformulate the commit message and give some more 
details here if you would like?
-- 
Florian