Stefan, On Tue, Apr 1, 2014 at 1:35 PM, <stefan@xxxxxxxx> wrote: > From: Stefan Agner <stefan@xxxxxxxx> > > 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@xxxxxxxx> > --- > 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@xxxxxxxxxxxx> Tested-by: Doug Anderson <dianders@xxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
