# Kernel 7.2.3 (shipped in 4.0.3): ELAN i2c-hid touchpad intermittently freezes — A/B confirmed against linux-lts

## System details

- Acer Nitro 5 laptop, Intel TigerLake-H (i915) + RTX 3050 mobile
- Touchpad: `ELAN0521:01 04F3:31B1` on i2c-designware adapter `i2c_designware.1`
  (Intel LPSS PCI 0000:00:15.1)
- Omarchy 4.0.3, kernel `7.2.3-arch1-3` (updated from 4.0.2 / `7.1.9-arch1-2` in the
  same `Update > Omarchy` run)
- Note: the i2c-designware driver is built into the Arch `linux` and `linux-lts`
  kernels (`modules.builtin`), so this cannot be worked around with module overrides.

## What's wrong

After updating to 4.0.3 (which bumped the kernel 7.1.9 → 7.2.3), the touchpad
intermittently freezes for seconds at a time. No errors appear in the kernel log
while it happens. Freezes occur on a fresh boot, after a cold power-off boot, and
after suspend/resume, within minutes of normal use.

`omarchy restart trackpad` (i2c_hid_acpi unbind/rebind) restores function, but the
freezes return after the next reboot.

## Evidence

### Regression window

- On 7.1.9: weeks of daily use, 9 S3 suspend/resume cycles across boots, zero
  touchpad issues and zero i2c errors in the entire journal history.
- On the first 7.2.3 boot + first suspend (same day the update was applied): the
  first-ever occurrence of
  `i2c_hid_acpi i2c-ELAN0521:01: i2c_hid_get_input: incomplete report (14/65280)`
  (twice), followed by the intermittent freezes.
- Stable changelogs 7.2.1–7.2.3 contain no commits touching i2c-hid,
  i2c-designware, or elantech paths → the regression window is v7.1 → v7.2 mainline.

### A/B test (same machine, same day, same workload)

| Kernel | Result |
|---|---|
| 7.2.3-arch1-3 (cold boot, no suspend) | freezes recur within minutes |
| 6.18.49-3-lts | 2+ hours of normal use, zero freezes |

### Exclusions tested

- Fractional scale / software cursor (1.25): in use for 3 weeks before the update
  without issue — excluded.
- Leftover suspend state: freezes persist after full cold power-off — excluded.
- i2c controller runtime PM wake path: `power/control=on` pinned on PCI 00:15.1 —
  no change — excluded as sole cause.
- Stuck touchpad MCU/EC state: cold power-off + fresh enumeration — excluded.

### Commit-level analysis of v7.1 → v7.2 in the touchpad path

Functional delta in `drivers/i2c/busses/i2c-designware*` reachable from v7.2 but
not v7.1:

1. `f5cfe0a71` — **i2c: designware: Handle active target cleanly** (prime suspect)
   Changes post-transfer handling in the master xfer path: when the controller is
   still active after a transfer, the new code runs `i2c_recover_bus()` +
   `i2c_dw_init()` and *skips* `__i2c_dw_disable_nowait()`. This is the exact code
   path that decides whether a wedged controller gets cleaned up, and the symptom
   (intermittent silent input stalls on an i2c-hid client) is compatible.
   Caveat: the `controller active after xfer, recovering` message this branch
   prints was not observed in dmesg during captured freezes.
2. `beec6b0a3` — i2c: designware: use PM_RUNTIME_ACQUIRE()/PM_RUNTIME_ACQUIRE_ERR()
   in probe. Cosmetic if the macros are equivalent; PM-adjacent, second-tier suspect.
3. `199a0fd95` — i2c: designware: shutdown handling for target (slave) mode.
   Not applicable to this device (master-mode client).

(All other i2c-hid commits in the window — BLTP7853 quirk, hid_safe_input_report(),
EMPTYFIFO_HOLD support, I2C_M_STOP, the January refactor series — are already in
v7.1 and therefore excluded. Remaining window commits in these files are
include/cosmetic cleanups.)

## Reproduce

On affected hardware: boot `linux` 7.2.3, use the touchpad normally; multi-second
freezes occur with empty dmesg. Boot `linux-lts` under identical conditions; no
freezes.

## Suggestions

- Affected users can run `linux-lts` as a workaround (`omarchy install` / pacman),
  with the LTS entry selected in the Limine menu.
- Consider documenting the workaround or a `restart trackpad` resume hook for
  affected ELAN/designware machines until the kernel-side fix lands.
- Happy to run a custom 7.2.3 build with `f5cfe0a71` reverted for commit-level
  attribution if that would help.