On Wed, Nov 25, 2015 at 09:25:59AM -0800, Todd E Brandt wrote: > On Tue, Nov 24, 2015 at 05:26:15PM -0800, Dmitry Torokhov wrote: > > On Tue, Nov 24, 2015 at 4:58 PM, Todd Brandt > > <todd.e.brandt@xxxxxxxxxxxxxxx> wrote: > > > Delay the error rescan for serio devices until the PM > > > complete phase. PM complete requires locking each device > > > before checking for and executing the complete callbacks. > > > Serio rescan also locks the device in order to reinit on > > > error, so this can cause a conflict which will result in > > > unnecessary delay. > > > > > > History: > > > > > > The issue was discovered on an ivy bridge platform with > > > i8042 keyboard/mouse. The mouse resume fails > > > > I'd first try to figure out why reconnect failed. What kind of > > mouse/touchpad is that? > > It's an Alps PS/2 glidepoint touchpad. The actual error appears to be > a failure in alps_identify as it attempts to get the EC report using > alps_rpt_cmd. However, I don't think this is too important since > the psmouse driver is just doing what it's supposed to. It's the > fact that the error was mitigated right in the middle of the system > resume that caused the delay. > > I expect that errors in input drivers will happen quite a lot. Users I do not expect that. If device is still there then we should be able to communicate with it. Failure to do so indicates that there is some issue (resume order?) and I would like to know what it is. > > don't typically care as long as the device eventually rights itself > and they don't notice. Theoretically you lose settings that you done manually through sysfs. Suspend/resume cycle is not supposed to lose your settings. Thanks. -- Dmitry -- 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
