Hi!
> >> This gives the userspace (Replicant) a chance to fully handle the
> >> pm_wakeup_event, before autosleep suspends the system alltogether
> >> again.
> >>
> >> This fixes suspend/resume on the OpenPhoenux GTA04, in combination with
> >> the Replicant 4.2.2 userspace, which needs to execute this to stay
> >> awake: 'echo on > /sys/power/state'
> >>
> >> Signed-off-by: Lukas Märdian <lu...@goldelico.com>
> >> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> >
> > I'm sorry, but we should not be doing this.
> >
> > You basically put a delay in driver to work around userspace bug.
>
> Do you think it is a user-space bug if the kernel goes to sleep again
> before giving user space any chance to react to an event?
Well, who says 1000msec is enough? Some userspace may need
more. ... for example on PC when you keyboard-handling deamon is
swapped out.
> And the msec parameter is described as:
>
> @msec: Anticipated event processing time (in milliseconds).
>
> Isn't calling pm_wakeup_event() with a non-zero msec the standard
> method to handle this situation? And it is used in other drivers. E.g. in
> _mmc_detect_change() or hub_suspend().
* Notify the PM core of a wakeup event whose source is @ws that will
take
* approximately @msec milliseconds to be processed by the kernel. If
@ws is
* not active, activate it. If @msec is nonzero, set up the @ws'
timer to
* execute pm_wakeup_timer_fn() in future.
Will take @msec milliseconds to be processed by the _kernel_. Yes, USB
probing takes a lot of time in kernel. But you are using this
parameter to wait for userspace...
> > There must be better
> > solution....
>
> I am not sure how it could look like.
Rafael, do you have any idea how this is supposed to work?
Original patch is at https://lkml.org/lkml/2014/4/10/156 .
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
