Re: Patches still in the queue

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel