Re: [linux-usb-devel] Re: OHCI problems with suspend/resume

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >>I'm not sure how the design is intended to work, but either way something 
> >>needs to be fixed.
> 
> Yes, it seems like all the HCDs (and the hub driver) need attention.

Why the hub driver?

For basic functionality, you simply power it down (doing virtual
unplug), and power it back up on resume (doing virtual plug of all
devices). That should work reasonably for everything but mass-storage.

> Plus, the enumeration process should respect hubs' power budgets,
> and handle overcurrent better.  I had a hub re-enumerate over forty
> times not that long ago, just because it enabled too many things at
> once and the surge currents made lots of trouble.  Plenty of power,
> if it got turned on carefully enough... :)

Havin enough juice in "common case", but not in "worst case" is not
too legal situation, is it?

> >Could well be. I need to spend some time auditing power management
> >in the USB drivers in general. The idea here is that a sub-driver
> >(USB device driver) should make sure it has no more pending URBs
> >when returning from suspend() and the HCD driver should just cancel
> >pending URBs if still any and reject any one that would be submited
> 
> Agreed, this needs work.  Some USB device drivers will likely need to
> implement suspend()/resume() callbacks, which thoughtfully enough the
> driver model conversion already gave us.  At one point it was planned
> to have it automatically traverse the devices and suspend, leaves up to
> root; and resume in the reverse order.  Is that behaving now?

Yes.

> Suspend should likely enable remote wakeup (trevor.pering@intel.com
> has been asking about that), at least as a config option.  That'll
> be useful for things like keyboards and mice.

Okay, but we need normal suspend/resume working first :-).

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]