Re: Re: Hotplug events during sleep transition

Rafael J. Wysocki
2005-12-29T11:29:44Z

[-- 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