From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mario Limonciello <mario_limonciello@dell.com>
Date: Mon, 27 Jul 2009 21:19:57 +0000
Subject: [PATCH 1/2] hid2hci: iterate libusb devices twice
Message-Id: <4A6E19FD.7040908@dell.com>
MIME-Version: 1
Content-Type: multipart/mixed; boundary="------------enig2D2EF9FA53FA161FF9ED90EE"
List-Id: <linux-hotplug.vger.kernel.org>
To: linux-hotplug@vger.kernel.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2D2EF9FA53FA161FF9ED90EE
Content-Type: multipart/mixed;
 boundary="------------010508080402090309040500"

This is a multi-part message in MIME format.
--------------010508080402090309040500
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi:

After the previous cleanup submitted to hid2hci, a race condition has
been exposed with regard to libusb.  Even though we know the bus and
devnum are existing, the call to usb_find_devices isn't necessarily
finding it on the first time after the device is introduced to the bus
by the BT killswitch.  I'm not too keen upon iterating something twice
as a solution, it does solve the problem until a method is introduced in
usb_device_open_from_udev that doesn't require libusb's iteration of the
bus in the first place.

Regards
--=20
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com

--------------010508080402090309040500
Content-Type: text/x-patch;
 name="iterate.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="iterate.diff"

Even though we know that the device is on the proper bus, libusb
doesn't always find it on the first try.  Once we find the right
bus, if we iterate it twice, we tend to find the device.
=3D=3D=3D modified file 'extras/hid2hci/hid2hci.c'
--- extras/hid2hci/hid2hci.c	2009-07-24 16:06:22 +0000
+++ extras/hid2hci/hid2hci.c	2009-07-27 20:45:34 +0000
@@ -161,6 +161,7 @@
 	const char *str;
 	int busnum;
 	int devnum;
+	int trynum;
=20
 	str =3D udev_device_get_sysattr_value(usb_dev, "busnum");
 	if (str =3D=3D NULL)
@@ -174,7 +175,6 @@
=20
 	usb_init();
 	usb_find_busses();
-	usb_find_devices();
=20
 	for (bus =3D usb_get_busses(); bus; bus =3D bus->next) {
 		struct usb_device *dev;
@@ -182,9 +182,11 @@
 		if (strtol(bus->dirname, NULL, 10) !=3D busnum)
 			continue;
=20
-		for (dev =3D bus->devices; dev; dev =3D dev->next) {
-			if (dev->devnum =3D=3D devnum)
-				return dev;
+		for (trynum =3D 0; trynum < 2; trynum++) {
+			usb_find_devices();
+			for (dev =3D bus->devices; dev; dev =3D dev->next)
+				if (dev->devnum =3D=3D devnum)
+					return dev;
 		}
 	}
=20


--------------010508080402090309040500--

--------------enig2D2EF9FA53FA161FF9ED90EE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpuGf0ACgkQ2CrZjkA73YtIKACfVc4+1Au0pihlJzg6lv3nBG4D
M5EAnR/+KJJSk3moo6x7BuxmcJbzVLm+
=Wgjb
-----END PGP SIGNATURE-----

--------------enig2D2EF9FA53FA161FF9ED90EE--