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
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
