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

From: Ulf Hansson

Date: Tue May 12 2026 - 09:45:56 EST


On Mon, 11 May 2026 at 18:01, Florian Fainelli
<florian.fainelli@xxxxxxxxxxxx> wrote:
>
> On 5/11/26 07:18, Ulf Hansson wrote:
> > On Mon, 13 Apr 2026 at 20:06, Florian Fainelli
> > <florian.fainelli@xxxxxxxxxxxx> 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

Is the CMD0 sent solely by HW/FW before the mmc core executes
_mmc_resume() during system resume?

> 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

Can you please clarify what tSLEEP_EXIT refers to? Are you referring
to the S_A_TIMEOUT in the EXT_CSD register for the eMMC card?

Anyway, waking up an eMMC from sleep state in just 1ms sounds a bit
optimistic to me.

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

Okay, I see.

In this regard, it's important to understand for me how the mmc host
driver (and the HW/FW) manages VCC and VCCQ when the mmc core calls
mmc_power_off() from _mmc_suspend()?

Does this turn off any of these regulators or what happens to them
during system suspend?

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

Yes, but let's discuss a bit more first.

Kind regards
Uffe