Dynamic MMC device naming vs. bootloaders

Dynamic MMC device naming vs. bootloaders

[Stephen Warren]

Chris et. al.,

I'm working on an ARM system that contains at least two MMC/SD devices;
specifically the board has an internal MMC device, and an SD card slot,
although the SoC has four MMC/SD hosts IIRC.

The kernel's naming of these devices is dynamic. If the SD card is not
plugged in, the internal MMC is always known as mmcblock0. If the SD card
is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
them "in order", whereas 2.6.38 usually seems to name them "backwards".

This causes problems with the bootloader scripts I'm using, which assumes
that the internal MMC is always device 0 and the SD slot is always device 1,
and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
is searched for a valid image first by the bootloader).

This could be solved by naming the kernel MMC devices statically based on
the host controller, rather than dynamically based on the first available
ID when the actual storage is detected. The patch below implements this.

Is this patch conceptually acceptable for the MMC driver? Obviously, a
complete patch would need to also remove the dev_use structure etc.

Another solution might be for the kernel command-line to specify the
filesystem UUID, rather than a device node. However, this entails much more
work for the bootloader. I'm not sure whether U-Boot can do this right now?
And actually, the filesystem images I'm using don't always have a UUID by
dDefault IIRC.

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index bfc8a8a..5131b02 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -581,7 +581,7 @@ static struct mmc_blk_data *mmc_blk_alloc(struct mmc_card *card)
        struct mmc_blk_data *md;
        int devidx, ret;
 
-       devidx = find_first_zero_bit(dev_use, max_devices);
+       devidx = card->host->index;
        if (devidx >= max_devices)
                return ERR_PTR(-ENOSPC);
        __set_bit(devidx, dev_use);

Thanks for any feedback.

-- 
nvpublic

Re: Dynamic MMC device naming vs. bootloaders

[Chris Ball]

Hi Stephen,

On Mon, Apr 04 2011, Stephen Warren wrote:
> Chris et. al.,
>
> I'm working on an ARM system that contains at least two MMC/SD devices;
> specifically the board has an internal MMC device, and an SD card slot,
> although the SoC has four MMC/SD hosts IIRC.
>
> The kernel's naming of these devices is dynamic. If the SD card is not
> plugged in, the internal MMC is always known as mmcblock0. If the SD card
> is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
> mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
> them "in order", whereas 2.6.38 usually seems to name them "backwards".

The standard way to solve this is to use an initrd that performs the
naming (and mounting) that you'd like based on characteristics of the
device or card -- this could include making mmcblk{0,1} always attach
to the controllers that you're expecting it to.  It's hard enough to get
device naming policy right that we don't usually try to do it in-kernel.

> This causes problems with the bootloader scripts I'm using, which assumes
> that the internal MMC is always device 0 and the SD slot is always device 1,
> and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
> root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
> is searched for a valid image first by the bootloader).
>
> This could be solved by naming the kernel MMC devices statically based on
> the host controller, rather than dynamically based on the first available
> ID when the actual storage is detected. The patch below implements this.
>
> Is this patch conceptually acceptable for the MMC driver? Obviously, a
> complete patch would need to also remove the dev_use structure etc.
>
> Another solution might be for the kernel command-line to specify the
> filesystem UUID, rather than a device node. However, this entails much more
> work for the bootloader. I'm not sure whether U-Boot can do this right now?
> And actually, the filesystem images I'm using don't always have a UUID by
> dDefault IIRC.
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index bfc8a8a..5131b02 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -581,7 +581,7 @@ static struct mmc_blk_data *mmc_blk_alloc(struct mmc_card *card)
>         struct mmc_blk_data *md;
>         int devidx, ret;
>  
> -       devidx = find_first_zero_bit(dev_use, max_devices);
> +       devidx = card->host->index;
>         if (devidx >= max_devices)
>                 return ERR_PTR(-ENOSPC);
>         __set_bit(devidx, dev_use);

Hm, will think about this, thanks.

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

RE: Dynamic MMC device naming vs. bootloaders

[Stephen Warren]

