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 <labb...@fedoraproject.org>
> ---
> 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-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
