On 12/26/05, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 26 Dec 2005, Dmitry Torokhov wrote: > > > Device removal could happen at any point, even during suspend transition. > > The kernel should be able to handle this scenario therefore implementation > > that assumes that device tree is frozen in flawed. As far as I understand > > the only thing that does not work at the moment is invoking hotplug handler. > > The situation isn't all that bad. > > The device tree can be changed only by calling device_add or device_del > (or the corresponding register/unregister routines). That can only be > done in process context; hence if processes are frozen it can't happen. > Or rather, it can happen only if a suspend() or resume() method tries to > do it. > > If those methods don't try to handle device removal or addition -- which > in most cases they shouldn't -- then there's nothing to worry about. It's > only oddball situations (like calling the remove method when the driver > doesn't define a suspend method) that cause problems. > Hmm, I am confused. What should ->resume() method do when it fails to resume a device? I would say kill it, espacially if it is bus-generic method. How else would we clean up after removed devices? And here we have a problem because swsuspend likes to resume all devices before writing the image and drivers don't rellay know if they are woken up for real or just to complete suspend transition. > And even then, with most drivers you don't get a hotplug event when the > driver is unbound. It happens only with things like usb-storage, that > define child devices. > No, I'd say most drivers generate hotplug events because most of them create/destroy class devices nowadays. -- Dmitry
