Re: [RFC 2/2] mmc: use SD/MMC host ID for block device name ID
From: Doug Anderson
Date: Wed Aug 06 2014 - 15:50:39 EST
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/