Re: [PATCH v7] mmc : general purpose partition support.

[NamJae Jeon]

2011/10/3 Sebastian Rasmussen <sebras@xxxxxxxxx>:
> Hi!
>
>> It allows gerneral purpose partitions in MMC Device.
>
> Reading this patch raised a few questions with me. I hope
> you can find some time to answer some of them.
>
>> And I try to simpliy make mmc_blk_alloc_parts using mmc_part structure suggested by Andrei Warkentin.
>> After patching, we can see general purpose partitions like this.
>>> cat /proc/partitions
>> Â Â Â Â Â179 0 847872 mmcblk0
>> Â Â Â Â Â179 192 4096 mmcblk0gp3
>> Â Â Â Â Â179 160 4096 mmcblk0gp2
>> Â Â Â Â Â179 128 4096 mmcblk0gp1
>> Â Â Â Â Â179 96 Â1052672 mmcblk0gp0
>> Â Â Â Â Â179 64 Â1024 mmcblk0boot1
>> Â Â Â Â Â179 32 Â1024 mmcblk0boot0
>>
>> Signed-off-by: Namjae Jeon <linkinjeon@xxxxxxxxx>
>> ---
>> Âdrivers/mmc/card/block.c | Â 31 +++++++++++++++++--------------
>> Âdrivers/mmc/core/mmc.c  |  45 +++++++++++++++++++++++++++++++++++++++++++--
>> Âinclude/linux/mmc/card.h | Â 33 ++++++++++++++++++++++++++++++++-
>> Âinclude/linux/mmc/mmc.h Â| Â Â2 +-
>> Â4 files changed, 93 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index 1ff5486..56f7185 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1377,26 +1377,29 @@ static int mmc_blk_alloc_part(struct mmc_card *card,
>> Â Â Â Âreturn 0;
>> Â}
>>
>> +/* MMC Physical partition consist of two boot partitons and
>> + * four general purpose partitions.
>
> up to four general purpose partitions.
Hi~
I will add.
>
>> + * if the register of respective partitions is set in ext_csd,
>> + * it allocate block device to be accessed.
>
> For each partition enabled in EXT_CSD a block device will
> be allocated to provide access to the partition.
I wiil modify also.
>
>> + */
>> +
>> Âstatic int mmc_blk_alloc_parts(struct mmc_card *card, struct mmc_blk_data *md)
>> Â{
>> - Â Â Â int ret = 0;
>> + Â Â Â int idx, ret = 0;
>>
>> Â Â Â Âif (!mmc_card_mmc(card))
>> Â Â Â Â Â Â Â Âreturn 0;
>>
>> - Â Â Â if (card->ext_csd.boot_size) {
>> - Â Â Â Â Â Â Â ret = mmc_blk_alloc_part(card, md, EXT_CSD_PART_CONFIG_ACC_BOOT0,
>> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âcard->ext_csd.boot_size >> 9,
>> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âtrue,
>> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â"boot0");
>> - Â Â Â Â Â Â Â if (ret)
>> - Â Â Â Â Â Â Â Â Â Â Â return ret;
>> - Â Â Â Â Â Â Â ret = mmc_blk_alloc_part(card, md, EXT_CSD_PART_CONFIG_ACC_BOOT1,
>> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âcard->ext_csd.boot_size >> 9,
>> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âtrue,
>> - Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â"boot1");
>> - Â Â Â Â Â Â Â if (ret)
>> - Â Â Â Â Â Â Â Â Â Â Â return ret;
>> + Â Â Â Âfor (idx = 0; idx < card->nr_parts; idx++) {
>> + Â Â Â Â Â Â Â if (card->part[idx].size) {
>> + Â Â Â Â Â Â Â Â Â Â Â ret = mmc_blk_alloc_part(card, md,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â card->part[idx].cookie,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â card->part[idx].size >> 9,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â card->part[idx].force_ro,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â card->part[idx].name);
>> + Â Â Â Â Â Â Â Â Â Â Â if (ret)
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â return ret;
>> + Â Â Â Â Â Â Â }
>> Â Â Â Â}
>>
>> Â Â Â Âreturn ret;
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 5700b1c..818778f 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -239,7 +239,8 @@ static int mmc_get_ext_csd(struct mmc_card *card, u8 **new_ext_csd)
>> Â*/
>> Âstatic int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>> Â{
>> - Â Â Â int err = 0;
>> + Â Â Â int err = 0, idx;
>> + Â Â Â unsigned int part_size, gp_size_mult;
>>
>> Â Â Â ÂBUG_ON(!card);
>>
>> @@ -340,7 +341,15 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>> Â Â Â Â Â Â Â Â * There are two boot regions of equal size, defined in
>> Â Â Â Â Â Â Â Â * multiples of 128K.
>> Â Â Â Â Â Â Â Â */
>> - Â Â Â Â Â Â Â card->ext_csd.boot_size = ext_csd[EXT_CSD_BOOT_MULT] << 17;
>> + Â Â Â Â Â Â Â if (ext_csd[EXT_CSD_BOOT_MULT]) {
>> + Â Â Â Â Â Â Â Â Â Â Â for (idx = 0; idx < MMC_NUM_BOOT_PARTITION;
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â idx++) {
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â part_size = ext_csd[EXT_CSD_BOOT_MULT] << 17;
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â mmc_part_add(card, part_size,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â EXT_CSD_PART_CONFIG_ACC_BOOT0 + idx,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "boot%d", idx, true);
>> + Â Â Â Â Â Â Â Â Â Â Â }
>> + Â Â Â Â Â Â Â }
>> Â Â Â Â}
>>
>> Â Â Â Âcard->ext_csd.raw_hc_erase_gap_size =
>> @@ -392,6 +401,38 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
>> Â Â Â Â Â Â Â Â Â Â Â Âcard->ext_csd.enhanced_area_offset = -EINVAL;
>> Â Â Â Â Â Â Â Â Â Â Â Âcard->ext_csd.enhanced_area_size = -EINVAL;
>> Â Â Â Â Â Â Â Â}
>> +
>> + Â Â Â Â Â Â Â /*
>> + Â Â Â Â Â Â Â Â* General purpose partition feature support --
>> + Â Â Â Â Â Â Â Â* If ext_csd have the size of general purpose partitions,
>> + Â Â Â Â Â Â Â Â* set size, part_type, partition name in mmc_part.
>
> What does part_type refer to?
it refer to cookie, and it will be used for part_type.
I will modify with below your suggestion.
>
>> + Â Â Â Â Â Â Â Â*/
>> +
>> + Â Â Â Â Â Â Â if (ext_csd[EXT_CSD_PARTITION_SUPPORT] & 0x1) {
>
> Maybe #define PARTITIONING_EN (0x1) in mmc.h somewhere?
>
>> + Â Â Â Â Â Â Â Â Â Â Â u8 hc_erase_grp_sz =
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE];
>> + Â Â Â Â Â Â Â Â Â Â Â u8 hc_wp_grp_sz =
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â card->ext_csd.enhanced_area_en = 1;
>
> Why is it ok to unconditionally enable this without checking
> ext_csd[EXT_CSD_PARTITION_SUPPORT] & 0x02, i.e.
> ENH_ATTRIBUTE_EN?
yes, it can dupilicatley set in case of user ehanced area is set.
I will add.
>
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â for (idx = 0, gp_size_mult = 143;
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â idx < MMC_NUM_GP_PARTITION;
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â idx++, gp_size_mult += 3) {
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (!ext_csd[gp_size_mult] &&
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â !ext_csd[gp_size_mult + 1] &&
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â !ext_csd[gp_size_mult + 2])
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â part_size = (ext_csd[gp_size_mult + 2] << 16) +
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (ext_csd[gp_size_mult + 1] << 8) +
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ext_csd[gp_size_mult];
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â part_size *= (size_t)(hc_erase_grp_sz *
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â hc_wp_grp_sz);
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â mmc_part_add(card, part_size <<= 19,
>
> Is <<= really a valid operator? Does this even compile?
yes, it is compiled without problem. but I will modify part_size << 19.
>
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â EXT_CSD_PART_CONFIG_ACC_GP0 + idx,
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "gp%d", idx, false);
>> + Â Â Â Â Â Â Â Â Â Â Â }
>
> I think the gp_size_mult being set to 143 is a magic number
> not very well explained. Also I'm of the opinion that the code
> above could be improved upon readability-wise. Below you
> find my suggestion. This would loose the gp_size_mult variable
> and instead depend on a proper constant that should go in mmc.h.
> Mind you I haven't compiled or tested the code below.
yes, I agree. I followed current other code. As you know, user
enhanced area set code is used to constant value directly.
I think that your opinion is correct.
and.. I don't know why idx * 3 is used.
>
> #define EXT_CSD_GP_SIZE_MULT_X_Y Â Â143 /* R/W */
>
> for (idx = 0; idx < MMC_NUM_GP_PARTITION; idx++)
> {
> Â Â Â Âpart_size =
> Â Â Â Â Â Â Â Â(ext_csd[EXT_CSD_GP_SIZE_MULT_X_Y + idx * 3 + 2] << 16) |
> Â Â Â Â Â Â Â Â(ext_csd[EXT_CSD_GP_SIZE_MULT_X_Y + idx * 3 + 1] << Â8) |
> Â Â Â Â Â Â Â Â(ext_csd[EXT_CSD_GP_SIZE_MULT_X_Y + idx * 3] << 0);
>
> Â Â Â Âpart_size *= (size_t)(hc_erase_grp_sz * hc_wp_grp_sz);
>
> Â Â Â Âif (part_size)
> Â Â Â Â Â Âmmc_part_add(card, part_size << 19,
> Â Â Â Â Â Â Â Â Â ÂEXT_CSD_PART_CONFIG_ACC_GP0 + idx,
> Â Â Â Â Â Â Â Â Â Â"gp%d", idx, false);
>
> }
>
>> + Â Â Â Â Â Â Â }
>> Â Â Â Â Â Â Â Âcard->ext_csd.sec_trim_mult =
>> Â Â Â Â Â Â Â Â Â Â Â Âext_csd[EXT_CSD_SEC_TRIM_MULT];
>> Â Â Â Â Â Â Â Âcard->ext_csd.sec_erase_mult =
>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>> index b460fc2..550c2ed 100644
>> --- a/include/linux/mmc/card.h
>> +++ b/include/linux/mmc/card.h
>> @@ -12,6 +12,7 @@
>>
>> Â#include <linux/mmc/core.h>
>> Â#include <linux/mod_devicetable.h>
>> +#include <linux/genhd.h>
>>
>> Âstruct mmc_cid {
>>    Âunsigned int      Âmanfid;
>> @@ -63,7 +64,6 @@ struct mmc_ext_csd {
>>    Âbool          Âenhanced_area_en;    /* enable bit */
>>    Âunsigned long long   Âenhanced_area_offset;  /* Units: Byte */
>>    Âunsigned int      Âenhanced_area_size;   /* Units: KB */
>> -    unsigned int      Âboot_size;       Â/* in bytes */
>> Â Â Â Âu8 Â Â Â Â Â Â Â Â Â Â Âraw_partition_support; Â/* 160 */
>> Â Â Â Âu8 Â Â Â Â Â Â Â Â Â Â Âraw_erased_mem_count; Â /* 181 */
>> Â Â Â Âu8 Â Â Â Â Â Â Â Â Â Â Âraw_ext_csd_structure; Â/* 194 */
>> @@ -157,6 +157,22 @@ struct sdio_func_tuple;
>>
>> Â#define SDIO_MAX_FUNCS Â Â Â Â 7
>>
>> +/* The number of MMC physical partitions
>> + * It consist of boot partitions(2), general purpose partitions(4) in MMC v4.4
>> + */
>> +#define MMC_NUM_BOOT_PARTITION 2
>> +#define MMC_NUM_GP_PARTITION Â 4
>
> Just to make the code above a little easier to fit into 80 characters,
> maybe these should be known as MMC_BOOT_PARTS and
> MMC_GENERAL_PARTS? That also expands the GP acronym
> without making it too unwieldy.
As you know, any other fields was also over 80 characters in struct
card. So I thought that it is permitted in this structure.
And the meaning of GP should be "General Purpose"
>
>> +
>> +/*
>> + * MMC Physical partitions
>> + */
>> +struct mmc_part {
>> +    unsigned int  Âsize;  /* partition size (in bytes) */
>> +    unsigned int  Âcookie; /* it used to part_type */
>
> This information seems to be called part_type, cookie and
> part_cfg in different parts of your patch. A common name
> used everywhere is preferable, maybe settle on part_type?
It called to partition config in ext_csd filed. so I used part_config
name when using this value first.
And I think that cookie meaning is shortly stored and used.
so I used it. so I think that these have each meaning.
I can change part_config in mmc_part instead of cookie.
how do you think ?

Thanks for your review.
>
>> +    char  Âname[DISK_NAME_LEN];
>> +    bool  Âforce_ro;    /* to make boot parts RO by default */
>> +};
>> +
>> Â/*
>> Â* MMC device
>> Â*/
>> @@ -216,9 +232,24 @@ struct mmc_card {
>>    Âunsigned int      Âsd_bus_speed;  /* Bus Speed Mode set for the card */
>>
>>    Âstruct dentry      *debugfs_root;
>> + Â Â Â struct mmc_part part[MMC_NUM_BOOT_PARTITION + MMC_NUM_GP_PARTITION]; Â Â/* mmc physical partitions */
>> +    unsigned int  Ânr_parts;
>> Â};
>>
>> Â/*
>> + * This function fill contents in mmc_part.
>> + */
>> +static inline void mmc_part_add(struct mmc_card *card, unsigned int size,
>> + Â Â Â unsigned int part_cfg, char *name, int idx, bool ro)
>> +{
>> + Â Â Â card->part[card->nr_parts].size = size;
>> + Â Â Â card->part[card->nr_parts].cookie = part_cfg;
>> + Â Â Â sprintf(card->part[card->nr_parts].name, name, idx);
>> + Â Â Â card->part[card->nr_parts].force_ro = ro;
>> + Â Â Â card->nr_parts++;
>> +}
>> +
>> +/*
>> Â* ÂThe world is not perfect and supplies us with broken mmc/sdio devices.
>> Â* ÂFor at least some of these bugs we need a work-around.
>> Â*/
>> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
>> index 5a794cb..29b7cb6 100644
>> --- a/include/linux/mmc/mmc.h
>> +++ b/include/linux/mmc/mmc.h
>> @@ -302,7 +302,7 @@ struct _mmc_csd {
>>
>> Â#define EXT_CSD_PART_CONFIG_ACC_MASK Â (0x7)
>> Â#define EXT_CSD_PART_CONFIG_ACC_BOOT0 Â(0x1)
>> -#define EXT_CSD_PART_CONFIG_ACC_BOOT1 Â(0x2)
>> +#define EXT_CSD_PART_CONFIG_ACC_GP0 Â Â(0x4)
>>
>> Â#define EXT_CSD_CMD_SET_NORMAL Â Â Â Â (1<<0)
>> Â#define EXT_CSD_CMD_SET_SECURE Â Â Â Â (1<<1)
>> --
>> 1.7.4.4
>>
>>
>
> Â/ Sebastian
>
N‹§²æìr¸›yúèšØb²X¬¶ÇvØ^–)Þ{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü}©ž²ÆzÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ßf”ù^jÇy§m…á@A«a¶Úÿ0¶ìh®å’i