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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE5UKNqPA4SnnXyaB7Hwk0kcKMMQ_DUuxogDphnnvSGP8g1nAQ@mail.gmail.com>
Date: Tue, 23 Apr 2024 13:32:21 +0200
From: Łukasz Majczak <lma@...omium.org>
To: Kenny Levinsen <kl@...wtf>
Cc: Johan Hovold <johan@...nel.org>, benjamin.tissoires@...hat.com, dianders@...omium.org, 
	dtor@...omium.org, hdegoede@...hat.com, jikos@...nel.org, 
	johan+linaro@...nel.org, kai.heng.feng@...onical.com, 
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org, mripard@...nel.org, 
	rad@...omium.org
Subject: Re: [PATCH v2] HID: i2c-hid: wait for i2c touchpad deep-sleep to
 power-up transition

On Mon, Apr 15, 2024 at 7:14 PM Kenny Levinsen <kl@...wtf> wrote:
>
> On 4/15/24 3:22 PM, Johan Hovold wrote:
> > We also use it for devices that may not be populated (e.g. an optional
> > touchscreen) and in that case we should not print anything.
>
> I sent a patch series[0] that shows how the same can be achieved
> (gracefully handling missing device + retry to wake device) without any
> smbus probes, following the existing retry style in i2c_hid_set_power().
>
> Radoslaw and Lukasz, it somehow felt rude to tag and blame you for code
> you hadn't seen yet. If my patch ends up favored we should make sure to
> have the appropriate attribution tags added...
>
> [0]: https://lore.kernel.org/all/20240415170517.18780-1-kl@kl.wtf/
>
Hi Kenny,

Unfortunately, your fix doesn't help in our case as there is no sleep
before the second call to
i2c_hid_fetch_hid_descriptor().

Saying more, this STM exposes two i2c addresses (connected physically
to the same bus)
one is the HID interface and the other one gives an access to the base
firmware and is
served by cros_ec_i2c driver and actually thanks to this driver,
touchpad is woken up because
In the resume path cros_ec_i2c "starts talking" through the i2c bus
thus generating a wakeup
interrupt.

So we need to send a dummy (or any other) transaction that may fail to
wake up the controller after
a whole chromebook rebook and on the resume path.

Best regards,
Lukasz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