linux-kernel - Re: [PATCH v2] HID: i2c-hid: wait for i2c touchpad deep-sleep to power-up transition

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, 15 Apr 2024 12:28:28 +0200
From: Kenny Levinsen <kl@...wtf>
To: lma@...omium.org
Cc: benjamin.tissoires@...hat.com, dianders@...omium.org, dtor@...omium.org,
 hdegoede@...hat.com, jikos@...nel.org, johan+linaro@...nel.org,
 johan@...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

> The problem is that the probe function calling i2c_smbus_read_byte()
> is not aware that
> uC on the other end is in a deep sleep state so the first read will
> fail and so the whole probe.
Well, the probe was just added to "avoid scary messages", so we could 
just do away with it and fix the "scary messages" instead.

I think it would be better to handle the wake-up near the command being 
sent that requires the device to be awake, just like is done for 
i2c_hid_set_power(). This would mean removing the smbus probe 
altogether, extending the HID descriptor fetch code to retry on 
EREMOTEIO, and to avoid the "scary messages", print something nice if 
the second attempt also fails with EREMOTEIO.

If the device can enter deep-sleep arbitrarily, then we presumably also 
have problems in i2c_hid_output_raw_report() and 
i2c_hid_get_raw_report() which could happen after the device has gone to 
sleep from inactivity. These places would also need EREMOTEIO retry logic.

All these places should have the same sleeping behavior as they are 
working around the same device glitch. I imagine the client ACK timeout 
is longer than your required 400µs, in which case you don't need any 
sleep on retry at all, as is the case in the current i2c_hid_set_power() 
implementation.

However, as we litter retry-code all over the place, Johan's suggestion 
about doing this in the I2C driver does become a bit more relevant...

Best regards,
Kenny Levinsen