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 usb
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 w
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 us
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 fl
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 th
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 to
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
> >
> > pm_runtime_idl
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
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(&usbhid->intf->dev);
>
> in usbhid_close() just after need
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 to
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 o
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
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 serv
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 t
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
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 act
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
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
p
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. Th
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 Eng
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:
> >
> > - usb_kill_urb(usbhid->urbi
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);
> usbhid->intf->needs_remot
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
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 cl
24 matches
Mail list logo
