On Mon, Jul 27, 2009 at 23:32, Marcel Holtmann<marcel@xxxxxxxxxxxx> wrote: >> 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. Now it's getting funny. We need to call the nonsense two times to make it work? We need to fix the real issue here instead of doing guesswork and adding hacks like this. Any idea what's going on with the first scan? The device node is guaranteed to exist when we call stuff from RUN+= instructions. > then the usage of libusb needs to be removed. Read Kay's statement about > libusb being utterly stupid. Well, libusb might be ok for stuff that just searches things which are always there, it's definitely not suitable to be used in conjunction with udev. The entire coldplug with 500 devices takes ~0.5 seconds here, while a single call to libusb takes ~0.15 just to find the device we already have. That alone is not acceptable, and now we should call the useless scan twice? Tsss ... :) Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
