On Wed, 16 May 2007, Oliver Neukum wrote: > Am Dienstag, 15. Mai 2007 23:49 schrieb Alan Stern: > > On Tue, 15 May 2007, Oliver Neukum wrote: > > > I think we're getting off the point here. Suppose the usbhid driver > > gets a powerloss_resume call for a mouse. What do you want it to do > > that we aren't already doing? > > Nothing. My point was that powerloss_resume() would be a benefit for > every driver. Only that some drivers can't implement it.
Okay. In very many cases it should be true that drivers won't try to verify a device's identify in powerloss_resume, since there isn't much they can check that the core hasn't checked already. In these cases powerloss_resume and reset_resume would do exactly the same things. Now consider cases where the driver does perform an identity check. Combine this with a previous remark you made: Devices with the reset_resume quirk are quite rare. Hence such drivers won't stand to lose much if they also do the identify check in reset_resume. Sure it would be unnecessary, but it wouldn't cost much and it would hardly ever happen. In other words, there's never any real reason for powerloss_resume and reset_resume to do different things. So there's no reason to have two separate methods. > > reset_resume will happen only because of the quirk. But when it > > happens during an autoresume, we cannot unbind the driver because we > > don't own the device lock. So what do you want to do then? > > This would need a separate thread. Yes. Along with all the complications of keeping track of references and making sure the thread gets flushed at the right time. > But if a driver does not support > reset_resume() and a device is quirky, why would you autosuspend > in the first place? You would autosuspend a quirky device for the same reason you autosuspend a normal device: to save power. The fact that it needs a reset to resume isn't necessarily a drawback. I could add a check to prevent autosuspend for quirky devices with a driver that doesn't support reset_resume. Is this really needed? > It seems to me that this issue arises only if > reset_resume() returns an error. Is there a reason to treat this differently > from resume() failing? On a system resume, we can unbind. The only reason to treat it differently is because it occurs in a different context. System resume is different from autoresume, most especially because autoresume is often invoked by the driver itself. When that happens, trying to unbind could lead to deadlock. 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
