[PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index

[PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index

[Dirk Behme]

On embedded devices, often there is a combination of removable mmc
devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
Depending on the hardware configuration, the 'mmcblkN' node might
change if the removable device is available or not at boot time.

E.g. if the removable device is attached at boot time, it might
become mmxblk0. And the hard wired one mmcblk1. But if the removable
device isn't there at boot time, the hard wired one will become
mmcblk0. This makes it somehow difficult to hard code the root device
to the non-removable device and boot fast.

This change does simply associate 'N' of 'mmcblkN' with the slot index
instead of the dynamic name index. The slot index is always the same,
ensuring that the non-removable mmc device is associated always
with the same mmcblkN. Independent of the availability of the removable
one.

This issue has a long history. One prominent one is e.g. from the
Maemo based Nokia N810 device:

https://bugs.maemo.org/show_bug.cgi?id=2747

Signed-off-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
CC: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/card/block.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index f1c84de..a01d306 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1517,7 +1517,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 	 */
 
 	snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
-		 "mmcblk%d%s", md->name_idx, subname ? subname : "");
+		 "mmcblk%d%s", card->host->index, subname ? subname : "");
 
 	if (mmc_card_mmc(card))
 		blk_queue_logical_block_size(md->queue.queue,
-- 
1.7.0.4

[PATCH 2/2] mmc: block: remove unused name_idx

[Dirk Behme]

With the previous patch "mmc: block: mmcblkN: use slot index instead of
dynamic name index" name_idx is not needed any more.

Signed-off-by: Dirk Behme <dirk.behme-V5te9oGctAVWk0Htik3J/w@public.gmane.org>
CC: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CC: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
---
 drivers/mmc/card/block.c |   16 ----------------
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a01d306..555d840 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -74,7 +74,6 @@ static int max_devices;
 
 /* 256 minors, so at most 256 separate devices */
 static DECLARE_BITMAP(dev_use, 256);
-static DECLARE_BITMAP(name_use, 256);
 
 /*
  * There is one mmc_blk_data per slot.
@@ -92,7 +91,6 @@ struct mmc_blk_data {
 	unsigned int	usage;
 	unsigned int	read_only;
 	unsigned int	part_type;
-	unsigned int	name_idx;
 	unsigned int	reset_done;
 #define MMC_BLK_READ		BIT(0)
 #define MMC_BLK_WRITE		BIT(1)
@@ -1458,19 +1456,6 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 		goto out;
 	}
 
-	/*
-	 * !subname implies we are creating main mmc_blk_data that will be
-	 * associated with mmc_card with mmc_set_drvdata. Due to device
-	 * partitions, devidx will not coincide with a per-physical card
-	 * index anymore so we keep track of a name index.
-	 */
-	if (!subname) {
-		md->name_idx = find_first_zero_bit(name_use, max_devices);
-		__set_bit(md->name_idx, name_use);
-	} else
-		md->name_idx = ((struct mmc_blk_data *)
-				dev_to_disk(parent)->private_data)->name_idx;
-
 	md->area_type = area_type;
 
 	/*
@@ -1660,7 +1645,6 @@ static void mmc_blk_remove_parts(struct mmc_card *card,
 	struct list_head *pos, *q;
 	struct mmc_blk_data *part_md;
 
-	__clear_bit(md->name_idx, name_use);
 	list_for_each_safe(pos, q, &md->part) {
 		part_md = list_entry(pos, struct mmc_blk_data, part);
 		list_del(pos);
-- 
1.7.0.4

Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index

[Chris Ball]

Hi,

On Mon, Aug 06 2012, Dirk Behme wrote:
> On embedded devices, often there is a combination of removable mmc
> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
> Depending on the hardware configuration, the 'mmcblkN' node might
> change if the removable device is available or not at boot time.
>
> E.g. if the removable device is attached at boot time, it might
> become mmxblk0. And the hard wired one mmcblk1. But if the removable
> device isn't there at boot time, the hard wired one will become
> mmcblk0. This makes it somehow difficult to hard code the root device
> to the non-removable device and boot fast.
>
> This change does simply associate 'N' of 'mmcblkN' with the slot index
> instead of the dynamic name index. The slot index is always the same,
> ensuring that the non-removable mmc device is associated always
> with the same mmcblkN. Independent of the availability of the removable
> one.

I like this change in principle, but doesn't it break boot for everyone
currently using e.g. root=/dev/mmcblk0p1 on slot index 2?  That doesn't
sound like an acceptable regression.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index

[Jassi Brar]

On 6 August 2012 21:01, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> On Mon, Aug 06 2012, Dirk Behme wrote:
>> On embedded devices, often there is a combination of removable mmc
>> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
>> Depending on the hardware configuration, the 'mmcblkN' node might
>> change if the removable device is available or not at boot time.
>>
>> E.g. if the removable device is attached at boot time, it might
>> become mmxblk0. And the hard wired one mmcblk1. But if the removable
>> device isn't there at boot time, the hard wired one will become
>> mmcblk0. This makes it somehow difficult to hard code the root device
>> to the non-removable device and boot fast.
>>
>> This change does simply associate 'N' of 'mmcblkN' with the slot index
>> instead of the dynamic name index. The slot index is always the same,
>> ensuring that the non-removable mmc device is associated always
>> with the same mmcblkN. Independent of the availability of the removable
>> one.
>
> I like this change in principle, but doesn't it break boot for everyone
> currently using e.g. root=/dev/mmcblk0p1 on slot index 2?  That doesn't
> sound like an acceptable regression.
>
It shouldn't break boot for any user already doing the right thing.
If the user's platform probes only slot-2, it will still be 'mmcblk0'
If the platform probes slot-1 & 2, it is fundamentally unsafe to count
upon the card in slot-2 to be enumerated before the one in slot-1.

Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index

[Dirk Behme]

Hi Chris,

On 06.08.2012 17:31, Chris Ball wrote:
> Hi,
> 
> On Mon, Aug 06 2012, Dirk Behme wrote:
>> On embedded devices, often there is a combination of removable mmc
>> devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
>> Depending on the hardware configuration, the 'mmcblkN' node might
>> change if the removable device is available or not at boot time.
>>
>> E.g. if the removable device is attached at boot time, it might
>> become mmxblk0. And the hard wired one mmcblk1. But if the removable
>> device isn't there at boot time, the hard wired one will become
>> mmcblk0. This makes it somehow difficult to hard code the root device
>> to the non-removable device and boot fast.
>>
>> This change does simply associate 'N' of 'mmcblkN' with the slot index
>> instead of the dynamic name index. The slot index is always the same,
>> ensuring that the non-removable mmc device is associated always
>> with the same mmcblkN. Independent of the availability of the removable
>> one.
> 
> I like this change in principle,

Thanks :)

> but doesn't it break boot for everyone
> currently using e.g. root=/dev/mmcblk0p1 on slot index 2?  That doesn't
> sound like an acceptable regression.

I'm not really an expert of the code in block.c. Could you imagine a 
change which has the same result we'd like to get with the proposed 
patch but doesn't have the regression you mention?

Many thanks and best regards

Dirk