lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 1 May 2023 20:11:59 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Jonathan Denose <jdenose@...omium.org>
Cc:     Andrew Duggan <andrew@...gan.us>, Lyude Paul <lyude@...hat.com>,
        Andrew Duggan <aduggan@...aptics.com>,
        "amandhoot12@...il.com" <amandhoot12@...il.com>,
        "jdenose@...gle.com" <jdenose@...gle.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "markpearson@...ovo.com" <markpearson@...ovo.com>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        benjamin.tissoires@...hat.com
Subject: Re: [PATCH v2] Input: synaptics - disable intertouch for Lenovo L440

On Mon, Apr 24, 2023 at 02:11:28PM -0500, Jonathan Denose wrote:
> Hi Andrew,
> 
> Thanks for your reply. As an update, I was able to try the patch here:
> https://lore.kernel.org/all/YgHTYrODoo2ou49J@google.com/ and it
> resolves the suspend/resume issue on this device. I'm not sure what
> the status of the linked patch is, to me it doesn't look like it was
> merged anywhere.

This patch shoudl have been superseded by:

commit 7b1f781f2d2460693f43d5f764198df558e3494b
Author: Dmitry Torokhov <dmitry.torokhov@...il.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@...gle.com>
    Tested-by: Jarkko Nikula <jarkko.nikula@...ux.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@...il.com>

Which should have ensured that PS/2 device is resumed first, before
trying to resume RMI interface. I wonder why it is not working for you.

Can you enable logging and see if the order of resume is correct or not.
If it is still wrong we need to figure out why setting the link between
the devices does not have the desired effect.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