> I am not sure I understand why this patch is needed. When a new card > is inserted/removed and the upper levels gets notification about the > new card, triggering the mounting/un-mounting of the file system, why > should it be the lowest layer (mmc) that prevents the platform from > enter suspend/sleep? Why do we need to prevent it at all? > > Note that notifier handling in mmc_pm_notify, was if I remember > correctly, not completely developed when the original version of this > patch was being discussed. mmc_pm_notify prevents cards from being > inserted/removed in the middle of suspend->resume sequence, is that > not enough? I will try to speak on behalf of the original implementers in a hope they would provide the original motivation for the patch. My understanding is that any preemption in the procedure could be an opportunity to suspend, as there may be a suspend request racing with this code. This is why the calls to __pm_stay_awake() and queue_delayed_work() are so tightly coupled. It would be up to the delayed work procedure (mmc_rescan()) to decide whether or not it is safe to suspend. If there are no changes in the MMC state or all changes can be handled by mmc_rescan(), it is safe to call __pm_relax(). Otherwise, userland may take over processing of this event, and this is why the awake state needs to be extended by 1/2 second. Regards, Zoran -- 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
