On Mon, 26 Jun 2006, David Brownell wrote: > On Monday 26 June 2006 4:57 pm, Greg KH wrote: > > On Fri, Jun 23, 2006 at 10:51:47AM -0400, Alan Stern wrote: > > > On Thu, 22 Jun 2006, Greg KH wrote: > > > > > > > > Under what scenario could it possibly be legitimate to suspend a > > > > > usb device -- or interface, or anything else -- with its children > > > > > remaining active? The ability to guarantee that could _never_ happen > > > > > was one of the fundamental motivations for the driver model ... > > > > > > > > I'm not disagreeing with that. It's just that you are looping all > > > > struct devices that are attached to a struct usb_device and assuming > > > > that they are all of type struct usb_interface. ... > > > > > > In fact the code doesn't make that assumption. It only assumes that the > > > dev->power.power_state.event field is set correctly ... > > > > Yes, but it's looking at devices it should _not_ care about. The USB > > core should only care about devices it controls, not other devices in > > the device chain. Those are for the driver core to handle. > > The basic problem is that the driver core does ** NOT ** maintain such > integrity constraints. So it's unsafe to remove those checks for cases > (like USB) where devices get suspended outside transition to "system sleep" > states like "standby", "suspend-to-ram", and "suspend-to-disk". [1] > > Go back to my original question: is there a legitimate scenario where > that test should fail? Nobody has come up with even one ... > > > Even so-called "virtual" devices (talking to abstracted hardware) need to > quiesce. And as Adam has pointed out separately, often most of the work to > quiesce drivers should be at such a "virtual" level. Most of the time when > a driver for a "physical" device (touches real registers) does complicated > work to quiesce, it's because the next level in the driver stack didn't > create a "virtual" device to package that logic. As with "eth0". An easy way around the problem is to create simple suspend/resume methods for the endpoint devices. They don't have to do anything other than set dev->power.power_state.event. Not until these "endpoint devices" start implementing some real functionality. Alan Stern
