Re: [PATCH v2 5/9] dt-bindings: input: microchip,cap11xx: Add reset-gpios property

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The threaded interrupt handler returns IRQ_HANDLED even when it fails to clear the hardware interrupt due to I2C errors.
--

commit ace8e5621e0baa976a27041614c9c01f25526d5e
Author: Jun Yan <jerrysteve1101@gmail.com>

dt-bindings: input: microchip,cap11xx: Add reset-gpios property

This commit adds support for the optional reset-gpios property to describe
the active-high reset pin for CAP1126 and CAP1188 devices. It restricts
this property to only these variants, as other variants lack a hardware
reset pin.

> drivers/input/keyboard/cap11xx.c:cap11xx_thread_func() {
> ...
> 	ret = regmap_update_bits(priv->regmap, CAP11XX_REG_MAIN_CONTROL, 1, 0);
> 	if (ret < 0)
> 		goto out;
> 
> 	ret = regmap_read(priv->regmap, priv->model->sensor_input_reg_base, &status);
> 	if (ret < 0)
> 		goto out;
> ...
> out:
> 	return IRQ_HANDLED;
> }

[Severity: High]
This is a pre-existing issue, but does this error path cause an
interrupt storm?

If the I2C operations regmap_update_bits() or regmap_read() fail, the
function jumps to the out label and returns IRQ_HANDLED instead of
returning IRQ_NONE or disabling the IRQ.

Since the IRQ is registered with IRQF_ONESHOT, returning IRQ_HANDLED tells
the IRQ subsystem to unmask the interrupt line. If the interrupt condition
on the hardware was not successfully cleared due to the I2C failure, will
the interrupt immediately fire again?

This could create an infinite loop of threaded IRQ scheduling that bypasses
the kernel's spurious interrupt detector (which requires IRQ_NONE to
trigger), potentially consuming 100% of a CPU core and causing a soft
lockup.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=5