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

[Oliver Neukum <oliver@neukum.org>]

Am Dienstag, 11. Oktober 2011, 13:04:21 schrieb Henrik Rydberg:
> On Tue, Oct 11, 2011 at 06:10:12AM +0200, Oliver Neukum wrote:
> > Am Dienstag, 11. Oktober 2011, 02:11:03 schrieb Matthew Garrett:
> > 
> > > Ah, right, sorry - I wasn't trying to use the device after it had been 
> > > closed. In an ideal world we'd really want to be able to indicate that 
> > > we don't want a remote wakeup in that situation. Otherwise, the patch 
> > > looks good. Thank you!
> > 
> > It looks like we had exactly that capability until
> > 48826626263d4a61d06fd8c5805da31f925aefa0
> > removed it.
> 
> Hm. Throwing in another related question below.
> 
> 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.

> Question:  If the hid interrupt handler were to actually prevent
> suspend during keypress, what would be the natural way to do it?

Firstly we must prevent autosuspension when a key is pressed
because most keyboards do not generate a wakeup upon key release
which is then lost.

Secondly a key pres triggers the mark_busy. We could do an async
get on every key press and an async put on every key release. But you
cannot beat the principal race here because the operation happen
in interrupt and must therefore be async. You must be prepared for
the window to be hit and return an error code.

	Regards
		Oliver