PATCH: (as339) Interpret down_trylock() result code correctly in usb.c

PATCH: (as339) Interpret down_trylock() result code correctly in usb.c

[Alan Stern]

Greg:

As Andrew Morton has already spotted, I messed up the interpretation of
the result codes from various _trylock() routines.  I didn't notice that
down_trylock() and down_read_trylock() use opposite conventions for
indicating success!  This patch fixes the incorrect interpretation of
down_trylock().  That error may well be responsible for some of the
problems cropping up recently with OHCI controllers.  Please apply.

Alan Stern



Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

===== drivers/usb/core/usb.c 1.281 vs edited =====
--- 1.281/drivers/usb/core/usb.c	Wed Jun 30 09:44:26 2004
+++ edited/drivers/usb/core/usb.c	Tue Jul  6 12:00:32 2004
@@ -871,7 +871,7 @@
 {
 	if (!down_read_trylock(&usb_all_devices_rwsem))
 		return 0;
-	if (!down_trylock(&udev->serialize)) {
+	if (down_trylock(&udev->serialize)) {
 		up_read(&usb_all_devices_rwsem);
 		return 0;
 	}

Re: PATCH: (as339) Interpret down_trylock() result code correctly in usb.c

[Greg KH]

On Tue, Jul 06, 2004 at 12:11:19PM -0400, Alan Stern wrote:
> Greg:
> 
> As Andrew Morton has already spotted, I messed up the interpretation of
> the result codes from various _trylock() routines.  I didn't notice that
> down_trylock() and down_read_trylock() use opposite conventions for
> indicating success!  This patch fixes the incorrect interpretation of
> down_trylock().  That error may well be responsible for some of the
> problems cropping up recently with OHCI controllers.  Please apply.

Applied.

But even with this patch, and Andrew's, I have a hang at boot with my
USB mouse plugged in (uhci system).

thanks,

greg k-h

Re: PATCH: (as339) Interpret down_trylock() result code correctly in usb.c

[Greg KH]

On Wed, Jul 07, 2004 at 02:54:16PM -0700, Greg KH wrote:
> On Tue, Jul 06, 2004 at 12:11:19PM -0400, Alan Stern wrote:
> > Greg:
> > 
> > As Andrew Morton has already spotted, I messed up the interpretation of
> > the result codes from various _trylock() routines.  I didn't notice that
> > down_trylock() and down_read_trylock() use opposite conventions for
> > indicating success!  This patch fixes the incorrect interpretation of
> > down_trylock().  That error may well be responsible for some of the
> > problems cropping up recently with OHCI controllers.  Please apply.
> 
> Applied.
> 
> But even with this patch, and Andrew's, I have a hang at boot with my
> USB mouse plugged in (uhci system).

If I remove the mouse, and then boot, it works just fine.  I can then
insert it and the drivers are loaded just fine too.

Looks like a race on accessing usbfs and loading a driver at the same
time, as the "cold-boot" code scans usbfs to determine what driver to
load.

thanks,

greg k-h