> > It doesn't make sense to me that if more delays are added in > > the kernel code, userland needs to see even more. > > I agree, but Olaf and others prove that this works.
There was that hypothesis that it's really control traffic interference ... I notice that usb_control_msg() chose against the "keep the setup data in struct usb_device and lock it with a semaphore" strategy (it kmallocs the setup buffer), so I could see how that'd happen. "usbmodules" asks the device for its config descriptor, rather than reading /proc/bus/usb/BBB/DDD, so HCDs that don't handle control queuing (I think OHCI behaves there, and EHCI, but not the UHCIs) might suffer from concurrent control messages from it and from HID ... I think the best that can be done for now would be a hack: add a lock in usb_device that must be held by whoever submits a control request, and released when that request completes. The non-hack solution is to support control queuing in all HCDs. What kind of lock? Maybe that binary semaphore. Code that needs to issue control requests in_interrupt() would need to be modified, as would usb_control_msg(). > I'm more puzzled why usbmodules is needing to talk to a device. I > thought usbmodules was only for cold-plug stuff. Have any ideas? Usbmodules is used to cope with /sbin/hotplug not providing a complete interface descriptor dump: it only shows the first of N inferface descriptors. With coldplug, it doesn't run, and doesn't provide any descriptors at all -- so it must be used. However, even for the hotplug case "usbmodules" gives a more complete module list. In the case of an audio device with a sound/ISO interface and a control/HID interface, it'll pick up the HID. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
