* Re: [PATCH 01/10] Input: synaptics-rmi4 - fix F55 transmitter electrode count typo
From: sashiko-bot @ 2026-06-26 5:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260626051802.4033172-1-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] F55:Ctrl2 register array is read from an incorrect static offset, causing overlapping reads with the preceding F55:Ctrl1 register array.
--
commit b444f8759d3d03dbb87e0c3fd33dd8bdd2ff2bcf
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - fix F55 transmitter electrode count typo
This commit fixes a typo during F55 sensor detection where the transmitter
electrode count was incorrectly assigned the value of the receiver electrode
count. The incorrect value was then propagated to the driver data and
inflated the perceived TX count for F54, potentially leading to
out-of-bounds buffer accesses.
> diff --git a/drivers/input/rmi4/rmi_f55.c b/drivers/input/rmi4/rmi_f55.c
> index 488adaca4dd00..a0877d32a9141 100644
> --- a/drivers/input/rmi4/rmi_f55.c
> +++ b/drivers/input/rmi4/rmi_f55.c
> @@ -54,10 +54,10 @@ static int rmi_f55_detect(struct rmi_function *fn)
> f55->num_tx_electrodes = f55->qry[F55_NUM_TX_OFFSET];
>
> f55->cfg_num_rx_electrodes = f55->num_rx_electrodes;
> - f55->cfg_num_tx_electrodes = f55->num_rx_electrodes;
> + f55->cfg_num_tx_electrodes = f55->num_tx_electrodes;
>
> drv_data->num_rx_electrodes = f55->cfg_num_rx_electrodes;
> - drv_data->num_tx_electrodes = f55->cfg_num_rx_electrodes;
> + drv_data->num_tx_electrodes = f55->cfg_num_tx_electrodes;
>
> if (f55->qry[F55_PHYS_CHAR_OFFSET] & F55_CAP_SENSOR_ASSIGN) {
> int i, total;
[Severity: Medium]
This is a pre-existing issue, but I have a question about the offset used when
reading the F55:Ctrl2 register array.
Just below this hunk in rmi_f55_detect(), the code reads the transmitter
assignment array using a hardcoded +2 offset:
drivers/input/rmi4/rmi_f55.c:rmi_f55_detect() {
...
error = rmi_read_block(fn->rmi_dev,
fn->fd.control_base_addr + 1,
buf, f55->num_rx_electrodes);
...
error = rmi_read_block(fn->rmi_dev,
fn->fd.control_base_addr + 2,
buf, f55->num_tx_electrodes);
...
}
Will using a hardcoded +2 offset for Ctrl2 cause it to overlap with the Ctrl1
array if num_rx_electrodes > 1, or skip a byte if num_rx_electrodes == 0?
Should the offset dynamically account for the size of Ctrl1, such as using
control_base_addr + 1 + f55->num_rx_electrodes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 03/10] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
From: sashiko-bot @ 2026-06-26 5:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-3-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Devm-managed V4L2 video_device leads to Use-After-Free on deferred file close.
- [Medium] Missing vb2_queue_release() leaks videobuf2 resources during device unbind.
--
commit 7c7a1b6617a82d10a8cfe2c055e62e4a1c8fe287
Author: Bryam Vargas <hexlabsecurity@proton.me>
Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
This commit prevents a buffer overflow in rmi_f54_work() by rejecting reports
that are larger than the allocated size of f54->report_data. It records the
allocation size during probe and ensures the report_size does not exceed it.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 8eac320c43e35..75839a54656b9 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -104,6 +104,7 @@ struct f54_data {
>
> enum rmi_f54_report_type report_type;
> u8 *report_data;
> + size_t max_report_size;
> int report_size;
>
> bool is_busy;
[Severity: High]
This isn't a bug introduced by this patch, but looking at struct f54_data
which embeds struct video_device vdev, can its devm-managed lifecycle lead
to a use-after-free on a deferred file close?
If a user holds the video node open while the device is unbound,
rmi_f54_remove() calls video_unregister_device(&f54->vdev).
Devres will then free struct f54_data immediately upon return.
When the user later closes the file descriptor, will the V4L2 core access
the freed video_device to decrement its kref and invoke the release callback?
[Severity: Medium]
This is a pre-existing issue, but does rmi_f54_remove() leak videobuf2
resources during device unbind?
The teardown path unregisters the video device with
video_unregister_device(&f54->vdev).
If userspace requests buffers (e.g., via VIDIOC_REQBUFS) and the device is
subsequently unbound without the application cleanly releasing the buffers,
will the driver leak the videobuf2 kernel resources and allocated buffers
since it fails to call vb2_queue_release()?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 07/10] Input: synaptics-rmi4 - check V4L2 buffer size in F54 queue
From: sashiko-bot @ 2026-06-26 5:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-7-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The driver embeds V4L2 structures (`video_device`, `vb2_queue`, `mutex`) within `struct f54_data` allocated using `devm_kzalloc()`, leading to a use-after-free when the device is unbound while file descriptors remain open.
--
commit 5a88e74ace3829801abe168bf6f2a7e65b6ad4b8
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - check V4L2 buffer size in F54 queue
Add a safety check in rmi_f54_buffer_queue() to ensure that the requested
report size (f54->report_size) does not exceed the actual allocated size of
the V4L2 buffer (vb2_plane_size()). This provides a defense-in-depth
measure against any potential size mismatches between the V4L2 queue and
the driver's internal state.
[Severity: Critical]
This is a pre-existing issue, but does the driver have a use-after-free
in the V4L2 device unbind path?
In drivers/input/rmi4/rmi_f54.c:rmi_f54_probe(), f54_data is allocated
using devm:
f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);
And in rmi_f54_remove():
video_unregister_device(&f54->vdev);
When the device is unbound while a user holds the V4L2 file descriptor
open, devres will immediately free f54_data after rmi_f54_remove()
returns. However, the V4L2 core retains a reference to the embedded
video_device for the open file descriptor.
Additionally, vb2_queue_release() is never called, leaving active V4L2
waitqueues pointing to the freed memory.
Can subsequent operations on the open file descriptor dereference the
freed f54->vdev, f54->lock, or f54->queue?
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index c86bc81845bb1..93526feea5636 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH 02/10] Input: synaptics-rmi4 - zero report size on F54 work error
From: sashiko-bot @ 2026-06-26 5:32 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-2-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] V4L2 structures are embedded in a `devm` allocated struct, leading to a Use-After-Free if a file descriptor is kept open after device unbind.
--
commit 509674cded5ede5f74a6a2812b17819c5b929655
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - zero report size on F54 work error
This commit fixes a heap buffer overflow in the F54 diagnostic code. It
modifies the error path in rmi_f54_work() to ensure the report_size field is
always set to 0 on failure, preventing stale larger payload sizes from being
copied into shrunken v4l2 buffers.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 61909e1a39e24..8eac320c43e35 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
[ ... ]
> @@ -588,16 +588,16 @@ static void rmi_f54_work(struct work_struct *work)
> if (error) {
> dev_err(&fn->dev, "%s: read [%d bytes] returned %d\n",
> __func__, size, error);
> - goto abort;
> + goto out;
> }
> }
>
> -abort:
> - f54->report_size = error ? 0 : report_size;
> -error:
> +out:
> if (error)
> report_size = 0;
>
> + f54->report_size = report_size;
> +
[Severity: High]
This is a pre-existing issue, but since we are modifying the v4l2-related f54
struct, is it safe to embed the video_device in a devm allocated struct?
Looking at rmi_f54_probe() and rmi_f54_remove():
drivers/input/rmi4/rmi_f54.c:rmi_f54_probe() {
...
f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);
...
f54->vdev = rmi_f54_video_device;
...
ret = video_register_device(&f54->vdev, VFL_TYPE_TOUCH, -1);
...
}
drivers/input/rmi4/rmi_f54.c:rmi_f54_remove() {
...
video_unregister_device(&f54->vdev);
...
}
When rmi_f54_remove() completes, the driver core frees the devm allocated
memory for f54. If a user keeps /dev/videoX open during unbind, the
video_device refcount remains above zero, but its memory has been freed.
Would subsequent system calls (like ioctl) from the open fd attempt to
dereference vdev->fops from the freed f54 memory, resulting in a
use-after-free?
> if (report_size == 0 && !error) {
> queue_delayed_work(f54->workqueue, &f54->work,
> msecs_to_jiffies(1));
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 10/10] Input: synaptics-rmi4 - use __le16 for FIFO offset in F54
From: sashiko-bot @ 2026-06-26 5:33 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-10-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The struct f54_data is devm-allocated but embeds a struct video_device and sets its release callback to video_device_release_empty. This causes a Use-After-Free (UAF) upon driver unbind if userspace keeps the V4L2 file descriptor open.
--
commit e9522f5af1c14ea69a1ea7da84dfd2f3170f97d8
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - use __le16 for FIFO offset in F54
Instead of manually splitting the 16-bit offset into a 2-byte array,
use __le16 and cpu_to_le16() to serialize the FIFO offset in
rmi_f54_work(). This is cleaner and more portable.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 5d045ece3c2f2..3eeb189be18b3 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
[ ... ]
> @@ -597,12 +597,11 @@ static void rmi_f54_work(struct work_struct *work)
>
> for (size_t i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
> size_t size = min_t(size_t, F54_REPORT_DATA_SIZE, report_size - i);
> + __le16 fifo = cpu_to_le16(i);
>
> - fifo[0] = i & 0xff;
> - fifo[1] = i >> 8;
> error = rmi_write_block(fn->rmi_dev,
> fn->fd.data_base_addr + F54_FIFO_OFFSET,
> - fifo, sizeof(fifo));
> + &fifo, sizeof(fifo));
[Severity: High]
This is a pre-existing issue, but I noticed a potential use-after-free
lifecycle bug related to how struct f54_data is managed.
The struct f54_data is devm-allocated in rmi_f54_probe():
f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);
However, it embeds a struct video_device and sets its release callback to
video_device_release_empty. If userspace keeps the V4L2 file descriptor open
during driver unbind, devres will immediately free f54_data when
rmi_f54_remove() completes:
static void rmi_f54_remove(struct rmi_function *fn)
{
struct f54_data *f54 = dev_get_drvdata(&fn->dev);
video_unregister_device(&f54->vdev);
v4l2_device_unregister(&f54->v4l2);
cancel_delayed_work_sync(&f54->work);
destroy_workqueue(f54->workqueue);
}
Since rmi_f54_remove() doesn't wait for the video device to be fully
released (or synchronize with in-flight V4L2 ioctls holding f54->lock),
an active ioctl could sleep and wake up after the struct is freed.
For example, if VIDIOC_QBUF blocks in rmi_f54_buffer_queue():
if (!wait_for_completion_timeout(&f54->cmd_done,
msecs_to_jiffies(1000))) {
Could this wake up after the driver is unbound and access the freed
f54->data_mutex or f54->sequence?
Does this violate the V4L2 lifecycle contract, which requires that memory
backing a video_device must not be freed until the core invokes the .release
callback?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=10
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: Dmitry Torokhov @ 2026-06-26 5:37 UTC (permalink / raw)
To: david
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Krzysztof Kozlowski
In-Reply-To: <20260523-synaptics-rmi4-dt-v2-1-0645122babdc@ixit.cz>
On Sat, May 23, 2026 at 11:45:34AM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Mostly irrelevant for authentic Synaptics touchscreens, but very important
> for applying workarounds to cheap TS knockoffs.
>
> These knockoffs work well with the downstream driver, and since the user
> has no way to distinguish them, later in this patch set, we introduce
> workarounds to ensure they function as well as possible.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Dmitry Torokhov @ 2026-06-26 5:38 UTC (permalink / raw)
To: David Heidelberg
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Konrad Dybcio,
Rob Herring, Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <32affded-bae2-46c4-a702-2054fbfe46a8@ixit.cz>
On Thu, Jun 25, 2026 at 08:39:15PM +0200, David Heidelberg wrote:
> On 25/06/2026 18:57, Dmitry Torokhov wrote:
> > Hi Krzysztof,
> >
> > On Thu, Jun 25, 2026 at 10:23:54AM +0200, Krzysztof Kozlowski wrote:
> > > On 25/06/2026 06:53, Dmitry Torokhov wrote:
> > > > On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
> > > > > On 24/06/2026 06:28, Dmitry Torokhov wrote:
> > > > > > Hi David,
> > > > > >
> > > > > > On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
> > > > > > > On 28/05/2026 00:13, David Heidelberg wrote:
> > > > > > > > On 27/05/2026 23:56, Dmitry Torokhov wrote:
> > > > > > > > > Hi David,
> > > > > > > > >
> > > > > > > > > On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
> > > > > > > > > > From: David Heidelberg <david@ixit.cz>
> > > > > > > > > >
> > > > > > > > > > We know the driver is reporting s3706b, introduce the compatible so we
> > > > > > > > > > can more easily introduce quirks for weird touchscreen replacements in
> > > > > > > > > > followup series.
> > > > > > > > > >
> > > > > > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > > > > > > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > > > > > > > > ---
> > > > > > > > > > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > index 6b7378cf4d493..148164d456a5a 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
> > > > > > > > > > };
> > > > > > > > > > };
> > > > > > > > > > &i2c12 {
> > > > > > > > > > status = "okay";
> > > > > > > > > > clock-frequency = <400000>;
> > > > > > > > > > synaptics-rmi4-i2c@20 {
> > > > > > > > > > - compatible = "syna,rmi4-i2c";
> > > > > > > > > > + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
> > > > > > > > >
> > > > > > > > > So I believe we established that this device (s3706b) does not in fact
> > > > > > > > > implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
> > > > > > > > > fallback? Shouldn't it be just "syna,rmi4-s3706b"?
> > > > > > > >
> > > > > > > > The vendor supplies s3706b which does implement the RMI4 properly.
> > > > > > > >
> > > > > > > > The 3rd party replacement impersonating original parts may not implement
> > > > > > > > it properly, but I don't address this issue in this initial submission.
> > > > > > > >
> > > > > > > > With this compatible we know which original part is used by the vendor
> > > > > > > > and installed in the phones, so later we can deduct specific sequences
> > > > > > > > for the replacement aftermarket parts to keep phone touchscreen working
> > > > > > > > same as they do on Android without affecting other devices.
> > > > > > >
> > > > > > > Hello Dmitry.
> > > > > > >
> > > > > > > May I ask what is currently preventing this series from moving forward?
> > > > > > >
> > > > > > > The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
> > > > > > > and am now on the 9th iteration (this patchset). At this point, the series
> > > > > > > has been under discussion for well over a year, with relatively little
> > > > > > > feedback and increasingly long gaps between review rounds.
> > > > > > >
> > > > > > > The current approach is based on the guidance I have received so far,
> > > > > > > including suggestions from the device-tree maintainers. When concerns were
> > > > > > > raised, I tried to address them and rework the series accordingly.
> > > > > > >
> > > > > > > What I am struggling with is understanding what specific issue still needs
> > > > > > > to be resolved before these patches can be accepted. If there are remaining
> > > > > > > requirements, objections to the approach, or technical concerns that I have
> > > > > > > not addressed, I would appreciate having them stated explicitly so I can
> > > > > > > work on them.
> > > > > > >
> > > > > > > I also split out the straightforward, self-contained changes in the hope
> > > > > > > that at least those could progress independently while I continued working
> > > > > > > on any follow-up requirements. However, even those patches do not appear to
> > > > > > > be moving forward.
> > > > > > >
> > > > > > > Could you please clarify what outcome you would like to see from this
> > > > > > > series, and what concrete changes would be required to get it accepted?
> > > > > >
> > > > > > I am still confused about how you want to differentiate between the full
> > > > > > RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
> > > > > > mentioned, implements RMI4 protocol properly, so we do not need to
> > > > > > actually have it documented neither in binding nor in DTS.
> > > > >
> > > > > --- part 1 ---
> > > > >
> > > > > This series addresses identification within device-tree. It's normal
> > > > > recommended practice.
> > > > >
> > > > > If we know, the device ships specific, but **compliant** variant, we just
> > > > > put it as compatible = "more-specific", "less-specific"; in this case
> > > > > "syna,rmi4-s3706b", "syna,rmi4-i2c"
> > > > >
> > > > > This approach is used everywhere. This has nothing to do with after-market parts.
> > > >
> > > > We do this in many cases, sometimes when a part has different timings or
> > > > maybe additional functionality compared to the base model.
> > >
> > > Generic expectation is to have always dedicated front compatible for
> > > every device. rmi4-i2c is not really specific enough, more like a
> > > family, thus a specific device compatible is essential by the DT rules.
> >
> > Essential in what way? What will break if such compatible is not there?
> > We have lived without it for many years and will continue live happily
> > without it for years to come.
>
> Hi Dmitry, Krzystof,
>
> Device tree should describe the hardware, rmi4-i2c isn't the exact model of
> hardware used, the real hardware is Synaptics S3706B. Device-tree should,
> where possible, describe the actual hardware used.
>
> >
> > We keep having this conversation each time there is self-describing
> > protocol that does not require knowledge of a specific part number:
> > i2c-hid, rmi4, spi-hid coming over soon.
>
> While the protocol doesn't require this knowledge, where is the issue
> provide the model, at least in the places where we know it?
>
> Does it making things worse to describe hardware in more detail?
OK, I applied the binding change, the dts change should go through some
other tree.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 06/10] Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue
From: sashiko-bot @ 2026-06-26 7:30 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-6-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The V4L2 video_device, vb2_queue, and mutex lock are embedded inside struct f54_data, which is allocated using devm_kzalloc(). When the device is unbound, devres frees f54_data immediately after rmi_f54_remove() returns. If a userspace process holds the /dev/videoX file descriptor open, subsequent V4L2 ioctl calls or close() operations will trigger a Use-After-Free.
- [Medium] The V4L2 buf_queue callback executes synchronous, blocking hardware polling via wait_for_completion_timeout(), turning an asynchronous queueing mechanism into a fully blocking operation that starves other ioctls.
--
commit ed5dda6c6cb42efd8468fff80b16a819c0e59afb
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue
Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but
ignored whether it succeeded. This patch adds a report_error field to struct
f54_data to store the worker's exit status and marks the buffer with
VB2_BUF_STATE_ERROR if the worker failed.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index e86dfc9ce7d9a..c86bc81845bb1 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -106,6 +106,7 @@ struct f54_data {
> u8 *report_data;
> size_t max_report_size;
> int report_size;
> + int report_error;
[Severity: High]
This is a pre-existing issue, but does using devres to allocate struct
f54_data create a use-after-free risk during device removal?
Since the V4L2 video_device, vb2_queue, and mutex lock are embedded inside
this structure, and it is allocated via devm_kzalloc() in rmi_f54_probe():
rmi_f54_probe() {
...
f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);
...
}
The memory will be freed immediately when the device is unbound. If a
userspace process still holds the /dev/videoX file descriptor open,
subsequent V4L2 ioctl calls or close() operations could access the freed
video_device or queue.
[ ... ]
> @@ -340,6 +341,12 @@ static void rmi_f54_buffer_queue(struct vb2_buffer *vb)
> mutex_lock(&f54->data_mutex);
> }
>
> + if (f54->report_error) {
> + dev_err(&f54->fn->dev, "Error acquiring report: %d\n", f54->report_error);
> + state = VB2_BUF_STATE_ERROR;
> + goto data_done;
> + }
> +
[Severity: Medium]
This isn't a bug introduced by this patch, but does waiting for the hardware
completion inside rmi_f54_buffer_queue() starve other concurrent V4L2
operations?
Just before this error check, rmi_f54_buffer_queue() executes:
rmi_f54_buffer_queue() {
...
while (f54->is_busy) {
mutex_unlock(&f54->data_mutex);
if (!wait_for_completion_timeout(&f54->cmd_done, ...)) {
...
}
This executes synchronously while holding the V4L2 queue lock. Blocking here
via wait_for_completion_timeout() for up to 1000ms could prevent other users
from executing concurrent ioctls like DQBUF or STREAMOFF.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Krzysztof Kozlowski @ 2026-06-26 7:42 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: David Heidelberg, Krzysztof Kozlowski, Konrad Dybcio, Rob Herring,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <aj1OhZQjO5nNYlAo@google.com>
On 25/06/2026 18:57, Dmitry Torokhov wrote:
> Hi Krzysztof,
>
> On Thu, Jun 25, 2026 at 10:23:54AM +0200, Krzysztof Kozlowski wrote:
>> On 25/06/2026 06:53, Dmitry Torokhov wrote:
>>> On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
>>>> On 24/06/2026 06:28, Dmitry Torokhov wrote:
>>>>> Hi David,
>>>>>
>>>>> On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
>>>>>> On 28/05/2026 00:13, David Heidelberg wrote:
>>>>>>> On 27/05/2026 23:56, Dmitry Torokhov wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>
>>>>>>>>> We know the driver is reporting s3706b, introduce the compatible so we
>>>>>>>>> can more easily introduce quirks for weird touchscreen replacements in
>>>>>>>>> followup series.
>>>>>>>>>
>>>>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>>>>>>> ---
>>>>>>>>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
>>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> index 6b7378cf4d493..148164d456a5a 100644
>>>>>>>>> --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>>>>>>>> @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>>> &i2c12 {
>>>>>>>>> status = "okay";
>>>>>>>>> clock-frequency = <400000>;
>>>>>>>>> synaptics-rmi4-i2c@20 {
>>>>>>>>> - compatible = "syna,rmi4-i2c";
>>>>>>>>> + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
>>>>>>>>
>>>>>>>> So I believe we established that this device (s3706b) does not in fact
>>>>>>>> implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
>>>>>>>> fallback? Shouldn't it be just "syna,rmi4-s3706b"?
>>>>>>>
>>>>>>> The vendor supplies s3706b which does implement the RMI4 properly.
>>>>>>>
>>>>>>> The 3rd party replacement impersonating original parts may not implement
>>>>>>> it properly, but I don't address this issue in this initial submission.
>>>>>>>
>>>>>>> With this compatible we know which original part is used by the vendor
>>>>>>> and installed in the phones, so later we can deduct specific sequences
>>>>>>> for the replacement aftermarket parts to keep phone touchscreen working
>>>>>>> same as they do on Android without affecting other devices.
>>>>>>
>>>>>> Hello Dmitry.
>>>>>>
>>>>>> May I ask what is currently preventing this series from moving forward?
>>>>>>
>>>>>> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
>>>>>> and am now on the 9th iteration (this patchset). At this point, the series
>>>>>> has been under discussion for well over a year, with relatively little
>>>>>> feedback and increasingly long gaps between review rounds.
>>>>>>
>>>>>> The current approach is based on the guidance I have received so far,
>>>>>> including suggestions from the device-tree maintainers. When concerns were
>>>>>> raised, I tried to address them and rework the series accordingly.
>>>>>>
>>>>>> What I am struggling with is understanding what specific issue still needs
>>>>>> to be resolved before these patches can be accepted. If there are remaining
>>>>>> requirements, objections to the approach, or technical concerns that I have
>>>>>> not addressed, I would appreciate having them stated explicitly so I can
>>>>>> work on them.
>>>>>>
>>>>>> I also split out the straightforward, self-contained changes in the hope
>>>>>> that at least those could progress independently while I continued working
>>>>>> on any follow-up requirements. However, even those patches do not appear to
>>>>>> be moving forward.
>>>>>>
>>>>>> Could you please clarify what outcome you would like to see from this
>>>>>> series, and what concrete changes would be required to get it accepted?
>>>>>
>>>>> I am still confused about how you want to differentiate between the full
>>>>> RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
>>>>> mentioned, implements RMI4 protocol properly, so we do not need to
>>>>> actually have it documented neither in binding nor in DTS.
>>>>
>>>> --- part 1 ---
>>>>
>>>> This series addresses identification within device-tree. It's normal
>>>> recommended practice.
>>>>
>>>> If we know, the device ships specific, but **compliant** variant, we just
>>>> put it as compatible = "more-specific", "less-specific"; in this case
>>>> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>>>>
>>>> This approach is used everywhere. This has nothing to do with after-market parts.
>>>
>>> We do this in many cases, sometimes when a part has different timings or
>>> maybe additional functionality compared to the base model.
>>
>> Generic expectation is to have always dedicated front compatible for
>> every device. rmi4-i2c is not really specific enough, more like a
>> family, thus a specific device compatible is essential by the DT rules.
>
> Essential in what way? What will break if such compatible is not there?
Essential by the rules we defined for DT and documented in writing-bindings.
> We have lived without it for many years and will continue live happily
> without it for years to come.
Does not matter if compatible is used or not. The rules are dictating that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-06-26 7:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <aj28fvj34b4_VI3k@google.com>
пт, 26 черв. 2026 р. о 02:45 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
>
> Hi Svyatoslav,
>
> On Wed, Jun 17, 2026 at 10:05:27AM +0300, Svyatoslav Ryhel wrote:
> > From: Linus Walleij <linusw@kernel.org>
> >
> > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > motors for haptic feedback in mobile phones. Used in many mobile devices
> > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Tested-by: Linus Walleij <linusw@kernel.org> # GT-I9070 Janice
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>
>
> Sashiko convinced me that using mutex_trylock() in the playback work
> handler will result in dropping requests and that we are safe not taking
> the lock there at all. Can you please try the following modification?
>
> diff --git a/drivers/input/misc/isa1200.c b/drivers/input/misc/isa1200.c
> index c61adc4b605c..fb7f68fa0a2b 100644
> --- a/drivers/input/misc/isa1200.c
> +++ b/drivers/input/misc/isa1200.c
> @@ -253,15 +253,12 @@ static void isa1200_stop(struct isa1200 *isa)
> static void isa1200_play_work(struct work_struct *work)
> {
> struct isa1200 *isa = container_of(work, struct isa1200, play_work);
> - struct input_dev *input = isa->input;
> -
> - scoped_guard(mutex_try, &input->mutex) {
> - if (!isa->suspended) {
> - if (isa->level)
> - isa1200_start(isa);
> - else
> - isa1200_stop(isa);
> - }
> +
> + if (!READ_ONCE(isa->suspended)) {
> + if (isa->level)
> + isa1200_start(isa);
> + else
> + isa1200_stop(isa);
> }
> }
>
>
> If this works no need to resend, I'll fold on my side.
>
It does work fine. Thank you.
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH] Input: synaptics - enable InterTouch on Dell Inspiron 3521
From: Shashwat Agrawal @ 2026-06-26 13:00 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Shashwat Agrawal
The Synaptics touchpad on Dell Inspiron 3521 (PNP ID DLL0597) advertises
InterTouch / SMBus support, but is not on the SMBus passlist, so the
driver falls back to PS/2 and logs a hint to try
psmouse.synaptics_intertouch=1.
Add DLL0597 to smbus_pnp_ids so InterTouch is enabled automatically on
this model (and other Dells that reuse the same PNP ID).
Hardware: Dell Inc. Inspiron 3521 (board 06RYX8, BIOS A07),
Synaptics fw 8.1 / board id 2382, firmware_id "PNP: DLL0597 PNP0f13".
Signed-off-by: Shashwat Agrawal <shashwatagrawal473@gmail.com>
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c70502e24031..2170bbe4c589 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -164,6 +164,7 @@ static const char * const topbuttonpad_pnp_ids[] = {
#ifdef CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS
static const char * const smbus_pnp_ids[] = {
/* all of the topbuttonpad_pnp_ids are valid, we just add some extras */
+ "DLL0597", /* Dell Inspiron 3521 */
"DLL060d", /* Dell Precision M3800 */
"LEN0048", /* X1 Carbon 3 */
"LEN0046", /* X250 */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-06-26 14:11 UTC (permalink / raw)
To: Dmitry Torokhov, Bjorn Andersson
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Konrad Dybcio,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Rob Herring
In-Reply-To: <aj4QUY5p7gqLplVT@google.com>
[...]
>
> OK, I applied the binding change, the dts change should go through some
> other tree.
>
> Thanks.
>
Thank you, I think Bjorn will be picking the dts change :)
David
^ permalink raw reply
* detection and reporting of replacement and aftermarket parts
From: David Heidelberg @ 2026-06-26 15:01 UTC (permalink / raw)
To: linux-input, netdev, Dmitry Torokhov, LKML; +Cc: Petr Hodina
Hello.
As we port Linux phones to the mainline kernel, we often encounter devices with
replaced screens (and touchscreens).
Many these devices are replaced with original parts, but mostly in Asia markets,
very often replacement parts are not original, but knockoffs.
I would see value in providing information via tools and/or GUI [1] to the
users, that parts of their phone has been replaced.
There is multiple reasons, including user awareness when buying the device, or
developer debugging user problem being aware that device been serviced.
Right now, I'm not aware any vendor (outside of Apple, which is unsupported by
Linux) shipping list of serial number of the components in the phone inside some
memory region or EEPROM.
When we **can** do with information currently available, is to detect:
1. different chip used, than what manufacturer declared (e.g. matching the
model device-tree compatible property), thus implying replacement part
2. the chip not being fully compliant with the vendor specification, thus
implying non-original part
This doesn't cover all cases, but could already give user and developer valuable
information why:
1. component isn't fully supported (let say driver doesn't have support for this
variant)
2. component misbehave, if non-original part doesn't follow specification properly
I think the display/touchscreen part is most often affected, so thus why I would
like to start discussion here, but I think this issue apply to many other
components (I recall some FTDI discussions long time ago)
In the end, would be nice to have devlink-info-like [2] reporting in the input
subsystem extended by not only reporting on-device / in-memory firmware, but
also the driver reporting non-complaint non-original replacements (Cc: netdev).
I'm very interested in feedback or/and ideas how this situations can be handled.
Thank you
David
[1] https://support.apple.com/en-us/102658
[2] https://docs.kernel.org/networking/devlink/devlink-info.html
^ permalink raw reply
* Re: [PATCH] Input: synaptics - enable InterTouch on Dell Inspiron 3521
From: Dmitry Torokhov @ 2026-06-26 18:04 UTC (permalink / raw)
To: Shashwat Agrawal; +Cc: linux-input, linux-kernel
In-Reply-To: <20260626130051.2574-1-shashwatagrawal473@gmail.com>
On Fri, Jun 26, 2026 at 06:30:51PM +0530, Shashwat Agrawal wrote:
> The Synaptics touchpad on Dell Inspiron 3521 (PNP ID DLL0597) advertises
> InterTouch / SMBus support, but is not on the SMBus passlist, so the
> driver falls back to PS/2 and logs a hint to try
> psmouse.synaptics_intertouch=1.
>
> Add DLL0597 to smbus_pnp_ids so InterTouch is enabled automatically on
> this model (and other Dells that reuse the same PNP ID).
>
> Hardware: Dell Inc. Inspiron 3521 (board 06RYX8, BIOS A07),
> Synaptics fw 8.1 / board id 2382, firmware_id "PNP: DLL0597 PNP0f13".
>
> Signed-off-by: Shashwat Agrawal <shashwatagrawal473@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS d577e46785d45484b2ab7e7309c49b18764bf56c
From: kernel test robot @ 2026-06-26 18:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: d577e46785d45484b2ab7e7309c49b18764bf56c Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count
elapsed time: 771m
configs tested: 299
configs skipped: 14
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260626 gcc-11.5.0
arc randconfig-001-20260626 gcc-13.4.0
arc randconfig-002-20260626 gcc-13.4.0
arc randconfig-002-20260626 gcc-9.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm randconfig-001-20260626 gcc-13.4.0
arm randconfig-002-20260626 clang-23
arm randconfig-002-20260626 gcc-13.4.0
arm randconfig-003-20260626 gcc-13.4.0
arm randconfig-004-20260626 clang-21
arm randconfig-004-20260626 gcc-13.4.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260626 clang-23
arm64 randconfig-001-20260626 gcc-8.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260626 clang-23
arm64 randconfig-002-20260626 gcc-8.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260626 clang-23
arm64 randconfig-003-20260626 gcc-8.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260626 clang-23
arm64 randconfig-004-20260626 gcc-8.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260626 clang-23
csky randconfig-001-20260626 gcc-8.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260626 clang-23
csky randconfig-002-20260626 gcc-8.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260626 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260626 gcc-11.5.0
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260626 gcc-14
i386 buildonly-randconfig-002-20260626 gcc-14
i386 buildonly-randconfig-003-20260626 gcc-14
i386 buildonly-randconfig-004-20260626 gcc-14
i386 buildonly-randconfig-005-20260626 gcc-14
i386 buildonly-randconfig-006-20260626 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001 gcc-14
i386 randconfig-001-20260626 clang-22
i386 randconfig-001-20260626 gcc-14
i386 randconfig-002 gcc-14
i386 randconfig-002-20260626 gcc-14
i386 randconfig-003 gcc-14
i386 randconfig-003-20260626 clang-22
i386 randconfig-003-20260626 gcc-14
i386 randconfig-004 gcc-14
i386 randconfig-004-20260626 clang-22
i386 randconfig-004-20260626 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260626 gcc-14
i386 randconfig-006 gcc-14
i386 randconfig-006-20260626 gcc-14
i386 randconfig-007 gcc-14
i386 randconfig-007-20260626 gcc-14
i386 randconfig-011-20260626 gcc-14
i386 randconfig-012-20260626 gcc-14
i386 randconfig-013-20260626 gcc-14
i386 randconfig-014-20260626 gcc-14
i386 randconfig-015-20260626 gcc-14
i386 randconfig-016-20260626 gcc-14
i386 randconfig-017-20260626 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260626 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260626 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig clang-23
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
microblaze defconfig gcc-16.1.0
microblaze mmu_defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips loongson2k_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260626 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260626 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260626 gcc-12.5.0
parisc randconfig-002-20260626 gcc-8.5.0
parisc64 defconfig clang-23
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
powerpc ep88xc_defconfig gcc-16.1.0
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260626 clang-23
powerpc randconfig-001-20260626 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260626 gcc-11.5.0
powerpc randconfig-002-20260626 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260626 clang-23
powerpc64 randconfig-001-20260626 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260626 gcc-13.4.0
powerpc64 randconfig-002-20260626 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 clang-23
riscv randconfig-001-20260626 clang-23
riscv randconfig-001-20260626 gcc-11.5.0
riscv randconfig-002 clang-23
riscv randconfig-002-20260626 clang-23
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 defconfig gcc-16.1.0
s390 randconfig-001 clang-23
s390 randconfig-001-20260626 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260626 clang-23
s390 randconfig-002-20260626 gcc-8.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh defconfig gcc-16.1.0
sh randconfig-001 clang-23
sh randconfig-001-20260626 clang-23
sh randconfig-001-20260626 gcc-9.5.0
sh randconfig-002 clang-23
sh randconfig-002-20260626 clang-23
sh randconfig-002-20260626 gcc-16.1.0
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-16.1.0
sparc randconfig-001-20260626 gcc-12.5.0
sparc randconfig-002 gcc-11.5.0
sparc randconfig-002-20260626 gcc-12.5.0
sparc randconfig-002-20260626 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-12.5.0
sparc64 randconfig-001-20260626 clang-20
sparc64 randconfig-001-20260626 gcc-12.5.0
sparc64 randconfig-002 clang-20
sparc64 randconfig-002-20260626 clang-20
sparc64 randconfig-002-20260626 gcc-12.5.0
um allmodconfig clang-23
um allnoconfig clang-16
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 clang-23
um randconfig-001-20260626 clang-18
um randconfig-001-20260626 gcc-12.5.0
um randconfig-002 clang-23
um randconfig-002-20260626 clang-23
um randconfig-002-20260626 gcc-12.5.0
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260626 clang-22
x86_64 buildonly-randconfig-001-20260626 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260626 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260626 clang-22
x86_64 buildonly-randconfig-003-20260626 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260626 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260626 clang-22
x86_64 buildonly-randconfig-005-20260626 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260626 clang-22
x86_64 buildonly-randconfig-006-20260626 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260626 clang-22
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260626 clang-22
x86_64 randconfig-002-20260626 gcc-14
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260626 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260626 clang-22
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260626 clang-22
x86_64 randconfig-005-20260626 gcc-13
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260626 clang-22
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260626 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260626 gcc-14
x86_64 randconfig-013 clang-22
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260626 clang-22
x86_64 randconfig-013-20260626 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260626 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260626 gcc-14
x86_64 randconfig-016 clang-22
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260626 gcc-14
x86_64 randconfig-071 gcc-14
x86_64 randconfig-071-20260626 gcc-14
x86_64 randconfig-072 gcc-14
x86_64 randconfig-072-20260626 clang-22
x86_64 randconfig-072-20260626 gcc-14
x86_64 randconfig-073 clang-22
x86_64 randconfig-073 gcc-14
x86_64 randconfig-073-20260626 gcc-14
x86_64 randconfig-074 gcc-14
x86_64 randconfig-074-20260626 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075 gcc-14
x86_64 randconfig-075-20260626 gcc-14
x86_64 randconfig-076 clang-22
x86_64 randconfig-076 gcc-14
x86_64 randconfig-076-20260626 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260626 gcc-12.5.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260626 gcc-10.5.0
xtensa randconfig-002-20260626 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS f373f18a3c43afaad15b2a91880dd65347ed760f
From: kernel test robot @ 2026-06-26 18:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: f373f18a3c43afaad15b2a91880dd65347ed760f dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
elapsed time: 733m
configs tested: 290
configs skipped: 12
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-8.5.0
arc randconfig-001-20260626 gcc-11.5.0
arc randconfig-001-20260626 gcc-13.4.0
arc randconfig-002 gcc-8.5.0
arc randconfig-002-20260626 gcc-13.4.0
arc randconfig-002-20260626 gcc-9.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001 gcc-16.1.0
arm randconfig-001-20260626 gcc-13.4.0
arm randconfig-002 gcc-15.2.0
arm randconfig-002-20260626 clang-23
arm randconfig-002-20260626 gcc-13.4.0
arm randconfig-003 clang-23
arm randconfig-003-20260626 gcc-13.4.0
arm randconfig-004 gcc-13.4.0
arm randconfig-004-20260626 clang-21
arm randconfig-004-20260626 gcc-13.4.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260626 clang-23
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260626 clang-23
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260626 clang-23
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260626 clang-23
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260626 clang-23
csky randconfig-002 clang-23
csky randconfig-002-20260626 clang-23
hexagon allmodconfig clang-23
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig clang-23
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260626 clang-23
hexagon randconfig-001-20260626 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260626 clang-23
hexagon randconfig-002-20260626 gcc-11.5.0
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260626 gcc-14
i386 buildonly-randconfig-002-20260626 gcc-14
i386 buildonly-randconfig-003-20260626 gcc-14
i386 buildonly-randconfig-004-20260626 gcc-12
i386 buildonly-randconfig-004-20260626 gcc-14
i386 buildonly-randconfig-005-20260626 gcc-14
i386 buildonly-randconfig-006-20260626 gcc-14
i386 defconfig clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001 clang-22
i386 randconfig-001-20260626 clang-22
i386 randconfig-001-20260626 gcc-14
i386 randconfig-002 gcc-14
i386 randconfig-002-20260626 gcc-14
i386 randconfig-003 gcc-14
i386 randconfig-003-20260626 clang-22
i386 randconfig-003-20260626 gcc-14
i386 randconfig-004 clang-22
i386 randconfig-004-20260626 clang-22
i386 randconfig-004-20260626 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260626 gcc-14
i386 randconfig-006 gcc-14
i386 randconfig-006-20260626 gcc-14
i386 randconfig-007 gcc-14
i386 randconfig-007-20260626 gcc-14
i386 randconfig-011-20260626 gcc-14
i386 randconfig-012-20260626 clang-22
i386 randconfig-012-20260626 gcc-14
i386 randconfig-013-20260626 clang-22
i386 randconfig-013-20260626 gcc-14
i386 randconfig-014-20260626 gcc-14
i386 randconfig-015-20260626 gcc-14
i386 randconfig-016-20260626 clang-22
i386 randconfig-016-20260626 gcc-14
i386 randconfig-017-20260626 clang-22
i386 randconfig-017-20260626 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260626 gcc-11.5.0
loongarch randconfig-001-20260626 gcc-16.1.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260626 clang-18
loongarch randconfig-002-20260626 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig gcc-16.1.0
microblaze mmu_defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips cu1830-neo_defconfig gcc-16.1.0
mips rbtx49xx_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260626 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-11.5.0
nios2 randconfig-002-20260626 gcc-8.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260626 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260626 gcc-12.5.0
parisc randconfig-002-20260626 gcc-8.5.0
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260626 clang-23
powerpc randconfig-001-20260626 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260626 gcc-11.5.0
powerpc randconfig-002-20260626 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260626 clang-23
powerpc64 randconfig-001-20260626 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260626 gcc-13.4.0
powerpc64 randconfig-002-20260626 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv randconfig-001 clang-23
riscv randconfig-001-20260626 gcc-11.5.0
riscv randconfig-002 clang-23
riscv randconfig-002-20260626 clang-23
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 randconfig-001 clang-23
s390 randconfig-001-20260626 clang-23
s390 randconfig-002 clang-23
s390 randconfig-002-20260626 gcc-8.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh defconfig gcc-16.1.0
sh randconfig-001 clang-23
sh randconfig-001-20260626 gcc-9.5.0
sh randconfig-002 clang-23
sh randconfig-002-20260626 gcc-16.1.0
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-16.1.0
sparc randconfig-001-20260626 gcc-12.5.0
sparc randconfig-002 gcc-11.5.0
sparc randconfig-002-20260626 gcc-12.5.0
sparc randconfig-002-20260626 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-12.5.0
sparc64 randconfig-001-20260626 clang-20
sparc64 randconfig-001-20260626 gcc-12.5.0
sparc64 randconfig-002 clang-20
sparc64 randconfig-002-20260626 clang-20
sparc64 randconfig-002-20260626 gcc-12.5.0
um allmodconfig clang-23
um allnoconfig clang-16
um allyesconfig gcc-14
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 clang-23
um randconfig-001-20260626 clang-18
um randconfig-001-20260626 gcc-12.5.0
um randconfig-002 clang-23
um randconfig-002-20260626 clang-23
um randconfig-002-20260626 gcc-12.5.0
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-12
x86_64 buildonly-randconfig-001-20260626 clang-22
x86_64 buildonly-randconfig-001-20260626 gcc-14
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260626 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260626 clang-22
x86_64 buildonly-randconfig-003-20260626 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260626 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260626 clang-22
x86_64 buildonly-randconfig-005-20260626 gcc-14
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260626 clang-22
x86_64 buildonly-randconfig-006-20260626 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260626 clang-22
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260626 clang-22
x86_64 randconfig-002-20260626 gcc-14
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260626 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260626 clang-22
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260626 clang-22
x86_64 randconfig-005-20260626 gcc-13
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260626 clang-22
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260626 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260626 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260626 clang-22
x86_64 randconfig-013-20260626 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260626 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260626 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260626 gcc-14
x86_64 randconfig-071-20260626 gcc-14
x86_64 randconfig-072-20260626 clang-22
x86_64 randconfig-072-20260626 gcc-14
x86_64 randconfig-073-20260626 gcc-14
x86_64 randconfig-074-20260626 gcc-14
x86_64 randconfig-075-20260626 gcc-14
x86_64 randconfig-076-20260626 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260626 gcc-12.5.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260626 gcc-10.5.0
xtensa randconfig-002-20260626 gcc-12.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v6 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-06-26 20:20 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAPVz0n0Ja0eKrpirtMxK8bkTV0NY-UoKU0c09qLEF-xMWmOzKQ@mail.gmail.com>
On Fri, Jun 26, 2026 at 10:45:20AM +0300, Svyatoslav Ryhel wrote:
> пт, 26 черв. 2026 р. о 02:45 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Wed, Jun 17, 2026 at 10:05:27AM +0300, Svyatoslav Ryhel wrote:
> > > From: Linus Walleij <linusw@kernel.org>
> > >
> > > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > > motors for haptic feedback in mobile phones. Used in many mobile devices
> > > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> > >
> > > The exact datasheet for the ISA1200 is not available; all data was modeled
> > > based on available downstream kernel sources for various devices and
> > > fragments of information scattered across the internet.
> > >
> > > Tested-by: Linus Walleij <linusw@kernel.org> # GT-I9070 Janice
> > > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> >
> >
> > Sashiko convinced me that using mutex_trylock() in the playback work
> > handler will result in dropping requests and that we are safe not taking
> > the lock there at all. Can you please try the following modification?
> >
> > diff --git a/drivers/input/misc/isa1200.c b/drivers/input/misc/isa1200.c
> > index c61adc4b605c..fb7f68fa0a2b 100644
> > --- a/drivers/input/misc/isa1200.c
> > +++ b/drivers/input/misc/isa1200.c
> > @@ -253,15 +253,12 @@ static void isa1200_stop(struct isa1200 *isa)
> > static void isa1200_play_work(struct work_struct *work)
> > {
> > struct isa1200 *isa = container_of(work, struct isa1200, play_work);
> > - struct input_dev *input = isa->input;
> > -
> > - scoped_guard(mutex_try, &input->mutex) {
> > - if (!isa->suspended) {
> > - if (isa->level)
> > - isa1200_start(isa);
> > - else
> > - isa1200_stop(isa);
> > - }
> > +
> > + if (!READ_ONCE(isa->suspended)) {
> > + if (isa->level)
> > + isa1200_start(isa);
> > + else
> > + isa1200_stop(isa);
> > }
> > }
> >
> >
> > If this works no need to resend, I'll fold on my side.
> >
>
> It does work fine. Thank you.
Excelled, thank you. Applied both patches.
--
Dmitry
^ permalink raw reply
* [regression] synaptics-rmi4: Failed to read the Control Register Descriptor: EIO
From: David Heidelberg @ 2026-06-26 21:09 UTC (permalink / raw)
To: linux-input, Dmitry Torokhov; +Cc: Linux Next Mailing List
With next-20260626 without any additional patches, the synaptics fails on
OnePlus 6T with:
```
[ 16.620292] rmi4_i2c 12-0020: registering I2C-connected sensor
[ 16.857617] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics,
product: S3706B, fw id: 2852315
[ 16.867324] rmi4_f12 rmi4-00.fn12: Failed to read the Control Register
Descriptor: -5
[ 16.867338] rmi4_f12 rmi4-00.fn12: probe with driver rmi4_f12 failed with
error -5
```
I assume it's due to refactoring. My best guess it's signed/unsigned 32/64bit
type changes, but since I haven't figured it out within reasonable timeframe.
David
^ permalink raw reply
* Re: [regression] synaptics-rmi4: Failed to read the Control Register Descriptor: EIO
From: Dmitry Torokhov @ 2026-06-26 21:18 UTC (permalink / raw)
To: David Heidelberg; +Cc: linux-input, Linux Next Mailing List
In-Reply-To: <de6d34b7-619c-46bd-a6e3-a3917b318571@ixit.cz>
Hi David,
On Fri, Jun 26, 2026 at 11:09:54PM +0200, David Heidelberg wrote:
> With next-20260626 without any additional patches, the synaptics fails on
> OnePlus 6T with:
>
> ```
> [ 16.620292] rmi4_i2c 12-0020: registering I2C-connected sensor
> [ 16.857617] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer:
> Synaptics, product: S3706B, fw id: 2852315
> [ 16.867324] rmi4_f12 rmi4-00.fn12: Failed to read the Control Register
> Descriptor: -5
> [ 16.867338] rmi4_f12 rmi4-00.fn12: probe with driver rmi4_f12 failed with
> error -5
> ```
Yes, at least a98518e72439 "Input: rmi4 - fix register descriptor address
calculation" is wrong and needs to be reverted.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 0/2] Input: ilitek_ts: add stylus support for 0x0c reports
From: Kristian Mide @ 2026-06-26 21:42 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Kristian Mide
Hi,
I bought a CHUWI Hi10 Max and was annoyed to find that the built-in
stylus was not usable with the upstream ilitek_ts driver.
This small series adds support for the pen report format emitted by the
device, exposing the stylus as a separate input device with hover,
pressure, and side-button support. The pen device is created lazily on
first pen report so touchscreen-only hardware does not advertise stylus
capabilities up front.
The packet format was reverse engineered on this device. In particular,
report ID 0x0c appears to carry pen events, pressure comes from
buf[6..7] shifted right by one, and the side buttons map to two bits in
buf[1].
The second patch is unrelated to the pen support itself, but keeps the
existing wrong-report logging from flooding dmesg when unexpected packets
repeat quickly.
On the tested CHUWI Hi10 Max this makes the pen usable in GNOME/Krita,
including pressure and side buttons.
Thanks,
Kristian
Kristian Mide (2):
Input: ilitek_ts: add stylus input support
Input: ilitek_ts: ratelimit unexpected report logging
drivers/input/touchscreen/ilitek_ts_i2c.c | 134 +++++++++++++++++++++-
1 file changed, 133 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* [PATCH 1/2] Input: ilitek_ts: add stylus input support
From: Kristian Mide @ 2026-06-26 21:42 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Kristian Mide
In-Reply-To: <20260626214248.5563-1-kristian@mide.dk>
Add a separate stylus input device for report ID 0x0c packets,
with pressure, hover, and side-button support.
The pen device is created lazily on first pen report so
touchscreen-only hardware does not expose stylus capabilities up
front.
The packet format is reverse engineered from a tested CHUWI
Hi10 Max. Pressure is reported from buf[6..7] shifted right by
one, matching the observed 1024 pressure levels on the tested
device.
Pen coordinates are reported through touchscreen_report_pos()
so the same axis inversion and swapping properties used by the
touch path apply to the stylus as well.
---
drivers/input/touchscreen/ilitek_ts_i2c.c | 130 ++++++++++++++++++++++
1 file changed, 130 insertions(+)
diff --git a/drivers/input/touchscreen/ilitek_ts_i2c.c b/drivers/input/touchscreen/ilitek_ts_i2c.c
index 3de0fbf8d..f0721af02 100644
--- a/drivers/input/touchscreen/ilitek_ts_i2c.c
+++ b/drivers/input/touchscreen/ilitek_ts_i2c.c
@@ -18,6 +18,7 @@
#include <linux/gpio/consumer.h>
#include <linux/errno.h>
#include <linux/acpi.h>
+#include <linux/device/devres.h>
#include <linux/input/touchscreen.h>
#include <linux/unaligned.h>
@@ -37,6 +38,18 @@
#define ILITEK_TP_CMD_GET_IC_MODE 0xC0
#define ILITEK_TP_I2C_REPORT_ID 0x48
+/* Reverse engineered stylus report on a tested CHUWI Hi10 Max device. */
+#define ILITEK_PEN_I2C_REPORT_ID 0x0C
+#define ILITEK_PEN_PRESSURE_MAX 1023
+#define ILITEK_PEN_DISTANCE_MAX 2
+/* Userspace expects tablet axis resolution; with INPUT_PROP_DIRECT this is */
+/* mostly descriptive and does not materially affect event coordinates. */
+#define ILITEK_PEN_RESOLUTION 68
+
+#define ILITEK_PEN_FLAG_TOUCH 0x01
+#define ILITEK_PEN_FLAG_STYLUS2 0x02
+#define ILITEK_PEN_FLAG_STYLUS 0x08
+#define ILITEK_PEN_FLAG_PROX 0x10
#define REPORT_COUNT_ADDRESS 61
#define ILITEK_SUPPORT_MAX_POINT 40
@@ -50,6 +63,7 @@ struct ilitek_ts_data {
struct i2c_client *client;
struct gpio_desc *reset_gpio;
struct input_dev *input_dev;
+ struct input_dev *pen_input_dev;
struct touchscreen_properties prop;
const struct ilitek_protocol_map *ptl_cb_func;
@@ -89,6 +103,9 @@ enum ilitek_cmds {
MAX_CMD_CNT
};
+static int ilitek_pen_input_dev_init(struct device *dev,
+ struct ilitek_ts_data *ts);
+
/* ILITEK I2C R/W APIs */
static int ilitek_i2c_write_and_read(struct ilitek_ts_data *ts,
u8 *cmd, int write_len, int delay,
@@ -146,6 +163,62 @@ static void ilitek_touch_down(struct ilitek_ts_data *ts, unsigned int id,
touchscreen_report_pos(input, &ts->prop, x, y, true);
}
+static void ilitek_unregister_pen_input(void *data)
+{
+ struct ilitek_ts_data *ts = data;
+
+ input_unregister_device(ts->pen_input_dev);
+ ts->pen_input_dev = NULL;
+}
+
+/*
+ * buf[1] carries prox/touch/side-button state and buf[6..7] carries
+ * pressure. A right shift by one matches the observed 1024 pressure levels.
+ */
+static int ilitek_process_pen_report(struct ilitek_ts_data *ts, u8 *buf)
+{
+ struct device *dev = &ts->client->dev;
+ struct input_dev *input = ts->pen_input_dev;
+ unsigned int x, y, z, distance;
+ bool prox, touch, stylus, stylus2;
+ int error;
+
+ if (!input) {
+ error = ilitek_pen_input_dev_init(dev, ts);
+ if (error) {
+ dev_err_ratelimited(dev,
+ "failed to register pen input device: %d\n",
+ error);
+ return 0;
+ }
+ input = ts->pen_input_dev;
+ }
+
+ x = get_unaligned_le16(buf + 2);
+ y = get_unaligned_le16(buf + 4);
+ z = get_unaligned_le16(buf + 6) >> 1;
+ prox = !!(buf[1] & ILITEK_PEN_FLAG_PROX);
+ touch = !!(buf[1] & ILITEK_PEN_FLAG_TOUCH);
+ stylus = !!(buf[1] & ILITEK_PEN_FLAG_STYLUS);
+ stylus2 = !!(buf[1] & ILITEK_PEN_FLAG_STYLUS2);
+ distance = prox ? (touch ? 0 : 1) : ILITEK_PEN_DISTANCE_MAX;
+ if (!touch)
+ z = 0;
+ else if (z > ILITEK_PEN_PRESSURE_MAX)
+ z = ILITEK_PEN_PRESSURE_MAX;
+
+ input_report_key(input, BTN_TOOL_PEN, prox || touch);
+ input_report_key(input, BTN_TOUCH, touch);
+ input_report_key(input, BTN_STYLUS, stylus);
+ input_report_key(input, BTN_STYLUS2, stylus2);
+ touchscreen_report_pos(input, &ts->prop, x, y, false);
+ input_report_abs(input, ABS_PRESSURE, z);
+ input_report_abs(input, ABS_DISTANCE, distance);
+ input_sync(input);
+
+ return 0;
+}
+
static int ilitek_process_and_report_v6(struct ilitek_ts_data *ts)
{
int error = 0;
@@ -164,6 +237,9 @@ static int ilitek_process_and_report_v6(struct ilitek_ts_data *ts)
return error;
}
+ if (buf[0] == ILITEK_PEN_I2C_REPORT_ID)
+ return ilitek_process_pen_report(ts, buf);
+
if (buf[0] != ILITEK_TP_I2C_REPORT_ID) {
dev_err(dev, "get touch info failed. Wrong id: 0x%02X\n", buf[0]);
return -EINVAL;
@@ -459,6 +535,60 @@ static int ilitek_read_tp_info(struct ilitek_ts_data *ts, bool boot)
return 0;
}
+static int ilitek_pen_input_dev_init(struct device *dev, struct ilitek_ts_data *ts)
+{
+ struct input_dev *pen_input;
+ int error;
+
+ if (ts->pen_input_dev)
+ return 0;
+
+ /* No explicit pen capability probe is known; create on first pen report. */
+
+ pen_input = input_allocate_device();
+ if (!pen_input)
+ return -ENOMEM;
+
+ ts->pen_input_dev = pen_input;
+ pen_input->dev.parent = dev;
+ pen_input->name = "ilitek_ts_pen";
+ pen_input->id.bustype = BUS_I2C;
+
+ __set_bit(INPUT_PROP_DIRECT, pen_input->propbit);
+ __set_bit(EV_KEY, pen_input->evbit);
+ __set_bit(EV_ABS, pen_input->evbit);
+ __set_bit(BTN_TOUCH, pen_input->keybit);
+ __set_bit(BTN_TOOL_PEN, pen_input->keybit);
+ __set_bit(BTN_STYLUS, pen_input->keybit);
+ __set_bit(BTN_STYLUS2, pen_input->keybit);
+
+ input_set_abs_params(pen_input, ABS_X,
+ ts->screen_min_x, ts->screen_max_x, 0, 0);
+ input_set_abs_params(pen_input, ABS_Y,
+ ts->screen_min_y, ts->screen_max_y, 0, 0);
+ input_set_abs_params(pen_input, ABS_PRESSURE, 0,
+ ILITEK_PEN_PRESSURE_MAX, 0, 0);
+ input_set_abs_params(pen_input, ABS_DISTANCE, 0,
+ ILITEK_PEN_DISTANCE_MAX, 0, 0);
+ input_abs_set_res(pen_input, ABS_X, ILITEK_PEN_RESOLUTION);
+ input_abs_set_res(pen_input, ABS_Y, ILITEK_PEN_RESOLUTION);
+
+ error = input_register_device(pen_input);
+ if (error)
+ goto err_free_pen_input;
+
+ error = devm_add_action_or_reset(dev, ilitek_unregister_pen_input, ts);
+ if (error)
+ return error;
+
+ return 0;
+
+err_free_pen_input:
+ ts->pen_input_dev = NULL;
+ input_free_device(pen_input);
+ return error;
+}
+
static int ilitek_input_dev_init(struct device *dev, struct ilitek_ts_data *ts)
{
int error;
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] Input: ilitek_ts: ratelimit unexpected report logging
From: Kristian Mide @ 2026-06-26 21:42 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Kristian Mide
In-Reply-To: <20260626214248.5563-1-kristian@mide.dk>
Unexpected report IDs can repeat quickly when the controller
emits unknown packets.
Use dev_err_ratelimited() and include the first 16 bytes of the
raw packet to keep dmesg usable while preserving enough context
for debugging.
---
drivers/input/touchscreen/ilitek_ts_i2c.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ilitek_ts_i2c.c b/drivers/input/touchscreen/ilitek_ts_i2c.c
index f0721af02..8886bd39b 100644
--- a/drivers/input/touchscreen/ilitek_ts_i2c.c
+++ b/drivers/input/touchscreen/ilitek_ts_i2c.c
@@ -241,7 +241,9 @@ static int ilitek_process_and_report_v6(struct ilitek_ts_data *ts)
return ilitek_process_pen_report(ts, buf);
if (buf[0] != ILITEK_TP_I2C_REPORT_ID) {
- dev_err(dev, "get touch info failed. Wrong id: 0x%02X\n", buf[0]);
+ dev_err_ratelimited(dev,
+ "get touch info failed. Wrong id: 0x%02X raw[0:16]=%*ph\n",
+ buf[0], 16, buf);
return -EINVAL;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 2/2] Input: ilitek_ts: ratelimit unexpected report logging
From: sashiko-bot @ 2026-06-26 21:56 UTC (permalink / raw)
To: Kristian Mide; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626214248.5563-3-kristian@mide.dk>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] The I2C read/write wrapper does not properly check for short transfers, and this patch leaks the resulting uninitialized stack memory to dmesg.
Pre-existing issues:
- [High] The patch fails to prevent dmesg flooding and causes the interrupt handler to incorrectly signal a spurious interrupt, which can permanently disable the touchscreen.
- [High] Dynamically adding a devres action in a threaded IRQ handler creates an inverted teardown order during device unbind, leading to a memory leak and Use-After-Free.
- [High] If the I2C sleep command fails during suspend, the function returns an error without re-enabling the IRQ, rendering the touchscreen permanently unresponsive.
- [High] The driver passes stack-allocated arrays to i2c_transfer(), violating DMA mapping rules and risking memory corruption.
--
commit ec332d9cd1c7923c04e4eec0684513387a92348d
Author: Kristian Mide <kristian@mide.dk>
Input: ilitek_ts: ratelimit unexpected report logging
Unexpected report IDs can repeat quickly when the controller emits unknown
packets. This commit uses dev_err_ratelimited() and includes the first 16
bytes of the raw packet for context.
> diff --git a/drivers/input/touchscreen/ilitek_ts_i2c.c b/drivers/input/touchscreen/ilitek_ts_i2c.c
> index f0721af02adf2..8886bd39bc0b6 100644
> --- a/drivers/input/touchscreen/ilitek_ts_i2c.c
> +++ b/drivers/input/touchscreen/ilitek_ts_i2c.c
> @@ -241,7 +241,9 @@ static int ilitek_process_and_report_v6(struct ilitek_ts_data *ts)
[Severity: High]
This is a pre-existing issue, but does ilitek_process_and_report_v6() pass a
stack-allocated array to i2c_transfer()?
drivers/input/touchscreen/ilitek_ts_i2c.c:ilitek_process_and_report_v6() {
...
u8 buf[512];
...
error = ilitek_i2c_write_and_read(ts, NULL, 0, 0, buf, 64);
If the underlying I2C host controller driver maps the buffer for DMA, it might
attempt to map a stack address. On modern kernels where VMAP_STACK is enabled,
can this cause an immediate panic because stack memory is not physically
contiguous, or lead to cacheline sharing corruption otherwise?
> return ilitek_process_pen_report(ts, buf);
[Severity: High]
This is a pre-existing issue, but does dynamically adding a devres action
in the threaded IRQ handler create an inverted teardown order?
The IRQ is registered via devm_request_threaded_irq() in probe. Later, the
ISR dynamically calls devm_add_action_or_reset() to register the pen cleanup:
drivers/input/touchscreen/ilitek_ts_i2c.c:ilitek_process_pen_report() {
...
if (!input) {
error = ilitek_pen_input_dev_init(dev, ts);
which calls devm_add_action_or_reset(dev, ilitek_unregister_pen_input, ts).
Because devm is a LIFO stack, the pen cleanup is placed above the IRQ release
action. During device unbind, devres_release_all() will run the pen cleanup
first, freeing the device, while the IRQ remains active. If an interrupt fires
before the IRQ is finally freed, could the ISR access the freed device and
cause a use-after-free, or attempt to append a new devres action while the
stack is being torn down?
>
> if (buf[0] != ILITEK_TP_I2C_REPORT_ID) {
> - dev_err(dev, "get touch info failed. Wrong id: 0x%02X\n", buf[0]);
> + dev_err_ratelimited(dev,
> + "get touch info failed. Wrong id: 0x%02X raw[0:16]=%*ph\n",
> + buf[0], 16, buf);
[Severity: High]
Does this new logging leak uninitialized kernel stack memory to dmesg?
Looking at ilitek_i2c_write_and_read(), it checks if error < 0, but
i2c_transfer() returns the number of successfully transferred messages:
drivers/input/touchscreen/ilitek_ts_i2c.c:ilitek_i2c_write_and_read() {
...
error = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
if (error < 0)
return error;
If a short transfer occurs, this evaluates to false, so the wrapper returns 0
(success) despite the read buffer not being populated. When that happens,
won't this new log message directly print 16 bytes of uninitialized kernel
stack memory to the dmesg buffer?
> return -EINVAL;
[Severity: High]
This is a pre-existing issue, but does returning -EINVAL here cause the
interrupt handler to incorrectly signal a spurious interrupt?
When an unknown packet is received, ilitek_process_and_report_v6() returns
-EINVAL to the ISR, which then handles the error like this:
drivers/input/touchscreen/ilitek_ts_i2c.c:ilitek_i2c_isr() {
...
error = ilitek_process_and_report_v6(ts);
if (error < 0) {
dev_err(&ts->client->dev, "[%s] err:%d\n", __func__, error);
return IRQ_NONE;
}
First, the ISR unconditionally logs the error, which defeats the ratelimiting
added in this patch. Second, could repeatedly returning IRQ_NONE when the
hardware interrupt was actually serviced (cleared by the I2C read) cause the
kernel's spurious interrupt detection to eventually disable the IRQ line
permanently?
> }
>
[ ... ]
[Severity: High]
This is a pre-existing issue, but does ilitek_suspend() return an error
without re-enabling the previously disabled IRQ?
drivers/input/touchscreen/ilitek_ts_i2c.c:ilitek_suspend() {
...
disable_irq(client->irq);
if (!device_may_wakeup(dev)) {
error = api_protocol_set_cmd(ts, SET_IC_SLEEP, NULL, NULL);
if (error)
return error;
}
If the I2C sleep command fails during suspend, the function returns an error
while the device IRQ is disabled. The PM core will abort the suspend
transition and resume previously suspended devices, but it will not call the
resume callback for the device that returned the error. Could this render the
touchscreen permanently unresponsive until reboot or module reload?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626214248.5563-1-kristian@mide.dk?part=2
^ permalink raw reply
* Re: [PATCH 1/2] Input: ilitek_ts: add stylus input support
From: sashiko-bot @ 2026-06-26 21:56 UTC (permalink / raw)
To: Kristian Mide; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626214248.5563-2-kristian@mide.dk>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] Lazy initialization of the pen input device from within the IRQ handler causes a devres LIFO ordering inversion, leading to a memory leak and Use-After-Free during device unbind.
- [High] The pen input device axis limits are not synced with Device Tree properties, leading to mismatched axis boundaries and massive coordinate underflow values.
- [Low] Direct bit manipulation is used instead of the preferred `input_set_capability()` helper.
Pre-existing issues:
- [High] I2C transfers are performed using buffers allocated on the stack, which is unsafe for DMA.
--
commit 0912736a7a818d72cc6868aba6ad50c6f06afd78
Author: Kristian Mide <kristian@mide.dk>
Input: ilitek_ts: add stylus input support
Add a separate stylus input device for report ID 0x0c packets,
with pressure, hover, and side-button support. The pen device is
created lazily on first pen report so touchscreen-only hardware does
not expose stylus capabilities up front.
> diff --git a/drivers/input/touchscreen/ilitek_ts_i2c.c b/drivers/input/touchscreen/ilitek_ts_i2c.c
> index 3de0fbf8da386..f0721af02adf2 100644
> --- a/drivers/input/touchscreen/ilitek_ts_i2c.c
> +++ b/drivers/input/touchscreen/ilitek_ts_i2c.c
[ ... ]
> @@ -164,6 +237,9 @@ static int ilitek_process_and_report_v6(struct ilitek_ts_data *ts)
> return error;
> }
>
> + if (buf[0] == ILITEK_PEN_I2C_REPORT_ID)
> + return ilitek_process_pen_report(ts, buf);
[Severity: High]
This is a pre-existing issue and was not introduced by the patch under
review, but since buf is passed here, is it safe to allocate buf as a
512-byte array on the stack in ilitek_process_and_report_v6() and pass it to
I2C transfer functions?
When CONFIG_VMAP_STACK is enabled, stack addresses cannot be safely mapped
for DMA. If the underlying I2C host controller uses DMA, could attempting
to map this stack buffer lead to memory corruption or kernel panics?
> +
> if (buf[0] != ILITEK_TP_I2C_REPORT_ID) {
> dev_err(dev, "get touch info failed. Wrong id: 0x%02X\n", buf[0]);
> return -EINVAL;
[ ... ]
> @@ -459,6 +535,60 @@ static int ilitek_read_tp_info(struct ilitek_ts_data *ts, bool boot)
> return 0;
> }
>
> +static int ilitek_pen_input_dev_init(struct device *dev, struct ilitek_ts_data *ts)
> +{
> + struct input_dev *pen_input;
> + int error;
> +
> + if (ts->pen_input_dev)
> + return 0;
> +
> + /* No explicit pen capability probe is known; create on first pen report. */
> +
> + pen_input = input_allocate_device();
> + if (!pen_input)
> + return -ENOMEM;
> +
> + ts->pen_input_dev = pen_input;
> + pen_input->dev.parent = dev;
> + pen_input->name = "ilitek_ts_pen";
> + pen_input->id.bustype = BUS_I2C;
> +
> + __set_bit(INPUT_PROP_DIRECT, pen_input->propbit);
> + __set_bit(EV_KEY, pen_input->evbit);
> + __set_bit(EV_ABS, pen_input->evbit);
> + __set_bit(BTN_TOUCH, pen_input->keybit);
> + __set_bit(BTN_TOOL_PEN, pen_input->keybit);
> + __set_bit(BTN_STYLUS, pen_input->keybit);
> + __set_bit(BTN_STYLUS2, pen_input->keybit);
[Severity: Low]
This isn't a bug, but could we use the input_set_capability() helper here
instead of direct bit manipulation?
> +
> + input_set_abs_params(pen_input, ABS_X,
> + ts->screen_min_x, ts->screen_max_x, 0, 0);
> + input_set_abs_params(pen_input, ABS_Y,
> + ts->screen_min_y, ts->screen_max_y, 0, 0);
[Severity: High]
Should the touchscreen properties (DT properties) be applied to these
absolute parameters?
The touchscreen_report_pos() function called during event processing will
apply inversion and swapping based on Device Tree properties to the
coordinates.
If the limits advertised here are strictly from the raw hardware bounds and
are unaware of those DT properties, could this cause the device to report
out-of-bounds coordinates or result in unsigned underflows when an axis is
inverted?
> + input_set_abs_params(pen_input, ABS_PRESSURE, 0,
> + ILITEK_PEN_PRESSURE_MAX, 0, 0);
> + input_set_abs_params(pen_input, ABS_DISTANCE, 0,
> + ILITEK_PEN_DISTANCE_MAX, 0, 0);
> + input_abs_set_res(pen_input, ABS_X, ILITEK_PEN_RESOLUTION);
> + input_abs_set_res(pen_input, ABS_Y, ILITEK_PEN_RESOLUTION);
> +
> + error = input_register_device(pen_input);
> + if (error)
> + goto err_free_pen_input;
> +
> + error = devm_add_action_or_reset(dev, ilitek_unregister_pen_input, ts);
[Severity: High]
Since this function is called lazily from the threaded IRQ handler after
probe has completed, does adding a devm action here break the LIFO teardown
ordering?
During device unbind, devres will release resources in LIFO order. This
action would run first and set ts->pen_input_dev = NULL, but the IRQ
handler would still be active.
If a hardware interrupt fires during unbind after this has been
unregistered, would the IRQ handler observe the NULL pointer, allocate a
new pen device, and add a new devres action that devres_release_all()
will never process, resulting in a memory leak and a potential
use-after-free?
> + if (error)
> + return error;
> +
> + return 0;
> +
> +err_free_pen_input:
> + ts->pen_input_dev = NULL;
> + input_free_device(pen_input);
> + return error;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626214248.5563-1-kristian@mide.dk?part=1
^ permalink raw reply
* Re: [PATCH v6 1/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Vicki Pfau @ 2026-06-27 1:27 UTC (permalink / raw)
To: sashiko-reviews; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260625051651.723051F000E9@smtp.kernel.org>
More LLM hallucinations to deal with:
On 6/24/26 10:16 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 14 potential issue(s) to consider:
> - [High] Early HID start before driver data is set causes NULL pointer dereference in event handler.
> - [High] Explicitly unregistering and freeing a devm-allocated input device violates input subsystem rules and causes double-frees.
> - [High] LEDs registered with devm tied to `input->dev` lead to Use-After-Free when the parent `ns2` structure is dynamically freed.
> - [High] USB bulk input pipeline permanently stalls if URBs complete before the workqueue processes them.
> - [High] Lockless modification of `urb->state` before unanchoring in USB output error path causes UAF and DMA corruption.
> - [High] Concurrent driver unbind causes a Use-After-Free of `struct switch2_controller`.
> - [High] Teardown ordering in `switch2_usb_disconnect()` frees `bulk_out` URBs before cancelling `message_in_work`.
> - [High] Missing `cancel_work_sync()` in `switch2_usb_probe` error path leads to UAF of `ns2_usb`.
> - [High] Calling `hid_hw_close(hdev)` after `hid_hw_open(hdev)` fails corrupts `ll_open_count`.
> - [High] `usb_free_coherent()` is called while holding a spinlock with IRQs disabled.
> - [Medium] Calling `ida_free()` with an unallocated player ID (`U32_MAX`) triggers a kernel warning.
> - [Medium] Leaking OUT URBs on memory allocation failure in `switch2_usb_probe`.
> - [Medium] Mixing `goto` error handling with `guard()` cleanup violates subsystem anti-pattern rules.
> - [Low] Calling `usb_make_path()` introduces an undeclared hard dependency on the USB core.
> --
>
> commit 322f53e1d34ab62127ead48da7aeff5c1763e2a2
> Author: Vicki Pfau <vi@endrift.com>
>
> HID: nintendo: Add preliminary Switch 2 controller driver
>
> This commit introduces support for the Nintendo Switch 2 Joy-Cons,
> Pro Controller, and GameCube controllers. It implements a split-interface
> design using a main HID driver and a secondary configuration interface.
> Initial support handles general input and USB communications.
>
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -843,10 +843,13 @@ config HID_NINTENDO
>> depends on LEDS_CLASS
>> select POWER_SUPPLY
>
> [Severity: Low]
> Does this new configuration introduce an undeclared dependency?
>
> The newly added switch2_probe() function in hid-nintendo.c calls
> usb_make_path(), which is an exported symbol from the USB core. However,
> CONFIG_HID_NINTENDO does not specify depends on USB.
No it's not. It's a static inline function in a header and has been since 2.4.20 over 20 years ago.
>
> If the kernel is built with CONFIG_HID_NINTENDO=y and CONFIG_USB=m, will
> the build fail during linking due to an unresolved reference to
> usb_make_path?>
>> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
>> --- a/drivers/hid/hid-nintendo.c
>> +++ b/drivers/hid/hid-nintendo.c
> [ ... ]
>> +static int switch2_init_input(struct switch2_controller *ns2)
>> +{
>> + struct input_dev *input;
> [ ... ]
>> + input = devm_input_allocate_device(&hdev->dev);
>> + if (!input)
>> + return -ENOMEM;
>> +
>> + input_set_drvdata(input, ns2);
>> + input->dev.parent = &hdev->dev;
>
> [Severity: High]
> Does explicitly unregistering and freeing a devm-allocated input device
> violate input subsystem rules and cause double-frees?
>
> The driver allocates the input device using devm_input_allocate_device().
> The input subsystem automatically handles cleanup when the provider device is
> unbound. However, the driver explicitly calls input_free_device() on failure
> paths in switch2_init_input() and input_unregister_device() in its teardown
> path switch2_controller_put().
>
> Can this cause a double-free or double-unregister when the devres callbacks
> later attempt to clean up the same device? Additionally, is manually setting
> input->dev.parent redundant and prohibited for devm-allocated input devices?
I've already explained why this is wrong.
>
> [ ... ]
>> + for (i = 0; i < JC_NUM_LEDS; i++) {
>> + struct led_classdev *led = &ns2->leds[i];
> [ ... ]
>> + ret = devm_led_classdev_register(&input->dev, led);
>> + if (ret < 0) {
>> + dev_err(&input->dev, "Failed to register player %d LED; ret=%d\n",
>> + i + 1, ret);
>> + input_unregister_device(input);
>> + return ret;
>> + }
>> + }
>
> [Severity: High]
> Can tying the devm-managed LEDs to input->dev lead to a Use-After-Free
> when the parent ns2 structure is dynamically freed?
>
> The LEDs are registered using devm_led_classdev_register() with input->dev.
> The ns2 structure containing the LEDs is manually freed via kfree(ns2) in
> switch2_controller_put().
>
> The devres callbacks for input->dev execute when its refcount drops to zero.
> If userspace holds an open file descriptor to the input device, this
> cleanup can be arbitrarily delayed.
>
> Will the driver free ns2 immediately while the LEDs remain registered and
> pointing to freed memory until the fd is closed, resulting in a
> Use-After-Free if sysfs LED attributes are accessed?
While there is an exceedingly narrow window for this I think it is theoretically possible. I'll just treat issues creating the LEDs as non-fatal and continue onwards. They can get torn down at the end like everything else.
>
> [ ... ]
>> +static void switch2_controller_put(struct switch2_controller *ns2)
>> +{
>> + struct input_dev *input;
>> + bool do_free;
>> +
>> + guard(mutex)(&switch2_controllers_lock);
>> + mutex_lock(&ns2->lock);
>> +
>> + rcu_read_lock();
>> + input = rcu_dereference(ns2->input);
>> + rcu_read_unlock();
>> +
>> + rcu_assign_pointer(ns2->input, NULL);
>> + synchronize_rcu();
>> +
>> + ns2->init_step = 0;
>> + do_free = !ns2->hdev && !ns2->cfg;
>> + mutex_unlock(&ns2->lock);
>> +
>> + if (input)
>> + input_unregister_device(input);
>> +
>> + if (do_free) {
>> + list_del_init(&ns2->entry);
>> + mutex_destroy(&ns2->lock);
>> + kfree(ns2);
>> + }
>> +}
>
> [Severity: High]
> Could a concurrent driver unbind cause a Use-After-Free of the ns2 structure?
>
> The guard(mutex)(&switch2_controllers_lock) holds the global lock for the
> entire function scope. If HID and USB disconnect concurrently, both clear
> their pointers and call switch2_controller_put().
>
> If the first thread evaluates do_free as true, destroys the mutex, frees
> ns2, and returns, it releases the global lock.
>
> Will the second thread, which was blocked waiting on the global lock,
> wake up and immediately call mutex_lock(&ns2->lock) using the pointer
> that was just freed?
I'm unsure if that re-entry is possible from an external subsystem perspective, but if it is then this narrow hole also exists. I'll convert this to just a basic ref count.
>
> [ ... ]
>> +static int switch2_event(struct hid_device *hdev, struct hid_report *report, uint8_t *raw_data,
>> + int size)
>> +{
>> + struct switch2_controller *ns2 = hid_get_drvdata(hdev);
>> + struct input_dev *input;
>> +
>> + if (report->type != HID_INPUT_REPORT)
>> + return 0;
>> +
>> + if (size < 15)
>> + return -EINVAL;
>> +
>> + guard(rcu)();
>> + input = rcu_dereference(ns2->input);
>
> [Severity: High]
> Could this event handler dereference uninitialized driver data during early
> hardware I/O startup?
>
> The switch2_probe() function calls hid_hw_start(hdev, HID_CONNECT_HIDRAW)
> before assigning its private data with hid_set_drvdata(). This connects the
> device to hidraw, allowing userspace to immediately open it and trigger input
> events, or the underlying transport can send events.
>
> If an event arrives during this race window, will switch2_event() call
> hid_get_drvdata(hdev) and receive a NULL pointer, leading to a kernel crash
> when calling rcu_dereference(ns2->input)?
Seems I've misunderstood the difference between hid_hw_start and hid_hw_open. Fixing in v7.
>
> [ ... ]
>> +int switch2_receive_command(struct switch2_controller *ns2,
>> + const uint8_t *message, size_t length)
>> +{
>> + const struct switch2_cmd_header *header;
>> + int ret = 0;
>> +
>> + if (length < 8)
>> + return -EINVAL;
>> +
>> + print_hex_dump_debug("got cmd: ", DUMP_PREFIX_OFFSET, 16, 1, message, length, false);
>> +
>> + guard(mutex)(&ns2->lock);
>> +
>> + header = (const struct switch2_cmd_header *)message;
>> + if (!(header->flags & NS2_FLAG_OK)) {
>> + dev_warn(ns2->cfg->dev, "Packet error %02x replying to command %x:%x",
>> + header->flags, header->command, header->subcommand);
>> + ret = -EIO;
>> + goto exit;
>> + }
> [ ... ]
>> +exit:
>> + if (ns2->init_step < NS2_INIT_DONE)
>> + switch2_init_controller(ns2);
>> +
>> + return ret;
>> +}
>
> [Severity: Medium]
> Does mixing goto error handling with guard() cleanup violate subsystem rules?
>
> This function utilizes guard(mutex)(&ns2->lock) to acquire the lock using
> scope-based cleanup, but later uses goto exit to jump to a cleanup label
> on error paths.
>
> The core kernel cleanup guidelines explicitly forbid mixing goto-based
> cleanup labels and guard() declarations in the same routine, as it
> creates confusing ownership semantics.
Ah, I guess I misunderstood the how this was forbidden. Easy enough to clean up now that I have a single exit.>
> [ ... ]
>> +static int switch2_probe(struct hid_device *hdev, const struct hid_device_id *id)
>> +{
> [ ... ]
>> + ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
>> + if (ret) {
>> + hid_err(hdev, "hw_start failed %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ns2 = switch2_get_controller(phys);
> [ ... ]
>> + ns2->player_id = U32_MAX;
>> + ret = ida_alloc(&nintendo_player_id_allocator, GFP_KERNEL);
>> + if (ret < 0)
>> + hid_warn(hdev, "Failed to allocate player ID, skipping; ret=%d\n", ret);
>> + else
>> + ns2->player_id = ret;
> [ ... ]
>> + hid_set_drvdata(hdev, ns2);
>> +
>> + ret = hid_hw_open(hdev);
>> + if (ret) {
>> + hid_err(hdev, "hw_open failed %d\n", ret);
>> + goto err_cleanup;
>> + }
>> +
>> + ret = 0;
>> + if (ns2->cfg)
>> + ret = switch2_init_controller(ns2);
>> +
>> + if (!ret) {
>> + mutex_unlock(&ns2->lock);
>> + return 0;
>> + }
>> +
>> +err_cleanup:
>> + hid_hw_close(hdev);
>> + ida_free(&nintendo_player_id_allocator, ns2->player_id);
>> + ns2->hdev = NULL;
>> + mutex_unlock(&ns2->lock);
>
> [Severity: High]
> If hid_hw_open() fails, does the unconditional call to hid_hw_close(hdev)
> corrupt the ll_open_count tracking?
>
> If hid_hw_open(hdev) fails, execution jumps to the err_cleanup label, which
> unconditionally calls hid_hw_close(hdev).
>
> Since hid_hw_open() does not increment ll_open_count on failure, will
> hid_hw_close() decrement the count from 0, wrapping it around to UINT_MAX
> and permanently silently preventing any future opens of the device?
Fixing as part of other cleanup.
>
> [Severity: Medium]
> Does this error path trigger a WARN_ON when trying to free an unallocated
> player ID?
>
> The code initializes ns2->player_id to U32_MAX. If ida_alloc() fails,
> it skips allocation but retains the U32_MAX value.
>
> In the err_cleanup path, or during switch2_remove(), the driver
> unconditionally calls ida_free(&nintendo_player_id_allocator, ns2->player_id).
>
> Will passing -1 (U32_MAX) to ida_free() trigger a WARN_ON within the IDA
> framework?
Already shown to be a hallucination in the last reply.
>
>> diff --git a/drivers/input/joystick/nintendo-switch2-usb.c b/drivers/input/joystick/nintendo-switch2-usb.c
>> --- /dev/null
>> +++ b/drivers/input/joystick/nintendo-switch2-usb.c
> [ ... ]
>> +static void switch2_bulk_in(struct urb *urb)
>> +{
> [ ... ]
>> + spin_lock_irqsave(&ns2_usb->bulk_in_lock, flags);
>> + for (i = 0; i < NS2_IN_URBS; i++) {
>> + int err;
>> + struct switch2_urb *ns2_urb;
>> +
>> + if (ns2_usb->bulk_in[i].urb == urb) {
>> + ns2_usb->bulk_in[i].state = NS2_URB_IN;
>> + continue;
>> + }
>> +
>> + if (ns2_usb->bulk_in[i].state != NS2_URB_FREE)
>> + continue;
>> +
>> + ns2_urb = &ns2_usb->bulk_in[i];
>> + usb_anchor_urb(ns2_urb->urb, &ns2_usb->bulk_in_anchor);
>> + err = usb_submit_urb(ns2_urb->urb, GFP_ATOMIC);
>> + if (err) {
>> + usb_unanchor_urb(ns2_urb->urb);
>> + dev_dbg(&ns2_usb->udev->dev, "failed to queue input urb: %d\n", err);
>> + } else {
>> + ns2_urb->state = NS2_URB_OUT;
>> + }
>> + }
>> + spin_unlock_irqrestore(&ns2_usb->bulk_in_lock, flags);
>> +
>> + if (schedule)
>> + schedule_work(&ns2_usb->message_in_work);
>> +}
> [ ... ]
>> +static void switch2_usb_message_in_work(struct work_struct *work)
>> +{
> [ ... ]
>> + spin_lock_irqsave(&ns2_usb->bulk_in_lock, flags);
>> + urb->state = NS2_URB_FREE;
>> + }
>> + spin_unlock_irqrestore(&ns2_usb->bulk_in_lock, flags);
>> +}
>
> [Severity: High]
> Does this input URB handling stall the USB bulk input pipeline permanently
> if the URBs complete too quickly?
>
> The driver manages IN URBs via a ping-pong mechanism. switch2_bulk_in()
> submits URBs in the NS2_URB_FREE state. The worker
> switch2_usb_message_in_work() clears processed URBs to NS2_URB_FREE but
> does not re-submit them.
>
> If all active URBs complete in quick succession before the workqueue
> thread runs, they will all be marked NS2_URB_IN. The worker will process
> them and mark them FREE, but since no URBs are left active in the USB core
> to trigger the completion handler, will switch2_bulk_in() never be called
> again, permanently halting input?
In theory, the Switch 2 controller should only send a bulk IN in reply to a bulk OUT, and we don't tend to schedule more than one of those at a time, but it'd be good to fix this anyway.>
> [ ... ]
>> +static int switch2_usb_send_cmd(enum switch2_cmd command, uint8_t subcommand,
>> + const void *message, size_t size, struct switch2_cfg_intf *cfg)
>> +{
> [ ... ]
>> + usb_anchor_urb(urb->urb, &ns2_usb->bulk_out_anchor);
>> + ret = usb_submit_urb(urb->urb, GFP_ATOMIC);
>> + if (ret) {
>> + if (ret != -ENODEV)
>> + dev_warn(&ns2_usb->udev->dev, "failed to submit output urb: %i", ret);
>> + urb->state = NS2_URB_FREE;
>> + usb_unanchor_urb(urb->urb);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>
> [Severity: High]
> Can this lockless modification of urb->state lead to a data race and
> potential DMA corruption?
>
> If usb_submit_urb() fails, urb->state = NS2_URB_FREE is set without
> re-acquiring ns2_usb->bulk_out_lock. Additionally, it is marked FREE
> before calling usb_unanchor_urb().
>
> Could a concurrent thread acquire the lock, claim this supposedly free
> URB, write to its DMA buffer, and submit it, right as the original
> thread unanchors it? During teardown, usb_kill_anchored_urbs() would not
> wait for this unanchored URB, potentially leading to its DMA buffer being
> freed while the hardware is still accessing it.
Missed this. Fixing in v7. Wish the stochastic parrot had found this on v5.
>
> [ ... ]
>> +static int switch2_usb_probe(struct usb_interface *intf, const struct usb_device_id *id)
>> +{
> [ ... ]
>> + for (i = 0; i < NS2_OUT_URBS; i++) {
>> + struct urb *urb;
>> + uint8_t *data;
>> +
>> + urb = usb_alloc_urb(0, GFP_KERNEL);
>> + if (!urb) {
>> + ret = -ENOMEM;
>> + goto err_free_in;
>> + }
> [ ... ]
>> + ret = switch2_controller_attach_cfg(phys, &ns2_usb->cfg);
>> + if (ret < 0)
>> + goto err_free_out;
>> +
>> + return 0;
>> +
>> +err_free_out:
>> + usb_kill_anchored_urbs(&ns2_usb->bulk_out_anchor);
>> + spin_lock_irqsave(&ns2_usb->bulk_out_lock, flags);
>> + for (i = 0; i < NS2_OUT_URBS; i++) {
>> + if (!ns2_usb->bulk_out[i].urb)
>> + continue;
>> +
>> + usb_free_coherent(ns2_usb->udev, NS2_BULK_SIZE, ns2_usb->bulk_out[i].data,
>> + ns2_usb->bulk_out[i].urb->transfer_dma);
>> + usb_free_urb(ns2_usb->bulk_out[i].urb);
>> + }
>> + spin_unlock_irqrestore(&ns2_usb->bulk_out_lock, flags);
>> +err_free_in:
>> + usb_kill_anchored_urbs(&ns2_usb->bulk_in_anchor);
> [ ... ]
>> + devm_kfree(&intf->dev, ns2_usb);
>> +
>> + return ret;
>> +}
>
> [Severity: Medium]
> Does this error handling skip cleaning up successfully allocated OUT URBs?
>
> During the loop allocating OUT URBs, if usb_alloc_urb() fails, the code
> branches to goto err_free_in. This skips the err_free_out block entirely.
>
> Will this permanently leak the OUT URBs and their DMA buffers from
> any preceding successful loop iterations?
Fixed.
>
> [Severity: High]
> Does calling usb_free_coherent() inside the atomic critical section violate
> DMA API rules?
>
> In the err_free_out block, usb_free_coherent() is called while the
> bulk_out_lock spinlock is held with IRQs disabled (using spin_lock_irqsave).
>
> Since usb_free_coherent() is a wrapper for dma_free_coherent() and freeing
> memory allocated with GFP_KERNEL may sleep, will this cause deadlocks or
> kernel panics under CONFIG_DEBUG_ATOMIC_SLEEP?
Fixed.
>
> [Severity: High]
> Is a cancel_work_sync() missing from this error path, potentially causing
> a Use-After-Free?
>
> An IN URB is submitted before calling switch2_controller_attach_cfg().
> If the device responds immediately, switch2_bulk_in() will schedule
> ns2_usb->message_in_work.
>
> If attach_cfg fails, the error path frees ns2_usb via devm_kfree() but
> never calls cancel_work_sync(&ns2_usb->message_in_work).
>
> Could the scheduled work execute later on the freed memory footprint of
> ns2_usb?
Fixed.
>
> [ ... ]
>> +static void switch2_usb_disconnect(struct usb_interface *intf)
>> +{
>> + struct switch2_usb *ns2_usb = usb_get_intfdata(intf);
>> + unsigned long flags;
>> + int i;
>> +
>> + usb_kill_anchored_urbs(&ns2_usb->bulk_out_anchor);
>> + spin_lock_irqsave(&ns2_usb->bulk_out_lock, flags);
>> + for (i = 0; i < NS2_OUT_URBS; i++) {
>> + usb_free_coherent(ns2_usb->udev, NS2_BULK_SIZE, ns2_usb->bulk_out[i].data,
>> + ns2_usb->bulk_out[i].urb->transfer_dma);
>> + usb_free_urb(ns2_usb->bulk_out[i].urb);
>> + }
>> + spin_unlock_irqrestore(&ns2_usb->bulk_out_lock, flags);
>> +
>> + usb_kill_anchored_urbs(&ns2_usb->bulk_in_anchor);
>> + cancel_work_sync(&ns2_usb->message_in_work);
>
> [Severity: High]
> Does freeing the bulk_out URBs before cancelling the worker lead to
> a Use-After-Free and DMA corruption?
>
> All bulk_out URBs and their DMA buffers are freed before the driver
> invokes cancel_work_sync(&ns2_usb->message_in_work).
>
> Can the globally scheduled workqueue run concurrently during this gap,
> process incoming messages, and trigger a reply via switch2_usb_send_cmd()?
>
> If so, will the send function claim a freed URB and write to the freed DMA
> buffer, leading to a Use-After-Free and submitting corrupted DMA to the
> USB controller?
>
> [Severity: High]
> Does calling usb_free_coherent() inside the atomic critical section violate
> DMA API rules?
>
> Similar to the probe error path, usb_free_coherent() is called while the
> bulk_out_lock spinlock is held with IRQs disabled (using spin_lock_irqsave).
>
> Since freeing memory allocated with GFP_KERNEL may sleep, will this cause
> deadlocks or kernel panics under CONFIG_DEBUG_ATOMIC_SLEEP?
>
Fixed a bunch of things in this too.
I'm noticing a bunch of ordering stuff in this file that's rough to get right. Hopefully I've fixed it now and will be submitting v7 on Monday probably. Still need to review patch 2 and retest everything.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox