[PATCH v4 0/9] Add SDUC Support

[PATCH v4 0/9] Add SDUC Support

[Avri Altman]

Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.  Those
cards support capacity larger than 2TB and up to including 128TB. Thus,
the address range of the card expands beyond the 32-bit command
argument. To that end, a new command - CMD22 is defined, to carry the
extra 6-bit upper part of the 38-bit block address that enable access to
128TB memory space.

SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – Same
as SDXC.

The spec defines several extensions/modifications to the current SDXC
cards, which we address in patches 1 - 10.  Otherwise requirements are
out-of-scope of this change.  Specifically, CMDQ (CMD44+CMD45), and
Extension for Video Speed Class (CMD20).

First publication of SDUC was in [1].  This series was developed and
tested separately from [1] and does not borrow from it.

[1] https://lwn.net/Articles/982566/

---
Changes in v4:
 - Squash patches 1 & 2 (Ulf)
 - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
 - Use card state instead of caps2 (Ricky & Ulf)
 - Switch patches 5 & 6 (Ulf)

Changes in v3:
 - Some more kernel test robot fixes
 - Fix a typo in a commit log (Ricky WU)
 - Fix ACMD22 returned value
 - Add 'Tested-by' tag for the whole series (Ricky WU)

Changes in v2:
 - Attend kernel test robot warnings

---

Avri Altman (9):
  mmc: sd: SDUC Support Recognition
  mmc: sd: Add Extension memory addressing
  mmc: core: Add open-ended Ext memory addressing
  mmc: core: Add close-ended Ext memory addressing
  mmc: host: Always use manual-cmd23 in SDUC
  mmc: host: Add close-ended Ext memory addressing
  mmc: core: Allow mmc erase to carry large addresses
  mmc: core: Add Ext memory addressing for erase
  mmc: core: Adjust ACMD22 to SDUC

 drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
 drivers/mmc/core/bus.c    |  4 ++-
 drivers/mmc/core/card.h   |  3 ++
 drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++-----------
 drivers/mmc/core/core.h   | 14 +++++++--
 drivers/mmc/core/queue.h  |  1 +
 drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
 drivers/mmc/core/sd.h     |  2 +-
 drivers/mmc/core/sd_ops.c | 16 ++++++++++
 drivers/mmc/core/sd_ops.h |  1 +
 drivers/mmc/core/sdio.c   |  2 +-
 drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
 include/linux/mmc/card.h  |  2 +-
 include/linux/mmc/core.h  |  1 +
 include/linux/mmc/sd.h    |  4 +++
 15 files changed, 195 insertions(+), 50 deletions(-)

-- 
2.25.1

[PATCH v4 1/9] mmc: sd: SDUC Support Recognition

[Avri Altman]

Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.  Those
cards support capacity larger than 2TB and up to including 128TB.

ACMD41 was extended to support the host-card handshake during
initialization.  The card expects that the HCS & HO2T bits to be set in
the command argument, and sets the applicable bits in the R3 returned
response.  On the contrary, if a SDUC card is inserted to a
non-supporting host, it will never respond to this ACMD41 until
eventually, the host will timed out and give up.

