[PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[ziniu.wang_1]

From: Luke Wang <ziniu.wang_1@nxp.com>

This patch series optimize secure erase performance for certain Kingston
eMMC devices (IY2964 and IB2932) that take a fixed ~2 seconds per secure
erase operation regardless of size.

Currently, a 1GB secure erase requires ~300 operations (limited by max
discard size), taking ~10 minutes. With these changes, the same secure
erase completes in a single operation, reducing time to just 2 seconds.

---
Changes in v2:
- Rebased on v6.19-rc1 as requested
- Cover letter: terminology fix (command -> operation)
---

Luke Wang (2):
  block: decouple secure erase size limit from discard size limit
  mmc: add quirk to optimize certain Kingston eMMC secure erase/trim
    performance

 block/blk-merge.c         | 9 +++++++--
 block/blk.h               | 6 +++++-
 drivers/mmc/core/card.h   | 5 +++++
 drivers/mmc/core/queue.c  | 9 +++++++--
 drivers/mmc/core/quirks.h | 9 +++++++++
 include/linux/mmc/card.h  | 1 +
 6 files changed, 34 insertions(+), 5 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] block: decouple secure erase size limit from discard size limit

[ziniu.wang_1]

From: Luke Wang <ziniu.wang_1@nxp.com>

Secure erase should use max_secure_erase_sectors instead of being limited
by max_discard_sectors. Separate the handling of REQ_OP_SECURE_ERASE from
REQ_OP_DISCARD to allow each operation to use its own size limit.

Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
 block/blk-merge.c | 9 +++++++--
 block/blk.h       | 6 +++++-
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index d3115d7469df..0885e4b982ed 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -169,8 +169,13 @@ struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
 
 	granularity = max(lim->discard_granularity >> 9, 1U);
 
-	max_discard_sectors =
-		min(lim->max_discard_sectors, bio_allowed_max_sectors(lim));
+	if (bio_op(bio) == REQ_OP_SECURE_ERASE)
+		max_discard_sectors = min(lim->max_secure_erase_sectors,
+					  bio_allowed_max_sectors(lim));
+	else
+		max_discard_sectors = min(lim->max_discard_sectors,
+					  bio_allowed_max_sectors(lim));
+
 	max_discard_sectors -= max_discard_sectors % granularity;
 	if (unlikely(!max_discard_sectors))
 		return bio;
diff --git a/block/blk.h b/block/blk.h
index e4c433f62dfc..4cd5a91346d8 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -208,10 +208,14 @@ static inline unsigned int blk_queue_get_max_sectors(struct request *rq)
 	struct request_queue *q = rq->q;
 	enum req_op op = req_op(rq);
 
-	if (unlikely(op == REQ_OP_DISCARD || op == REQ_OP_SECURE_ERASE))
+	if (unlikely(op == REQ_OP_DISCARD))
 		return min(q->limits.max_discard_sectors,
 			   UINT_MAX >> SECTOR_SHIFT);
 
+	if (unlikely(op == REQ_OP_SECURE_ERASE))
+		return min(q->limits.max_secure_erase_sectors,
+			   UINT_MAX >> SECTOR_SHIFT);
+
 	if (unlikely(op == REQ_OP_WRITE_ZEROES))
 		return q->limits.max_write_zeroes_sectors;
 
-- 
2.34.1

Re: [PATCH v2 1/2] block: decouple secure erase size limit from discard size limit

[Christoph Hellwig]

> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -169,8 +169,13 @@ struct bio *bio_split_discard(struct bio *bio, const struct queue_limits *lim,
>  
>  	granularity = max(lim->discard_granularity >> 9, 1U);
>  
> -	max_discard_sectors =
> -		min(lim->max_discard_sectors, bio_allowed_max_sectors(lim));
> +	if (bio_op(bio) == REQ_OP_SECURE_ERASE)
> +		max_discard_sectors = min(lim->max_secure_erase_sectors,
> +					  bio_allowed_max_sectors(lim));
> +	else
> +		max_discard_sectors = min(lim->max_discard_sectors,
> +					  bio_allowed_max_sectors(lim));

Please factor our a low-level helper and pass the max_sectors
as argument.

RE: [EXT] Re: [PATCH v2 1/2] block: decouple secure erase size limit from discard size limit

[Luke Wang]

> -----Original Message-----
> From: Christoph Hellwig <hch@infradead.org>
> Sent: Monday, December 15, 2025 11:43 PM
> To: Luke Wang <ziniu.wang_1@nxp.com>
> Cc: axboe@kernel.dk; ulf.hansson@linaro.org; linux-block@vger.kernel.org;
> linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: [EXT] Re: [PATCH v2 1/2] block: decouple secure erase size limit from
> discard size limit
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> > --- a/block/blk-merge.c
> > +++ b/block/blk-merge.c
> > @@ -169,8 +169,13 @@ struct bio *bio_split_discard(struct bio *bio, const
> struct queue_limits *lim,
> >
> >       granularity = max(lim->discard_granularity >> 9, 1U);
> >
> > -     max_discard_sectors =
> > -             min(lim->max_discard_sectors, bio_allowed_max_sectors(lim));
> > +     if (bio_op(bio) == REQ_OP_SECURE_ERASE)
> > +             max_discard_sectors = min(lim->max_secure_erase_sectors,
> > +                                       bio_allowed_max_sectors(lim));
> > +     else
> > +             max_discard_sectors = min(lim->max_discard_sectors,
> > +                                       bio_allowed_max_sectors(lim));
> 
> Please factor our a low-level helper and pass the max_sectors
> as argument.

I'm not sure I get your point. Do you mean helper function like get_max_io_size()? 
Or do you mean something different?  Please explain in more detail.

Thanks,
Luke

[PATCH v2 2/2] mmc: add quirk to optimize certain Kingston eMMC secure erase/trim performance

[ziniu.wang_1]

From: Luke Wang <ziniu.wang_1@nxp.com>

Kingston eMMC IY2964 and IB2932 takes a fixed ~2 seconds for each secure
erase/trim operation regardless of size - that is, a single secure
erase/trim operation of 1MB takes the same time as 1GB. With default
calculated 3.5MB max discard size, secure erase 1GB requires ~300 separate
operations taking ~10 minutes total.

Add MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME quirk to set maximum secure
erase size for those devices. This allows 1GB secure erase to complete
in a single operation, reducing time from 10 minutes to just 2 seconds.

Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
---
 drivers/mmc/core/card.h   | 5 +++++
 drivers/mmc/core/queue.c  | 9 +++++++--
 drivers/mmc/core/quirks.h | 9 +++++++++
 include/linux/mmc/card.h  | 1 +
 4 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/card.h b/drivers/mmc/core/card.h
index 1200951bab08..0a198a2c2616 100644
--- a/drivers/mmc/core/card.h
+++ b/drivers/mmc/core/card.h
@@ -305,4 +305,9 @@ static inline int mmc_card_no_uhs_ddr50_tuning(const struct mmc_card *c)
 	return c->quirks & MMC_QUIRK_NO_UHS_DDR50_TUNING;
 }
 
+static inline int mmc_card_fixed_secure_erase_trim_time(const struct mmc_card *c)
+{
+	return c->quirks & MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME;
+}
+
 #endif
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 284856c8f655..eb1053d8cae7 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -184,8 +184,13 @@ static void mmc_queue_setup_discard(struct mmc_card *card,
 		return;
 
 	lim->max_hw_discard_sectors = max_discard;
-	if (mmc_card_can_secure_erase_trim(card))
-		lim->max_secure_erase_sectors = max_discard;
+	if (mmc_card_can_secure_erase_trim(card)) {
+		if (mmc_card_fixed_secure_erase_trim_time(card))
+			lim->max_secure_erase_sectors = UINT_MAX >> card->erase_shift;
+		else
+			lim->max_secure_erase_sectors = max_discard;
+	}
+
 	if (mmc_card_can_trim(card) && card->erased_byte == 0)
 		lim->max_write_zeroes_sectors = max_discard;
 
diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
index c417ed34c057..1f7406c0ab03 100644
--- a/drivers/mmc/core/quirks.h
+++ b/drivers/mmc/core/quirks.h
@@ -153,6 +153,15 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = {
 	MMC_FIXUP("M62704", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
 		  MMC_QUIRK_TRIM_BROKEN),
 
+	/*
+	 * On Some Kingston eMMCs, secure erase/trim time is independent
+	 * of erase size, fixed at approximately 2 seconds.
+	 */
+	MMC_FIXUP("IY2964", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
+		  MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME),
+	MMC_FIXUP("IB2932", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc,
+		  MMC_QUIRK_FIXED_SECURE_ERASE_TRIM_TIME),
+
 	END_FIXUP
 };
 
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index e9e964c20e53..1882267ef201 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_FIXED_SECURE_ERASE_TRIM_TIME	(1<<19) /* Secure erase/trim time is fixed regardless of size */
 
 	bool			written_flag;	/* Indicates eMMC has been written since power on */
 	bool			reenable_cmdq;	/* Re-enable Command Queue */
-- 
2.34.1

Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Ulf Hansson]

On Mon, 15 Dec 2025 at 11:18, <ziniu.wang_1@nxp.com> wrote:
>
> From: Luke Wang <ziniu.wang_1@nxp.com>
>
> This patch series optimize secure erase performance for certain Kingston
> eMMC devices (IY2964 and IB2932) that take a fixed ~2 seconds per secure
> erase operation regardless of size.

Well, that sounds to me like the eMMC isn't really erasing the blocks.
I wonder how "secure" this is in practice.

>
> Currently, a 1GB secure erase requires ~300 operations (limited by max
> discard size), taking ~10 minutes. With these changes, the same secure
> erase completes in a single operation, reducing time to just 2 seconds.

Hmm, is the problem really the size or is it the timeout? Why does 300
operations to erase 1GB take ~10 minutes?

Can you please elaborate what happens on the mmc host driver level for
each operation. What mmc host driver/controller is being used? Does it
support MMC_CAP_WAIT_WHILE_BUSY or do we end up polling for
busy-completion in-between each command?

Kind regards
Uffe

>
> ---
> Changes in v2:
> - Rebased on v6.19-rc1 as requested
> - Cover letter: terminology fix (command -> operation)
> ---
>
> Luke Wang (2):
>   block: decouple secure erase size limit from discard size limit
>   mmc: add quirk to optimize certain Kingston eMMC secure erase/trim
>     performance
>
>  block/blk-merge.c         | 9 +++++++--
>  block/blk.h               | 6 +++++-
>  drivers/mmc/core/card.h   | 5 +++++
>  drivers/mmc/core/queue.c  | 9 +++++++--
>  drivers/mmc/core/quirks.h | 9 +++++++++
>  include/linux/mmc/card.h  | 1 +
>  6 files changed, 34 insertions(+), 5 deletions(-)
>
> --
> 2.34.1
>

RE: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Luke Wang]

> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@linaro.org>
> Sent: Monday, December 15, 2025 11:38 PM
> To: Luke Wang <ziniu.wang_1@nxp.com>
> Cc: axboe@kernel.dk; linux-block@vger.kernel.org; linux-
> mmc@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for
> certain Kingston eMMC devices
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
> 
> 
> On Mon, 15 Dec 2025 at 11:18, <ziniu.wang_1@nxp.com> wrote:
> >
> > From: Luke Wang <ziniu.wang_1@nxp.com>
> >
> > This patch series optimize secure erase performance for certain Kingston
> > eMMC devices (IY2964 and IB2932) that take a fixed ~2 seconds per secure
> > erase operation regardless of size.
> 
> Well, that sounds to me like the eMMC isn't really erasing the blocks.
> I wonder how "secure" this is in practice.

Compared to other eMMC, 2 second secure erase time for 1GB is reasonable.

Using the default 3.5MB secure erase chunk, the total time spent secure erasing 1GB:
Sandisk SDINBDG4-32G-I 0.8s
Micron MTFC32GAKAEEF-AIT 4.7s
Longsys FEMDNN032G-C9A55 0.6s

In fact, secure erase does not guarantee that data is physically erased. We previously encountered
an issue with long secure trim times on the MTFC32GAKAEEF-AIT eMMC, and got confirmation
from Micron:
"Secure Erase (0x80000000) is treated as a simple Erase (0x00000000), while Secure
Trim (0x80000001 + 0x80008000) and Trim (0x00000001) are treated differently. So, it is
possible that Secure Trim really is the heaviest possible erase operation for the FW to execute. "

