| Message ID | 2f6ac51155f9d34791b274b5102d15a997ff8b99.1396384101.git.stefan@agner.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 04/01/2014 02:35 PM, stefan@agner.ch wrote: > From: Stefan Agner <stefan@agner.ch> > > By using the SD/MMC host device ID as a starting point for block > device numbering, one can reliably predict the first block device > name (at least for the first controller). That's not true. There's no guarantee that a device name/ID gets released as soon as the SD card is removed; something might still have it mounted for example. The correct solution here is to use filesystem or partition UUIDs to identify the device/partition, not to attempt to assign static device IDs. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Stefan, On Tue, Apr 1, 2014 at 1:35 PM, <stefan@agner.ch> wrote: > From: Stefan Agner <stefan@agner.ch> > > By using the SD/MMC host device ID as a starting point for block > device numbering, one can reliably predict the first block device > name (at least for the first controller). This is especially useful > for SoCs with multiple SD/MMC host controller, where the controller > with index 0 is connected to a eMMC device. > > Usually the first controller gets the first block device name ID, > however this is not guaranteed. Also if the first controller is > aliased as second controller and visa-versa (using device tree > aliases), the block device name ID assignation is not ordered by > the SD/MMC host device ID (since mmc_rescan is called in order of > the memory mapped pheripherial addresses). > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > drivers/mmc/card/block.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) As Stephen points out, "mmcblk" IDs for SD cards are not actually guaranteed. Also UUID is a better API for things to use. That being said, your patch helps me a lot when doing development. As you said, I'm guaranteed that if eMMC is no-removable and enumerated at boot that it will be a predictable ID and I can use it in my scripts. Also this helps keep me from having to do lots of extra thinking to figure out whether I happened to have an SD card plugged in at boot or I didn't. I'd love to see this land. Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org> -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 7b5424f..03626ed 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -2045,7 +2045,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card, * index anymore so we keep track of a name index. */ if (!subname) { - md->name_idx = find_first_zero_bit(name_use, max_devices); + md->name_idx = find_next_zero_bit(name_use, max_devices, + card->host->index); __set_bit(md->name_idx, name_use); } else md->name_idx = ((struct mmc_blk_data *)