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 <lukas@xxxxxxxxxxxxx> > >> Signed-off-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> > > > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
