Hi,
this fixes an issue in btusb's suspend/resume support that strikes if
the adapter is suspended while the hci is down.
This probably fixes the bug Pavel sees with autosuspend and fixes a bug
for me. I am currently looking at issues with new hardware, but with this patch
it should work at least for the best hardware.
What tree should I base a clean patch against?
Signed-off-by: Oliver Neukum <[email protected]>
Regards
Oliver
---
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ef24515..47ff028 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1072,6 +1069,10 @@ static int btusb_resume(struct usb_interface *intf)
clear_bit(HCI_RUNNING, &hdev->flags);
return ret;
}
+ } else {
+ spin_lock_irq(&data->lock);
+ clear_bit(BTUSB_SUSPENDING, &data->flags);
+ spin_unlock_irq(&data->lock);
}
if (hdev->conn_hash.acl_num > 0) {
Hi Oliver,
> this fixes an issue in btusb's suspend/resume support that strikes if
> the adapter is suspended while the hci is down.
> This probably fixes the bug Pavel sees with autosuspend and fixes a bug
> for me. I am currently looking at issues with new hardware, but with this patch
> it should work at least for the best hardware.
>
> What tree should I base a clean patch against?
can you send patches against my bluetooth-testing tree:
http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-testing.git;a=summary
Regards
Marcel
Hi Oliver,
> this fixes an issue in btusb's suspend/resume support that strikes if
> the adapter is suspended while the hci is down.
> This probably fixes the bug Pavel sees with autosuspend and fixes a bug
> for me. I am currently looking at issues with new hardware, but with this patch
> it should work at least for the best hardware.
>
> What tree should I base a clean patch against?
give me the weekend to sort out the trees. I want to get two extra fixes
into 2.6.27-rc9 and then we can start working on the suspend stuff for
2.6.28. I have pending patches that your patches should be based on so
we have a clean revision history and see how the evolved. I really hated
the quick fixing inside hci_usb and nobody ever could figure out what
actually made it work and what not.
Regards
Marcel
Hi!
> this fixes an issue in btusb's suspend/resume support that strikes if
> the adapter is suspended while the hci is down.
> This probably fixes the bug Pavel sees with autosuspend and fixes a bug
> for me. I am currently looking at issues with new hardware, but with this patch
> it should work at least for the best hardware.
It seems to fix the problem here.
> What tree should I base a clean patch against?
>
> Signed-off-by: Oliver Neukum <[email protected]>
Tested-by: Pavel Machek <[email protected]>
[okay, _lightly_ tested...]
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html