Hi, On Wed, 2021-11-03 at 16:11 -0400, Alan Stern wrote: > On Wed, Nov 03, 2021 at 08:31:03PM +0100, Marcel Holtmann wrote: > > the problem seems to be that we hitting HCI command timeout. So the > > firmware download is done via HCI commands. These commands are send to > > the transport driver btusb.c via hdev->send (as btusb_send_frame). > > This triggers the usb_submit_urb or queues them via data->deferred > > anchor. All this reports back the error properly except that nobody > > does anything with it. > > > > See hci_send_frame() last portion: > > > > err = hdev->send(hdev, skb); > > if (err < 0) { > > bt_dev_err(hdev, "sending frame failed (%d)", err); > > kfree_skb(skb); > > } > > > > And that is it. We are not checking for ENODEV or any error here. That > > means the failure of the HCI command gets only caught via the HCI > > command timeout. I don’t know how to do this yet, but you would have > > to look there to fail HCI command right away instead of waiting for > > the timeout. > > I have no idea how all the different layers work here. Clearly > something has to signal hdev->req_wait_q after setting hdev->req_status > to some appropriate value. Can this be done in btusb.c, either when the > URB is submitted or when it completes? Or in hci_send_frame? I submitted https://patchwork.kernel.org/project/bluetooth/list/?series=577565 for this now. The patchset pretty much calls hci_req_sync_cancel to set req_status and signal req_wait_q. Doing this and hooking it up in various location appears to work reasonably well for the synchronous commands. Benjamin PS: The user now reported that TLP is blocking the rfkill switch after resume. So an good workaround is to just not use TLP.
Attachment:
signature.asc
Description: This is a digitally signed message part