linux-toradex.git/drivers/hid/i2c-hid, branch v6.11

HID: i2c-hid: elan: fix reset suspend current leakage

2024-06-07T09:18:11+00:00

The Elan eKTH5015M touch controller found on the Lenovo ThinkPad X13s
shares the VCC33 supply with other peripherals that may remain powered
during suspend (e.g. when enabled as wakeup sources).

The reset line is also wired so that it can be left deasserted when the
supply is off.

This is important as it avoids holding the controller in reset for
extended periods of time when it remains powered, which can lead to
increased power consumption, and also avoids leaking current through the
X13s reset circuitry during suspend (and after driver unbind).

Use the new 'no-reset-on-power-off' devicetree property to determine
when reset needs to be asserted on power down.

Notably this also avoids wasting power on machine variants without a
touchscreen for which the driver would otherwise exit probe with reset
asserted.

Fixes: bd3cba00dcc6 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens")
Cc: 	# 6.0
Cc: Douglas Anderson 
Tested-by: Steev Klimaszewski 
Signed-off-by: Johan Hovold 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20240507144821.12275-5-johan+linaro@kernel.org
Signed-off-by: Benjamin Tissoires

Merge branch 'for-6.10/i2c-hid' into for-linus

2024-05-14T11:51:19+00:00

- PM fixes for STM and Weida Tech devices (Kenny Levinsen)

HID: i2c-hid: Remove unused label in i2c_hid_set_power

2024-05-07T08:43:10+00:00

This label was left behind when the wake-up logic was moved from
i2c_hid_set_power to i2c_hid_probe_address. Clean it up as it causes
warnings-as-errors builds to fail.

Fixes: bb1033c8a3ea ("HID: i2c-hid: Use address probe to wake on resume")
Reported-by: Stephen Rothwell 
Signed-off-by: Kenny Levinsen 
Signed-off-by: Jiri Kosina

HID: i2c-hid: Use address probe to wake on resume

2024-05-06T21:27:37+00:00

Certain devices, both from STM and Weida Tech, need to be woken up after
having entered a deeper sleep state. The relevant places to wake up such
device is during our initial HID probe, and after resuming.

A retry for power commands was previously added to i2c_hid_set_power to
wake up Weida Tech devices, but lacked sufficient sleep for STM devices.
Replace the power command retry with the same address probe we using
during our initial HID probe.

Signed-off-by: Kenny Levinsen 
Signed-off-by: Jiri Kosina

HID: i2c-hid: Retry address probe after delay

2024-05-06T21:27:37+00:00

Some STM microcontrollers need 400µs after rising clock edge in order to
come out of their deep sleep state. This in turn means that our address
probe will fail as the device is not ready to service it.

Retry the probe once after a delay to see if the device came alive,
otherwise treat the device as missing.

Link: https://lore.kernel.org/all/20240405102436.3479210-1-lma@chromium.org/#t
Co-developed-by: Radoslaw Biernacki 
Co-developed-by: Lukasz Majczak 
Signed-off-by: Kenny Levinsen 
Signed-off-by: Jiri Kosina

HID: i2c-hid: Revert to await reset ACK before reading report descriptor

2024-04-03T12:01:21+00:00

In af93a167eda9, i2c_hid_parse was changed to continue with reading the
report descriptor before waiting for reset to be acknowledged.

This has lead to two regressions:

1. We fail to handle reset acknowledgment if it happens while reading
   the report descriptor. The transfer sets I2C_HID_READ_PENDING, which
   causes the IRQ handler to return without doing anything.

   This affects both a Wacom touchscreen and a Sensel touchpad.

2. On a Sensel touchpad, reading the report descriptor this quickly
   after reset results in all zeroes or partial zeroes.

The issues were observed on the Lenovo Thinkpad Z16 Gen 2.

The change in question was made based on a Microsoft article[0] stating
that Windows 8 *may* read the report descriptor in parallel with
awaiting reset acknowledgment, intended as a slight reset performance
optimization. Perhaps they only do this if reset is not completing
quickly enough for their tastes?

As the code is not currently ready to read registers in parallel with a
pending reset acknowledgment, and as reading quickly breaks the report
descriptor on the Sensel touchpad, revert to waiting for reset
acknowledgment before proceeding to read the report descriptor.

[0]: https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/plug-and-play-support-and-power-management

Fixes: af93a167eda9 ("HID: i2c-hid: Move i2c_hid_finish_hwreset() to after reading the report-descriptor")
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2271136
Cc: stable@vger.kernel.org
Signed-off-by: Kenny Levinsen 
Link: https://lore.kernel.org/r/20240331182440.14477-1-kl@kl.wtf
[hdegoede@redhat.com Drop no longer necessary abort_reset error exit path]
Signed-off-by: Hans de Goede 
Tested-by: Mark Pearson 
Signed-off-by: Jiri Kosina

HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up

2024-03-21T12:26:35+00:00

The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.

More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.

Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.

Delete this unnecessary flag.

Reported-and-tested-by: Eva Kurchatova 
Closes: https://lore.kernel.org/r/CA+eeCSPUDpUg76ZO8dszSbAGn+UHjcyv8F1J-CUPVARAzEtW9w@mail.gmail.com
Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation")
Cc: 
Signed-off-by: Nam Cao 
Signed-off-by: Jiri Kosina

HID: i2c-hid-of: fix NULL-deref on failed power up

2024-01-26T17:52:14+00:00

A while back the I2C HID implementation was split in an ACPI and OF
part, but the new OF driver never initialises the client pointer which
is dereferenced on power-up failures.

Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
Cc: stable@vger.kernel.org      # 5.12
Cc: Douglas Anderson 
Signed-off-by: Johan Hovold 
Reviewed-by: Douglas Anderson 
Signed-off-by: Jiri Kosina

HID: i2c-hid: Skip SET_POWER SLEEP for Cirque touchpad on system suspend

2024-01-23T10:26:06+00:00

There's a Cirque touchpad that wakes system up without anything touched
the touchpad. The input report is empty when this happens.
The reason is stated in HID over I2C spec, 7.2.8.2:
"If the DEVICE wishes to wake the HOST from its low power state, it can
issue a wake by asserting the interrupt."

This is fine if OS can put system back to suspend by identifying input
wakeup count stays the same on resume, like Chrome OS Dark Resume [0].
But for regular distro such policy is lacking.

Though the change doesn't bring any impact on power consumption for
touchpad is minimal, other i2c-hid device may depends on SLEEP control
power. So use a quirk to limit the change scope.

[0] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/power_manager/docs/dark_resume.md

Signed-off-by: Kai-Heng Feng 
Reviewed-by: Douglas Anderson 
Signed-off-by: Jiri Kosina

Merge branch 'for-6.8/i2c-hid' into for-linus

2024-01-08T20:03:27+00:00

- rework of wait-for-reset in order to reduce the need
  for I2C_HID_QUIRK_NO_IRQ_AFTER_RESET qurk; the success rate is now
  50% better, but there are still further improvements to be made (Hans de Goede)