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.
Signed-off-by: Wen-chien Jesse Sung <[email protected]>
---
drivers/bluetooth/btusb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Am Dienstag, 25. Oktober 2011, 16:48:59 schrieb Jesse Sung:
> 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
On 10/25/2011 07:43 PM, Oliver Neukum wrote:
> Am Dienstag, 25. Oktober 2011, 13:20:13 schrieb Jesse Sung:
>> On 10/25/2011 04:40 PM, Oliver Neukum wrote:
>>> Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
>>>>
>>>> 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.
>>>
>>> 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?
>>
>> 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.
>
> 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, 13:20:13 schrieb Jesse Sung:
> On 10/25/2011 04:40 PM, Oliver Neukum wrote:
> > Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
> >>
> >> 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.
> >
> > 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.
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
On 10/25/2011 04:40 PM, Oliver Neukum wrote:
> Am Dienstag, 25. Oktober 2011, 10:37:38 schrieb Jesse Sung:
>>
>> 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.
>
> 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, 10:37:38 schrieb Jesse Sung:
>
> 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.
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