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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux