Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jun Yan" <jerrysteve1101@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
	conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 7/9] Input: cap11xx - refactor code for better CAP1114 support.
Date: Fri, 12 Jun 2026 07:35:02 +0000	[thread overview]
Message-ID: <20260612073503.1B73E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612072237.1177304-8-jerrysteve1101@gmail.com>

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

Pre-existing issues:
- [High] The input device is registered and exposed to userspace before its threaded IRQ handler is requested, creating a race window where events could be lost or unhandled.
--

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

Input: cap11xx - refactor code for better CAP1114 support.

Extend cap11xx_hw_model structure to support CAP1114 with
different register offsets and hardware characteristics.

> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 75746a8a22332..d45bb231d7a1f 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -554,41 +564,64 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
>  }

[Severity: High]
This isn't a bug introduced by this patch, but looking at cap11xx_i2c_probe(),
the input device is registered and exposed to userspace before its threaded
IRQ handler is requested:

	error = input_register_device(priv->idev);
	if (error)
		return error;

	error = devm_request_threaded_irq(dev, i2c_client->irq,
					  NULL, cap11xx_thread_func,
					  IRQF_ONESHOT, dev_name(dev), priv);

Since input_register_device() makes the device visible to userspace, processes
like udev can immediately open the device. This invokes cap11xx_input_open()
and wakes the hardware from deep sleep.

If a hardware interrupt occurs before devm_request_threaded_irq() registers
the handler, could this unhandled interrupt cause an interrupt storm? The
kernel might then disable the IRQ line ('nobody cared'), rendering the touch
controller permanently inoperable until the module is reloaded or the system
reboots.

Should the IRQ handler be requested before the device is registered?

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

  reply	other threads:[~2026-06-12  7:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12  7:22 [PATCH v2 0/9] Input: cap11xx - Add support for CAP1114 Jun Yan
2026-06-12  7:22 ` [PATCH v2 1/9] Input: cap11xx - clean up duplicate log and add probe error logs Jun Yan
2026-06-12  7:32   ` sashiko-bot
2026-06-12  7:22 ` [PATCH v2 2/9] Input: cap11xx - remove unused register macros Jun Yan
2026-06-12  7:22 ` [PATCH v2 3/9] dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED reg range Jun Yan
2026-06-12  7:22 ` [PATCH v2 4/9] dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg constraints Jun Yan
2026-06-12  7:22 ` [PATCH v2 5/9] dt-bindings: input: microchip,cap11xx: Add reset-gpios property Jun Yan
2026-06-12  7:32   ` sashiko-bot
2026-06-12  7:22 ` [PATCH v2 6/9] Input: cap11xx - add reset gpio support Jun Yan
2026-06-12  7:31   ` sashiko-bot
2026-06-12  7:22 ` [PATCH v2 7/9] Input: cap11xx - refactor code for better CAP1114 support Jun Yan
2026-06-12  7:35   ` sashiko-bot [this message]
2026-06-12  7:22 ` [PATCH v2 8/9] dt-bindings: input: microchip,cap11xx: Add " Jun Yan
2026-06-12  7:35   ` sashiko-bot
2026-06-12  7:22 ` [PATCH v2 9/9] Input: cap11xx - add support for CAP1114 Jun Yan
2026-06-12  7:42   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260612073503.1B73E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jerrysteve1101@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox