> You could do this with a straight mutex except for the > dev_suspend_trylock/unlock bit in uninterruptable contexts, but I > seem to recall somebody saying that could be made to work if there > was a real need for it. Alternatively you could just drive the > "Generic Mutex" guys up the wall by inventing your own pseudo-mutex > with a spinlock, a boolean value, and a waitqueue. Most of the time, the interrupt/atomic contexts are part of what I call the "main path" of the driver, which doesn't need most of this stuff. Depending on what is "upstream" from the driver, you typically set a condition stopping the flow of "interrupt" activity and wait for it to drain in suspend. For example, a block driver would instruct the driver to stop processing the request queue and wait for pending in flight requests to drain, or a network driver would stop the tx queue and wait for pending/concurrent xmit() callbacks to complete (basically sync. bh and sync. with NAPI poll). In both examples, helpers can be provided in the block layer or network stack to make that easier. In many cases, the driver may just turn off something in the chip in "suspend" (using a low level spinlock that it already has if it has an irq path to sync. HW access) and set some flag/state to instruct the irq handler to not restart, then synchronize_irq(). All those techniques are fairly simple and well known. The main source of problems are the "sideband" channels, such as sysfs accesses to driver tunables, ioctl's, etc... for which I believe mutexes can solve 90% of them. Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
