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
