On 13 June 2011 20:52, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > We need to debug the suspend/resume path. Now that we have the other > runtime pm paths working, we can pretty much tell there's no hw issue > at hand. Found it. It's a timing issue. In our other tests we had not yet hit the case when power is removed then immediately restored. However, during resume, the card is powered up, powered down, powered up, and then probed by libertas. A msleep(250) is needed during power_restore. Then the reset works fine. Why is there so much power flipping going on during resume? Is this a bug? Shouldn't it power it up, realise it has a driver already loaded, and go straight into probe? But even if that gets fixed, we still need to fix the case where the network interface is brought down then up immediately (another way to trigger the issue). Would you suggest a card quirk for that? Adding another 250ms to the already-slow libertas powerup routine would be a bit painful, would you support the added complexity needed to make the 250ms delay only occur when >250ms has passed since it was powered off? Thanks, Daniel -- 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
