@@ -45,13 +45,25 @@ static int rmi_smb_get_version(struct rmi_smb_xport *rmi_smb)
int retval;
/* Check if for SMBus new version device by reading version byte. */
- retval = i2c_smbus_read_byte_data(client, SMB_PROTOCOL_VERSION_ADDRESS);
- if (retval < 0) {
+ for (int i = 0; i < 2; i++) {
+ if (i > 0) {
+ dev_warn(&client->dev, "sleeping to retry getting the SMBus version number\n");
+ fsleep(30000);
+ }
+ retval = i2c_smbus_read_byte_data(client,
+ SMB_PROTOCOL_VERSION_ADDRESS);
+ if (retval >= 0)
+ return retval + 1;
+
dev_err(&client->dev, "failed to get SMBus version number!\n");
- return retval;
+ /* There can be a delay on resume where the read returns
+ * -ENXIO. Retry to allow additional time for the read
+ * to become responsive.
+ */
+ if (retval != -ENXIO)
+ break;
}
-
- return retval + 1;
+ return retval;
}
/* SMB block write - wrapper over ic2_smb_write_block */
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 [1]. With this patch the trimmed resume logs look similar to: ``` psmouse serio1: PM: calling serio_resume+0x0/0x8c @ 5399, parent: i8042 [5399] libps2:__ps2_command:316: psmouse serio1: f5 [] - 0/00000000 [] psmouse serio1: PM: serio_resume+0x0/0x8c returned 0 after 3259 usecs ... rmi4_smbus 0-002c: PM: calling rmi_smb_resume ... @ 5454, parent: i2c-0 ... [5454] i2c_i801:i801_check_post:414: i801_smbus 0000:00:1f.3: No response smbus_result: i2c-0 a=02c f=0000 c=fd BYTE_DATA rd res=-6 rmi4_smbus 0-002c: failed to get SMBus version number! rmi4_smbus 0-002c: sleeping to retry getting the SMBus version number ... rmi4_smbus 0-002c: PM: rmi_smb_resume ... returned 0 after 41351 usecs ``` [1]: https://lore.kernel.org/all/BYAPR03MB47572F2C65E52ED673238D41B2439@BYAPR03MB4757.namprd03.prod.outlook.com/ Signed-off-by: Jeffery Miller <jefferymiller@google.com> --- Early boot dmesg include: ``` rmi4_smbus 0-002c: registering SMbus-connected sensor rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2722-001, fw id: 0 ``` The resume order looks correct. The `psmouse serio1` resume returns before the rmi_smb_resume is called showing the patch from https://lore.kernel.org/all/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com/ is applied and working for that ordering. I attempted to try to rule out some interaction between the concurrent input resume calls for other i8042 devices. Adding a 7ms delay after psmouse_deactivate which is called in the preceding psmouse serio1 serio_resume function also allows this version call to succeed. If the rmi_smb_probe device_disable_async_suspend patch is applied it will also avoid this issue. However the time between the psmouse_deactivate call for serio_resume and rmi_smb_resume was over 60ms on my test machine. This would naturally be long enough to avoid this particular delay. Changes in v2: - Changed to a single retry of 30ms based on previous feedback. drivers/input/rmi4/rmi_smbus.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)