And the eMMC 5.1 Spec:
"NOTE Secure Erase is included for backwards compatibility. New system level implementations
(based on v4.51 devices and beyond) should use Erase combined with Sanitize instead of secure erase."

> 
> >
> > Currently, a 1GB secure erase requires ~300 operations (limited by max
> > discard size), taking ~10 minutes. With these changes, the same secure
> > erase completes in a single operation, reducing time to just 2 seconds.
> 
> Hmm, is the problem really the size or is it the timeout? Why does 300
> operations to erase 1GB take ~10 minutes?

I think the problem is caused by the fact that this Kingston eMMC secure erase
small chunk need ~2 second. In contrast, other eMMC secure erase small chunk
only take tens of milliseconds.

Also, the calculated max discard is too small. For the I.MX8MN USBHC controller, 
host->max_busy_timeout is 2684ms, and the calculated max discard is always
card->pref_erase - 1, which is 3.5MB.

> 
> Can you please elaborate what happens on the mmc host driver level for
> each operation. What mmc host driver/controller is being used? Does it
> support MMC_CAP_WAIT_WHILE_BUSY or do we end up polling for
> busy-completion in-between each command?

This issue is found on IMX8MN-EVK, uSDHC controller. We end up polling for 
busy-completion in-between each command.

I print some log during secure erasing:
Without this patch
[  126.760429] mmc2: starting CMD35 arg 01294000 flags 00000095
[  126.766530] mmc2: starting CMD36 arg 01295bff flags 00000095
[  126.772246] mmc2: starting CMD38 arg 80000000 flags 00000095
[  126.777988] mmc2: mmc_poll_for_busy
[  128.616245] mmc2: erase operation completes
[  128.628511] mmc2: starting CMD35 arg 01295c00 flags 00000095
[  128.634293] mmc2: starting CMD36 arg 012977ff flags 00000095
[  128.640089] mmc2: starting CMD38 arg 80000000 flags 00000095
[  128.645811] mmc2: mmc_poll_for_busy
[  130.456184] mmc2: erase operation completes
[  130.468390] mmc2: starting CMD35 arg 01297800 flags 00000095
[  130.474160] mmc2: starting CMD36 arg 012993ff flags 00000095
[  130.479928] mmc2: starting CMD38 arg 80000000 flags 00000095
[  130.485798] mmc2: mmc_poll_for_busy
[  132.192309] mmc2: erase operation completes
...

Apply this patch
[  296.480818] mmc2: starting CMD35 arg 01294000 flags 00000095
[  296.487219] mmc2: starting CMD36 arg 01493fff flags 00000095
[  296.492995] mmc2: starting CMD38 arg 80000000 flags 00000095
[  296.498999] mmc2: mmc_poll_for_busy
[  298.712865] mmc2: erase operation completes

Regards,
Luke
> 
> Kind regards
> Uffe
> 
> >
> > ---
> > Changes in v2:
> > - Rebased on v6.19-rc1 as requested
> > - Cover letter: terminology fix (command -> operation)
> > ---
> >
> > Luke Wang (2):
> >   block: decouple secure erase size limit from discard size limit
> >   mmc: add quirk to optimize certain Kingston eMMC secure erase/trim
> >     performance
> >
> >  block/blk-merge.c         | 9 +++++++--
> >  block/blk.h               | 6 +++++-
> >  drivers/mmc/core/card.h   | 5 +++++
> >  drivers/mmc/core/queue.c  | 9 +++++++--
> >  drivers/mmc/core/quirks.h | 9 +++++++++
> >  include/linux/mmc/card.h  | 1 +
> >  6 files changed, 34 insertions(+), 5 deletions(-)
> >
> > --
> > 2.34.1
> >

Re: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Christoph Hellwig]

On Tue, Dec 16, 2025 at 10:02:49AM +0000, Luke Wang wrote:
> In fact, secure erase does not guarantee that data is physically
> erased.

