lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C3A9A104-993C-4C8F-A323-93FF58F03162@holtmann.org>
Date:	Tue, 2 Jun 2015 03:32:05 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Laura Abbott <labbott@...oraproject.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Takashi Iwai <tiwai@...e.de>, Oliver Neukum <oneukum@...e.com>,
	Ming Lei <ming.lei@...onical.com>,
	"David S. Miller" <davem@...emloft.net>,
	Johan Hedberg <johan.hedberg@...il.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	linux-bluetooth@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] Bluetooth: btusb: Add reset_resume function

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@...oraproject.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