In hci_transport_usb, make sure close wasn't called before resubmitting transfers

[GoogleCodeExporter]

In hci_transport_usb, handle_completed_transfer calls the packet_handler and 
resubmits the transfer when needed. But if the packet handler has caused 
usb_close to be called (by calling hci_power_control for example), usb 
processing should be stopped.

What steps will reproduce the problem?
1. Run the daemon.
2. Connect and disconnect a client.
3. Wait for for the daemon_no_connections_timeout timer to run (and call 
hci_power_control).
4. If on the next run loop iteration a libusb fd is set, 
handle_completed_transfer will get called and call the packet_handler.
5. The hci packet handler callback will call usb_close (in HCI_STATE_HALTING 
handling).
6. Calling libusb_submit_transfer in this state, or later iterating the 
handle_packet in usb_process_ds, is invalid.

What is the expected output? What do you see instead?
- usb_close should set libusb_state back to LIB_USB_CLOSED, and set handle to 
NULL;
- Before calling libusb_submit_transfer in handle_completed_transfer, check 
that the state is still valid.
- In usb_process_ds, after calling handle_completed_transfer, a similar check 
should be done (since the handle_packet is invalid after usb_close is called).

What version of the product are you using? On what operating system?
Present in the latest r2599.

Original issue reported on code.google.com by kob...@mce-sys.com on 12 Jun 2014 at 8:57

[GoogleCodeExporter]

Thanks again. I've only used the daemon on iOS and Android, where there was an 
H4_UART.

I've added the state checks as suggested. Please check if you miss another one.

Original comment by matthias.ringwald@gmail.com on 12 Jun 2014 at 12:25

• Changed state: Fixed