From: sashiko-bot@kernel.org
To: "Luka Panio" <lukapanio@gmail.com>
Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org, robh@kernel.org,
conor+dt@kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH 2/7] Input: edt-ft5x06 - move the controller bring-up into a helper
Date: Sat, 17 Oct 2026 14:16:56 +0000 [thread overview]
Message-ID: <sashiko-outbox-175542@kernel.org> (raw)
In-Reply-To: <20261017140827.290666-3-lukapanio@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Input: edt-ft5x06: edt_ft5x06_ts_init_hw() registers device before IRQ
--
commit 5aab9a2f7e5d9f696c6cdfb8f9baf87581af8689
Author: Luka Panio <lukapanio@gmail.com>
Input: edt-ft5x06 - move the controller bring-up into a helper
This commit moves the controller reset release, hardware identification,
input device registration, and debugfs setup out of edt_ft5x06_probe()
into a new edt_ft5x06_ts_init_hw() helper function.
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 543cc62088c7a..536d633d97a78 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -1116,16 +1116,96 @@ static void edt_ft5x06_disable_regulators(void *arg)
> regulator_disable(data->iovcc);
> }
>
> +/*
> + * Take the controller out of reset, identify it and register the input
> + * device.
> + */
> +static int edt_ft5x06_ts_init_hw(struct edt_ft5x06_ts_data *tsdata)
> +{
[ ... ]
> + error = input_register_device(input);
> + if (error)
> + return error;
> +
> + edt_ft5x06_ts_prepare_debugfs(tsdata);
> +
> + return 0;
> +}
> +
> int edt_ft5x06_probe(struct device *dev, struct regmap *regmap, int irq,
> const struct edt_ft5x06_chip_data *chip_data, u16 bustype,
> struct dentry *debugfs)
> {
[ ... ]
> @@ -1225,78 +1305,22 @@ int edt_ft5x06_probe(struct device *dev, struct regmap *regmap, int irq,
[ ... ]
> + error = edt_ft5x06_ts_init_hw(tsdata);
> + if (error)
> return error;
> - }
>
> irq_flags = irq_get_trigger_type(irq);
> if (irq_flags == IRQF_TRIGGER_NONE)
> @@ -1310,12 +1334,6 @@ int edt_ft5x06_probe(struct device *dev, struct regmap *regmap, int irq,
> return error;
> }
>
> - error = input_register_device(input);
> - if (error)
> - return error;
> -
> - edt_ft5x06_ts_prepare_debugfs(tsdata);
> -
> dev_dbg(dev,
> "EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
> irq,
[Severity: Medium]
Previously, edt_ft5x06_probe() called devm_request_threaded_irq() before
calling input_register_device() and edt_ft5x06_ts_prepare_debugfs().
With edt_ft5x06_ts_init_hw() now running before devm_request_threaded_irq(),
the input device and debugfs files are published to userspace before the
touchscreen IRQ is requested.
If devm_request_threaded_irq() fails, the input device is announced to
userspace only to be immediately torn down during devres release.
Additionally, because edt_ft5x06_ts_prepare_debugfs() exposes the debugfs
mode file early, writing 1 to it before or during IRQ setup triggers:
edt_ft5x06_debugfs_mode_set()
-> edt_ft5x06_factory_mode()
disable_irq(tsdata->irq);
if (!tsdata->raw_buffer) {
tsdata->raw_bufsize = tsdata->num_x * tsdata->num_y *
sizeof(u16);
tsdata->raw_buffer = kzalloc(tsdata->raw_bufsize, GFP_KERNEL);
...
}
Can this cause disable_irq() (or enable_irq() on error or when switching
back in edt_ft5x06_work_mode()) to be called before the IRQ is requested, or
cause irq_startup() inside devm_request_threaded_irq() to re-enable the
interrupt while tsdata->factory_mode is true?
Also, if devm_request_threaded_irq() fails after tsdata->raw_buffer is
allocated, edt_ft5x06_remove() -> edt_ft5x06_ts_teardown_debugfs() is not
run on probe failure. Does this leak tsdata->raw_buffer?
Should devm_request_threaded_irq() be called before edt_ft5x06_ts_init_hw()
(for example, with IRQF_NO_AUTOEN if needed until the hardware is ready), or
should input_register_device() and edt_ft5x06_ts_prepare_debugfs() happen
after the IRQ is requested?
oggler
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261017140827.290666-1-lukapanio@gmail.com?part=2
next prev parent reply other threads:[~2026-10-17 14:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 14:07 [PATCH 0/7] Input: edt-ft5x06 - add SPI transport and FocalTech FT8722 support Luka Panio
2026-10-17 14:07 ` [PATCH 1/7] Input: edt-ft5x06 - split the bus independent core from the I2C driver Luka Panio
2026-10-17 14:07 ` [PATCH 2/7] Input: edt-ft5x06 - move the controller bring-up into a helper Luka Panio
2026-10-17 14:16 ` sashiko-bot [this message]
2026-10-17 14:07 ` [PATCH 3/7] Input: edt-ft5x06 - add an optional controller boot hook Luka Panio
2026-10-17 14:07 ` [PATCH 4/7] Input: edt-ft5x06 - allow a chip specific touch data register Luka Panio
2026-10-17 14:07 ` [PATCH 5/7] dt-bindings: input: touchscreen: edt-ft5x06: Add FocalTech FT8722 Luka Panio
2026-10-17 14:07 ` [PATCH 6/7] Input: edt-ft5x06 - add SPI transport and FT8722 support Luka Panio
2026-10-17 14:29 ` sashiko-bot
2026-10-17 14:07 ` [PATCH 7/7] Input: edt-ft5x06 - support following a DRM panel Luka Panio
2026-10-17 14:30 ` 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=sashiko-outbox-175542@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-input@vger.kernel.org \
--cc=lukapanio@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.