Also, add SD CSD version 3.0 - designated for SDUC, and properly parse
the csd register as the c_size field got expanded to 28 bits.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/bus.c   |  4 +++-
 drivers/mmc/core/card.h  |  3 +++
 drivers/mmc/core/sd.c    | 36 ++++++++++++++++++++++++------------
 drivers/mmc/core/sd.h    |  2 +-
 drivers/mmc/core/sdio.c  |  2 +-
 include/linux/mmc/card.h |  2 +-
 include/linux/mmc/sd.h   |  1 +
 7 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 0ddaee0eae54..30763b342bd3 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -321,7 +321,9 @@ int mmc_add_card(struct mmc_card *card)
 	case MMC_TYPE_SD:
 		type = "SD";
 		if (mmc_card_blockaddr(card)) {
-			if (mmc_card_ext_capacity(card))
+			if (mmc_card_ult_capacity(card))
+				type = "SDUC";
+			else if (mmc_card_ext_capacity(card))
 				type = "SDXC";
 			else
 				type = "SDHC";
diff --git a/drivers/mmc/core/card.h b/drivers/mmc/core/card.h
index b7754a1b8d97..64dcb463a4f4 100644
--- a/drivers/mmc/core/card.h
+++ b/drivers/mmc/core/card.h
@@ -23,6 +23,7 @@
 #define MMC_CARD_SDXC		(1<<3)		/* card is SDXC */
 #define MMC_CARD_REMOVED	(1<<4)		/* card has been removed */
 #define MMC_STATE_SUSPENDED	(1<<5)		/* card is suspended */
+#define MMC_CARD_SDUC		(1<<6)		/* card is SDUC */
 
 #define mmc_card_present(c)	((c)->state & MMC_STATE_PRESENT)
 #define mmc_card_readonly(c)	((c)->state & MMC_STATE_READONLY)
@@ -30,11 +31,13 @@
 #define mmc_card_ext_capacity(c) ((c)->state & MMC_CARD_SDXC)
 #define mmc_card_removed(c)	((c) && ((c)->state & MMC_CARD_REMOVED))
 #define mmc_card_suspended(c)	((c)->state & MMC_STATE_SUSPENDED)
+#define mmc_card_ult_capacity(c) ((c)->state & MMC_CARD_SDUC)
 
 #define mmc_card_set_present(c)	((c)->state |= MMC_STATE_PRESENT)
 #define mmc_card_set_readonly(c) ((c)->state |= MMC_STATE_READONLY)
 #define mmc_card_set_blockaddr(c) ((c)->state |= MMC_STATE_BLOCKADDR)
 #define mmc_card_set_ext_capacity(c) ((c)->state |= MMC_CARD_SDXC)
+#define mmc_card_set_ult_capacity(c) ((c)->state |= MMC_CARD_SDUC)
 #define mmc_card_set_removed(c) ((c)->state |= MMC_CARD_REMOVED)
 #define mmc_card_set_suspended(c) ((c)->state |= MMC_STATE_SUSPENDED)
 #define mmc_card_clr_suspended(c) ((c)->state &= ~MMC_STATE_SUSPENDED)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 1c8148cdda50..616bd7d5915d 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -113,7 +113,7 @@ void mmc_decode_cid(struct mmc_card *card)
 /*
  * Given a 128-bit response, decode to our card CSD structure.
  */
-static int mmc_decode_csd(struct mmc_card *card)
+static int mmc_decode_csd(struct mmc_card *card, bool is_sduc)
 {
 	struct mmc_csd *csd = &card->csd;
 	unsigned int e, m, csd_struct;
@@ -157,9 +157,10 @@ static int mmc_decode_csd(struct mmc_card *card)
 			mmc_card_set_readonly(card);
 		break;
 	case 1:
+	case 2:
 		/*
-		 * This is a block-addressed SDHC or SDXC card. Most
-		 * interesting fields are unused and have fixed
+		 * This is a block-addressed SDHC, SDXC or SDUC card.
+		 * Most interesting fields are unused and have fixed
 		 * values. To avoid getting tripped by buggy cards,
 		 * we assume those fixed values ourselves.
 		 */
@@ -172,14 +173,19 @@ static int mmc_decode_csd(struct mmc_card *card)
 		e = UNSTUFF_BITS(resp, 96, 3);
 		csd->max_dtr	  = tran_exp[e] * tran_mant[m];
 		csd->cmdclass	  = UNSTUFF_BITS(resp, 84, 12);
-		csd->c_size	  = UNSTUFF_BITS(resp, 48, 22);
 
-		/* SDXC cards have a minimum C_SIZE of 0x00FFFF */
-		if (csd->c_size >= 0xFFFF)
+		if (csd_struct == 1)
+			m = UNSTUFF_BITS(resp, 48, 22);
+		else
+			m = UNSTUFF_BITS(resp, 48, 28);
+		csd->c_size = m;
+
+		if (csd->c_size >= 0x400000 && is_sduc)
+			mmc_card_set_ult_capacity(card);
+		else if (csd->c_size >= 0xFFFF)
 			mmc_card_set_ext_capacity(card);
 
-		m = UNSTUFF_BITS(resp, 48, 22);
-		csd->capacity     = (1 + m) << 10;
+		csd->capacity     = (1 + (typeof(sector_t))m) << 10;
 
 		csd->read_blkbits = 9;
 		csd->read_partial = 0;
@@ -840,8 +846,11 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32 *cid, u32 *rocr)
 	 * block-addressed SDHC cards.
 	 */
 	err = mmc_send_if_cond(host, ocr);
-	if (!err)
+	if (!err) {
 		ocr |= SD_OCR_CCS;
+		/* Set HO2T as well - SDUC card won't respond otherwise */
+		ocr |= SD_OCR_2T;
+	}
 
 	/*
 	 * If the host supports one of UHS-I modes, request the card
@@ -886,7 +895,7 @@ int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32 *cid, u32 *rocr)
 	return err;
 }
 
-int mmc_sd_get_csd(struct mmc_card *card)
+int mmc_sd_get_csd(struct mmc_card *card, bool is_sduc)
 {
 	int err;
 
@@ -897,7 +906,7 @@ int mmc_sd_get_csd(struct mmc_card *card)
 	if (err)
 		return err;
 
-	err = mmc_decode_csd(card);
+	err = mmc_decode_csd(card, is_sduc);
 	if (err)
 		return err;
 
@@ -1452,7 +1461,10 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
 	}
 
 	if (!oldcard) {
-		err = mmc_sd_get_csd(card);
+		u32 sduc_arg = SD_OCR_CCS | SD_OCR_2T;
+		bool is_sduc = (rocr & sduc_arg) == sduc_arg;
+
+		err = mmc_sd_get_csd(card, is_sduc);
 		if (err)
 			goto free_card;
 
diff --git a/drivers/mmc/core/sd.h b/drivers/mmc/core/sd.h
index fe6dd46927a4..7e8beface2ca 100644
--- a/drivers/mmc/core/sd.h
+++ b/drivers/mmc/core/sd.h
@@ -10,7 +10,7 @@ struct mmc_host;
 struct mmc_card;
 
 int mmc_sd_get_cid(struct mmc_host *host, u32 ocr, u32 *cid, u32 *rocr);
-int mmc_sd_get_csd(struct mmc_card *card);
+int mmc_sd_get_csd(struct mmc_card *card, bool is_sduc);
 void mmc_decode_cid(struct mmc_card *card);
 int mmc_sd_setup_card(struct mmc_host *host, struct mmc_card *card,
 	bool reinit);
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 4fb247fde5c0..9566837c9848 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -769,7 +769,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 	 * Read CSD, before selecting the card
 	 */
 	if (!oldcard && mmc_card_sd_combo(card)) {
-		err = mmc_sd_get_csd(card);
+		err = mmc_sd_get_csd(card, false);
 		if (err)
 			goto remove;
 
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index f34407cc2788..f39bce322365 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -35,7 +35,7 @@ struct mmc_csd {
 	unsigned int		wp_grp_size;
 	unsigned int		read_blkbits;
 	unsigned int		write_blkbits;
-	unsigned int		capacity;
+	sector_t		capacity;
 	unsigned int		read_partial:1,
 				read_misalign:1,
 				write_partial:1,
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 6727576a8755..865cc0ca8543 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -36,6 +36,7 @@
 /* OCR bit definitions */
 #define SD_OCR_S18R		(1 << 24)    /* 1.8V switching request */
 #define SD_ROCR_S18A		SD_OCR_S18R  /* 1.8V switching accepted by card */
+#define SD_OCR_2T		(1 << 27)    /* HO2T/CO2T - SDUC support */
 #define SD_OCR_XPC		(1 << 28)    /* SDXC power control */
 #define SD_OCR_CCS		(1 << 30)    /* Card Capacity Status */
 
-- 
2.25.1

[PATCH v4 2/9] mmc: sd: Add Extension memory addressing

[Avri Altman]

SDUC memory addressing spans beyond 2TB and up to 128TB.  Therefore, 38
bits are required to access the entire memory space of all sectors.
Those extra 6 bits are to be carried by CMD22 prior of sending
read/write/erase commands: CMD17, CMD18, CMD24, CMD25, CMD32, and CMD33.

CMD22 will carry the higher order 6 bits, and must precedes any of the
above commands even if it targets sector < 2TB.

No error related to address or length is indicated in CMD22 but rather
in the read/write command itself.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/sd_ops.c | 16 ++++++++++++++++
 drivers/mmc/core/sd_ops.h |  1 +
 include/linux/mmc/sd.h    |  3 +++
 3 files changed, 20 insertions(+)

diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
index 8b9b34286ef3..780c5dd7266f 100644
--- a/drivers/mmc/core/sd_ops.c
+++ b/drivers/mmc/core/sd_ops.c
@@ -16,6 +16,7 @@
 #include <linux/mmc/sd.h>
 
 #include "core.h"
+#include "card.h"
 #include "sd_ops.h"
 #include "mmc_ops.h"
 
@@ -188,6 +189,21 @@ int mmc_send_app_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
 	return 0;
 }
 
+int mmc_send_ext_addr(struct mmc_host *host, sector_t addr)
+{
+	struct mmc_command cmd = {
+		.opcode = SD_ADDR_EXT,
+		.arg = (u32)((addr >> 32) & 0x3F),
+		.flags = MMC_RSP_R1 | MMC_CMD_AC,
+	};
+
+	if (!mmc_card_ult_capacity(host->card))
+		return 0;
+
+	return mmc_wait_for_cmd(host, &cmd, 0);
+}
+EXPORT_SYMBOL_GPL(mmc_send_ext_addr);
+
 static int __mmc_send_if_cond(struct mmc_host *host, u32 ocr, u8 pcie_bits,
 			      u32 *resp)
 {
diff --git a/drivers/mmc/core/sd_ops.h b/drivers/mmc/core/sd_ops.h
index 7667fc223b74..462efd43acfa 100644
--- a/drivers/mmc/core/sd_ops.h
+++ b/drivers/mmc/core/sd_ops.h
@@ -21,6 +21,7 @@ int mmc_send_relative_addr(struct mmc_host *host, unsigned int *rca);
 int mmc_app_send_scr(struct mmc_card *card);
 int mmc_app_sd_status(struct mmc_card *card, void *ssr);
 int mmc_app_cmd(struct mmc_host *host, struct mmc_card *card);
+int mmc_send_ext_addr(struct mmc_host *host, sector_t addr);
 
 #endif
 
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 865cc0ca8543..af5fc70e09a2 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -15,6 +15,9 @@
 #define SD_SEND_IF_COND           8   /* bcr  [11:0] See below   R7  */
 #define SD_SWITCH_VOLTAGE         11  /* ac                      R1  */
 
+/* Class 2 */
+#define SD_ADDR_EXT		 22   /* ac   [5:0]              R1  */
+
   /* class 10 */
 #define SD_SWITCH                 6   /* adtc [31:0] See below   R1  */
 
-- 
2.25.1

Re: [PATCH v4 2/9] mmc: sd: Add Extension memory addressing

[Adrian Hunter]

On 25/08/24 10:41, Avri Altman wrote:
> SDUC memory addressing spans beyond 2TB and up to 128TB.  Therefore, 38
> bits are required to access the entire memory space of all sectors.
> Those extra 6 bits are to be carried by CMD22 prior of sending
> read/write/erase commands: CMD17, CMD18, CMD24, CMD25, CMD32, and CMD33.
> 
> CMD22 will carry the higher order 6 bits, and must precedes any of the
> above commands even if it targets sector < 2TB.
> 
> No error related to address or length is indicated in CMD22 but rather
> in the read/write command itself.
> 
> Tested-by: Ricky WU <ricky_wu@realtek.com>
> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> ---
>  drivers/mmc/core/sd_ops.c | 16 ++++++++++++++++
>  drivers/mmc/core/sd_ops.h |  1 +
>  include/linux/mmc/sd.h    |  3 +++
>  3 files changed, 20 insertions(+)
> 
> diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
> index 8b9b34286ef3..780c5dd7266f 100644
> --- a/drivers/mmc/core/sd_ops.c
> +++ b/drivers/mmc/core/sd_ops.c
> @@ -16,6 +16,7 @@
>  #include <linux/mmc/sd.h>
>  
>  #include "core.h"
> +#include "card.h"
>  #include "sd_ops.h"
>  #include "mmc_ops.h"
>  
> @@ -188,6 +189,21 @@ int mmc_send_app_op_cond(struct mmc_host *host, u32 ocr, u32 *rocr)
>  	return 0;
>  }
>  
> +int mmc_send_ext_addr(struct mmc_host *host, sector_t addr)
> +{
> +	struct mmc_command cmd = {
> +		.opcode = SD_ADDR_EXT,
> +		.arg = (u32)((addr >> 32) & 0x3F),

If addr were outside the acceptable range, then the command
should fail, which is what we want, so better to leave out
the mask i.e.

		.arg = (u32)(addr >> 32),


> +		.flags = MMC_RSP_R1 | MMC_CMD_AC,
> +	};
> +
> +	if (!mmc_card_ult_capacity(host->card))
> +		return 0;
> +
> +	return mmc_wait_for_cmd(host, &cmd, 0);
> +}
> +EXPORT_SYMBOL_GPL(mmc_send_ext_addr);
> +
>  static int __mmc_send_if_cond(struct mmc_host *host, u32 ocr, u8 pcie_bits,
>  			      u32 *resp)
>  {
> diff --git a/drivers/mmc/core/sd_ops.h b/drivers/mmc/core/sd_ops.h
> index 7667fc223b74..462efd43acfa 100644
> --- a/drivers/mmc/core/sd_ops.h
> +++ b/drivers/mmc/core/sd_ops.h
> @@ -21,6 +21,7 @@ int mmc_send_relative_addr(struct mmc_host *host, unsigned int *rca);
>  int mmc_app_send_scr(struct mmc_card *card);
>  int mmc_app_sd_status(struct mmc_card *card, void *ssr);
>  int mmc_app_cmd(struct mmc_host *host, struct mmc_card *card);
> +int mmc_send_ext_addr(struct mmc_host *host, sector_t addr);
>  
>  #endif
>  
> diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
> index 865cc0ca8543..af5fc70e09a2 100644
> --- a/include/linux/mmc/sd.h
> +++ b/include/linux/mmc/sd.h
> @@ -15,6 +15,9 @@
>  #define SD_SEND_IF_COND           8   /* bcr  [11:0] See below   R7  */
>  #define SD_SWITCH_VOLTAGE         11  /* ac                      R1  */
>  
> +/* Class 2 */
> +#define SD_ADDR_EXT		 22   /* ac   [5:0]              R1  */
> +
>    /* class 10 */
>  #define SD_SWITCH                 6   /* adtc [31:0] See below   R1  */
>  

RE: [PATCH v4 2/9] mmc: sd: Add Extension memory addressing

[Avri Altman]

> 
> On 25/08/24 10:41, Avri Altman wrote:
> > SDUC memory addressing spans beyond 2TB and up to 128TB.  Therefore,
> > 38 bits are required to access the entire memory space of all sectors.
> > Those extra 6 bits are to be carried by CMD22 prior of sending
> > read/write/erase commands: CMD17, CMD18, CMD24, CMD25, CMD32,
> and CMD33.
> >
> > CMD22 will carry the higher order 6 bits, and must precedes any of the
> > above commands even if it targets sector < 2TB.
> >
> > No error related to address or length is indicated in CMD22 but rather
> > in the read/write command itself.
> >
> > Tested-by: Ricky WU <ricky_wu@realtek.com>
> > Signed-off-by: Avri Altman <avri.altman@wdc.com>
> > ---
> >  drivers/mmc/core/sd_ops.c | 16 ++++++++++++++++
> > drivers/mmc/core/sd_ops.h |  1 +
> >  include/linux/mmc/sd.h    |  3 +++
> >  3 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
> > index 8b9b34286ef3..780c5dd7266f 100644
> > --- a/drivers/mmc/core/sd_ops.c
> > +++ b/drivers/mmc/core/sd_ops.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/mmc/sd.h>
> >
> >  #include "core.h"
> > +#include "card.h"
> >  #include "sd_ops.h"
> >  #include "mmc_ops.h"
> >
> > @@ -188,6 +189,21 @@ int mmc_send_app_op_cond(struct mmc_host
> *host, u32 ocr, u32 *rocr)
> >       return 0;
> >  }
> >
> > +int mmc_send_ext_addr(struct mmc_host *host, sector_t addr) {
> > +     struct mmc_command cmd = {
> > +             .opcode = SD_ADDR_EXT,
> > +             .arg = (u32)((addr >> 32) & 0x3F),
> 
> If addr were outside the acceptable range, then the command should fail,
> which is what we want, so better to leave out the mask i.e.
> 
>                 .arg = (u32)(addr >> 32),
Done.

Thanks,
Avri

> 
> 
> > +             .flags = MMC_RSP_R1 | MMC_CMD_AC,
> > +     };
> > +
> > +     if (!mmc_card_ult_capacity(host->card))
> > +             return 0;
> > +
> > +     return mmc_wait_for_cmd(host, &cmd, 0); }
> > +EXPORT_SYMBOL_GPL(mmc_send_ext_addr);
> > +
> >  static int __mmc_send_if_cond(struct mmc_host *host, u32 ocr, u8
> pcie_bits,
> >                             u32 *resp)  { diff --git
> > a/drivers/mmc/core/sd_ops.h b/drivers/mmc/core/sd_ops.h index
> > 7667fc223b74..462efd43acfa 100644
> > --- a/drivers/mmc/core/sd_ops.h
> > +++ b/drivers/mmc/core/sd_ops.h
> > @@ -21,6 +21,7 @@ int mmc_send_relative_addr(struct mmc_host *host,
> > unsigned int *rca);  int mmc_app_send_scr(struct mmc_card *card);  int
> > mmc_app_sd_status(struct mmc_card *card, void *ssr);  int
> > mmc_app_cmd(struct mmc_host *host, struct mmc_card *card);
> > +int mmc_send_ext_addr(struct mmc_host *host, sector_t addr);
> >
> >  #endif
> >
> > diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h index
> > 865cc0ca8543..af5fc70e09a2 100644
> > --- a/include/linux/mmc/sd.h
> > +++ b/include/linux/mmc/sd.h
> > @@ -15,6 +15,9 @@
> >  #define SD_SEND_IF_COND           8   /* bcr  [11:0] See below   R7  */
> >  #define SD_SWITCH_VOLTAGE         11  /* ac                      R1  */
> >
> > +/* Class 2 */
> > +#define SD_ADDR_EXT           22   /* ac   [5:0]              R1  */
> > +
> >    /* class 10 */
> >  #define SD_SWITCH                 6   /* adtc [31:0] See below   R1  */
> >

[PATCH v4 3/9] mmc: core: Add open-ended Ext memory addressing

[Avri Altman]

For open-ended read/write - just send CMD22 before issuing the command.
While at it, make sure that the rw command arg is properly casting the
lower 32 bits, as it can be larger now.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/block.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 2c9963248fcb..8816b3f0a312 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -180,6 +180,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 static void mmc_blk_hsq_req_done(struct mmc_request *mrq);
 static int mmc_spi_err_check(struct mmc_card *card);
 static int mmc_blk_busy_cb(void *cb_data, bool *busy);
+static int mmc_blk_wait_for_idle(struct mmc_queue *mq, struct mmc_host *host);
 
 static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
 {
@@ -1664,7 +1665,7 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 
 	brq->mrq.cmd = &brq->cmd;
 
-	brq->cmd.arg = blk_rq_pos(req);
+	brq->cmd.arg = blk_rq_pos(req) & 0xFFFFFFFF;
 	if (!mmc_card_blockaddr(card))
 		brq->cmd.arg <<= 9;
 	brq->cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
@@ -1712,6 +1713,9 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 			(do_data_tag ? (1 << 29) : 0);
 		brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
 		brq->mrq.sbc = &brq->sbc;
+	} else if (mmc_card_ult_capacity(card)) {
+		mmc_blk_wait_for_idle(mq, card->host);
+		mmc_send_ext_addr(card->host, blk_rq_pos(req));
 	}
 }
 
-- 
2.25.1

[PATCH v4 4/9] mmc: core: Add close-ended Ext memory addressing

[Avri Altman]

In a multi-block data transfer, CMD23 shall precede CMD22. Prepare CMD22
in advance as an additional extension of the mrq, to be handle by the
host once CMD23 is done.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/block.c |  7 +++++++
 drivers/mmc/core/core.c  | 18 ++++++++++++++++++
 drivers/mmc/core/queue.h |  1 +
 include/linux/mmc/core.h |  1 +
 4 files changed, 27 insertions(+)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 8816b3f0a312..7020a568fb79 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1713,6 +1713,13 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
 			(do_data_tag ? (1 << 29) : 0);
 		brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
 		brq->mrq.sbc = &brq->sbc;
+
+		if (mmc_card_ult_capacity(card)) {
+			brq->ext.opcode = SD_ADDR_EXT;
+			brq->ext.arg = (u32)((blk_rq_pos(req) >> 32) & 0x3F);
+			brq->ext.flags = MMC_RSP_R1 | MMC_CMD_AC;
+			brq->mrq.ext = &brq->ext;
+		}
 	} else if (mmc_card_ult_capacity(card)) {
 		mmc_blk_wait_for_idle(mq, card->host);
 		mmc_send_ext_addr(card->host, blk_rq_pos(req));
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d6c819dd68ed..4808e42d7855 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -184,6 +184,14 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
 				mrq->sbc->resp[2], mrq->sbc->resp[3]);
 		}
 
+		if (mrq->ext) {
+			pr_debug("%s: req done <CMD%u>: %d: %08x %08x %08x %08x\n",
+				 mmc_hostname(host), mrq->ext->opcode,
+				 mrq->ext->error,
+				 mrq->ext->resp[0], mrq->ext->resp[1],
+				 mrq->ext->resp[2], mrq->ext->resp[3]);
+		}
+
 		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x %08x\n",
 			mmc_hostname(host), cmd->opcode, err,
 			cmd->resp[0], cmd->resp[1],
@@ -270,6 +278,12 @@ static void mmc_mrq_pr_debug(struct mmc_host *host, struct mmc_request *mrq,
 			 mrq->sbc->arg, mrq->sbc->flags);
 	}
 
