On Wed, 27 Feb 2008, David Newall wrote: > David Brownell wrote: > > On Tuesday 26 February 2008, David Newall wrote: > > > >> Hardware can be inserted and removed while we're in a suspend state; and > >> there's nothing that we can do about it until we resume. Is it fair to > >> say, then, that having started suspend, we could reasonably ignore any > >> device insertion and removal, and handle it on resume? > >> > > > > "Ignore" seems a bit strong; those events may be wakeup triggers, > > which would cause the hardware to make it a very short suspend state. > > > > "Defer handling" is more to the point, be it by hardware or software. > > > > > > Of course, "defer". The insertion has to be handled eventually. What > I'm wondering is if we can ignore it, and catch it on the resume. Certainly. If hardware-change events can get lost because of the system sleep, the resume method should make every effort to verify that what it remembers of the hardware state matches the current reality. > >> Presumably we need to scan for hardware changes on resume. > >> > > > > Not on most busses I work with; the hardware issues notifications > > whenever the devices are removable. > > > > There's no notification while we're suspended. Isn't it necessary to > scan all busses on resume, just to know what's on them? It depends on the bus. If the bus doesn't support hotplugging then scanning isn't necessary. If the bus does support hotplugging then scanning after suspend may or may not be necessary, depending on whether or not the bus controller remained powered during the suspend. For hotpluggable buses, scanning after hibernation is always necessary. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
