On Mon, Sep 11, 2017 at 4:29 PM, Benson Leung wrote:
> Hi Oliver,
>
> On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
>> Thanks for the pointer. I'll respin the patch with the no_resume version of
>> usb_autopm_get_interface and retest.
>>
>
> I went and tried
On Mon, Sep 11, 2017 at 4:29 PM, Benson Leung wrote:
> Hi Oliver,
>
> On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
>> Thanks for the pointer. I'll respin the patch with the no_resume version of
>> usb_autopm_get_interface and retest.
>>
>
> I went and tried this patch but with
Hi Oliver,
On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
> Thanks for the pointer. I'll respin the patch with the no_resume version of
> usb_autopm_get_interface and retest.
>
I went and tried this patch but with usb_autopm_get_interface_no_resume instead
and the original bug I
Hi Oliver,
On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
> Thanks for the pointer. I'll respin the patch with the no_resume version of
> usb_autopm_get_interface and retest.
>
I went and tried this patch but with usb_autopm_get_interface_no_resume instead
and the original bug I
Hi Oliver,
On Sat, Sep 09, 2017 at 09:35:52AM +0200, Oliver Neukum wrote:
> Am Freitag, den 08.09.2017, 10:43 -0700 schrieb Dmitry Torokhov:
> > From: Benson Leung
> >
> > usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
> > cleared when a device is
Hi Oliver,
On Sat, Sep 09, 2017 at 09:35:52AM +0200, Oliver Neukum wrote:
> Am Freitag, den 08.09.2017, 10:43 -0700 schrieb Dmitry Torokhov:
> > From: Benson Leung
> >
> > usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
> > cleared when a device is closed.
> >
> > In
Am Freitag, den 08.09.2017, 10:43 -0700 schrieb Dmitry Torokhov:
> From: Benson Leung
>
> usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
> cleared when a device is closed.
>
> In usbhid_open, usb_autopm_get_interface is called before setting the
>
Am Freitag, den 08.09.2017, 10:43 -0700 schrieb Dmitry Torokhov:
> From: Benson Leung
>
> usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
> cleared when a device is closed.
>
> In usbhid_open, usb_autopm_get_interface is called before setting the
> needs_remote_wakeup
From: Benson Leung
usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
cleared when a device is closed.
In usbhid_open, usb_autopm_get_interface is called before setting the
needs_remote_wakeup flag, and usb_autopm_put_interface is called after
From: Benson Leung
usbhid->intf->needs_remote_wakeup is set when a device is opened, and is
cleared when a device is closed.
In usbhid_open, usb_autopm_get_interface is called before setting the
needs_remote_wakeup flag, and usb_autopm_put_interface is called after
hid_start_in. However, when
On Tue, Nov 25, 2014 at 7:24 AM, Alan Stern wrote:
> On Mon, 24 Nov 2014, Benson Leung wrote:
>
>> Hi Alan,
>>
>>
>> On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern
>> wrote:
>> > There is no USB wrapper for pm_runtime_idle calls, but one could be
>> > added. Still, in the meantime can you check
On Mon, 24 Nov 2014, Benson Leung wrote:
> Hi Alan,
>
>
> On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern wrote:
> > There is no USB wrapper for pm_runtime_idle calls, but one could be
> > added. Still, in the meantime can you check to see what happens if you
> > add
> >
> >
On Mon, 2014-11-24 at 16:56 -0800, Benson Leung wrote:
> Hi Oliver,
>
> On Mon, Nov 24, 2014 at 1:13 AM, Oliver Neukum wrote:
> >
> > But there is very little to be gained by switching off remote wakeup.
> > The additional energy consumption devices with remote wakeup enabled
> > will be dwarfed
On Mon, 2014-11-24 at 16:56 -0800, Benson Leung wrote:
Hi Oliver,
On Mon, Nov 24, 2014 at 1:13 AM, Oliver Neukum oneu...@suse.de wrote:
But there is very little to be gained by switching off remote wakeup.
The additional energy consumption devices with remote wakeup enabled
will be
On Mon, 24 Nov 2014, Benson Leung wrote:
Hi Alan,
On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern st...@rowland.harvard.edu wrote:
There is no USB wrapper for pm_runtime_idle calls, but one could be
added. Still, in the meantime can you check to see what happens if you
add
On Tue, Nov 25, 2014 at 7:24 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 24 Nov 2014, Benson Leung wrote:
Hi Alan,
On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern st...@rowland.harvard.edu
wrote:
There is no USB wrapper for pm_runtime_idle calls, but one could be
added. Still,
Hi Alan,
On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern wrote:
> There is no USB wrapper for pm_runtime_idle calls, but one could be
> added. Still, in the meantime can you check to see what happens if you
> add
>
> pm_runtime_idle(>intf->dev);
>
> in usbhid_close() just after
Hi Oliver,
On Mon, Nov 24, 2014 at 1:13 AM, Oliver Neukum wrote:
>
> But there is very little to be gained by switching off remote wakeup.
> The additional energy consumption devices with remote wakeup enabled
> will be dwarfed by the energy needed for an additional wakeup.
>
That makes sense
On Fri, 2014-11-21 at 17:00 -0800, Benson Leung wrote:
> If devices are already asleep with this flag enabled, that means that
> they are presently configured for remote wake.
Yes, but that doesn't matter. The drivers must be ready for a device
being resumed at any time. Remote wakeup just adds
On Fri, 2014-11-21 at 17:00 -0800, Benson Leung wrote:
If devices are already asleep with this flag enabled, that means that
they are presently configured for remote wake.
Yes, but that doesn't matter. The drivers must be ready for a device
being resumed at any time. Remote wakeup just adds
Hi Oliver,
On Mon, Nov 24, 2014 at 1:13 AM, Oliver Neukum oneu...@suse.de wrote:
But there is very little to be gained by switching off remote wakeup.
The additional energy consumption devices with remote wakeup enabled
will be dwarfed by the energy needed for an additional wakeup.
That
Hi Alan,
On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern st...@rowland.harvard.edu wrote:
There is no USB wrapper for pm_runtime_idle calls, but one could be
added. Still, in the meantime can you check to see what happens if you
add
pm_runtime_idle(usbhid-intf-dev);
in usbhid_close()
On Sat, 22 Nov 2014, Alan Stern wrote:
> There is no USB wrapper for pm_runtime_idle calls, but one could be
> added. Still, in the meantime can you check to see what happens if you
> add
>
> pm_runtime_idle(>intf->dev);
>
> in usbhid_close() just after needs_remote_wakeup is set to 0?
On Fri, 21 Nov 2014, Benson Leung wrote:
> Sorry for the delay in my response. I did some more checking of my
> particular failure, and my commit message is incorrect. The
> usb_kill_urb is actually not the cause of this problem. It does not
> result in autosuspend_check() itself, and is only
On Fri, 21 Nov 2014, Benson Leung wrote:
Sorry for the delay in my response. I did some more checking of my
particular failure, and my commit message is incorrect. The
usb_kill_urb is actually not the cause of this problem. It does not
result in autosuspend_check() itself, and is only serving
On Sat, 22 Nov 2014, Alan Stern wrote:
There is no USB wrapper for pm_runtime_idle calls, but one could be
added. Still, in the meantime can you check to see what happens if you
add
pm_runtime_idle(usbhid-intf-dev);
in usbhid_close() just after needs_remote_wakeup is set to 0?
On Fri, Nov 14, 2014 at 1:08 AM, Oliver Neukum wrote:
> On Thu, 2014-11-13 at 12:16 -0800, Benson Leung wrote:
>
>> In usbhid_open, usb_autopm_get_interface is called
>> before setting the needs_remote_wakeup flag, and
>> usb_autopm_put_interface is called after hid_start_in.
>>
>> However, when
Hi Alan,
On Fri, Nov 14, 2014 at 7:17 AM, Alan Stern wrote:
>
> The reason for the get/put is to force a call to autosuspend_check().
> But in this case, if killing the interrupt URB causes
> autosuspend_check() to run then the get/put isn't needed.
>
> On the other hand, I don't see why killing
Hi Alan,
On Fri, Nov 14, 2014 at 7:17 AM, Alan Stern st...@rowland.harvard.edu wrote:
The reason for the get/put is to force a call to autosuspend_check().
But in this case, if killing the interrupt URB causes
autosuspend_check() to run then the get/put isn't needed.
On the other hand, I
On Fri, Nov 14, 2014 at 1:08 AM, Oliver Neukum oneu...@suse.de wrote:
On Thu, 2014-11-13 at 12:16 -0800, Benson Leung wrote:
In usbhid_open, usb_autopm_get_interface is called
before setting the needs_remote_wakeup flag, and
usb_autopm_put_interface is called after hid_start_in.
However,
On Thu, 13 Nov 2014, Benson Leung wrote:
> Hi Alan,
>
> On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern wrote:
> > Wait a minute -- in your previous email you said this approach didn't
> > work. So does it work or doesn't it?
>
> Sorry for the confusion. The approach *does* work.
>
> That was
On Thu, 2014-11-13 at 12:16 -0800, Benson Leung wrote:
> In usbhid_open, usb_autopm_get_interface is called
> before setting the needs_remote_wakeup flag, and
> usb_autopm_put_interface is called after hid_start_in.
>
> However, when the device is closed in usbhid_close, the same
> protection
On Thu, 2014-11-13 at 12:16 -0800, Benson Leung wrote:
In usbhid_open, usb_autopm_get_interface is called
before setting the needs_remote_wakeup flag, and
usb_autopm_put_interface is called after hid_start_in.
However, when the device is closed in usbhid_close, the same
protection isn't
On Thu, 13 Nov 2014, Benson Leung wrote:
Hi Alan,
On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern st...@rowland.harvard.edu wrote:
Wait a minute -- in your previous email you said this approach didn't
work. So does it work or doesn't it?
Sorry for the confusion. The approach *does* work.
Hi Alan,
On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern wrote:
> Wait a minute -- in your previous email you said this approach didn't
> work. So does it work or doesn't it?
Sorry for the confusion. The approach *does* work.
That was actually my original idea to fix the problem, but I saw other
On Thu, 13 Nov 2014, Benson Leung wrote:
> On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern wrote:
> > If you interchange the two lines then the flag _will_ be cleared before
> > usb_kill_urb() and autosuspend_check() can run. This means your patch
> > description is bogus.
>
> Gotcha. v2 posted.
On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern wrote:
> If you interchange the two lines then the flag _will_ be cleared before
> usb_kill_urb() and autosuspend_check() can run. This means your patch
> description is bogus.
Gotcha. v2 posted. Thanks for the direction.
--
Benson Leung
Software
On Thu, 13 Nov 2014, Benson Leung wrote:
> On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern
> wrote:
> > usbhid_stop probably doesn't need it. And it should be possible to fix
> > usbhid_close more easily just by interchanging the two lines:
> >
> > -
On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern wrote:
> usbhid_stop probably doesn't need it. And it should be possible to fix
> usbhid_close more easily just by interchanging the two lines:
>
> - usb_kill_urb(usbhid->urbin);
>
On Thu, 13 Nov 2014, Benson Leung wrote:
> usbhid->intf->needs_remote_wakeup is set when a device is
> opened, and is cleared when a device is closed.
>
> When a usbhid device that does not support remote wake
> ( i.e. !device_can_wakeup() ) is closed, we fail out of
> autosuspend_check()
usbhid->intf->needs_remote_wakeup is set when a device is
opened, and is cleared when a device is closed.
When a usbhid device that does not support remote wake
( i.e. !device_can_wakeup() ) is closed, we fail out of
autosuspend_check() because the autosuspend check is called
before the flag is
usbhid-intf-needs_remote_wakeup is set when a device is
opened, and is cleared when a device is closed.
When a usbhid device that does not support remote wake
( i.e. !device_can_wakeup() ) is closed, we fail out of
autosuspend_check() because the autosuspend check is called
before the flag is
On Thu, 13 Nov 2014, Benson Leung wrote:
usbhid-intf-needs_remote_wakeup is set when a device is
opened, and is cleared when a device is closed.
When a usbhid device that does not support remote wake
( i.e. !device_can_wakeup() ) is closed, we fail out of
autosuspend_check() because the
On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
usbhid_stop probably doesn't need it. And it should be possible to fix
usbhid_close more easily just by interchanging the two lines:
- usb_kill_urb(usbhid-urbin);
On Thu, 13 Nov 2014, Benson Leung wrote:
On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern st...@rowland.harvard.edu
wrote:
usbhid_stop probably doesn't need it. And it should be possible to fix
usbhid_close more easily just by interchanging the two lines:
-
On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern st...@rowland.harvard.edu wrote:
If you interchange the two lines then the flag _will_ be cleared before
usb_kill_urb() and autosuspend_check() can run. This means your patch
description is bogus.
Gotcha. v2 posted. Thanks for the direction.
--
On Thu, 13 Nov 2014, Benson Leung wrote:
On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern st...@rowland.harvard.edu wrote:
If you interchange the two lines then the flag _will_ be cleared before
usb_kill_urb() and autosuspend_check() can run. This means your patch
description is bogus.
Hi Alan,
On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern st...@rowland.harvard.edu wrote:
Wait a minute -- in your previous email you said this approach didn't
work. So does it work or doesn't it?
Sorry for the confusion. The approach *does* work.
That was actually my original idea to fix the
48 matches
Mail list logo