It can't.  Given how Flash storage works there is no way to actually
securely erase data on a per-LBA range basis. 

> And the eMMC 5.1 Spec:
> "NOTE Secure Erase is included for backwards compatibility. New system level implementations
> (based on v4.51 devices and beyond) should use Erase combined with Sanitize instead of secure erase."

And this is 100% correct.  Only a device-level Sanitize operation
can do meaningful erasure of data on Flash based media (or modern
HDDs with all the remapping they do for that matter).

Re: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Ulf Hansson]

On Tue, 16 Dec 2025 at 11:02, Luke Wang <ziniu.wang_1@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> > Sent: Monday, December 15, 2025 11:38 PM
> > To: Luke Wang <ziniu.wang_1@nxp.com>
> > Cc: axboe@kernel.dk; linux-block@vger.kernel.org; linux-
> > mmc@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev
> > Subject: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for
> > certain Kingston eMMC devices
> >
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report
> > this email' button
> >
> >
> > On Mon, 15 Dec 2025 at 11:18, <ziniu.wang_1@nxp.com> wrote:
> > >
> > > From: Luke Wang <ziniu.wang_1@nxp.com>
> > >
> > > This patch series optimize secure erase performance for certain Kingston
> > > eMMC devices (IY2964 and IB2932) that take a fixed ~2 seconds per secure
> > > erase operation regardless of size.
> >
> > Well, that sounds to me like the eMMC isn't really erasing the blocks.
> > I wonder how "secure" this is in practice.
>
> Compared to other eMMC, 2 second secure erase time for 1GB is reasonable.
>
> Using the default 3.5MB secure erase chunk, the total time spent secure erasing 1GB:
> Sandisk SDINBDG4-32G-I 0.8s
> Micron MTFC32GAKAEEF-AIT 4.7s
> Longsys FEMDNN032G-C9A55 0.6s
>
> In fact, secure erase does not guarantee that data is physically erased. We previously encountered
> an issue with long secure trim times on the MTFC32GAKAEEF-AIT eMMC, and got confirmation
> from Micron:
> "Secure Erase (0x80000000) is treated as a simple Erase (0x00000000), while Secure
> Trim (0x80000001 + 0x80008000) and Trim (0x00000001) are treated differently. So, it is
> possible that Secure Trim really is the heaviest possible erase operation for the FW to execute. "
>
> And the eMMC 5.1 Spec:
> "NOTE Secure Erase is included for backwards compatibility. New system level implementations
> (based on v4.51 devices and beyond) should use Erase combined with Sanitize instead of secure erase."

Right, thanks for clarifying this! I do recall the complexity around this now.

>
> >
> > >
> > > Currently, a 1GB secure erase requires ~300 operations (limited by max
> > > discard size), taking ~10 minutes. With these changes, the same secure
> > > erase completes in a single operation, reducing time to just 2 seconds.
> >
> > Hmm, is the problem really the size or is it the timeout? Why does 300
> > operations to erase 1GB take ~10 minutes?
>
> I think the problem is caused by the fact that this Kingston eMMC secure erase
> small chunk need ~2 second. In contrast, other eMMC secure erase small chunk
> only take tens of milliseconds.

Okay! So it looks like using a card quirk, something along what you
propose in patch2 could make sense. I will have a closer look.

>
> Also, the calculated max discard is too small. For the I.MX8MN USBHC controller,
> host->max_busy_timeout is 2684ms, and the calculated max discard is always
> card->pref_erase - 1, which is 3.5MB.

I see, so regular REQ_OP_DISCARDs are suffering from similar problems
that are taking a very long time to complete?

Are you planning to make a similar card quirk for discards or what do
you have in mind?

