Hi Jeffery, On Thu, Jun 08, 2023 at 09:04:00PM +0000, Jeffery Miller wrote: > On resume there can be a period of time after the > preceding serio_resume -> psmouse_deactivate call > where calls to rmi_smb_get_version fail with > -ENXIO. > > The call path in rmi_smb_resume is rmi_smb_resume -> rmi_smb_reset -> > rmi_smb_enable_smbus_mode -> rmi_smb_get_version where > this failure would occur. > > Add a 30ms delay and retry in the ENXIO case to ensure the following > rmi_driver_resume calls in rmi_smbus_resume can succeed. > > This behavior was seen on a Lenovo T440p machine that required > a delay of approximately 7-12ms. > > The 30ms delay was chosen based on the linux-input message: > Link: https://lore.kernel.org/all/BYAPR03MB47572F2C65E52ED673238D41B2439@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ I do not quite like putting these retries in RMI code. I wonder if we should not move the delay into psmouse_smbus_reconnect(): if (smbdev->need_deactivate) { psmouse_deactivate(psmouse); /* Give the device time to switch to SMBus mode */ msleep(30); } or even factor it out into psmouse_activate_smbus_mode() and call it from psmouse_smbus_reconnect() as well as psmouse_smbus_init(). Thanks. or even factor it out into psmouse_activate_smbus_mode() and call it from psmouse_smbus_reconnect() as well as psmouse_smbus_init(). Thanks. -- Dmitry
