On Mon, 14 May 2007, Oliver Neukum wrote: > Am Montag, 14. Mai 2007 16:16 schrieb Alan Stern: > > > Well, we have again a distinction between device and interface > > > persistance. Some drivers and therefore interfaces will be unable > > > to support persistance. It must be possible to resurrect only some > > > interfaces of a device. > > > > In other words, it must be possible for a driver's post_reset() method > > to fail. That's a separate email thread. > > Worse. A driver may _lack_ a post_reset() method.
In which case its resume() method gets called, in lieu of anything better. Drivers like that are in trouble whenever their device gets reset, whether it is related to hibernation or not. > > Maybe so, but you're putting a burden on both the core and the user. The > > core would have to check, when resuming a hub, whether _any_ of the hub's > > descendants want to be persistent. It can be done but it's messy. And > > then the user has to decide, for every device that gets attached, whether > > or not it should be persistent. > > It is the same tree logic used to decide whether a hub can be suspended. > I suggest solving it the same way. This feature _is_ dangerous. It will be simpler to add a "persist" attribute for non-hub devices and always assume it is enabled for hubs. I don't think there's any downside to making hubs persistent. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
