Am 14.05.2018 um 11:58 schrieb Benjamin Tissoires: > Hi Heiner, > > On Fri, May 11, 2018 at 12:11 AM, Heiner Kallweit <hkallwe...@gmail.com> > wrote: >> Due to some other issue with one devices supported by hid-led I figured >> out that it's no longer needed to list devices with own driver in >> hid_have_special_driver[]. >> >> So I removed the entries for the hid-led devices and got the following. >> When I plugged in the device first the device-specific driver wasn't >> loaded. After unplugging/re-plugging the device-specific driver was >> loaded properly. >> >> It seems usbhid module wasn't fully loaded and active yet when >> hid-generic checks for a device-specific driver for the first time. >> This also explains why the second attempt was successful. > > I don't think so. When you plugged in the device, the usb core stack > emitted a uevent requesting usbhid to be loaded. Then udev loaded > usbhid, which created the USB-HID transport layer device immediately > and started probing devices attached to it. The kernel emitted then a > uevent regarding 0003:0FC5:B080, and udev answered by loading > hid-generic. hid-generic made its initialization of the HID device, > and then only now usbhid finished its initialization where it emits > "USB HID core driver". > > On the second attempt, the uevent is still emitted by the kernel, but > this time udev loaded hid-led, which is detected by the hid-sstack as > a new candidate and it takes precedence over hid-generic. > > Keep in mind that the kernel doesn't load external modules, but udev > does. So here, it seems we expected udev to load hid-led the first > time, but it didn't. > >> >> Did you come across similar races? At a first glance I'm not sure how >> to prevent this race. Any idea? > > This is related to udev and the way the uevents are emitted. > Maybe if we see the logs from "udevadm monitor" I'll be able to tell a > little bit more. Meanwhile, I'll try reproducing it locally. > > Also, the v4.17-rc series has seen a little cleanup in the way > hid-generic is unbound, so it is worth a try. > I used the latest linux-next kernel, so I assume these changes should be included. When trying to create the "udevadm monitor" log I found that I can't reproduce the issue. Hmm, strange .. I will keep an eye on it. Until then: sorry for the noise.
Heiner > Cheers, > Benjamin > >> >> [ 15.785205] usb 2-5: new low-speed USB device number 4 using xhci_hcd >> [ 15.917766] usb 2-5: New USB device found, idVendor=0fc5, idProduct=b080, >> bcdDevice= 0.1f >> [ 15.917842] usb 2-5: New USB device strings: Mfr=1, Product=2, >> SerialNumber=0 >> [ 15.917899] usb 2-5: Product: USB IO Controller >> [ 15.917941] usb 2-5: Manufacturer: Delcom Products Inc. >> [ 15.943667] hid-generic 0003:0FC5:B080.0001: hiddev96,hidraw0: USB HID >> v1.00 Device [Delcom Products Inc. USB IO Controller ] on >> usb-0000:00:14.0-5/input0 >> [ 15.944171] usbcore: registered new interface driver usbhid >> [ 15.944204] usbhid: USB HID core driver >> [ 101.496255] usb 2-5: USB disconnect, device number 4 >> [ 107.364402] usb 2-5: new low-speed USB device number 5 using xhci_hcd >> [ 107.496582] usb 2-5: New USB device found, idVendor=0fc5, idProduct=b080, >> bcdDevice= 0.1f >> [ 107.496659] usb 2-5: New USB device strings: Mfr=1, Product=2, >> SerialNumber=0 >> [ 107.496716] usb 2-5: Product: USB IO Controller >> [ 107.496757] usb 2-5: Manufacturer: Delcom Products Inc. >> [ 107.510676] hid-led 0003:0FC5:B080.0002: hidraw0: USB HID v1.00 Device >> [Delcom Products Inc. USB IO Controller ] on usb-0000:00:14.0-5/input0 >> [ 107.511975] hid-led 0003:0FC5:B080.0002: Delcom Visual Signal Indicator >> G2 initialized > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
