On Wed, Apr 6, 2011 at 11:59 AM, Stephen Warren <swarren@xxxxxxxxxx> 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 -- 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
