Re: [linux-pm] [RFC][PATCH] PM: Introduce new top levelsuspend and hibernation callbacks (rev. 2)

[Alan Stern]

On Tue, 25 Mar 2008, Rafael J. Wysocki wrote:

> On Tuesday, 25 of March 2008, Oliver Neukum wrote:
> > Am Dienstag, 25. März 2008 21:41:48 schrieb Rafael J. Wysocki:
> > > On Tuesday, 25 of March 2008, Oliver Neukum wrote:
> > > > Am Dienstag, 25. März 2008 15:33:22 schrieb Alan Stern:
> > > > > > so I'd say a
> > > > > > failure to resume is just a limited subcase of a device vanishing during
> > > > > > sleep.
> > > > > 
> > > > > I'll go along with that.  If a device vanishes during sleep, the PM 
> > > > > core isn't responsible for unregistering it -- the device's subsystem 
> > > > > is.
> > > > 
> > > > Yes, that makes sense. You are right.
> > > 
> > > Still, if ->resume() returns an error, does it make sense, from the PM core's
> > > point of view, to execute ->complete() for that device, for example?
> > 
> > IMO you must always keep the ordering invariant. If a parent returns an error
> > the PM core must not wake its children.

Don't think of it that way.  The PM core doesn't wake anything.  It
merely notifies drivers that the system sleep is ending, so that the
drivers can wake their devices.  It's up to the driver to detect
whether the parent failed to resume, in which case the driver should
take appropriate action.

The situation is no different from what happens when the user tries to 
access a mounted USB disk drive after the USB cable has been unplugged.  
The drivers take care of everything.

> I'm agreeing here, but one of the previous Alan's comments suggests he has a
> differing opinion.  Alan?
> 
> I'm considering to make the PM core skip the resuming of the children of
> devices that failed to resume and skip calling ->complete() for that devices
> and their children.

While that might in principle be a reasonable thing to do, it's 
different from how the PM core has behaved in the past.  I don't see 
any point in making a change like that now.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/