Re: Re: Hotplug events during sleep transition

["Rafael J. Wysocki" <rjw@sisk.pl>]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Hi,

On Thursday, 29 December 2005 03:55, Nigel Cunningham wrote:
> On Thu, 2005-12-29 at 12:18, Alan Stern wrote:
> > On Wed, 28 Dec 2005, Rafael J. Wysocki wrote:
> > 
> > > I think for a (suspended) device that can be removed, unplugged, undocked,
> > > etc. (call it "removable") the most natural place in which we can detect
> > > that the device is no longer accessible is the device driver's .resume()
> > > routine, at least as far as swsusp is concerned.
> > 
> > No.  The most natural place in which we can detect that a device is no 
> > longer accessible is the place where we already do these detections.  Not 
> > in the resume routine.
> > 
> > > IMO .resume() should check if the device is still there and if not, it should
> > > put the device on a list of "no-longer-present devices" and just return.
> > > After the .resume() routines of all devices have completed, the list can
> > > be processed by something (a kernel thread?) that will do the changes
> > > on whatever level is necessary.
> > 
> > Often the device-specific resume routine doesn't have the information
> > needed for checking whether the device is still there.  Such checks are 
> > done by generic bus-oriented routines.
> > 
> > Yes, the bus's resume handler can do such a check.  Why should it bother,
> > when other parts of the bus code will detect the device removal in the
> > normal course of events?  Or alternatively, why shouldn't the bus's resume
> > handler simply invoke those other parts of the bus code when it determines
> > that a device has been removed?
> 
> I guess because the resume routine is almost certainly the first piece
> of code that will try to access the hardware (and possibly choke and die
> it it's not there).

This is what I had in mind.

Greetings,
Rafael

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]