# Re: \[PATCH V3\] input: Fix USB autosuspend on bcm5974

- From: Alan Stern \<stern@rowland.harvard.edu\>
- Date: 2011-10-12 14:33:14 
- List: linux-input
- Page: https://ratatoskr.run/linux-input/2011/10/8918001
- Thread: https://ratatoskr.run/linux-input/2011/10/8917970/t.md

```text
On Wed, 12 Oct 2011, Oliver Neukum wrote:

> Am Dienstag, 11. Oktober 2011, 22:42:50 schrieb Matthew Garrett:
> > On Tue, Oct 11, 2011 at 01:09:21PM +0200, Oliver Neukum wrote:
> > > Am Dienstag, 11. Oktober 2011, 13:04:21 schrieb Henrik Rydberg:
> > > > Problem: the hid keyboard driver refuses to suspend while a key is
> > > > pressed, which is fine per se, but there is no indication presented to the power layer,
> > > > resulting in a failed suspend and (due to complex reasons it seems) disabled autosuspend.
> > > 
> > > That is a bug. Autosuspend at a later date should happen.
> > 
> > Yeah, there's definitely something broken here. If I hold down a key on 
> > a USB keyboard for more than two seconds then it attempts to suspend but 
> > fails. Releasing the key triggers another usb_mark_busy() but the core 
> > never tries to suspend it again. What /does/ trigger a second attempt at 
> > suspend is toggling an LED on and then off.
> 
> It seems to me that rpm_suspend() in drivers/base/power has already called
> pm_runtime_cancel_pending(dev) unconditionally before calling rpm_callback()
> And afterwards the timer is not restarted.

I admit to not being very familiar with the way usbhid handles 
autosuspend.  However in general, if a suspend fails because the driver 
is busy, then when the driver stops being busy it should initiate the 
next round of autosuspend.  In this case, when the key release has been 
fully processed, the driver should call usb_put_interface_async() or 
something similar, which would restart the timer.

Alan Stern

```