Re: i2c_hid_acpi: ELAN2514 touchscreen causes IRQ flood on HP Omnibook X 14 (Lunar Lake)

[Strider Jones <stridera@gmail.com>]

Adding a second machine with the same failure, in case it helps get this
looked at. Happy to test patches or collect more data.

Hardware
  HP OmniBook 7 Flip Laptop 16-au0xxx (SKU B88B1UA#ABA), board 8DA0
  Intel Core Ultra 7 258V (Lunar Lake), Insyde BIOS F.10 (2025-10-22),
  latest available on LVFS as of 2026-09-15
  Touchscreen: ELAN2514:00, 04F3:43F0 (yours is 43F4)
  ACPI path \_SB.PC00.I2C4.TPL1 on I2C #4, PCI 00:19.0
  (8086 Core Ultra 200V I2C #4), i2c_designware.2, IRQ 20
  Ubuntu 26.10 development branch, kernels 7.0.0-30 and 7.2.0-5 both
  affected; first seen 2026-08-09.

Symptoms match your report exactly. At probe:

  i2c_hid_acpi i2c-ELAN2514:00: i2c_hid_get_input: IRQ triggered but there's no data

and then IRQ 20 (the i2c-designware controller line, IR-IO-APIC level)
never stops. Measured today by binding the driver by hand with my udev
workaround disabled:

  - ~49,500 interrupts on IRQ 20 within 2 s of the bind
  - steady state ~21,500/s, all on one CPU
  - the irq/108-ELAN2514:00 thread sits in D state; on an earlier
    occurrence (2026-09-03) its kernel stack was inside i2c_dw_xfer and
    the log had repeated
      i2c_hid_get_input: incomplete report (67/65280)
    i.e. reads returning 0xff filler.
  - echo i2c-ELAN2514:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
    drops IRQ 20 to 0/s immediately.

The device's own interrupt is IRQ 108 (IR-IO-APIC, level). The touchpad
(SYNA3503:00 on I2C #5 / i2c_designware.3) on the same platform is fine.

DSDT details, consistent with your Interrupt()-vs-GpioInt() finding:
TPL1 carries two resource buffers; SBFI is an Extended Interrupt
descriptor with flags 0x05 (level, active-low, exclusive) and its vector
is patched at _INI with INT2 = INUM(GPLI). _CRS returns the GpioInt()
variant (G_IN(GPLI,...)) only when TPLM == 0; this firmware has
TPLM != 0, so we get the APIC path. _HID is rewritten to "ELAN2514" at
_INI when TPLT == 7.

Storm frequency is intermittent on my box rather than every boot: some
boots ran for days without it, others hit it at probe. When it happens
it takes the desktop down (compositor waits on the stuck I2C bus), so
I'm running the same unbind-at-probe udev rule you described:

  ACTION=="add|bind", SUBSYSTEM=="i2c", KERNEL=="i2c-ELAN2514:00", \
    RUN+="/bin/sh -c 'echo i2c-ELAN2514:00 > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind'"

Interesting aside: when hid-multitouch binds it registers the usual
touchscreen/stylus nodes plus five "UNKNOWN" input nodes and a
"Keyboard" node, same odd set you saw. When it probed via hid-generic on
one boot the primary node was reported as "I2C HID v1.00 Keyboard".

I can provide the decompiled DSDT, an acpidump, dmesg with
i2c-designware/i2c-hid dynamic debug, or test a quirk against 04F3:43F0
on request.

Strider Jones