Am Mittwoch, 16. Mai 2007 16:30 schrieb Alan Stern:
> On Wed, 16 May 2007, Oliver Neukum wrote:
> 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.
I had not considered that. You are right.
> > > 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.
How to avoid it? If the original driver fails, I see no alternative but to
yield to other drivers and usbfs.
> > 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.
You don't autosuspend a device unless the driver explicitely supports
autosuspend.
> I could add a check to prevent autosuspend for quirky devices with a
> driver that doesn't support reset_resume. Is this really needed?
Yes.
> > 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.
Let's disallow drivers failing during autoresume.
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