>
> >
> > Can you please elaborate what happens on the mmc host driver level for
> > each operation. What mmc host driver/controller is being used? Does it
> > support MMC_CAP_WAIT_WHILE_BUSY or do we end up polling for
> > busy-completion in-between each command?
>
> This issue is found on IMX8MN-EVK, uSDHC controller. We end up polling for
> busy-completion in-between each command.
>
> I print some log during secure erasing:
> Without this patch
> [  126.760429] mmc2: starting CMD35 arg 01294000 flags 00000095
> [  126.766530] mmc2: starting CMD36 arg 01295bff flags 00000095
> [  126.772246] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  126.777988] mmc2: mmc_poll_for_busy
> [  128.616245] mmc2: erase operation completes
> [  128.628511] mmc2: starting CMD35 arg 01295c00 flags 00000095
> [  128.634293] mmc2: starting CMD36 arg 012977ff flags 00000095
> [  128.640089] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  128.645811] mmc2: mmc_poll_for_busy
> [  130.456184] mmc2: erase operation completes
> [  130.468390] mmc2: starting CMD35 arg 01297800 flags 00000095
> [  130.474160] mmc2: starting CMD36 arg 012993ff flags 00000095
> [  130.479928] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  130.485798] mmc2: mmc_poll_for_busy
> [  132.192309] mmc2: erase operation completes
> ...
>
> Apply this patch
> [  296.480818] mmc2: starting CMD35 arg 01294000 flags 00000095
> [  296.487219] mmc2: starting CMD36 arg 01493fff flags 00000095
> [  296.492995] mmc2: starting CMD38 arg 80000000 flags 00000095
> [  296.498999] mmc2: mmc_poll_for_busy
> [  298.712865] mmc2: erase operation completes

Thanks for sharing the log, much appreciated!

Just to double check, I assume that you have verified that the
busy-polling works as expected on your HW? The reason for asking is
that we have seen problems with this several times in the past, on
other HWs.

Kind regards
Uffe

RE: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for certain Kingston eMMC devices

[Luke Wang]

> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@linaro.org>
> Sent: Tuesday, December 16, 2025 8:15 PM
> To: Luke Wang <ziniu.wang_1@nxp.com>
> Cc: axboe@kernel.dk; linux-block@vger.kernel.org; linux-mmc@vger.kernel.org;
> linux-kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for
> certain Kingston eMMC devices
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> On Tue, 16 Dec 2025 at 11:02, Luke Wang <ziniu.wang_1@nxp.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Ulf Hansson <ulf.hansson@linaro.org>
> > > Sent: Monday, December 15, 2025 11:38 PM
> > > To: Luke Wang <ziniu.wang_1@nxp.com>
> > > Cc: axboe@kernel.dk; linux-block@vger.kernel.org; linux-
> > > mmc@vger.kernel.org; linux-kernel@vger.kernel.org; imx@lists.linux.dev
> > > Subject: [EXT] Re: [PATCH v2 0/2] Optimize secure erase performance for
> > > certain Kingston eMMC devices
> > >
> > > Caution: This is an external email. Please take care when clicking links or
> > > opening attachments. When in doubt, report the message using the 'Report
> > > this email' button
> > >
> > >
> > > On Mon, 15 Dec 2025 at 11:18, <ziniu.wang_1@nxp.com> wrote:
> > > >
> > > > From: Luke Wang <ziniu.wang_1@nxp.com>
> > > >
> > > > This patch series optimize secure erase performance for certain Kingston
> > > > eMMC devices (IY2964 and IB2932) that take a fixed ~2 seconds per
> secure
> > > > erase operation regardless of size.
> > >
> > > Well, that sounds to me like the eMMC isn't really erasing the blocks.
> > > I wonder how "secure" this is in practice.
> >
> > Compared to other eMMC, 2 second secure erase time for 1GB is reasonable.
> >
> > Using the default 3.5MB secure erase chunk, the total time spent secure
> erasing 1GB:
> > Sandisk SDINBDG4-32G-I 0.8s
> > Micron MTFC32GAKAEEF-AIT 4.7s
> > Longsys FEMDNN032G-C9A55 0.6s
> >
> > In fact, secure erase does not guarantee that data is physically erased. We
> previously encountered
> > an issue with long secure trim times on the MTFC32GAKAEEF-AIT eMMC, and
> got confirmation
> > from Micron:
> > "Secure Erase (0x80000000) is treated as a simple Erase (0x00000000), while
> Secure
> > Trim (0x80000001 + 0x80008000) and Trim (0x00000001) are treated
> differently. So, it is
> > possible that Secure Trim really is the heaviest possible erase operation for
> the FW to execute. "
> >
> > And the eMMC 5.1 Spec:
> > "NOTE Secure Erase is included for backwards compatibility. New system level
> implementations
> > (based on v4.51 devices and beyond) should use Erase combined with Sanitize
> instead of secure erase."
> 
> Right, thanks for clarifying this! I do recall the complexity around this now.
> 
> >
> > >
> > > >
> > > > Currently, a 1GB secure erase requires ~300 operations (limited by max
> > > > discard size), taking ~10 minutes. With these changes, the same secure
> > > > erase completes in a single operation, reducing time to just 2 seconds.
> > >
> > > Hmm, is the problem really the size or is it the timeout? Why does 300
> > > operations to erase 1GB take ~10 minutes?
> >
> > I think the problem is caused by the fact that this Kingston eMMC secure
> erase
> > small chunk need ~2 second. In contrast, other eMMC secure erase small
> chunk
> > only take tens of milliseconds.
> 
> Okay! So it looks like using a card quirk, something along what you
> propose in patch2 could make sense. I will have a closer look.
> 
> >
> > Also, the calculated max discard is too small. For the I.MX8MN USBHC
> controller,
> > host->max_busy_timeout is 2684ms, and the calculated max discard is always
> > card->pref_erase - 1, which is 3.5MB.
> 
> I see, so regular REQ_OP_DISCARDs are suffering from similar problems
> that are taking a very long time to complete?
> 
> Are you planning to make a similar card quirk for discards or what do
> you have in mind?

