Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 31 Jul 2003 14:55:53 -0700 | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: OHCI problems with suspend/resume |
| |
Benjamin Herrenschmidt wrote: > > You should look at Patrick Mochel's stuff that shall be getting in > the official tree this month hopefully. It does that (among others)
OK, thanks for the update. It was puzzling to see this stuff in such a state ... I've got a few patches for USB PM that are worth putting back in advance of that, but it seems like real testing will need to wait until "next month". (Tomorrow!)
> The USB "device" drivers shall just rely on the Device Model > infrastructure to have their suspend/resume callbacks be called at the > appropriate time.
Yes, that's no problem. It looks like:
static int my_suspend(struct device *_intf, u32 state, u32 level) { struct usb_interface *intf; int retval = 0;
intf = to_usb_interface(_intf); switch (level) { ... cases are yet to stabilize ... } return retval; }
... similar for resume()
static struct usb_driver my_driver { .owner = THIS_MODULE, .name = "MyFirstDriver", .probe = my_probe, .disconnect = my_disconnect, .id_table = my_id_table, .driver = { .suspend = my_suspend, .resume = my_resume, }, };
But until the suspend()/resume() callback API stabilizes, it's mostly useful to know that it'll be exactly that simple, and that usbcore doesn't get in the way.
I suspect that USB should do some non-global PM stuff too. Hub ports can be suspended when the devices connected to them are idle for long enough ... that's not something I'd expect system-wide PM policies to address.
- Dave
- 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/
| ![\](/images/icornerr.gif) |