Bluetooth: set reset_resume handler
PATCH 1/1 Bluetooth: set reset_resume handler
On some machines, it seems that usb hubs do not get power while being suspended. We can get something like this in dmesg:
usb usb2: root hub lost power or was reset
When this is the case, .reset_resume is called instead of .resume. If .reset_resume is not set, bluetooth modules would stay in an unusable state because the resume function is not called.
--- drivers/bluetooth/btusb.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/bluetooth/btusb.c +1 -0
@@ -1220,6 +1220,7 @@ static struct usb_driver btusb_driver = {#ifdef CONFIG_PM .suspend = btusb_suspend, .resume = btusb_resume, + .reset_resume = btusb_resume, #endif .id_table = btusb_table, .supports_autosuspend = 1,
Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
Quoted 8 lines
On some machines, it seems that usb hubs do not get power while being suspended. We can get something like this in dmesg:
usb usb2: root hub lost power or was resetWhen this is the case, .reset_resume is called instead of .resume. If .reset_resume is not set, bluetooth modules would stay in an unusable state because the resume function is not called.
Have you experimentally verified that? This state of affairs is years old and should result in a virtual unplug/replug cycle. What are you seeing?
Regards
Oliver
Quoted 10 lines · Oliver Neukum
Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
Quoted 8 lines
On some machines, it seems that usb hubs do not get power while being suspended. We can get something like this in dmesg:
usb usb2: root hub lost power or was resetWhen this is the case, .reset_resume is called instead of .resume. If .reset_resume is not set, bluetooth modules would stay in an unusable state because the resume function is not called.
Quoted 6 lines
Have you experimentally verified that? This state of affairs is years old and should result in a virtual unplug/replug cycle. What are you seeing?
Regards
Oliver
Hi Oliver,
Humm... You're right, there is an unplug-replug cycle, but bluetooth doesn't work until I restart bluetoothd. If the resume function is called through .reset_resume, then bluetooth works right after resume.
Regards,
Jesse
Am Dienstag, 25. Oktober 2011, 13:20:13 schrieb Jesse Sung:
Quoted 15 lines · Oliver Neukum
Quoted 14 lines
Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
Quoted 8 lines
On some machines, it seems that usb hubs do not get power while being suspended. We can get something like this in dmesg:
usb usb2: root hub lost power or was resetWhen this is the case, .reset_resume is called instead of .resume. If .reset_resume is not set, bluetooth modules would stay in an unusable state because the resume function is not called.
Have you experimentally verified that? This state of affairs is years old and should result in a virtual unplug/replug cycle. What are you seeing?
Quoted 8 lines
Quoted 2 lines
Regards
OliverHi Oliver,
Humm... You're right, there is an unplug-replug cycle, but bluetooth doesn't work until I restart bluetoothd. If the resume function is called through .reset_resume, then bluetooth works right after resume.
Hi
Yes, but we fail to indicate to user space that connections may have been dropped. I doubt we can simply pretend the loss of power hasn't occured. Have you tested what happens if you go to S3 while eg. a file is transfered or audio played with your patch?
Regards
Oliver
Quoted 22 lines · Oliver Neukum
Am Dienstag, 25. Oktober 2011, 13:20:13 schrieb Jesse Sung:
Quoted 15 lines · Oliver Neukum
Quoted 6 lines
Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
Quoted 5 lines
On some machines, it seems that usb hubs do not get power while being suspended. We can get something like this in dmesg:
usb usb2: root hub lost power or was resetQuoted 7 lines
Quoted 3 lines
When this is the case, .reset_resume is called instead of .resume. If .reset_resume is not set, bluetooth modules would stay in an unusable state because the resume function is not called.
Have you experimentally verified that? This state of affairs is years old and should result in a virtual unplug/replug cycle. What are you seeing?
Quoted 5 lines
Hi Oliver,
Humm... You're right, there is an unplug-replug cycle, but bluetooth doesn't work until I restart bluetoothd. If the resume function is called through .reset_resume, then bluetooth works right after resume.
Quoted 6 lines
Hi
Yes, but we fail to indicate to user space that connections may have been dropped. I doubt we can simply pretend the loss of power hasn't occured. Have you tested what happens if you go to S3 while eg. a file is transfered or audio played with your patch?
Hi Oliver,
Indeed, loss of power event should not be ignored.
Just tested file transferring. If there's no active connection, everything goes fine. But if a file is transferring while going to S3, bluetooth is not working after resume. Use applet to disable and re-enable bluetooth makes it work again...
Wondering what is the right way to handle loss of power...
Regards,
Jesse
Am Dienstag, 25. Oktober 2011, 16:48:59 schrieb Jesse Sung:
Quoted 6 lines
Just tested file transferring. If there's no active connection, everything goes fine. But if a file is transferring while going to S3, bluetooth is not working after resume. Use applet to disable and re-enable bluetooth makes it work again...
Wondering what is the right way to handle loss of power...
A virtual unplug/plug worked until now, even if it was inelegant.
Regards
Oliver