Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Wednesday, 19 of October 2005 22:46, Alan Stern wrote:
> On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:
}-- snip --{
> There has been a lot of development on USB  
> suspend/resume in 2.6.14, and you don't have all the patches applied.  In 
> particular, you are missing usb-pm-05.patch (probably a bunch of others as 
> well).

If I'm missing any patches that's becasue they are not in 2.6.14-rc4-mm1
for some reason (I assume an important one).

> Take my advice: Start from 2.6.14-rc4, apply gregkh-all-2.6.14-rc4.patch 
> (it gets updated fairly often, so retrieve a fresh copy), and also apply 
> the PF_NOFREEZE patch (as585) I posted on lkml and linux-pm.

>From my POV this means there's no point in testing USB suspend/resume
on 2.6.14-rc4-mm1, because it's potentially broken.  Which is fair enough,
BTW.

> > > These errors occurred, naturally enough, because the driver for usb3 
> > > refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't 
> > > suspended.
> > 
> > I've figured out that too.  However, if something has no _suspend() routine,
> > verify_suspended() could return 0 for it, I think, instead of -EBUSY.
> 
> Dave Brownell would probably give you an argument, but I tend to agree.  
> Alternatively, if something has no ->suspend then we could just set its 
> ->power.power_state value directly so it would _appear_ to be suspended.

Well, that depends.  If the driver has a _resume() routine, it's ->power.power_state
should be set on suspend.  However, if it has neither _resume() nor _suspend(),
it's ->power.power_state is not really well defined, so it's just easier to ignore it.

Greetings,
Rafael