Re: [RFC][PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2008-03-20 at 10:45 -0400, Alan Stern wrote:
> 
> I didn't mention locking because it seemed obvious that locking is
> needed.  Of course a flag alone is mostly useless.
> 
> But we already _do_ have a lock (dev->sem) and we _don't_ have a flag.  
> I was pointing out that some drivers will want to have a flag added.
> Maybe so many drivers will want it that the flag should be added to the
> PM structure, where it will be available for every device.  If only a
> few drivers want this new flag, then yes, they can put it in their
> private data structures.

What I'm saying is that a flag set prior to prepare() would be almost
impossible to get right in term of locking for the reasons I explained.

I think this should be under driver reponsibility, using it's own
internal locking. Or else, drivers can rely on failure.

> > However, I think this is mostly a non-issue, because the core _does_
> > provide something here that is useful for drivers who don't want to
> > bother with the above: The failure return from device_add. If drivers
> > don't want to do something akin to what I described, they can just be
> > made to deal gracefully with the failure from device_add that would
> > happen due to the core internal flag being set after the return from
> > prepare().
> 
> Relying on a registration failure to handle this sort of thing is _not_
> a good idea.  For example, how would the driver distinguish failure
> caused by impending suspend from other sorts of failure?

By the precise error code of course. But as I said, I would expect most
bus drivers to have their own proper implementation that does the right
thing, it's not like it was hard and there aren't that many bus drivers.
Relying on failure is a possibility for simple ones that don't want to
care much, in which case, there is little need to differenciate the
failure caused by suspend from other failures other than maybe printing
some garbage in the log vs. not :-)

Ben.