On Mon, 25 Feb 2008 15:00:51 -0500 (EST)
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Maybe a better approach would be to leave the workqueue unfreezable,
> and keep cancel_delayed_work_sync() in mmc_suspend_host(). It would
> then be necessary to add a test to verify, if there is a card attached,
> that the card is indeed suspended. After all, it's possible that the
> cancel_delayed_work_sync() ended up waiting for a job already running
> on the workqueue to register a new card! (The same would be true even
> with flush_scheduled_work.)
How would that be handled? I'd prefer a patch as I'm evidently not up to date with how to fondle the pm stuff properly. :)
>
> Also, as a bit of defensive programming, it might be a good idea to add
> a "suspended" flag to the mmc_host structure. If mmc_rescan() sees
> that the flag is set then it should return immediately. This would
> protect against host drivers that aren't careful to disable detect
> IRQs before calling mmc_suspend_host().
Indeed. I'll add that to my todo.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
