On Wed, Apr 6, 2011 at 12:32 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > Andrei Warkentin wrote at Wednesday, April 06, 2011 11:19 AM: >> On Wed, Apr 6, 2011 at 11:59 AM, Stephen Warren <swarren@xxxxxxxxxx> 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 -- 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