Chris Ball wrote at Monday, April 04, 2011 11:58 AM:
> 
> Hi Stephen,
> 
> On Mon, Apr 04 2011, Stephen Warren wrote:
> > Chris et. al.,
> >
> > I'm working on an ARM system that contains at least two MMC/SD devices;
> > specifically the board has an internal MMC device, and an SD card slot,
> > although the SoC has four MMC/SD hosts IIRC.
> >
> > The kernel's naming of these devices is dynamic. If the SD card is not
> > plugged in, the internal MMC is always known as mmcblock0. If the SD card
> > is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
> > mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
> > them "in order", whereas 2.6.38 usually seems to name them "backwards".
> 
> The standard way to solve this is to use an initrd that performs the
> naming (and mounting) that you'd like based on characteristics of the
> device or card -- this could include making mmcblk{0,1} always attach
> to the controllers that you're expecting it to.  It's hard enough to get
> device naming policy right that we don't usually try to do it in-kernel.


Chris,

Thanks for the very quick response.

I have a followup question: How could the initrd identify each device, in
order to know which names to assign to them, or which one to mount?

Is there a way to query the block device to determine which host controller
ID it's connected to? Querying device size is pretty easy, but the user
could easily happen to choose an SD card of the same size as the internal
MMC for example.

I believe that x86 desktop distros typically use filesystem or device UUIDs
for this purpose in the initrd, but in the distro I'm using, there is
typically neither any UUID, nor an initrd. Equally, it's pretty easy with
grub to edit grub.cfg/menu.cfg to contain the correct UUID during install
or if it ever changes. Modifying U-Boot's saved environment (boot commands)
to include the a UUID would be more challenging, especially since
the boot commands are typically stored in the system's ROM/flash, whereas
the filesystem may be on some completely random user-supplied SD card.

Thanks.

-- 
nvpublic

Re: Dynamic MMC device naming vs. bootloaders

[Chris Ball]

Hi Stephen,

On Mon, Apr 04 2011, Stephen Warren wrote:
>> The standard way to solve this is to use an initrd that performs the
>> naming (and mounting) that you'd like based on characteristics of the
>> device or card -- this could include making mmcblk{0,1} always attach
>> to the controllers that you're expecting it to.  It's hard enough to get
>> device naming policy right that we don't usually try to do it in-kernel.
>
> I have a followup question: How could the initrd identify each device, in
> order to know which names to assign to them, or which one to mount?
>
> Is there a way to query the block device to determine which host controller
> ID it's connected to? Querying device size is pretty easy, but the user
> could easily happen to choose an SD card of the same size as the internal
> MMC for example.

That's a fine question.  I'm not sure what the *best* answer is, but you
have a few options:

* if your initrd contains udev, then the udev event for mmcblk creation
  looks like:

  UDEV  [1292447837.786721] add      /devices/platform/sdhci-pxa.0/mmc_host/mmc0/mmc0:d555/block/mmcblk1 (block)

  .. which contains the information you need.

* alternatively, you could grovel around sysfs:

  [root@localhost ~]# ls -la /sys/block/mmcblk0/device
  lrwxrwxrwx 1 root root 0 Jan  1  1970 /sys/block/mmcblk0/device -> ../../../mmc2:0001

So, the above tells you that on my system mmc2 (internal SD slot) hosts
mmcblk0, and mmc0 (external SD slot) hosts mmcblk1.

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

Re: Dynamic MMC device naming vs. bootloaders

[Kishore Kadiyala]

Hi Stephen,

On Mon, Apr 4, 2011 at 11:09 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Chris et. al.,
>
> I'm working on an ARM system that contains at least two MMC/SD devices;
> specifically the board has an internal MMC device, and an SD card slot,
> although the SoC has four MMC/SD hosts IIRC.
>
> The kernel's naming of these devices is dynamic. If the SD card is not
> plugged in, the internal MMC is always known as mmcblock0. If the SD card
> is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
> mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
> them "in order", whereas 2.6.38 usually seems to name them "backwards".
>
> This causes problems with the bootloader scripts I'm using, which assumes
> that the internal MMC is always device 0 and the SD slot is always device 1,
> and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
> root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
> is searched for a valid image first by the bootloader).

Just follow this thread which discusses the same but for OMAP4 controller
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47853.html

One solution could be make your internal MMC always registered as
mmcblk0 and the
removable one as next device.

