Re: [PATCH] get USB suspend to work again on 2.6.17-mm1

[Alan Stern <stern@rowland.harvard.edu>]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/