Re: Suspend/Resume (S3) issues with rmi_smbus

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Peter,

On Mon, May 30, 2022 at 10:48:06AM +0200, Peter Zijlstra wrote:
> Hi Dmitry,
> 
> My very aged x240 seems to require unloading and reloading of rmi_smbus
> after every suspend cycle, otherwise the touchpad won't work again.
> 
> It seems to have started a few releases ago, but it used to be
> occasional loss of touchpad, but now with 5.18 it is *every* suspend.
> 
> But the thing is, when I look at the git history of that file, it's not
> been touched in 2 years or so, so I'm somewhat confused what's causing
> this.
> 
> The relevant errors in dmesg are:
> 
> [26604.508618] rmi4_smbus 0-002c: failed to get SMBus version number!
> [26604.508852] rmi4_physical rmi4-03: rmi_driver_reset_handler: Failed to read current IRQ mask.
> [26604.509113] rmi4_f01 rmi4-03.fn01: Failed to restore normal operation: -6.
> [26604.509117] rmi4_f01 rmi4-03.fn01: Resume failed with code -6.
> [26604.509118] rmi4_physical rmi4-03: Failed to suspend functions: -6
> [26604.509120] rmi4_smbus 0-002c: Failed to resume device: -6
> 
> 
> Any clues where I should start poking? I'm not really familiar with this
> part of the kernel.

This is probably result of RMI device being resumed at a wrong time.
Some time ago we have enabled asynchronous resume of all I2C/SBbus
devices, but the touchpad is tricky as it can work in both PS/2 and
native RMI mode and the order of operations is important. It was
supposed to be fixed by

commit 7b1f781f2d2460693f43d5f764198df558e3494b
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Feb 15 13:32:26 2022 -0800

    Input: psmouse - set up dependency between PS/2 and SMBus companions

    When we switch from emulated PS/2 to native (RMI4 or Elan) protocols, we
    create SMBus companion devices that are attached to I2C/SMBus controllers.
    However, when suspending and resuming, we also need to make sure that we
    take into account the PS/2 device they are associated with, so that PS/2
    device is suspended after the companion and resumed before it, otherwise
    companions will not work properly. Before I2C devices were marked for
    asynchronous suspend/resume, this ordering happened naturally, but now we
    need to enforce it by establishing device links, with PS/2 devices being
    suppliers and SMBus companions being consumers.

    Fixes: 172d931910e1 ("i2c: enable async suspend/resume on i2c client devices")
    Reported-and-tested-by: Hugh Dickins <hughd@google.com>
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Link: https://lore.kernel.org/r/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com
    Link: https://lore.kernel.org/r/YgwQN8ynO88CPMju@google.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

that has landed in 5.17-rc6, but I wonder if something else in resume
process has changed.

Can you check the entire list of resume operations to make sure that
PS/2 device is resumed before RMI one?

You can also try overriding devices driven by rmi_smbus as needing
synchronous resume (see
https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/).

Thanks.

-- 
Dmitry