lkml.org 
[lkml]   [2006]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] get USB suspend to work again on 2.6.17-mm1
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/

\
 
 \ /
  Last update: 2006-06-27 17:27    [W:0.124 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site