Re: Dynamic MMC device naming vs. bootloaders

[Andrei Warkentin <andreiw@motorola.com>]

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