Suspend/Resume (S3) issues with rmi_smbus

Suspend/Resume (S3) issues with rmi_smbus

[Peter Zijlstra]

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.

Re: Suspend/Resume (S3) issues with rmi_smbus

[Dmitry Torokhov]

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

Re: Suspend/Resume (S3) issues with rmi_smbus

[Peter Zijlstra]

On Mon, May 30, 2022 at 12:15:40PM -0700, Dmitry Torokhov wrote:

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

It reports psmouse failure *after* the rmi4 failure. Is there a knob to
make it print more device model details on resume?

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

I can confirm this works.

Re: Suspend/Resume (S3) issues with rmi_smbus

[Dmitry Torokhov]

On Tue, May 31, 2022 at 10:54:19AM +0200, Peter Zijlstra wrote:
> On Mon, May 30, 2022 at 12:15:40PM -0700, Dmitry Torokhov wrote:
> 
> > Can you check the entire list of resume operations to make sure that
> > PS/2 device is resumed before RMI one?
> 
> It reports psmouse failure *after* the rmi4 failure. Is there a knob to
> make it print more device model details on resume?
> 
> > You can also try overriding devices driven by rmi_smbus as needing
> > synchronous resume (see
> > https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/).
> 
> I can confirm this works.

Let's ask Rafael if he has an idea why adding a link between PS/2 device
and its SMbus companion did not seem to affect resume order. Was there a
change in 5.18 timeframe (since original reporters said that adding
device link helped their case).

Let's also add a couple of more folks who experienced original issue to
see if they observe this as well.

Thanks.

-- 
Dmitry

Re: Suspend/Resume (S3) issues with rmi_smbus

[Peter Zijlstra]

On Tue, May 31, 2022 at 10:54:20AM +0200, Peter Zijlstra wrote:
> On Mon, May 30, 2022 at 12:15:40PM -0700, Dmitry Torokhov wrote:
> 
> > Can you check the entire list of resume operations to make sure that
> > PS/2 device is resumed before RMI one?
> 
> It reports psmouse failure *after* the rmi4 failure. Is there a knob to
> make it print more device model details on resume?
> 
> > You can also try overriding devices driven by rmi_smbus as needing
> > synchronous resume (see
> > https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/).
> 
> I can confirm this works.

I might have spoken too soon; this morning I still had no touchpad :/

Most weird.

Re: Suspend/Resume (S3) issues with rmi_smbus

[Jarkko Nikula]

On 5/31/22 18:50, Dmitry Torokhov wrote:
> On Tue, May 31, 2022 at 10:54:19AM +0200, Peter Zijlstra wrote:
>> On Mon, May 30, 2022 at 12:15:40PM -0700, Dmitry Torokhov wrote:
>>
>>> Can you check the entire list of resume operations to make sure that
>>> PS/2 device is resumed before RMI one?
>>
>> It reports psmouse failure *after* the rmi4 failure. Is there a knob to
>> make it print more device model details on resume?
>>
>>> You can also try overriding devices driven by rmi_smbus as needing
>>> synchronous resume (see
>>> https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/).
>>
>> I can confirm this works.
> 
> Let's ask Rafael if he has an idea why adding a link between PS/2 device
> and its SMbus companion did not seem to affect resume order. Was there a
> change in 5.18 timeframe (since original reporters said that adding
> device link helped their case).
> 
> Let's also add a couple of more folks who experienced original issue to
> see if they observe this as well.
> 
For me the psmouse keeps working on v5.18 over repeated suspend-resume 
cycles on the same machine that had the regression with the commit 
172d931910e1 ("i2c: enable async suspend/resume on i2c client devices").

Re: Suspend/Resume (S3) issues with rmi_smbus

[Hugh Dickins]

On Wed, 1 Jun 2022, Jarkko Nikula wrote:
> On 5/31/22 18:50, Dmitry Torokhov wrote:
> > On Tue, May 31, 2022 at 10:54:19AM +0200, Peter Zijlstra wrote:
> >> On Mon, May 30, 2022 at 12:15:40PM -0700, Dmitry Torokhov wrote:
> >>
> >>> Can you check the entire list of resume operations to make sure that
> >>> PS/2 device is resumed before RMI one?
> >>
> >> It reports psmouse failure *after* the rmi4 failure. Is there a knob to
> >> make it print more device model details on resume?
> >>
> >>> You can also try overriding devices driven by rmi_smbus as needing
> >>> synchronous resume (see
> >>> https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/).
> >>
> >> I can confirm this works.
> > 
> > Let's ask Rafael if he has an idea why adding a link between PS/2 device
> > and its SMbus companion did not seem to affect resume order. Was there a
> > change in 5.18 timeframe (since original reporters said that adding
> > device link helped their case).
> > 
> > Let's also add a couple of more folks who experienced original issue to
> > see if they observe this as well.
> > 
> For me the psmouse keeps working on v5.18 over repeated suspend-resume cycles
> on the same machine that had the regression with the commit 172d931910e1
> ("i2c: enable async suspend/resume on i2c client devices").

Same here for me, no problem with v5.18, thanks -
I'd have complained loudly if I had seen a problem!

Hugh