Re: Dynamic MMC device naming vs. bootloaders

[Andrei Warkentin <andreiw@motorola.com>]

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