On Friday, July 01, 2011, Alan Stern wrote: > On Fri, 1 Jul 2011, Rafael J. Wysocki wrote: > > > Hi, > > > > On Friday, July 01, 2011, Kevin Hilman wrote: > > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > > > > > > On Fri, 1 Jul 2011, Kevin Hilman wrote: > > > > > > > >> OK, so the ->probe() part has been explained and makes sense, but I > > > >> would expect ->remove() to be similarily protected (as the documentation > > > >> states.) But that is not the case. Is that a bug? If so, patch below > > > >> makes the code match the documentation. > > > > > > > > I suspect it is a bug, but it's hard to be sure. It's so _blatantly_ > > > > wrong that it looks like it was done deliberately. > > > > > > heh > > > > I seem to remeber having a problem with the pm_runtime_put_sync() after > > drv->remove(dev) ... > > > > So the code in question was introduced by > > > > commit e1866b33b1e89f077b7132daae3dfd9a594e9a1a > > Author: Rafael J. Wysocki <rjw@xxxxxxx> > > Date: Fri Apr 29 00:33:45 2011 +0200 > > > > PM / Runtime: Rework runtime PM handling during driver removal > > > > with a long changelog explaining the reason why. Which seems to make sense. ;-) > > Okay, that seems fair enough. Looks like the documentation needs to be > updated to match, though. Yes, it does. > And we probably still want to make sure that access to the > power/control and related attribute files is mutually exclusive with > probe and remove. I agree. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html