On 03/11/2011 05:33 PM, Gustavo F. Padovan wrote:
* Johan Hedberg<johan.hedberg@xxxxxxxxx> [2011-03-10 09:32:06 +0200]:
Hi,
On Wed, Mar 09, 2011, Ed Tomlinson wrote:
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 9c4541b..f690eb5 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -95,18 +95,17 @@ void hci_req_complete(struct hci_dev *hdev, __u16
cmd, int result)
{
BT_DBG("%s command 0x%04x result 0x%2.2x", hdev->name, cmd, result);
+ if (hdev->req_status == HCI_REQ_PEND) {
+ hdev->req_result = result;
+ hdev->req_status = HCI_REQ_DONE;
+ wake_up_interruptible(&hdev->req_wait_q);
+ }
/* If the request has set req_last_cmd (typical for multi-HCI
* command requests) check if the completed command matches
* this, and if not just return. Single HCI command requests
* typically leave req_last_cmd as 0 */
if (hdev->req_last_cmd&& cmd != hdev->req_last_cmd)
return;
-
- if (hdev->req_status == HCI_REQ_PEND) {
- hdev->req_result = result;
- hdev->req_status = HCI_REQ_DONE;
- wake_up_interruptible(&hdev->req_wait_q);
- }
}
static void hci_req_cancel(struct hci_dev *hdev, int err)
Works here too - bluetooth comes up enabled. On to Linus?
All the patch does is it re-breaks the __hci_request function by
removing proper synchronization from it (again) and thereby hides the
real bug which is the kernel sending commands to the controller before
the HCI_Reset command has completed.
I got an 1.1 Bluetooth dongle that can cause this issue, now I can test this
by myself. I'll work to fix this next week.
cool... I am not going insane!!! let me know if you want me to test any
patches out.
Justin P. Mattock
--
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