regular REQ_OP_DISCARDs also use 3.5MB size on I.MX. It will not take long
time to complete on this Kingston eMMC. This Kingston eMMC seems to treat
secure erase and regular erase different.

> 
> >
> > >
> > > Can you please elaborate what happens on the mmc host driver level for
> > > each operation. What mmc host driver/controller is being used? Does it
> > > support MMC_CAP_WAIT_WHILE_BUSY or do we end up polling for
> > > busy-completion in-between each command?
> >
> > This issue is found on IMX8MN-EVK, uSDHC controller. We end up polling for
> > busy-completion in-between each command.
> >
> > I print some log during secure erasing:
> > Without this patch
> > [  126.760429] mmc2: starting CMD35 arg 01294000 flags 00000095
> > [  126.766530] mmc2: starting CMD36 arg 01295bff flags 00000095
> > [  126.772246] mmc2: starting CMD38 arg 80000000 flags 00000095
> > [  126.777988] mmc2: mmc_poll_for_busy
> > [  128.616245] mmc2: erase operation completes
> > [  128.628511] mmc2: starting CMD35 arg 01295c00 flags 00000095
> > [  128.634293] mmc2: starting CMD36 arg 012977ff flags 00000095
> > [  128.640089] mmc2: starting CMD38 arg 80000000 flags 00000095
> > [  128.645811] mmc2: mmc_poll_for_busy
> > [  130.456184] mmc2: erase operation completes
> > [  130.468390] mmc2: starting CMD35 arg 01297800 flags 00000095
> > [  130.474160] mmc2: starting CMD36 arg 012993ff flags 00000095
> > [  130.479928] mmc2: starting CMD38 arg 80000000 flags 00000095
> > [  130.485798] mmc2: mmc_poll_for_busy
> > [  132.192309] mmc2: erase operation completes
> > ...
> >
> > Apply this patch
> > [  296.480818] mmc2: starting CMD35 arg 01294000 flags 00000095
> > [  296.487219] mmc2: starting CMD36 arg 01493fff flags 00000095
> > [  296.492995] mmc2: starting CMD38 arg 80000000 flags 00000095
> > [  296.498999] mmc2: mmc_poll_for_busy
> > [  298.712865] mmc2: erase operation completes
> 
> Thanks for sharing the log, much appreciated!
> 
> Just to double check, I assume that you have verified that the
> busy-polling works as expected on your HW? The reason for asking is
> that we have seen problems with this several times in the past, on
> other HWs.

Yes, busy-polling works as expected on I.MX

Regards,
Luke
> 
> Kind regards
> Uffe