Hi Laura,
> Some USB hubs may lose power across suspend/resume.
> Add a reset_resume callback to properly reset those bluetoot devices.
>
> Signed-off-by: Laura Abbott <labbott@xxxxxxxxxxxxxxxxx>
> ---
> Now the setup function is called again with the HCI_RESET_RESUME
> flag set. The various functions could then use that RESET_RESUME
> flag to determine if loading the firmware is appropriate or not.
> ---
> drivers/bluetooth/btusb.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3c10d4d..34884cf 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3382,6 +3382,21 @@ done:
>
> return err;
> }
> +
> +static int btusb_reset_resume(struct usb_interface *intf)
> +{
> + struct btusb_data *data = usb_get_intfdata(intf);
> + struct hci_dev *hdev = data->hdev;
> + int ret;
> +
> + BT_DBG("intf %p", intf);
> +
> + ret = btusb_resume(intf);
> + if (ret)
> + return ret;
> +
> + return hci_reset_resume_dev(hdev);
> +}
it seems convenient to call btusb_resume, but I would really prefer if we didn’t. From what I know is that when reset_resume callback is called, then the device has been reset. So that means any prior transfer we have remembered is null and void. So even trying to replay any of it is just a lost cause.
Instead we should clear any pending transfers and clear everything and instead pretend that we bring the transport back to its virgin state. It also means that isochronous transfers should be all killed since we will have no SCO connections after this. Remember that we are telling the Bluetooth core to reset this device.
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