+	if (mrq->ext) {
+		pr_debug("<%s: starting CMD%u arg %08x flags %08x>\n",
+			 mmc_hostname(host), mrq->ext->opcode,
+			 mrq->ext->arg, mrq->ext->flags);
+	}
+
 	if (mrq->cmd) {
 		pr_debug("%s: starting %sCMD%u arg %08x flags %08x\n",
 			 mmc_hostname(host), cqe ? "CQE direct " : "",
@@ -309,6 +323,10 @@ static int mmc_mrq_prep(struct mmc_host *host, struct mmc_request *mrq)
 		mrq->sbc->error = 0;
 		mrq->sbc->mrq = mrq;
 	}
+	if (mrq->ext) {
+		mrq->ext->error = 0;
+		mrq->ext->mrq = mrq;
+	}
 	if (mrq->data) {
 		if (mrq->data->blksz > host->max_blk_size ||
 		    mrq->data->blocks > host->max_blk_count ||
diff --git a/drivers/mmc/core/queue.h b/drivers/mmc/core/queue.h
index 1498840a4ea0..7e191d7f0461 100644
--- a/drivers/mmc/core/queue.h
+++ b/drivers/mmc/core/queue.h
@@ -40,6 +40,7 @@ struct mmc_blk_ioc_data;
 struct mmc_blk_request {
 	struct mmc_request	mrq;
 	struct mmc_command	sbc;
+	struct mmc_command	ext;
 	struct mmc_command	cmd;
 	struct mmc_command	stop;
 	struct mmc_data		data;
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 2c7928a50907..5560e70cb8d4 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -142,6 +142,7 @@ struct mmc_data {
 struct mmc_host;
 struct mmc_request {
 	struct mmc_command	*sbc;		/* SET_BLOCK_COUNT for multiblock */
+	struct mmc_command	*ext;		/* SD_ADDR_EXT for SDUC */
 	struct mmc_command	*cmd;
 	struct mmc_data		*data;
 	struct mmc_command	*stop;
-- 
2.25.1

RE: [PATCH v4 4/9] mmc: core: Add close-ended Ext memory addressing

[Avri Altman]

> In a multi-block data transfer, CMD23 shall precede CMD22. Prepare CMD22
> in advance as an additional extension of the mrq, to be handle by the host
> once CMD23 is done.
I am floundering about the close-ended part of this series.
My main concern is an amid stream of fixes & quirks of bogus hw,
that tends to apply extra logic specifically around acmd12 & acmd23.

Unless someone think it's absolutely necessary to be included,
I would like to drop patches 4, 5, and 6.
What do you think?

Thanks,
Avri

> 
> Tested-by: Ricky WU <ricky_wu@realtek.com>
> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> ---
>  drivers/mmc/core/block.c |  7 +++++++
>  drivers/mmc/core/core.c  | 18 ++++++++++++++++++
> drivers/mmc/core/queue.h |  1 +  include/linux/mmc/core.h |  1 +
>  4 files changed, 27 insertions(+)
> 
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index
> 8816b3f0a312..7020a568fb79 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -1713,6 +1713,13 @@ static void mmc_blk_rw_rq_prep(struct
> mmc_queue_req *mqrq,
>  			(do_data_tag ? (1 << 29) : 0);
>  		brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>  		brq->mrq.sbc = &brq->sbc;
> +
> +		if (mmc_card_ult_capacity(card)) {
> +			brq->ext.opcode = SD_ADDR_EXT;
> +			brq->ext.arg = (u32)((blk_rq_pos(req) >> 32) & 0x3F);
> +			brq->ext.flags = MMC_RSP_R1 | MMC_CMD_AC;
> +			brq->mrq.ext = &brq->ext;
> +		}
>  	} else if (mmc_card_ult_capacity(card)) {
>  		mmc_blk_wait_for_idle(mq, card->host);
>  		mmc_send_ext_addr(card->host, blk_rq_pos(req)); diff --git
> a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
> d6c819dd68ed..4808e42d7855 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -184,6 +184,14 @@ void mmc_request_done(struct mmc_host *host,
> struct mmc_request *mrq)
>  				mrq->sbc->resp[2], mrq->sbc->resp[3]);
>  		}
> 
> +		if (mrq->ext) {
> +			pr_debug("%s: req done <CMD%u>: %d: %08x %08x
> %08x %08x\n",
> +				 mmc_hostname(host), mrq->ext->opcode,
> +				 mrq->ext->error,
> +				 mrq->ext->resp[0], mrq->ext->resp[1],
> +				 mrq->ext->resp[2], mrq->ext->resp[3]);
> +		}
> +
>  		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x
> %08x\n",
>  			mmc_hostname(host), cmd->opcode, err,
>  			cmd->resp[0], cmd->resp[1],
> @@ -270,6 +278,12 @@ static void mmc_mrq_pr_debug(struct mmc_host
> *host, struct mmc_request *mrq,
>  			 mrq->sbc->arg, mrq->sbc->flags);
>  	}
> 
> +	if (mrq->ext) {
> +		pr_debug("<%s: starting CMD%u arg %08x flags %08x>\n",
> +			 mmc_hostname(host), mrq->ext->opcode,
> +			 mrq->ext->arg, mrq->ext->flags);
> +	}
> +
>  	if (mrq->cmd) {
>  		pr_debug("%s: starting %sCMD%u arg %08x flags %08x\n",
>  			 mmc_hostname(host), cqe ? "CQE direct " : "", @@ -
> 309,6 +323,10 @@ static int mmc_mrq_prep(struct mmc_host *host, struct
> mmc_request *mrq)
>  		mrq->sbc->error = 0;
>  		mrq->sbc->mrq = mrq;
>  	}
> +	if (mrq->ext) {
> +		mrq->ext->error = 0;
> +		mrq->ext->mrq = mrq;
> +	}
>  	if (mrq->data) {
>  		if (mrq->data->blksz > host->max_blk_size ||
>  		    mrq->data->blocks > host->max_blk_count || diff --git
> a/drivers/mmc/core/queue.h b/drivers/mmc/core/queue.h index
> 1498840a4ea0..7e191d7f0461 100644
> --- a/drivers/mmc/core/queue.h
> +++ b/drivers/mmc/core/queue.h
> @@ -40,6 +40,7 @@ struct mmc_blk_ioc_data;  struct mmc_blk_request {
>  	struct mmc_request	mrq;
>  	struct mmc_command	sbc;
> +	struct mmc_command	ext;
>  	struct mmc_command	cmd;
>  	struct mmc_command	stop;
>  	struct mmc_data		data;
> diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h index
> 2c7928a50907..5560e70cb8d4 100644
> --- a/include/linux/mmc/core.h
> +++ b/include/linux/mmc/core.h
> @@ -142,6 +142,7 @@ struct mmc_data {
>  struct mmc_host;
>  struct mmc_request {
>  	struct mmc_command	*sbc;		/* SET_BLOCK_COUNT for
> multiblock */
> +	struct mmc_command	*ext;		/* SD_ADDR_EXT for SDUC */
>  	struct mmc_command	*cmd;
>  	struct mmc_data		*data;
>  	struct mmc_command	*stop;
> --
> 2.25.1

Re: [PATCH v4 4/9] mmc: core: Add close-ended Ext memory addressing

[Adrian Hunter]

On 26/08/24 08:32, Avri Altman wrote:
>> In a multi-block data transfer, CMD23 shall precede CMD22. Prepare CMD22
>> in advance as an additional extension of the mrq, to be handle by the host
>> once CMD23 is done.
> I am floundering about the close-ended part of this series.
> My main concern is an amid stream of fixes & quirks of bogus hw,
> that tends to apply extra logic specifically around acmd12 & acmd23.
> 
> Unless someone think it's absolutely necessary to be included,
> I would like to drop patches 4, 5, and 6.
> What do you think?

What are the downsides to supporting open-ended only?

> 
> Thanks,
> Avri
> 
>>
>> Tested-by: Ricky WU <ricky_wu@realtek.com>
>> Signed-off-by: Avri Altman <avri.altman@wdc.com>
>> ---
>>  drivers/mmc/core/block.c |  7 +++++++
>>  drivers/mmc/core/core.c  | 18 ++++++++++++++++++
>> drivers/mmc/core/queue.h |  1 +  include/linux/mmc/core.h |  1 +
>>  4 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index
>> 8816b3f0a312..7020a568fb79 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -1713,6 +1713,13 @@ static void mmc_blk_rw_rq_prep(struct
>> mmc_queue_req *mqrq,
>>  			(do_data_tag ? (1 << 29) : 0);
>>  		brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>  		brq->mrq.sbc = &brq->sbc;
>> +
>> +		if (mmc_card_ult_capacity(card)) {
>> +			brq->ext.opcode = SD_ADDR_EXT;
>> +			brq->ext.arg = (u32)((blk_rq_pos(req) >> 32) & 0x3F);
>> +			brq->ext.flags = MMC_RSP_R1 | MMC_CMD_AC;
>> +			brq->mrq.ext = &brq->ext;
>> +		}
>>  	} else if (mmc_card_ult_capacity(card)) {
>>  		mmc_blk_wait_for_idle(mq, card->host);
>>  		mmc_send_ext_addr(card->host, blk_rq_pos(req)); diff --git
>> a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
>> d6c819dd68ed..4808e42d7855 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -184,6 +184,14 @@ void mmc_request_done(struct mmc_host *host,
>> struct mmc_request *mrq)
>>  				mrq->sbc->resp[2], mrq->sbc->resp[3]);
>>  		}
>>
>> +		if (mrq->ext) {
>> +			pr_debug("%s: req done <CMD%u>: %d: %08x %08x
>> %08x %08x\n",
>> +				 mmc_hostname(host), mrq->ext->opcode,
>> +				 mrq->ext->error,
>> +				 mrq->ext->resp[0], mrq->ext->resp[1],
>> +				 mrq->ext->resp[2], mrq->ext->resp[3]);
>> +		}
>> +
>>  		pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x
>> %08x\n",
>>  			mmc_hostname(host), cmd->opcode, err,
>>  			cmd->resp[0], cmd->resp[1],
>> @@ -270,6 +278,12 @@ static void mmc_mrq_pr_debug(struct mmc_host
>> *host, struct mmc_request *mrq,
>>  			 mrq->sbc->arg, mrq->sbc->flags);
>>  	}
>>
>> +	if (mrq->ext) {
>> +		pr_debug("<%s: starting CMD%u arg %08x flags %08x>\n",
>> +			 mmc_hostname(host), mrq->ext->opcode,
>> +			 mrq->ext->arg, mrq->ext->flags);
>> +	}
>> +
>>  	if (mrq->cmd) {
>>  		pr_debug("%s: starting %sCMD%u arg %08x flags %08x\n",
>>  			 mmc_hostname(host), cqe ? "CQE direct " : "", @@ -
>> 309,6 +323,10 @@ static int mmc_mrq_prep(struct mmc_host *host, struct
>> mmc_request *mrq)
>>  		mrq->sbc->error = 0;
>>  		mrq->sbc->mrq = mrq;
>>  	}
>> +	if (mrq->ext) {
>> +		mrq->ext->error = 0;
>> +		mrq->ext->mrq = mrq;
>> +	}
>>  	if (mrq->data) {
>>  		if (mrq->data->blksz > host->max_blk_size ||
>>  		    mrq->data->blocks > host->max_blk_count || diff --git
>> a/drivers/mmc/core/queue.h b/drivers/mmc/core/queue.h index
>> 1498840a4ea0..7e191d7f0461 100644
>> --- a/drivers/mmc/core/queue.h
>> +++ b/drivers/mmc/core/queue.h
>> @@ -40,6 +40,7 @@ struct mmc_blk_ioc_data;  struct mmc_blk_request {
>>  	struct mmc_request	mrq;
>>  	struct mmc_command	sbc;
>> +	struct mmc_command	ext;
>>  	struct mmc_command	cmd;
>>  	struct mmc_command	stop;
>>  	struct mmc_data		data;
>> diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h index
>> 2c7928a50907..5560e70cb8d4 100644
>> --- a/include/linux/mmc/core.h
>> +++ b/include/linux/mmc/core.h
>> @@ -142,6 +142,7 @@ struct mmc_data {
>>  struct mmc_host;
>>  struct mmc_request {
>>  	struct mmc_command	*sbc;		/* SET_BLOCK_COUNT for
>> multiblock */
>> +	struct mmc_command	*ext;		/* SD_ADDR_EXT for SDUC */
>>  	struct mmc_command	*cmd;
>>  	struct mmc_data		*data;
>>  	struct mmc_command	*stop;
>> --
>> 2.25.1
> 

RE: [PATCH v4 4/9] mmc: core: Add close-ended Ext memory addressing

[Avri Altman]

> On 26/08/24 08:32, Avri Altman wrote:
> >> In a multi-block data transfer, CMD23 shall precede CMD22. Prepare
> >> CMD22 in advance as an additional extension of the mrq, to be handle
> >> by the host once CMD23 is done.
> > I am floundering about the close-ended part of this series.
> > My main concern is an amid stream of fixes & quirks of bogus hw, that
> > tends to apply extra logic specifically around acmd12 & acmd23.
> >
> > Unless someone think it's absolutely necessary to be included, I would
> > like to drop patches 4, 5, and 6.
> > What do you think?
> 
> What are the downsides to supporting open-ended only?
I guess all the reasons for inventing close-ended in the first place...
Still, it could be added later, should those cards become ubiquitous, if any.

Thanks,
Avri
> 
> >
> > Thanks,
> > Avri
> >
> >>
> >> Tested-by: Ricky WU <ricky_wu@realtek.com>
> >> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> >> ---
> >>  drivers/mmc/core/block.c |  7 +++++++  drivers/mmc/core/core.c  | 18
> >> ++++++++++++++++++ drivers/mmc/core/queue.h |  1 +
> >> include/linux/mmc/core.h |  1 +
> >>  4 files changed, 27 insertions(+)
> >>
> >> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> >> index
> >> 8816b3f0a312..7020a568fb79 100644
> >> --- a/drivers/mmc/core/block.c
> >> +++ b/drivers/mmc/core/block.c
> >> @@ -1713,6 +1713,13 @@ static void mmc_blk_rw_rq_prep(struct
> >> mmc_queue_req *mqrq,
> >>                      (do_data_tag ? (1 << 29) : 0);
> >>              brq->sbc.flags = MMC_RSP_R1 | MMC_CMD_AC;
> >>              brq->mrq.sbc = &brq->sbc;
> >> +
> >> +            if (mmc_card_ult_capacity(card)) {
> >> +                    brq->ext.opcode = SD_ADDR_EXT;
> >> +                    brq->ext.arg = (u32)((blk_rq_pos(req) >> 32) & 0x3F);
> >> +                    brq->ext.flags = MMC_RSP_R1 | MMC_CMD_AC;
> >> +                    brq->mrq.ext = &brq->ext;
> >> +            }
> >>      } else if (mmc_card_ult_capacity(card)) {
> >>              mmc_blk_wait_for_idle(mq, card->host);
> >>              mmc_send_ext_addr(card->host, blk_rq_pos(req)); diff
> >> --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
> >> d6c819dd68ed..4808e42d7855 100644
> >> --- a/drivers/mmc/core/core.c
> >> +++ b/drivers/mmc/core/core.c
> >> @@ -184,6 +184,14 @@ void mmc_request_done(struct mmc_host
> *host,
> >> struct mmc_request *mrq)
> >>                              mrq->sbc->resp[2], mrq->sbc->resp[3]);
> >>              }
> >>
> >> +            if (mrq->ext) {
> >> +                    pr_debug("%s: req done <CMD%u>: %d: %08x %08x
> >> %08x %08x\n",
> >> +                             mmc_hostname(host), mrq->ext->opcode,
> >> +                             mrq->ext->error,
> >> +                             mrq->ext->resp[0], mrq->ext->resp[1],
> >> +                             mrq->ext->resp[2], mrq->ext->resp[3]);
> >> +            }
> >> +
> >>              pr_debug("%s: req done (CMD%u): %d: %08x %08x %08x
> >> %08x\n",
> >>                      mmc_hostname(host), cmd->opcode, err,
> >>                      cmd->resp[0], cmd->resp[1], @@ -270,6 +278,12 @@
> >> static void mmc_mrq_pr_debug(struct mmc_host *host, struct
> >> mmc_request *mrq,
> >>                       mrq->sbc->arg, mrq->sbc->flags);
> >>      }
> >>
> >> +    if (mrq->ext) {
> >> +            pr_debug("<%s: starting CMD%u arg %08x flags %08x>\n",
> >> +                     mmc_hostname(host), mrq->ext->opcode,
> >> +                     mrq->ext->arg, mrq->ext->flags);
> >> +    }
> >> +
> >>      if (mrq->cmd) {
> >>              pr_debug("%s: starting %sCMD%u arg %08x flags %08x\n",
> >>                       mmc_hostname(host), cqe ? "CQE direct " : "",
> >> @@ -
> >> 309,6 +323,10 @@ static int mmc_mrq_prep(struct mmc_host *host,
> >> struct mmc_request *mrq)
> >>              mrq->sbc->error = 0;
> >>              mrq->sbc->mrq = mrq;
> >>      }
> >> +    if (mrq->ext) {
> >> +            mrq->ext->error = 0;
> >> +            mrq->ext->mrq = mrq;
> >> +    }
> >>      if (mrq->data) {
> >>              if (mrq->data->blksz > host->max_blk_size ||
> >>                  mrq->data->blocks > host->max_blk_count || diff
> >> --git a/drivers/mmc/core/queue.h b/drivers/mmc/core/queue.h index
> >> 1498840a4ea0..7e191d7f0461 100644
> >> --- a/drivers/mmc/core/queue.h
> >> +++ b/drivers/mmc/core/queue.h
> >> @@ -40,6 +40,7 @@ struct mmc_blk_ioc_data;  struct mmc_blk_request {
> >>      struct mmc_request      mrq;
> >>      struct mmc_command      sbc;
> >> +    struct mmc_command      ext;
> >>      struct mmc_command      cmd;
> >>      struct mmc_command      stop;
> >>      struct mmc_data         data;
> >> diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
> >> index
> >> 2c7928a50907..5560e70cb8d4 100644
> >> --- a/include/linux/mmc/core.h
> >> +++ b/include/linux/mmc/core.h
> >> @@ -142,6 +142,7 @@ struct mmc_data {  struct mmc_host;  struct
> >> mmc_request {
> >>      struct mmc_command      *sbc;           /* SET_BLOCK_COUNT for
> >> multiblock */
> >> +    struct mmc_command      *ext;           /* SD_ADDR_EXT for SDUC */
> >>      struct mmc_command      *cmd;
> >>      struct mmc_data         *data;
> >>      struct mmc_command      *stop;
> >> --
> >> 2.25.1
> >

[PATCH v4 5/9] mmc: host: Always use manual-cmd23 in SDUC

[Avri Altman]

In Multi-Block read/write, CMD23 must precede CMD22.  Therefore always
use manual cmd23 so that we'll be able to control the sequence of
commands.  Also, add an applicable mmc_command member for both
mmc_blk_request and mmc_request to accommodate the address extension
command.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/host/sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4b91c9e96635..f62b489c9e9c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1399,13 +1399,13 @@ static inline bool sdhci_auto_cmd12(struct sdhci_host *host,
 static inline bool sdhci_auto_cmd23(struct sdhci_host *host,
 				    struct mmc_request *mrq)
 {
-	return mrq->sbc && (host->flags & SDHCI_AUTO_CMD23);
+	return mrq->sbc && (host->flags & SDHCI_AUTO_CMD23) && !mrq->ext;
 }
 
 static inline bool sdhci_manual_cmd23(struct sdhci_host *host,
 				      struct mmc_request *mrq)
 {
-	return mrq->sbc && !(host->flags & SDHCI_AUTO_CMD23);
+	return mrq->sbc && (mrq->ext || !(host->flags & SDHCI_AUTO_CMD23));
 }
 
 static inline void sdhci_auto_cmd_select(struct sdhci_host *host,
-- 
2.25.1

[PATCH v4 6/9] mmc: host: Add close-ended Ext memory addressing

[Avri Altman]

In a close-ended multi-block data transfer, CMD23 shall precede CMD22.
Handle that logic once the sbc is done.

Host drivers that handle their own sbc logic, e.g. bcm2835 etc. are out
of scope of this change.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/host/sdhci.c | 36 ++++++++++++++++++++++++++++++++----
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f62b489c9e9c..70c967029fe3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1791,9 +1791,38 @@ static void sdhci_read_rsp_136(struct sdhci_host *host, struct mmc_command *cmd)
 	}
 }
 
+static struct mmc_command *sdhci_get_sbc_ext(struct sdhci_host *host,
+					     struct mmc_command *cmd)
+{
+	bool is_sduc = mmc_card_ult_capacity(host->mmc->card);
+
+	if (is_sduc) {
+		/*  Finished CMD22, now send actual command */
+		if (cmd == cmd->mrq->ext)
+			return cmd->mrq->cmd;
+	}
+
+	/* Finished CMD23 */
+	if (cmd == cmd->mrq->sbc) {
+		if (is_sduc) {
+			/* send CMD22 after CMD23 */
+			if (WARN_ON(!cmd->mrq->ext))
+				return NULL;
+			else
+				return cmd->mrq->ext;
+		} else {
+			/* Finished CMD23, now send actual command */
+			return cmd->mrq->cmd;
+		}
+	}
+
+	return NULL;
+}
+
 static void sdhci_finish_command(struct sdhci_host *host)
 {
 	struct mmc_command *cmd = host->cmd;
+	struct mmc_command *sbc_ext = NULL;
 
 	host->cmd = NULL;
 
@@ -1828,14 +1857,13 @@ static void sdhci_finish_command(struct sdhci_host *host)
 		}
 	}
 
-	/* Finished CMD23, now send actual command. */
-	if (cmd == cmd->mrq->sbc) {
-		if (!sdhci_send_command(host, cmd->mrq->cmd)) {
+	sbc_ext = sdhci_get_sbc_ext(host, cmd);
+	if (sbc_ext) {
+		if (!sdhci_send_command(host, sbc_ext)) {
 			WARN_ON(host->deferred_cmd);
 			host->deferred_cmd = cmd->mrq->cmd;
 		}
 	} else {
-
 		/* Processed actual command. */
 		if (host->data && host->data_early)
 			sdhci_finish_data(host);
-- 
2.25.1

RE: [PATCH v4 6/9] mmc: host: Add close-ended Ext memory addressing

[Avri Altman]

> In a close-ended multi-block data transfer, CMD23 shall precede CMD22.
> Handle that logic once the sbc is done.
> 
> Host drivers that handle their own sbc logic, e.g. bcm2835 etc. are out of scope of
> this change.
> 
> Tested-by: Ricky WU <ricky_wu@realtek.com>
> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> ---
>  drivers/mmc/host/sdhci.c | 36 ++++++++++++++++++++++++++++++++----
>  1 file changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index
> f62b489c9e9c..70c967029fe3 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1791,9 +1791,38 @@ static void sdhci_read_rsp_136(struct sdhci_host
> *host, struct mmc_command *cmd)
>  	}
>  }
> 
> +static struct mmc_command *sdhci_get_sbc_ext(struct sdhci_host *host,
> +					     struct mmc_command *cmd)
> +{
> +	bool is_sduc = mmc_card_ult_capacity(host->mmc->card);
At this point, better move mmc_card_ult_capacity to include/linux/mmc/card.h.
Also better check host->mmc->card != NULL as it can be until mmc_sd_init_card() concludes.

Thanks,
Avri

> +
> +	if (is_sduc) {
> +		/*  Finished CMD22, now send actual command */
> +		if (cmd == cmd->mrq->ext)
> +			return cmd->mrq->cmd;
> +	}
> +
> +	/* Finished CMD23 */
> +	if (cmd == cmd->mrq->sbc) {
> +		if (is_sduc) {
> +			/* send CMD22 after CMD23 */
> +			if (WARN_ON(!cmd->mrq->ext))
> +				return NULL;
> +			else
> +				return cmd->mrq->ext;
> +		} else {
> +			/* Finished CMD23, now send actual command */
> +			return cmd->mrq->cmd;
> +		}
> +	}
> +
> +	return NULL;
> +}
> +
>  static void sdhci_finish_command(struct sdhci_host *host)  {
>  	struct mmc_command *cmd = host->cmd;
> +	struct mmc_command *sbc_ext = NULL;
> 
>  	host->cmd = NULL;
> 
> @@ -1828,14 +1857,13 @@ static void sdhci_finish_command(struct sdhci_host
> *host)
>  		}
>  	}
> 
> -	/* Finished CMD23, now send actual command. */
> -	if (cmd == cmd->mrq->sbc) {
> -		if (!sdhci_send_command(host, cmd->mrq->cmd)) {
> +	sbc_ext = sdhci_get_sbc_ext(host, cmd);
> +	if (sbc_ext) {
> +		if (!sdhci_send_command(host, sbc_ext)) {
>  			WARN_ON(host->deferred_cmd);
>  			host->deferred_cmd = cmd->mrq->cmd;
>  		}
>  	} else {
> -
>  		/* Processed actual command. */
>  		if (host->data && host->data_early)
>  			sdhci_finish_data(host);
> --
> 2.25.1

Re: [PATCH v4 6/9] mmc: host: Add close-ended Ext memory addressing

[kernel test robot]

Hi Avri,

kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v6.11-rc5 next-20240826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Avri-Altman/mmc-sd-SDUC-Support-Recognition/20240826-161527
base:   linus/master
patch link:    https://lore.kernel.org/r/20240825074141.3171549-7-avri.altman%40wdc.com
patch subject: [PATCH v4 6/9] mmc: host: Add close-ended Ext memory addressing
config: arc-randconfig-002-20240827 (https://download.01.org/0day-ci/archive/20240827/202408270315.TTjSYp25-lkp@intel.com/config)
compiler: arceb-elf-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240827/202408270315.TTjSYp25-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202408270315.TTjSYp25-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/mmc/host/sdhci.c: In function 'sdhci_get_sbc_ext':
>> drivers/mmc/host/sdhci.c:1797:24: error: implicit declaration of function 'mmc_card_ult_capacity' [-Werror=implicit-function-declaration]
    1797 |         bool is_sduc = mmc_card_ult_capacity(host->mmc->card);
         |                        ^~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/mmc_card_ult_capacity +1797 drivers/mmc/host/sdhci.c

  1793	
  1794	static struct mmc_command *sdhci_get_sbc_ext(struct sdhci_host *host,
  1795						     struct mmc_command *cmd)
  1796	{
> 1797		bool is_sduc = mmc_card_ult_capacity(host->mmc->card);
  1798	
  1799		if (is_sduc) {
  1800			/*  Finished CMD22, now send actual command */
  1801			if (cmd == cmd->mrq->ext)
  1802				return cmd->mrq->cmd;
  1803		}
  1804	
  1805		/* Finished CMD23 */
  1806		if (cmd == cmd->mrq->sbc) {
  1807			if (is_sduc) {
  1808				/* send CMD22 after CMD23 */
  1809				if (WARN_ON(!cmd->mrq->ext))
  1810					return NULL;
  1811				else
  1812					return cmd->mrq->ext;
  1813			} else {
  1814				/* Finished CMD23, now send actual command */
  1815				return cmd->mrq->cmd;
  1816			}
  1817		}
  1818	
  1819		return NULL;
  1820	}
  1821	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4 6/9] mmc: host: Add close-ended Ext memory addressing

[kernel test robot]

Hi Avri,

kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v6.11-rc5 next-20240826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Avri-Altman/mmc-sd-SDUC-Support-Recognition/20240826-161527
base:   linus/master
patch link:    https://lore.kernel.org/r/20240825074141.3171549-7-avri.altman%40wdc.com
patch subject: [PATCH v4 6/9] mmc: host: Add close-ended Ext memory addressing
config: arm-defconfig (https://download.01.org/0day-ci/archive/20240827/202408270619.qJDzvXzO-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240827/202408270619.qJDzvXzO-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202408270619.qJDzvXzO-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/mmc/host/sdhci.c:1797:17: error: implicit declaration of function 'mmc_card_ult_capacity' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
           bool is_sduc = mmc_card_ult_capacity(host->mmc->card);
                          ^
   1 error generated.


vim +/mmc_card_ult_capacity +1797 drivers/mmc/host/sdhci.c

  1793	
  1794	static struct mmc_command *sdhci_get_sbc_ext(struct sdhci_host *host,
  1795						     struct mmc_command *cmd)
  1796	{
> 1797		bool is_sduc = mmc_card_ult_capacity(host->mmc->card);
  1798	
  1799		if (is_sduc) {
  1800			/*  Finished CMD22, now send actual command */
  1801			if (cmd == cmd->mrq->ext)
  1802				return cmd->mrq->cmd;
  1803		}
  1804	
  1805		/* Finished CMD23 */
  1806		if (cmd == cmd->mrq->sbc) {
  1807			if (is_sduc) {
  1808				/* send CMD22 after CMD23 */
  1809				if (WARN_ON(!cmd->mrq->ext))
  1810					return NULL;
  1811				else
  1812					return cmd->mrq->ext;
  1813			} else {
  1814				/* Finished CMD23, now send actual command */
  1815				return cmd->mrq->cmd;
  1816			}
  1817		}
  1818	
  1819		return NULL;
  1820	}
  1821	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v4 7/9] mmc: core: Allow mmc erase to carry large addresses

[Avri Altman]

Preparing for SDUC, Allow the erase address to be larger beyond a 32 bit
address.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/block.c |  6 ++++--
 drivers/mmc/core/core.c  | 33 ++++++++++++++++++---------------
 drivers/mmc/core/core.h  | 16 ++++++++++++----
 3 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 7020a568fb79..ace701273230 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -1154,7 +1154,8 @@ static void mmc_blk_issue_erase_rq(struct mmc_queue *mq, struct request *req,
 {
 	struct mmc_blk_data *md = mq->blkdata;
 	struct mmc_card *card = md->queue.card;
-	unsigned int from, nr;
+	unsigned int nr;
+	sector_t from;
 	int err = 0;
 	blk_status_t status = BLK_STS_OK;
 
@@ -1209,7 +1210,8 @@ static void mmc_blk_issue_secdiscard_rq(struct mmc_queue *mq,
 {
 	struct mmc_blk_data *md = mq->blkdata;
 	struct mmc_card *card = md->queue.card;
-	unsigned int from, nr, arg;
+	unsigned int nr, arg;
+	sector_t from;
 	int err = 0, type = MMC_BLK_SECDISCARD;
 	blk_status_t status = BLK_STS_OK;
 
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 4808e42d7855..2148ce4535ee 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1616,8 +1616,8 @@ static unsigned int mmc_erase_timeout(struct mmc_card *card,
 		return mmc_mmc_erase_timeout(card, arg, qty);
 }
 
-static int mmc_do_erase(struct mmc_card *card, unsigned int from,
-			unsigned int to, unsigned int arg)
+static int mmc_do_erase(struct mmc_card *card, sector_t from,
+			sector_t to, unsigned int arg)
 {
 	struct mmc_command cmd = {};
 	unsigned int qty = 0, busy_timeout = 0;
@@ -1648,8 +1648,8 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from,
 	else if (mmc_card_sd(card))
 		qty += to - from + 1;
 	else
-		qty += ((to / card->erase_size) -
-			(from / card->erase_size)) + 1;
+		qty += (mmc_sector_div(to, card->erase_size) -
+			mmc_sector_div(from, card->erase_size)) + 1;
 
 	if (!mmc_card_blockaddr(card)) {
 		from <<= 9;
@@ -1718,18 +1718,19 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from,
 }
 
 static unsigned int mmc_align_erase_size(struct mmc_card *card,
-					 unsigned int *from,
-					 unsigned int *to,
+					 sector_t *from,
+					 sector_t *to,
 					 unsigned int nr)
 {
-	unsigned int from_new = *from, nr_new = nr, rem;
+	sector_t from_new = *from;
+	unsigned int nr_new = nr, rem;
 
 	/*
 	 * When the 'card->erase_size' is power of 2, we can use round_up/down()
 	 * to align the erase size efficiently.
 	 */
 	if (is_power_of_2(card->erase_size)) {
-		unsigned int temp = from_new;
+		sector_t temp = from_new;
 
 		from_new = round_up(temp, card->erase_size);
 		rem = from_new - temp;
@@ -1741,7 +1742,7 @@ static unsigned int mmc_align_erase_size(struct mmc_card *card,
 
 		nr_new = round_down(nr_new, card->erase_size);
 	} else {
-		rem = from_new % card->erase_size;
+		rem = mmc_sector_mod(from_new, card->erase_size);
 		if (rem) {
 			rem = card->erase_size - rem;
 			from_new += rem;
@@ -1774,10 +1775,12 @@ static unsigned int mmc_align_erase_size(struct mmc_card *card,
  *
  * Caller must claim host before calling this function.
  */
-int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
+int mmc_erase(struct mmc_card *card, sector_t from, unsigned int nr,
 	      unsigned int arg)
 {
-	unsigned int rem, to = from + nr;
+	unsigned int rem;
+	sector_t to = from + nr;
+
 	int err;
 
 	if (!(card->csd.cmdclass & CCC_ERASE))
@@ -1798,7 +1801,7 @@ int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
 		return -EOPNOTSUPP;
 
 	if (arg == MMC_SECURE_ERASE_ARG) {
-		if (from % card->erase_size || nr % card->erase_size)
+		if (mmc_sector_mod(from, card->erase_size) || nr % card->erase_size)
 			return -EINVAL;
 	}
 
@@ -1822,7 +1825,7 @@ int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
 	 * and call mmc_do_erase() twice if necessary. This special case is
 	 * identified by the card->eg_boundary flag.
 	 */
-	rem = card->erase_size - (from % card->erase_size);
+	rem = card->erase_size - mmc_sector_mod(from, card->erase_size);
 	if ((arg & MMC_TRIM_OR_DISCARD_ARGS) && card->eg_boundary && nr > rem) {
 		err = mmc_do_erase(card, from, from + rem - 1, arg);
 		from += rem;
@@ -1881,12 +1884,12 @@ int mmc_can_secure_erase_trim(struct mmc_card *card)
 }
 EXPORT_SYMBOL(mmc_can_secure_erase_trim);
 
-int mmc_erase_group_aligned(struct mmc_card *card, unsigned int from,
+int mmc_erase_group_aligned(struct mmc_card *card, sector_t from,
 			    unsigned int nr)
 {
 	if (!card->erase_size)
 		return 0;
-	if (from % card->erase_size || nr % card->erase_size)
+	if (mmc_sector_mod(from, card->erase_size) || nr % card->erase_size)
 		return 0;
 	return 1;
 }
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 37091a6589ed..fc9d5e9620b1 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -116,15 +116,13 @@ bool mmc_is_req_done(struct mmc_host *host, struct mmc_request *mrq);
 
 int mmc_start_request(struct mmc_host *host, struct mmc_request *mrq);
 
-int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
-		unsigned int arg);
+int mmc_erase(struct mmc_card *card, sector_t from, unsigned int nr, unsigned int arg);
 int mmc_can_erase(struct mmc_card *card);
 int mmc_can_trim(struct mmc_card *card);
 int mmc_can_discard(struct mmc_card *card);
 int mmc_can_sanitize(struct mmc_card *card);
 int mmc_can_secure_erase_trim(struct mmc_card *card);
-int mmc_erase_group_aligned(struct mmc_card *card, unsigned int from,
-			unsigned int nr);
+int mmc_erase_group_aligned(struct mmc_card *card, sector_t from, unsigned int nr);
 unsigned int mmc_calc_max_discard(struct mmc_card *card);
 
 int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen);
@@ -199,4 +197,14 @@ static inline int mmc_flush_cache(struct mmc_host *host)
 	return 0;
 }
 
+static inline unsigned int mmc_sector_div(sector_t dividend, u32 divisor)
+{
+	return div_u64(dividend, divisor);
+}
+
+static inline unsigned int mmc_sector_mod(sector_t dividend, u32 divisor)
+{
+	return sector_div(dividend, divisor);
+}
+
 #endif
-- 
2.25.1

[PATCH v4 8/9] mmc: core: Add Ext memory addressing for erase

[Avri Altman]

CMD22 shall precede CMD32 and CMD33 to configure 38-bit erase start
address and 38 bit erase stop address.

Tested-by: Ricky WU <ricky_wu@realtek.com>
Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/core.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2148ce4535ee..3315c1fad264 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1660,8 +1660,12 @@ static int mmc_do_erase(struct mmc_card *card, sector_t from,
 		cmd.opcode = SD_ERASE_WR_BLK_START;
 	else
 		cmd.opcode = MMC_ERASE_GROUP_START;
-	cmd.arg = from;
+	cmd.arg = from & 0xFFFFFFFF;
 	cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
+
+	if (mmc_card_ult_capacity(card))
+		mmc_send_ext_addr(card->host, from);
+
 	err = mmc_wait_for_cmd(card->host, &cmd, 0);
 	if (err) {
 		pr_err("mmc_erase: group start error %d, "
@@ -1675,8 +1679,12 @@ static int mmc_do_erase(struct mmc_card *card, sector_t from,
 		cmd.opcode = SD_ERASE_WR_BLK_END;
 	else
 		cmd.opcode = MMC_ERASE_GROUP_END;
-	cmd.arg = to;
+	cmd.arg = to & 0xFFFFFFFF;
 	cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_AC;
+
+	if (mmc_card_ult_capacity(card))
+		mmc_send_ext_addr(card->host, to);
+
 	err = mmc_wait_for_cmd(card->host, &cmd, 0);
 	if (err) {
 		pr_err("mmc_erase: group end error %d, status %#x\n",
-- 
2.25.1

[PATCH v4 9/9] mmc: core: Adjust ACMD22 to SDUC

[Avri Altman]

ACMD22 is used to verify the previously write operation.  Normally, it
returns the number of written sectors as u32.  SDUC, however, returns it
as u64.  This is not a superfluous requirement, because SDUC writes may
exceeds 2TB.  For Linux mmc however, the previously write operation
could not be more than the block layer limits, thus we make room for a
u64 and cast the returning value to u32.

Moreover, SD cards expect to be allowed the full 500msec busy period
post write operations.  This is true for standard capacity SD, and even
more so for high volume SD cards, specifically SDUC.  If CMD13 return an
error bit, the recovery flow is entered regardless of the busy period.
Thus, better enforce the busy period for SDUC, otherwise it might return
a bogus bytes written.

Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/mmc/core/block.c | 37 +++++++++++++++++++++++++++++++------
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index ace701273230..b73fdef1cb0d 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -48,6 +48,7 @@
 #include <linux/mmc/sd.h>
 
 #include <linux/uaccess.h>
+#include <asm/unaligned.h>
 
 #include "queue.h"
 #include "block.h"
@@ -948,13 +949,20 @@ static int mmc_sd_num_wr_blocks(struct mmc_card *card, u32 *written_blocks)
 	int err;
 	u32 result;
 	__be32 *blocks;
-
+	u8 resp_sz;
 	struct mmc_request mrq = {};
 	struct mmc_command cmd = {};
 	struct mmc_data data = {};
-
 	struct scatterlist sg;
 
+	/*
+	 * SD cards, specifically high volume cards, expect to be allowed with the
+	 * full 500msec busy period post write. Otherwise, they may not indicate
+	 * correctly the number of bytes written.
+	 */
+	if (mmc_card_ult_capacity(card))
+		mmc_delay(500);
+
 	err = mmc_app_cmd(card->host, card);
 	if (err)
 		return err;
@@ -963,7 +971,14 @@ static int mmc_sd_num_wr_blocks(struct mmc_card *card, u32 *written_blocks)
 	cmd.arg = 0;
 	cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
 
-	data.blksz = 4;
+	/*
+	 * Normally, ACMD22 returns the number of written sectors as u32.
+	 * SDUC, however, returns it as u64.  This is not a superfluous
+	 * requirement, because SDUC writes may exceed 2TB.
+	 */
+	resp_sz = mmc_card_ult_capacity(card) ? 8 : 4;
+
+	data.blksz = resp_sz;
 	data.blocks = 1;
 	data.flags = MMC_DATA_READ;
 	data.sg = &sg;
@@ -973,15 +988,25 @@ static int mmc_sd_num_wr_blocks(struct mmc_card *card, u32 *written_blocks)
 	mrq.cmd = &cmd;
 	mrq.data = &data;
 
-	blocks = kmalloc(4, GFP_KERNEL);
+	blocks = kmalloc(resp_sz, GFP_KERNEL);
 	if (!blocks)
 		return -ENOMEM;
 
-	sg_init_one(&sg, blocks, 4);
+	sg_init_one(&sg, blocks, resp_sz);
 
 	mmc_wait_for_req(card->host, &mrq);
 
-	result = ntohl(*blocks);
+	if (mmc_card_ult_capacity(card)) {
+		u64 blocks_64 = get_unaligned_be64(blocks);
+		/*
+		 * For Linux mmc however, the previously write operation could
+		 * not be more than the block layer limits, thus just make room
+		 * for a u64 and cast the response back to u32.
+		 */
+		result = blocks_64 > UINT_MAX ? UINT_MAX : (u32)blocks_64;
+	} else {
+		result = ntohl(*blocks);
+	}
 	kfree(blocks);
 
 	if (cmd.error || data.error)
-- 
2.25.1

Re: [PATCH v4 9/9] mmc: core: Adjust ACMD22 to SDUC

[Adrian Hunter]

On 25/08/24 10:41, Avri Altman wrote:
> ACMD22 is used to verify the previously write operation.  Normally, it
> returns the number of written sectors as u32.  SDUC, however, returns it
> as u64.  This is not a superfluous requirement, because SDUC writes may
> exceeds 2TB.  For Linux mmc however, the previously write operation
> could not be more than the block layer limits, thus we make room for a
> u64 and cast the returning value to u32.
> 
> Moreover, SD cards expect to be allowed the full 500msec busy period
> post write operations.  This is true for standard capacity SD, and even
> more so for high volume SD cards, specifically SDUC.  If CMD13 return an
> error bit, the recovery flow is entered regardless of the busy period.
> Thus, better enforce the busy period for SDUC, otherwise it might return
> a bogus bytes written.
> 
> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> ---
>  drivers/mmc/core/block.c | 37 +++++++++++++++++++++++++++++++------
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index ace701273230..b73fdef1cb0d 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -48,6 +48,7 @@
>  #include <linux/mmc/sd.h>
>  
>  #include <linux/uaccess.h>
> +#include <asm/unaligned.h>
>  
>  #include "queue.h"
>  #include "block.h"
> @@ -948,13 +949,20 @@ static int mmc_sd_num_wr_blocks(struct mmc_card *card, u32 *written_blocks)
>  	int err;
>  	u32 result;
>  	__be32 *blocks;
> -
> +	u8 resp_sz;
>  	struct mmc_request mrq = {};
>  	struct mmc_command cmd = {};
>  	struct mmc_data data = {};
> -
>  	struct scatterlist sg;
>  
> +	/*
> +	 * SD cards, specifically high volume cards, expect to be allowed with the
> +	 * full 500msec busy period post write. Otherwise, they may not indicate
> +	 * correctly the number of bytes written.
> +	 */
> +	if (mmc_card_ult_capacity(card))
> +		mmc_delay(500);

To get here, it should have had to go through:

	/* Try to get back to "tran" state */
	if (!mmc_host_is_spi(mq->card->host) &&
	    (err || !mmc_ready_for_data(status)))
		err = mmc_blk_fix_state(mq->card, req);

which would mean the card is not indicating "busy".
Either that is not working, or it seems like an issue
with the card, in which case it could be a card quirk
perhaps.

> +
>  	err = mmc_app_cmd(card->host, card);
>  	if (err)
>  		return err;
> @@ -963,7 +971,14 @@ static int mmc_sd_num_wr_blocks(struct mmc_card *card, u32 *written_blocks)
>  	cmd.arg = 0;
>  	cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
>  
> -	data.blksz = 4;
> +	/*
> +	 * Normally, ACMD22 returns the number of written sectors as u32.
> +	 * SDUC, however, returns it as u64.  This is not a superfluous
> +	 * requirement, because SDUC writes may exceed 2TB.
> +	 */
> +	resp_sz = mmc_card_ult_capacity(card) ? 8 : 4;
> +
> +	data.blksz = resp_sz;
>  	data.blocks = 1;
>  	data.flags = MMC_DATA_READ;
>  	data.sg = &sg;
> @@ -973,15 +988,25 @@ static int mmc_sd_num_wr_blocks(struct mmc_card *card, u32 *written_blocks)
>  	mrq.cmd = &cmd;
>  	mrq.data = &data;
>  
> -	blocks = kmalloc(4, GFP_KERNEL);
> +	blocks = kmalloc(resp_sz, GFP_KERNEL);
>  	if (!blocks)
>  		return -ENOMEM;
>  
> -	sg_init_one(&sg, blocks, 4);
> +	sg_init_one(&sg, blocks, resp_sz);
>  
>  	mmc_wait_for_req(card->host, &mrq);
>  
> -	result = ntohl(*blocks);
> +	if (mmc_card_ult_capacity(card)) {
> +		u64 blocks_64 = get_unaligned_be64(blocks);
> +		/*
> +		 * For Linux mmc however, the previously write operation could
> +		 * not be more than the block layer limits, thus just make room
> +		 * for a u64 and cast the response back to u32.
> +		 */
> +		result = blocks_64 > UINT_MAX ? UINT_MAX : (u32)blocks_64;
> +	} else {
> +		result = ntohl(*blocks);
> +	}
>  	kfree(blocks);
>  
>  	if (cmd.error || data.error)

RE: [PATCH v4 9/9] mmc: core: Adjust ACMD22 to SDUC

[Avri Altman]

> > +     /*
> > +      * SD cards, specifically high volume cards, expect to be allowed with the
> > +      * full 500msec busy period post write. Otherwise, they may not indicate
> > +      * correctly the number of bytes written.
> > +      */
> > +     if (mmc_card_ult_capacity(card))
> > +             mmc_delay(500);
> 
> To get here, it should have had to go through:
> 
>         /* Try to get back to "tran" state */
>         if (!mmc_host_is_spi(mq->card->host) &&
>             (err || !mmc_ready_for_data(status)))
>                 err = mmc_blk_fix_state(mq->card, req);
> 
> which would mean the card is not indicating "busy".
> Either that is not working, or it seems like an issue with the card, in which case
> it could be a card quirk perhaps.
I was getting here on a setup with micro-to-SD adapter - I guess because of phy errors on one of the early card versions.
On my other setups, the recovery flow wasn't triggered.
What was happening is:
mmc_blk_mq_req_done
	mmc_blk_mq_complete_prev_req
		mmc_blk_mq_poll_completion
			CMD13: 0: 00080900 00000000 00000000 00000000 = READY_FOR_DATA + ERROR
			mmc_blk_mq_rw_recovery
				mmc_sd_num_wr_blocks - bytes_xfered = 0

Consulting with our SD system guys, the 500msec must-have write timeout brought up,
And fixed that.
Shawn was interested in this as well - see the discussion in V3.

Thanks,
Avri

Re: [PATCH v4 9/9] mmc: core: Adjust ACMD22 to SDUC

[Adrian Hunter]

On 26/08/24 10:26, Avri Altman wrote:
>>> +     /*
>>> +      * SD cards, specifically high volume cards, expect to be allowed with the
>>> +      * full 500msec busy period post write. Otherwise, they may not indicate
>>> +      * correctly the number of bytes written.
>>> +      */
>>> +     if (mmc_card_ult_capacity(card))
>>> +             mmc_delay(500);
>>
>> To get here, it should have had to go through:
>>
>>         /* Try to get back to "tran" state */
>>         if (!mmc_host_is_spi(mq->card->host) &&
>>             (err || !mmc_ready_for_data(status)))
>>                 err = mmc_blk_fix_state(mq->card, req);
>>
>> which would mean the card is not indicating "busy".
>> Either that is not working, or it seems like an issue with the card, in which case
>> it could be a card quirk perhaps.
> I was getting here on a setup with micro-to-SD adapter - I guess because of phy errors on one of the early card versions.
> On my other setups, the recovery flow wasn't triggered.
> What was happening is:
> mmc_blk_mq_req_done
> 	mmc_blk_mq_complete_prev_req
> 		mmc_blk_mq_poll_completion
> 			CMD13: 0: 00080900 00000000 00000000 00000000 = READY_FOR_DATA + ERROR
> 			mmc_blk_mq_rw_recovery
> 				mmc_sd_num_wr_blocks - bytes_xfered = 0
> 
> Consulting with our SD system guys, the 500msec must-have write timeout brought up,
> And fixed that.
> Shawn was interested in this as well - see the discussion in V3.

The spec reads like the timeout is for card busy.  If the card is
not indicating busy when it is busy, then that is an issue with
the card.

RE: [PATCH v4 9/9] mmc: core: Adjust ACMD22 to SDUC

[Avri Altman]

> On 26/08/24 10:26, Avri Altman wrote:
> >>> +     /*
> >>> +      * SD cards, specifically high volume cards, expect to be allowed with
> the
> >>> +      * full 500msec busy period post write. Otherwise, they may not
> indicate
> >>> +      * correctly the number of bytes written.
> >>> +      */
> >>> +     if (mmc_card_ult_capacity(card))
> >>> +             mmc_delay(500);
> >>
> >> To get here, it should have had to go through:
> >>
> >>         /* Try to get back to "tran" state */
> >>         if (!mmc_host_is_spi(mq->card->host) &&
> >>             (err || !mmc_ready_for_data(status)))
> >>                 err = mmc_blk_fix_state(mq->card, req);
> >>
> >> which would mean the card is not indicating "busy".
> >> Either that is not working, or it seems like an issue with the card,
> >> in which case it could be a card quirk perhaps.
> > I was getting here on a setup with micro-to-SD adapter - I guess because of
> phy errors on one of the early card versions.
> > On my other setups, the recovery flow wasn't triggered.
> > What was happening is:
> > mmc_blk_mq_req_done
> >       mmc_blk_mq_complete_prev_req
> >               mmc_blk_mq_poll_completion
> >                       CMD13: 0: 00080900 00000000 00000000 00000000 =
> READY_FOR_DATA + ERROR
> >                       mmc_blk_mq_rw_recovery
> >                               mmc_sd_num_wr_blocks - bytes_xfered = 0
> >
> > Consulting with our SD system guys, the 500msec must-have write
> > timeout brought up, And fixed that.
> > Shawn was interested in this as well - see the discussion in V3.
> 
> The spec reads like the timeout is for card busy.  If the card is not indicating
> busy when it is busy, then that is an issue with the card.
Will remove it.

Thanks,
Avri

Re: [PATCH v4 0/9] Add SDUC Support

[Adrian Hunter]

On 25/08/24 10:41, Avri Altman wrote:
> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.  Those
> cards support capacity larger than 2TB and up to including 128TB. Thus,
> the address range of the card expands beyond the 32-bit command
> argument. To that end, a new command - CMD22 is defined, to carry the
> extra 6-bit upper part of the 38-bit block address that enable access to
> 128TB memory space.
> 
> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II – Same
> as SDXC.
> 
> The spec defines several extensions/modifications to the current SDXC
> cards, which we address in patches 1 - 10.  Otherwise requirements are
> out-of-scope of this change.  Specifically, CMDQ (CMD44+CMD45), and
> Extension for Video Speed Class (CMD20).
> 
> First publication of SDUC was in [1].  This series was developed and
> tested separately from [1] and does not borrow from it.
> 
> [1] https://lwn.net/Articles/982566/

Perhaps add support for mmc_test, and it would be better
if enabling SDUC was the last patch, so bisecting doesn't
leave a kernel that half-supports SDUC.

> 
> ---
> Changes in v4:
>  - Squash patches 1 & 2 (Ulf)
>  - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
>  - Use card state instead of caps2 (Ricky & Ulf)
>  - Switch patches 5 & 6 (Ulf)
> 
> Changes in v3:
>  - Some more kernel test robot fixes
>  - Fix a typo in a commit log (Ricky WU)
>  - Fix ACMD22 returned value
>  - Add 'Tested-by' tag for the whole series (Ricky WU)
> 
> Changes in v2:
>  - Attend kernel test robot warnings
> 
> ---
> 
> Avri Altman (9):
>   mmc: sd: SDUC Support Recognition
>   mmc: sd: Add Extension memory addressing
>   mmc: core: Add open-ended Ext memory addressing
>   mmc: core: Add close-ended Ext memory addressing
>   mmc: host: Always use manual-cmd23 in SDUC
>   mmc: host: Add close-ended Ext memory addressing
>   mmc: core: Allow mmc erase to carry large addresses
>   mmc: core: Add Ext memory addressing for erase
>   mmc: core: Adjust ACMD22 to SDUC
> 
>  drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
>  drivers/mmc/core/bus.c    |  4 ++-
>  drivers/mmc/core/card.h   |  3 ++
>  drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++-----------
>  drivers/mmc/core/core.h   | 14 +++++++--
>  drivers/mmc/core/queue.h  |  1 +
>  drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
>  drivers/mmc/core/sd.h     |  2 +-
>  drivers/mmc/core/sd_ops.c | 16 ++++++++++
>  drivers/mmc/core/sd_ops.h |  1 +
>  drivers/mmc/core/sdio.c   |  2 +-
>  drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
>  include/linux/mmc/card.h  |  2 +-
>  include/linux/mmc/core.h  |  1 +
>  include/linux/mmc/sd.h    |  4 +++
>  15 files changed, 195 insertions(+), 50 deletions(-)
> 

RE: [PATCH v4 0/9] Add SDUC Support

[Avri Altman]

> 
> On 25/08/24 10:41, Avri Altman wrote:
> > Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.  Those
> > cards support capacity larger than 2TB and up to including 128TB.
> > Thus, the address range of the card expands beyond the 32-bit command
> > argument. To that end, a new command - CMD22 is defined, to carry the
> > extra 6-bit upper part of the 38-bit block address that enable access
> > to 128TB memory space.
> >
> > SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II –
> > Same as SDXC.
> >
> > The spec defines several extensions/modifications to the current SDXC
> > cards, which we address in patches 1 - 10.  Otherwise requirements are
> > out-of-scope of this change.  Specifically, CMDQ (CMD44+CMD45), and
> > Extension for Video Speed Class (CMD20).
> >
> > First publication of SDUC was in [1].  This series was developed and
> > tested separately from [1] and does not borrow from it.
> >
> > [1] https://lwn.net/Articles/982566/
> 
> Perhaps add support for mmc_test, and it would be better if enabling SDUC
> was the last patch, so bisecting doesn't leave a kernel that half-supports SDUC.
Done.

Thanks,
Avri

> 
> >
> > ---
> > Changes in v4:
> >  - Squash patches 1 & 2 (Ulf)
> >  - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
> >  - Use card state instead of caps2 (Ricky & Ulf)
> >  - Switch patches 5 & 6 (Ulf)
> >
> > Changes in v3:
> >  - Some more kernel test robot fixes
> >  - Fix a typo in a commit log (Ricky WU)
> >  - Fix ACMD22 returned value
> >  - Add 'Tested-by' tag for the whole series (Ricky WU)
> >
> > Changes in v2:
> >  - Attend kernel test robot warnings
> >
> > ---
> >
> > Avri Altman (9):
> >   mmc: sd: SDUC Support Recognition
> >   mmc: sd: Add Extension memory addressing
> >   mmc: core: Add open-ended Ext memory addressing
> >   mmc: core: Add close-ended Ext memory addressing
> >   mmc: host: Always use manual-cmd23 in SDUC
> >   mmc: host: Add close-ended Ext memory addressing
> >   mmc: core: Allow mmc erase to carry large addresses
> >   mmc: core: Add Ext memory addressing for erase
> >   mmc: core: Adjust ACMD22 to SDUC
> >
> >  drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
> >  drivers/mmc/core/bus.c    |  4 ++-
> >  drivers/mmc/core/card.h   |  3 ++
> >  drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++---------
> --
> >  drivers/mmc/core/core.h   | 14 +++++++--
> >  drivers/mmc/core/queue.h  |  1 +
> >  drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
> >  drivers/mmc/core/sd.h     |  2 +-
> >  drivers/mmc/core/sd_ops.c | 16 ++++++++++  drivers/mmc/core/sd_ops.h
> > |  1 +
> >  drivers/mmc/core/sdio.c   |  2 +-
> >  drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
> > include/linux/mmc/card.h  |  2 +-  include/linux/mmc/core.h  |  1 +
> >  include/linux/mmc/sd.h    |  4 +++
> >  15 files changed, 195 insertions(+), 50 deletions(-)
> >

RE: [PATCH v4 0/9] Add SDUC Support

[Avri Altman]

> > On 25/08/24 10:41, Avri Altman wrote:
> > > Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.
> > > Those cards support capacity larger than 2TB and up to including 128TB.
> > > Thus, the address range of the card expands beyond the 32-bit
> > > command argument. To that end, a new command - CMD22 is defined, to
> > > carry the extra 6-bit upper part of the 38-bit block address that
> > > enable access to 128TB memory space.
> > >
> > > SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II –
> > > Same as SDXC.
> > >
> > > The spec defines several extensions/modifications to the current
> > > SDXC cards, which we address in patches 1 - 10.  Otherwise
> > > requirements are out-of-scope of this change.  Specifically, CMDQ
> > > (CMD44+CMD45), and Extension for Video Speed Class (CMD20).
> > >
> > > First publication of SDUC was in [1].  This series was developed and
> > > tested separately from [1] and does not borrow from it.
> > >
> > > [1] https://lwn.net/Articles/982566/
> >
> > Perhaps add support for mmc_test
Actually, I am not sure what should be added to mmc_test as far as SDUC indication:
from dmesg we have:
[ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at address d555
[ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB

Additionally, we have the card size sysfs entry:
# cat /sys/block/mmcblk0/size
7999258624

As well as the csd which implies its capacity:
# cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd
800e0032db79007732bf7f800a404001

What test did you had in mind?

Thanks,
Avri

>>, and it would be better if enabling
> > SDUC was the last patch, so bisecting doesn't leave a kernel that half-supports
> SDUC.
> Done.
> 
> Thanks,
> Avri
> 
> >
> > >
> > > ---
> > > Changes in v4:
> > >  - Squash patches 1 & 2 (Ulf)
> > >  - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
> > >  - Use card state instead of caps2 (Ricky & Ulf)
> > >  - Switch patches 5 & 6 (Ulf)
> > >
> > > Changes in v3:
> > >  - Some more kernel test robot fixes
> > >  - Fix a typo in a commit log (Ricky WU)
> > >  - Fix ACMD22 returned value
> > >  - Add 'Tested-by' tag for the whole series (Ricky WU)
> > >
> > > Changes in v2:
> > >  - Attend kernel test robot warnings
> > >
> > > ---
> > >
> > > Avri Altman (9):
> > >   mmc: sd: SDUC Support Recognition
> > >   mmc: sd: Add Extension memory addressing
> > >   mmc: core: Add open-ended Ext memory addressing
> > >   mmc: core: Add close-ended Ext memory addressing
> > >   mmc: host: Always use manual-cmd23 in SDUC
> > >   mmc: host: Add close-ended Ext memory addressing
> > >   mmc: core: Allow mmc erase to carry large addresses
> > >   mmc: core: Add Ext memory addressing for erase
> > >   mmc: core: Adjust ACMD22 to SDUC
> > >
> > >  drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
> > >  drivers/mmc/core/bus.c    |  4 ++-
> > >  drivers/mmc/core/card.h   |  3 ++
> > >  drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++---------
> > --
> > >  drivers/mmc/core/core.h   | 14 +++++++--
> > >  drivers/mmc/core/queue.h  |  1 +
> > >  drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
> > >  drivers/mmc/core/sd.h     |  2 +-
> > >  drivers/mmc/core/sd_ops.c | 16 ++++++++++
> > > drivers/mmc/core/sd_ops.h
> > > |  1 +
> > >  drivers/mmc/core/sdio.c   |  2 +-
> > >  drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
> > > include/linux/mmc/card.h  |  2 +-  include/linux/mmc/core.h  |  1 +
> > >  include/linux/mmc/sd.h    |  4 +++
> > >  15 files changed, 195 insertions(+), 50 deletions(-)
> > >

Re: [PATCH v4 0/9] Add SDUC Support

[Adrian Hunter]

On 27/08/24 10:45, Avri Altman wrote:
>>> On 25/08/24 10:41, Avri Altman wrote:
>>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.
>>>> Those cards support capacity larger than 2TB and up to including 128TB.
>>>> Thus, the address range of the card expands beyond the 32-bit
>>>> command argument. To that end, a new command - CMD22 is defined, to
>>>> carry the extra 6-bit upper part of the 38-bit block address that
>>>> enable access to 128TB memory space.
>>>>
>>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II –
>>>> Same as SDXC.
>>>>
>>>> The spec defines several extensions/modifications to the current
>>>> SDXC cards, which we address in patches 1 - 10.  Otherwise
>>>> requirements are out-of-scope of this change.  Specifically, CMDQ
>>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20).
>>>>
>>>> First publication of SDUC was in [1].  This series was developed and
>>>> tested separately from [1] and does not borrow from it.
>>>>
>>>> [1] https://lwn.net/Articles/982566/
>>>
>>> Perhaps add support for mmc_test
> Actually, I am not sure what should be added to mmc_test as far as SDUC indication:
> from dmesg we have:
> [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at address d555
> [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB
> 
> Additionally, we have the card size sysfs entry:
> # cat /sys/block/mmcblk0/size
> 7999258624
> 
> As well as the csd which implies its capacity:
> # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd
> 800e0032db79007732bf7f800a404001
> 
> What test did you had in mind?

Doesn't all the I/O need CMD22 first?

> 
> Thanks,
> Avri
> 
>>> , and it would be better if enabling
>>> SDUC was the last patch, so bisecting doesn't leave a kernel that half-supports
>> SDUC.
>> Done.
>>
>> Thanks,
>> Avri
>>
>>>
>>>>
>>>> ---
>>>> Changes in v4:
>>>>  - Squash patches 1 & 2 (Ulf)
>>>>  - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
>>>>  - Use card state instead of caps2 (Ricky & Ulf)
>>>>  - Switch patches 5 & 6 (Ulf)
>>>>
>>>> Changes in v3:
>>>>  - Some more kernel test robot fixes
>>>>  - Fix a typo in a commit log (Ricky WU)
>>>>  - Fix ACMD22 returned value
>>>>  - Add 'Tested-by' tag for the whole series (Ricky WU)
>>>>
>>>> Changes in v2:
>>>>  - Attend kernel test robot warnings
>>>>
>>>> ---
>>>>
>>>> Avri Altman (9):
>>>>   mmc: sd: SDUC Support Recognition
>>>>   mmc: sd: Add Extension memory addressing
>>>>   mmc: core: Add open-ended Ext memory addressing
>>>>   mmc: core: Add close-ended Ext memory addressing
>>>>   mmc: host: Always use manual-cmd23 in SDUC
>>>>   mmc: host: Add close-ended Ext memory addressing
>>>>   mmc: core: Allow mmc erase to carry large addresses
>>>>   mmc: core: Add Ext memory addressing for erase
>>>>   mmc: core: Adjust ACMD22 to SDUC
>>>>
>>>>  drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
>>>>  drivers/mmc/core/bus.c    |  4 ++-
>>>>  drivers/mmc/core/card.h   |  3 ++
>>>>  drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++---------
>>> --
>>>>  drivers/mmc/core/core.h   | 14 +++++++--
>>>>  drivers/mmc/core/queue.h  |  1 +
>>>>  drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
>>>>  drivers/mmc/core/sd.h     |  2 +-
>>>>  drivers/mmc/core/sd_ops.c | 16 ++++++++++
>>>> drivers/mmc/core/sd_ops.h
>>>> |  1 +
>>>>  drivers/mmc/core/sdio.c   |  2 +-
>>>>  drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
>>>> include/linux/mmc/card.h  |  2 +-  include/linux/mmc/core.h  |  1 +
>>>>  include/linux/mmc/sd.h    |  4 +++
>>>>  15 files changed, 195 insertions(+), 50 deletions(-)
>>>>
> 

RE: [PATCH v4 0/9] Add SDUC Support

[Avri Altman]

> On 27/08/24 10:45, Avri Altman wrote:
> >>> On 25/08/24 10:41, Avri Altman wrote:
> >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.
> >>>> Those cards support capacity larger than 2TB and up to including 128TB.
> >>>> Thus, the address range of the card expands beyond the 32-bit
> >>>> command argument. To that end, a new command - CMD22 is defined, to
> >>>> carry the extra 6-bit upper part of the 38-bit block address that
> >>>> enable access to 128TB memory space.
> >>>>
> >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II –
> >>>> Same as SDXC.
> >>>>
> >>>> The spec defines several extensions/modifications to the current
> >>>> SDXC cards, which we address in patches 1 - 10.  Otherwise
> >>>> requirements are out-of-scope of this change.  Specifically, CMDQ
> >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20).
> >>>>
> >>>> First publication of SDUC was in [1].  This series was developed
> >>>> and tested separately from [1] and does not borrow from it.
> >>>>
> >>>> [1] https://lwn.net/Articles/982566/
> >>>
> >>> Perhaps add support for mmc_test
> > Actually, I am not sure what should be added to mmc_test as far as SDUC
> indication:
> > from dmesg we have:
> > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at address
> > d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB
> >
> > Additionally, we have the card size sysfs entry:
> > # cat /sys/block/mmcblk0/size
> > 7999258624
> >
> > As well as the csd which implies its capacity:
> > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd
> > 800e0032db79007732bf7f800a404001
> >
> > What test did you had in mind?
> 
> Doesn't all the I/O need CMD22 first?
Oops - Right.

Thanks a lot,
Avri

> 
> >
> > Thanks,
> > Avri
> >
> >>> , and it would be better if enabling SDUC was the last patch, so
> >>> bisecting doesn't leave a kernel that half-supports
> >> SDUC.
> >> Done.
> >>
> >> Thanks,
> >> Avri
> >>
> >>>
> >>>>
> >>>> ---
> >>>> Changes in v4:
> >>>>  - Squash patches 1 & 2 (Ulf)
> >>>>  - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
> >>>>  - Use card state instead of caps2 (Ricky & Ulf)
> >>>>  - Switch patches 5 & 6 (Ulf)
> >>>>
> >>>> Changes in v3:
> >>>>  - Some more kernel test robot fixes
> >>>>  - Fix a typo in a commit log (Ricky WU)
> >>>>  - Fix ACMD22 returned value
> >>>>  - Add 'Tested-by' tag for the whole series (Ricky WU)
> >>>>
> >>>> Changes in v2:
> >>>>  - Attend kernel test robot warnings
> >>>>
> >>>> ---
> >>>>
> >>>> Avri Altman (9):
> >>>>   mmc: sd: SDUC Support Recognition
> >>>>   mmc: sd: Add Extension memory addressing
> >>>>   mmc: core: Add open-ended Ext memory addressing
> >>>>   mmc: core: Add close-ended Ext memory addressing
> >>>>   mmc: host: Always use manual-cmd23 in SDUC
> >>>>   mmc: host: Add close-ended Ext memory addressing
> >>>>   mmc: core: Allow mmc erase to carry large addresses
> >>>>   mmc: core: Add Ext memory addressing for erase
> >>>>   mmc: core: Adjust ACMD22 to SDUC
> >>>>
> >>>>  drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
> >>>>  drivers/mmc/core/bus.c    |  4 ++-
> >>>>  drivers/mmc/core/card.h   |  3 ++
> >>>>  drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++---------
> >>> --
> >>>>  drivers/mmc/core/core.h   | 14 +++++++--
> >>>>  drivers/mmc/core/queue.h  |  1 +
> >>>>  drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
> >>>>  drivers/mmc/core/sd.h     |  2 +-
> >>>>  drivers/mmc/core/sd_ops.c | 16 ++++++++++
> >>>> drivers/mmc/core/sd_ops.h
> >>>> |  1 +
> >>>>  drivers/mmc/core/sdio.c   |  2 +-
> >>>>  drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
> >>>> include/linux/mmc/card.h  |  2 +-  include/linux/mmc/core.h  |  1 +
> >>>>  include/linux/mmc/sd.h    |  4 +++
> >>>>  15 files changed, 195 insertions(+), 50 deletions(-)
> >>>>
> >

RE: [PATCH v4 0/9] Add SDUC Support

[Avri Altman]

> > On 27/08/24 10:45, Avri Altman wrote:
> > >>> On 25/08/24 10:41, Avri Altman wrote:
> > >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.
> > >>>> Those cards support capacity larger than 2TB and up to including 128TB.
> > >>>> Thus, the address range of the card expands beyond the 32-bit
> > >>>> command argument. To that end, a new command - CMD22 is defined,
> > >>>> to carry the extra 6-bit upper part of the 38-bit block address
> > >>>> that enable access to 128TB memory space.
> > >>>>
> > >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II
> > >>>> – Same as SDXC.
> > >>>>
> > >>>> The spec defines several extensions/modifications to the current
> > >>>> SDXC cards, which we address in patches 1 - 10.  Otherwise
> > >>>> requirements are out-of-scope of this change.  Specifically, CMDQ
> > >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20).
> > >>>>
> > >>>> First publication of SDUC was in [1].  This series was developed
> > >>>> and tested separately from [1] and does not borrow from it.
> > >>>>
> > >>>> [1] https://lwn.net/Articles/982566/
> > >>>
> > >>> Perhaps add support for mmc_test
> > > Actually, I am not sure what should be added to mmc_test as far as
> > > SDUC
> > indication:
> > > from dmesg we have:
> > > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at
> > > address
> > > d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB
> > >
> > > Additionally, we have the card size sysfs entry:
> > > # cat /sys/block/mmcblk0/size
> > > 7999258624
> > >
> > > As well as the csd which implies its capacity:
> > > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd
> > > 800e0032db79007732bf7f800a404001
> > >
> > > What test did you had in mind?
> >
> > Doesn't all the I/O need CMD22 first?
So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable mmc_test for sduc.
How about disable it for now, planning to ameliorate it in the very near future?

Thanks,
Avri

> Oops - Right.
> 
> Thanks a lot,
> Avri
> 
> >
> > >
> > > Thanks,
> > > Avri
> > >
> > >>> , and it would be better if enabling SDUC was the last patch, so
> > >>> bisecting doesn't leave a kernel that half-supports
> > >> SDUC.
> > >> Done.
> > >>
> > >> Thanks,
> > >> Avri
> > >>
> > >>>
> > >>>>
> > >>>> ---
> > >>>> Changes in v4:
> > >>>>  - Squash patches 1 & 2 (Ulf)
> > >>>>  - Amend SD_OCR_2T to SD_OCR_CCS in mmc_sd_get_cid (Ulf)
> > >>>>  - Use card state instead of caps2 (Ricky & Ulf)
> > >>>>  - Switch patches 5 & 6 (Ulf)
> > >>>>
> > >>>> Changes in v3:
> > >>>>  - Some more kernel test robot fixes
> > >>>>  - Fix a typo in a commit log (Ricky WU)
> > >>>>  - Fix ACMD22 returned value
> > >>>>  - Add 'Tested-by' tag for the whole series (Ricky WU)
> > >>>>
> > >>>> Changes in v2:
> > >>>>  - Attend kernel test robot warnings
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> Avri Altman (9):
> > >>>>   mmc: sd: SDUC Support Recognition
> > >>>>   mmc: sd: Add Extension memory addressing
> > >>>>   mmc: core: Add open-ended Ext memory addressing
> > >>>>   mmc: core: Add close-ended Ext memory addressing
> > >>>>   mmc: host: Always use manual-cmd23 in SDUC
> > >>>>   mmc: host: Add close-ended Ext memory addressing
> > >>>>   mmc: core: Allow mmc erase to carry large addresses
> > >>>>   mmc: core: Add Ext memory addressing for erase
> > >>>>   mmc: core: Adjust ACMD22 to SDUC
> > >>>>
> > >>>>  drivers/mmc/core/block.c  | 56 ++++++++++++++++++++++++++++------
> > >>>>  drivers/mmc/core/bus.c    |  4 ++-
> > >>>>  drivers/mmc/core/card.h   |  3 ++
> > >>>>  drivers/mmc/core/core.c   | 63 ++++++++++++++++++++++++++++--------
> -
> > >>> --
> > >>>>  drivers/mmc/core/core.h   | 14 +++++++--
> > >>>>  drivers/mmc/core/queue.h  |  1 +
> > >>>>  drivers/mmc/core/sd.c     | 36 ++++++++++++++--------
> > >>>>  drivers/mmc/core/sd.h     |  2 +-
> > >>>>  drivers/mmc/core/sd_ops.c | 16 ++++++++++
> > >>>> drivers/mmc/core/sd_ops.h
> > >>>> |  1 +
> > >>>>  drivers/mmc/core/sdio.c   |  2 +-
> > >>>>  drivers/mmc/host/sdhci.c  | 40 +++++++++++++++++++++----
> > >>>> include/linux/mmc/card.h  |  2 +-  include/linux/mmc/core.h  |  1 +
> > >>>>  include/linux/mmc/sd.h    |  4 +++
> > >>>>  15 files changed, 195 insertions(+), 50 deletions(-)
> > >>>>
> > >

Re: [PATCH v4 0/9] Add SDUC Support

[Adrian Hunter]

On 27/08/24 13:58, Avri Altman wrote:
>>> On 27/08/24 10:45, Avri Altman wrote:
>>>>>> On 25/08/24 10:41, Avri Altman wrote:
>>>>>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.
>>>>>>> Those cards support capacity larger than 2TB and up to including 128TB.
>>>>>>> Thus, the address range of the card expands beyond the 32-bit
>>>>>>> command argument. To that end, a new command - CMD22 is defined,
>>>>>>> to carry the extra 6-bit upper part of the 38-bit block address
>>>>>>> that enable access to 128TB memory space.
>>>>>>>
>>>>>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II
>>>>>>> – Same as SDXC.
>>>>>>>
>>>>>>> The spec defines several extensions/modifications to the current
>>>>>>> SDXC cards, which we address in patches 1 - 10.  Otherwise
>>>>>>> requirements are out-of-scope of this change.  Specifically, CMDQ
>>>>>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20).
>>>>>>>
>>>>>>> First publication of SDUC was in [1].  This series was developed
>>>>>>> and tested separately from [1] and does not borrow from it.
>>>>>>>
>>>>>>> [1] https://lwn.net/Articles/982566/
>>>>>>
>>>>>> Perhaps add support for mmc_test
>>>> Actually, I am not sure what should be added to mmc_test as far as
>>>> SDUC
>>> indication:
>>>> from dmesg we have:
>>>> [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at
>>>> address
>>>> d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB
>>>>
>>>> Additionally, we have the card size sysfs entry:
>>>> # cat /sys/block/mmcblk0/size
>>>> 7999258624
>>>>
>>>> As well as the csd which implies its capacity:
>>>> # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd
>>>> 800e0032db79007732bf7f800a404001
>>>>
>>>> What test did you had in mind?
>>>
>>> Doesn't all the I/O need CMD22 first?
> So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable mmc_test for sduc.
> How about disable it for now, planning to ameliorate it in the very near future?

Ok by me.

Re: [PATCH v4 0/9] Add SDUC Support

[Ulf Hansson]

On Tue, 27 Aug 2024 at 12:58, Avri Altman <Avri.Altman@wdc.com> wrote:
>
> > > On 27/08/24 10:45, Avri Altman wrote:
> > > >>> On 25/08/24 10:41, Avri Altman wrote:
> > > >>>> Ultra Capacity SD cards (SDUC) was already introduced in SD7.0.
> > > >>>> Those cards support capacity larger than 2TB and up to including 128TB.
> > > >>>> Thus, the address range of the card expands beyond the 32-bit
> > > >>>> command argument. To that end, a new command - CMD22 is defined,
> > > >>>> to carry the extra 6-bit upper part of the 38-bit block address
> > > >>>> that enable access to 128TB memory space.
> > > >>>>
> > > >>>> SDUC capacity is agnostic to the interface mode: UHS-I and UHS-II
> > > >>>> – Same as SDXC.
> > > >>>>
> > > >>>> The spec defines several extensions/modifications to the current
> > > >>>> SDXC cards, which we address in patches 1 - 10.  Otherwise
> > > >>>> requirements are out-of-scope of this change.  Specifically, CMDQ
> > > >>>> (CMD44+CMD45), and Extension for Video Speed Class (CMD20).
> > > >>>>
> > > >>>> First publication of SDUC was in [1].  This series was developed
> > > >>>> and tested separately from [1] and does not borrow from it.
> > > >>>>
> > > >>>> [1] https://lwn.net/Articles/982566/
> > > >>>
> > > >>> Perhaps add support for mmc_test
> > > > Actually, I am not sure what should be added to mmc_test as far as
> > > > SDUC
> > > indication:
> > > > from dmesg we have:
> > > > [ 4253.922220] mmc0: new ultra high speed SDR104 SDUC card at
> > > > address
> > > > d555 [ 4253.922409] mmcblk0: mmc0:d555 SR04T 3.72 TiB
> > > >
> > > > Additionally, we have the card size sysfs entry:
> > > > # cat /sys/block/mmcblk0/size
> > > > 7999258624
> > > >
> > > > As well as the csd which implies its capacity:
> > > > # cd /sys/class/mmc_host/mmc0/mmc0:* && cat csd
> > > > 800e0032db79007732bf7f800a404001
> > > >
> > > > What test did you had in mind?
> > >
> > > Doesn't all the I/O need CMD22 first?
> So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable mmc_test for sduc.
> How about disable it for now, planning to ameliorate it in the very near future?

Don't get me wrong, I am fine by this too, as Adrian.

However, the purpose of adding support for SDUC to mmc_test would also
be to help us test while developing the new code too.

[...]

Kind regards
Uffe

RE: [PATCH v4 0/9] Add SDUC Support

[Avri Altman]

> > > > > What test did you had in mind?
> > > >
> > > > Doesn't all the I/O need CMD22 first?
> > So I tried to add it, and it looks like I'll be needing 2 - 3 patches to enable
> mmc_test for sduc.
> > How about disable it for now, planning to ameliorate it in the very near future?
> 
> Don't get me wrong, I am fine by this too, as Adrian.
> 
> However, the purpose of adding support for SDUC to mmc_test would also be to
> help us test while developing the new code too.
Thanks.  Its on my very next to-do list.
Right after properly documenting mmc_test.

Thanks,
Avri

> 
> [...]
> 
> Kind regards
> Uffe