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.
> > > Not at all -- we should fix the driver! If it claims to support
> > > autosuspend then it should also be able to handle reset_resume without
> > > any need for rebinding.
> >
> > Why? Or rather which kind? Quirky devices are very rare. Why would
> > all drivers need to handle that? As for powerloss, a printer driver can
> > never do that, as it cannot restore the printer's setting. Likewise anything
> > claimed by usbfs. There are other examples.
>
> Two separate issues:
>
> 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. But if a driver does not support
reset_resume() and a device is quirky, why would you autosuspend
in the first place? 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.
> powerloss_resume will happen only when waking up from a system sleep,
> and since it won't be an autoresume we will own the device lock. Hence
> we will be able to rebind drivers.
Good. This method can potentially find out that it is running on the wrong
device. The others cannot.
Regards
Oliver
-------------------------------------------------------------------------
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
