> > I meant any part of USB core. Whoever calls disconnect > > could potentially tell HCD to cancel all requests on this device. > >The "potential" is that substantial (b) rework. Ok. I'll give it more thinking and may be propose something later. Gotta study USB code a bit more :).
Just to give you guys an update on Bluetooth USB driver status and outstanding issues. First of all, huge thanks to all who replied. Based on our discussion I did bunch of fixes in Bluetooth USB driver and it seems to work fine with all HCDs and weird Bluetooth USB devices now. Basically I don't free URBs in the completion handler any more. I also make sure that I don't send more than one ctrl packet at time even if I get interrupt before ctrl completion. And I protect my completion handlers with appropriate lock to make sure that they aren't running when I flush urb queues and cleanup stuff. So everything seems to be ok, no complains from uses so far. Here is list of outstanding issues: - uhci HCD has to be fixed to not call completion handler if submit_urb failed. It's still an issue because drivers do not expect that. - One shot interrupt transfer using USBDEVFS API. Couple of kernel releases ago we (Greg and I) added support for one shot interrupts to devio.c. Basically it's just a normal interrupt request with urb->interval == 0. It works just fine with uhci.c. usb-uhci returns ECONNABORTED even for successful transfer but it can be ignored and works. And it totally doesn't work with ohci. REAP_URB ioctl never returns and if device is unplugged machine crashes badly. I need interrupt transfers for my user space USB firmware loader for Broadcom USB devices. Thanks Max _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
