> > 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

Reply via email to