On Fri, 27 Nov 2009, Oliver Neukum wrote: > Am Freitag, 27. November 2009 01:47:44 schrieb Rafael J. Wysocki: > > On Thursday 26 November 2009, Oliver Neukum wrote: > > > Hi, > > > > > > using the USB autosuspend framework I've often faced characteristic > > > problems coding resume() methods. This has led me to an idea. Resume() > > > would be much easier to code if I knew about the reason of resumption, > > > especially about the code path resume() is called in. I wonder whether > > > we could introduce a message argument to resume and give it a few > > > bits from the caller. > > > > Each of the callbacks in struct dev_pm_ops is executed in exactly one > > context, so for each of them it is known why it was called. > > But the resume method in the driver doesn't learn. It is an extrem hassle > not to know whether you are called synchronously (ie from open which > already holds a lock) or asynchronously (which means you need to guard > against open) With the new Runtime PM framework, there isn't always a one-to-one correspondence between resume requests and method callbacks. So the "reason" for a callback isn't always well defined. And even if it were, the callback might happen in a different thread from the request. The way to guard against open from an asynchronous context is to approach the problem the other way around: Guard against async contexts while open is running. In other words, have open do an autoresume. Exactly what situation are you concerned about? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
