Hi Tedd, >>> +/* >>> + * Send Intel Reset command to the device to enable the operational >>> firmware. >>> + * Because the device will not send CC event for Intel Reset command, >>> + * the command is sent with btusb_send_frame() instead of >>> __hci_cmd_sync() so >>> + * the host won't wait for event. >>> + */ >> >> Why :( >> >> These are the things that does frustrate me sometimes. Is it too much to >> ask from the bootloader to acknowledge that it received the command and >> only then go and reset everything in the device. >> >> I mean you start using a well defined transport protocol and then you >> start violating it whenever you please because it is some tiny shortcut. >> It means that the host stack now has to do extra work and we can never >> tell when the device actually does a reset or if something fails. I mean >> how would we know if some of the firmware verification fails? > > I knew that you won¹t like it. :) > This is currently on discussion and this implementation is based on the > current spec and firmware design. > I will update you in a few days. if you go through the Bluetooth specification, then every HCI command sends a HCI command status event (or command complete) before doing its execution. Even commands like HCI Reset do this. If you have to deal with UART chips that change the baudrate even the vendor specific commands are pretty clear that the HCI command status event comes via the old baudrate and only after that the new baudrate can be assumed. I think it is just good practice to send the HCI command status event here and only after sending it out to do the reset and have the new firmware run. And I realize that internally there is some fun with the USB endpoints and making sure the host got this event. However that is better than the host guessing since if anything goes wrong, the host can not recover from this. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