Regards,
Kishore
>
> This could be solved by naming the kernel MMC devices statically based on
> the host controller, rather than dynamically based on the first available
> ID when the actual storage is detected. The patch below implements this.
>
> Is this patch conceptually acceptable for the MMC driver? Obviously, a
> complete patch would need to also remove the dev_use structure etc.
>
> Another solution might be for the kernel command-line to specify the
> filesystem UUID, rather than a device node. However, this entails much more
> work for the bootloader. I'm not sure whether U-Boot can do this right now?
> And actually, the filesystem images I'm using don't always have a UUID by
> dDefault IIRC.
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index bfc8a8a..5131b02 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -581,7 +581,7 @@ static struct mmc_blk_data *mmc_blk_alloc(struct mmc_card *card)
>        struct mmc_blk_data *md;
>        int devidx, ret;
>
> -       devidx = find_first_zero_bit(dev_use, max_devices);
> +       devidx = card->host->index;
>        if (devidx >= max_devices)
>                return ERR_PTR(-ENOSPC);
>        __set_bit(devidx, dev_use);
>
> Thanks for any feedback.
>
> --
> nvpublic
>
> --
> 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
>

RE: Dynamic MMC device naming vs. bootloaders

[Stephen Warren]

Kishore Kadiyala wrote at Tuesday, April 05, 2011 12:38 AM:
> 
> Hi Stephen,
> 
> On Mon, Apr 4, 2011 at 11:09 PM, Stephen Warren <swarren@nvidia.com> wrote:
> > Chris et. al.,
> >
> > I'm working on an ARM system that contains at least two MMC/SD devices;
> > specifically the board has an internal MMC device, and an SD card slot,
> > although the SoC has four MMC/SD hosts IIRC.
> >
> > The kernel's naming of these devices is dynamic. If the SD card is not
> > plugged in, the internal MMC is always known as mmcblock0. If the SD card
> > is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
> > mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
> > them "in order", whereas 2.6.38 usually seems to name them "backwards".
> >
> > This causes problems with the bootloader scripts I'm using, which assumes
> > that the internal MMC is always device 0 and the SD slot is always device 1,
> > and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
> > root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
> > is searched for a valid image first by the bootloader).
> 
> Just follow this thread which discusses the same but for OMAP4 controller
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47853.html

Kishore, thanks for the pointer. However, I don't see anything in that thread
that affects MMC block device IDs. The thread ended with the original poster
requesting the patch be dropped, since he'd made a mistake in his bootloader
settings.

Just perhaps the registration order change is enough to change the timing of
device (memory device, not host controller?) probing, which just happens to
affect the ID assignment?

> One solution could be make your internal MMC always registered as mmcblk0
> and the removable one as next device.

That's essentially what the patch I gave previously does.

-- 
nvpublic

Re: Dynamic MMC device naming vs. bootloaders

[Kishore Kadiyala]

On Wed, Apr 6, 2011 at 2:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> Kishore Kadiyala wrote at Tuesday, April 05, 2011 12:38 AM:
>>
>> Hi Stephen,
>>
>> On Mon, Apr 4, 2011 at 11:09 PM, Stephen Warren <swarren@nvidia.com> wrote:
>> > Chris et. al.,
>> >
>> > I'm working on an ARM system that contains at least two MMC/SD devices;
>> > specifically the board has an internal MMC device, and an SD card slot,
>> > although the SoC has four MMC/SD hosts IIRC.
>> >
>> > The kernel's naming of these devices is dynamic. If the SD card is not
>> > plugged in, the internal MMC is always known as mmcblock0. If the SD card
>> > is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
>> > mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
>> > them "in order", whereas 2.6.38 usually seems to name them "backwards".
>> >
>> > This causes problems with the bootloader scripts I'm using, which assumes
>> > that the internal MMC is always device 0 and the SD slot is always device 1,
>> > and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
>> > root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
>> > is searched for a valid image first by the bootloader).
>>
>> Just follow this thread which discusses the same but for OMAP4 controller
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47853.html
>
> Kishore, thanks for the pointer. However, I don't see anything in that thread
> that affects MMC block device IDs. The thread ended with the original poster
> requesting the patch be dropped, since he'd made a mistake in his bootloader
> settings.
>
> Just perhaps the registration order change is enough to change the timing of
> device (memory device, not host controller?) probing, which just happens to
> affect the ID assignment?
>
>> One solution could be make your internal MMC always registered as mmcblk0
>> and the removable one as next device.
>
> That's essentially what the patch I gave previously does.

Your change was in mmc/card/block.c, but you can handle this by
changing sequence during
device registeration.

Following change in the patch does that
https://patchwork.kernel.org/patch/595861/

diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1a943be..f914099 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -349,11 +349,6 @@  static struct twl4030_usb_data omap4_usbphy_data = {

 static struct omap2_hsmmc_info mmc[] = {
 	{
-		.mmc		= 1,
-		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
-		.gpio_wp	= -EINVAL,
-	},
-	{
 		.mmc		= 2,
 		.caps		=  MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
 		.gpio_cd	= -EINVAL,
@@ -361,19 +356,24 @@  static struct omap2_hsmmc_info mmc[] = {
 		.nonremovable   = true,
 		.ocr_mask	= MMC_VDD_29_30,
 	},
+	{
+		.mmc		= 1,
+		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+		.gpio_wp	= -EINVAL,
+	},
 	{}	/* Terminator */
 };

Regards,
Kishore

>
> --
> nvpublic
>
>

RE: Dynamic MMC device naming vs. bootloaders

[Stephen Warren]

Kishore Kadiyala wrote at Wednesday, April 06, 2011 4:11 AM:
> 
> On Wed, Apr 6, 2011 at 2:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > Kishore Kadiyala wrote at Tuesday, April 05, 2011 12:38 AM:
> >>
> >> Hi Stephen,
> >>
> >> On Mon, Apr 4, 2011 at 11:09 PM, Stephen Warren <swarren@nvidia.com> wrote:
> >> > Chris et. al.,
> >> >
> >> > I'm working on an ARM system that contains at least two MMC/SD devices;
> >> > specifically the board has an internal MMC device, and an SD card slot,
> >> > although the SoC has four MMC/SD hosts IIRC.
> >> >
> >> > The kernel's naming of these devices is dynamic. If the SD card is not
> >> > plugged in, the internal MMC is always known as mmcblock0. If the SD card
> >> > is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's
> >> > mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name
> >> > them "in order", whereas 2.6.38 usually seems to name them "backwards".
> >> >
> >> > This causes problems with the bootloader scripts I'm using, which assumes
> >> > that the internal MMC is always device 0 and the SD slot is always device 1,
> >> > and hence provides kernel command-line argument root=/dev/mmcblk0p3 or
> >> > root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD
> >> > is searched for a valid image first by the bootloader).
> >>
> >> Just follow this thread which discusses the same but for OMAP4 controller
> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47853.html
> >
> > Kishore, thanks for the pointer. However, I don't see anything in that thread
> > that affects MMC block device IDs. The thread ended with the original poster
> > requesting the patch be dropped, since he'd made a mistake in his bootloader
> > settings.
> >
> > Just perhaps the registration order change is enough to change the timing of
> > device (memory device, not host controller?) probing, which just happens to
> > affect the ID assignment?
> >
> >> One solution could be make your internal MMC always registered as mmcblk0
> >> and the removable one as next device.
> >
> > That's essentially what the patch I gave previously does.
> 
> Your change was in mmc/card/block.c, but you can handle this by
> changing sequence during device registeration.
> 
> Following change in the patch does that
> https://patchwork.kernel.org/patch/595861/

Ah. I do see now that Tegra's equivalent platform_device registration order was
changed between the two kernels that exhibit different behavior, so re-ordering
might work. I'll try it out.

However, isn't it just a fluke that this will work; registering the internal
host controller first will I assume start probing of any attached devices on
that controller first, but does it actually guarantee that such probing will
also complete first, which I believe is the necessary condition for the mmcblk
device to be assigned ID 0?

Equally, if there were two controllers with fixed/internal MMC and/or two
controllers which supported pluggable SD cards, the race issue would still
exist?

Thanks for the pointer!

-- 
nvpublic

Re: Dynamic MMC device naming vs. bootloaders

[Andrei Warkentin]

On Wed, Apr 6, 2011 at 11:59 AM, Stephen Warren <swarren@nvidia.com> wrote:
>
> Ah. I do see now that Tegra's equivalent platform_device registration order was
> changed between the two kernels that exhibit different behavior, so re-ordering
> might work. I'll try it out.
>
> However, isn't it just a fluke that this will work; registering the internal
> host controller first will I assume start probing of any attached devices on
> that controller first, but does it actually guarantee that such probing will
> also complete first, which I believe is the necessary condition for the mmcblk
> device to be assigned ID 0?
>

The device index is only assigned if the mmc block driver is started
on a detected card. This means that
if you remove a card from host 0, then card on host 1 will be detected
first. I would guess most platform code assigns an emmc/esd-containing
host as first to add.
Being first to add implies being first to resume so the ordering
should stick across PM states (and safe MMC resume)

> Equally, if there were two controllers with fixed/internal MMC and/or two
> controllers which supported pluggable SD cards, the race issue would still
> exist?

I think if you had two controllers and you plugged two cards in at the
"same time", then you would have  a race condition, as both would
mmc_detect_change (effectively schedule_work to an ordered wq), and it
would depend on which card change IRQ occured first. It seems like
different hosts use different delays for when the work will be done,
so if you have different hosts, you can make this even more obvious.
You'd have to really try, though, I think. I guess if you are never
going to support multiple cards on one host, you might as well tie the
block index to host index.

A

RE: Dynamic MMC device naming vs. bootloaders

[Stephen Warren]

Andrei Warkentin wrote at Wednesday, April 06, 2011 11:19 AM:
> On Wed, Apr 6, 2011 at 11:59 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > However, isn't it just a fluke that this will work; registering the internal
> > host controller first will I assume start probing of any attached devices on
> > that controller first, but does it actually guarantee that such probing will
> > also complete first, which I believe is the necessary condition for the mmcblk
> > device to be assigned ID 0?
> >
> 
> The device index is only assigned if the mmc block driver is started
> on a detected card. ...
> 
> > Equally, if there were two controllers with fixed/internal MMC and/or two
> > controllers which supported pluggable SD cards, the race issue would still
> > exist?
> 
> I think if you had two controllers and you plugged two cards in at the
> "same time", then you would have  a race condition, as both would
> mmc_detect_change (effectively schedule_work to an ordered wq), and it
> would depend on which card change IRQ occured first. It seems like
> different hosts use different delays for when the work will be done,
> so if you have different hosts, you can make this even more obvious.
> You'd have to really try, though, I think. I guess if you are never
> going to support multiple cards on one host, you might as well tie the
> block index to host index.

The case I care about most right now is a cold kernel boot. This is
basically the same as plugging two SD cards in at (exactly) the same time;
the time being when the SD platform driver is registered. The fact that
that on my board, one is actually eMMC and one really an SD card that's
already plugged in pre-boot isn't really that relevant.

So, if I interpret your statements correctly, you're agreeing that simply
registering the host controller for eMMC first doesn't guarantee that
the eMMC will be block device ID 0, albeit in practice that does seem to
be true a large enough percentage of the time not to notice any problem.

Am I correct?

Thanks.

-- 
nvpublic

Re: Dynamic MMC device naming vs. bootloaders

[Andrei Warkentin]

On Wed, Apr 6, 2011 at 12:32 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Andrei Warkentin wrote at Wednesday, April 06, 2011 11:19 AM:
>> On Wed, Apr 6, 2011 at 11:59 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> > However, isn't it just a fluke that this will work; registering the internal
>> > host controller first will I assume start probing of any attached devices on
>> > that controller first, but does it actually guarantee that such probing will
>> > also complete first, which I believe is the necessary condition for the mmcblk
>> > device to be assigned ID 0?
>> >
>>
>> The device index is only assigned if the mmc block driver is started
>> on a detected card. ...
>>
>> > Equally, if there were two controllers with fixed/internal MMC and/or two
>> > controllers which supported pluggable SD cards, the race issue would still
>> > exist?
>>
>> I think if you had two controllers and you plugged two cards in at the
>> "same time", then you would have  a race condition, as both would
>> mmc_detect_change (effectively schedule_work to an ordered wq), and it
>> would depend on which card change IRQ occured first. It seems like
>> different hosts use different delays for when the work will be done,
>> so if you have different hosts, you can make this even more obvious.
>> You'd have to really try, though, I think. I guess if you are never
>> going to support multiple cards on one host, you might as well tie the
>> block index to host index.
>
> The case I care about most right now is a cold kernel boot. This is
> basically the same as plugging two SD cards in at (exactly) the same time;
> the time being when the SD platform driver is registered. The fact that
> that on my board, one is actually eMMC and one really an SD card that's
> already plugged in pre-boot isn't really that relevant.
>
> So, if I interpret your statements correctly, you're agreeing that simply
> registering the host controller for eMMC first doesn't guarantee that
> the eMMC will be block device ID 0, albeit in practice that does seem to
> be true a large enough percentage of the time not to notice any problem.
>

The call path is:

mmc_add_host
mmc_start_host
mmc_detect_change schedules mmc_rescan work with no delay

So two consecutive mmc_add_host-s for two different hosts implies that
the first mmc_rescan will happen for the first added host. So the
answer to your question is no - you seem to have that guarantee.

A