On Mon, 21 May 2007, Oliver Neukum wrote: > > I guess it's just a theoretical problem. The whole point of the > > last_busy field is to prevent autosuspend too soon after any I/O. So > > if an URB does complete and nevertheless the device is suspended a few > > milliseconds later, then last_busy hasn't fulfilled its role. Like > > this: > > > > The autosuspend timer expires. > > last_busy is sufficiently old. > > hid_suspend() is called. > > The interrupt URB completes. > > last_busy is set to jiffies. > > hid_suspend() kills the > > interrupt URB and returns. > > usbcore doesn't notice that > > last_busy has been changed. > > usbcore suspends the device. > > > > It's not actually _wrong_, but it isn't optimal. > > Yes, the race exists. The original version scheduled work to reawake > the device in this case. Pete spotted the last vestige of that. Should I > put it back in? It seemed a pointless waste of perfection on a heuristics > that can't be perfect.
No, don't put it back in. My question was whether usbcore should look to see whether last_busy had changed. But it is, after all, a race -- and like you say, we'll never be perfect. So there's probably no point in worrying too much about it. 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
