Re: power management for usb_hci

Am Mittwoch 10 Oktober 2007 schrieb Marcel Holtmann:

Hello,

> the standard itself is fine, but non of the Bluetooth chip manufactures
> have properly tested it. They claim they support it, but that is about
> it. Some dongle manufactures actually explicitly set the remote wakeup
> to _not_ supported to avoid host stacks trying.

That's OK, too.

> The case we have no Bluetooth connection it is easy. In that case we
> only have an interrupt URB and that can be suspended easily. The problem
> case is when we have a connection and put that one into sniff to save
> power. That is problematic.

Yes. If it were easy, it'd be already done. ;-)

> > Will you post code?
> 
> http://git.infradead.org/?p=users/holtmann/bluetooth-drivers.git;a=summary
> 
> Look for the the btusb.ko driver.

+static int btusb_open(struct hci_dev *hdev)
+{
+       struct btusb_data *data = hdev->driver_data;
+       int err;
+
+       BT_DBG("%s", hdev->name);
+
+       if (test_and_set_bit(HCI_RUNNING, &hdev->flags))
+               return 0;
+
+       if (test_and_set_bit(BTUSB_INTR_RUNNING, &data->flags))
+               return 0;
+
+       err = btusb_submit_intr_urb(hdev);
+       if (err < 0) {
+               clear_bit(BTUSB_INTR_RUNNING, &hdev->flags);
+               clear_bit(HCI_RUNNING, &hdev->flags);
+       }
+
+       return err;
+}

That's a race. Furthermore, if btusb_submit_intr_urb() fails, you'll have
a second open suceeding without a running urb.

	Regards
		Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel