and Jim Blackson wrote:
> Just to confuse the issue a little more ... :-)
> ... does/will/should linux support USB device remote wakeup?
I expect it to. Seems to me that the reasons that this
support is not there now is based on (1) priorities [it
was low], (2) resources [we only have a few HCD developers
and they stay fairly busy; maybe we should have someone
else pick up power management issues], and (3) the power
management code in the kernel is changing for 2.3/2.4 [it
has a new API for APM xor ACPI support, but full ACPI support
won't be ready for 2.4.0].
> > > > I don't think this is the right way to handle suspend/resume.
> > > > So, I don't like that patch.
> > >
> > > I could perhaps try an alternate patch you provided. What is
> > > the issue you have with this one?
> >
> > You disconnect all devices and reset the USB-subsystem.
To confuse the issue even more, you don't know what devices
the user may have unplugged, added, or moved around
during suspend, so wouldn't a complete re-enumeration
be advisable, or is there something that would alert the
hub driver that a re-enumeration is needed?
~Randy
>
> They were getting disconnected later anyway. (Oops!) And as
> I noted, the USB controller seemed to need resetting before
> it'd transfer data again.
>
> > This is like a shutdown of a computer at a suspend and a
> > boot at a resume.
>
> It's certainly a "guaranteed to work in worst case" solution
> for most purposes, using code paths we have reason to trust.
> I didn't notice any delays in suspending or restarting.
>
> The OHCI spec shows me (fig 6-1) that the paths out of the
> "operational" state are either (a) through "reset", or else
> (b) through "suspend" then "resume". "suspend" state requires
> support of remote wakeups, which I didn't see in the driver.
>
> I wasn't seeing (b) work ... I didn't see another choice.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
