* [PATCH 08/10] Input: synaptics-rmi4 - F54 style and typo fixes
From: Dmitry Torokhov @ 2026-06-26 5:17 UTC (permalink / raw)
To: Bryam Vargas, Hans Verkuil; +Cc: linux-input, linux-kernel
In-Reply-To: <20260626051802.4033172-1-dmitry.torokhov@gmail.com>
Clean up style issues in rmi_f54.c reported by checkpatch.pl --strict:
- Convert (1 << X) caps to BIT(X).
- Align assignment operator '=' in report_types array.
- Add comments to status_mutex, data_mutex, and lock explaining what they protect.
- Align function arguments/parameters with open parenthesis in rmi_f54_get_reptype() and rmi_f54_vidioc_querycap().
- Fix typo 'firmare' -> 'firmware' in comment.
- Align dev_err() argument with open parenthesis in rmi_f54_work().
- Use '!ptr' instead of 'ptr == NULL' for report_data check in rmi_f54_probe().
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f54.c | 38 ++++++++++++++++++------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index 93526feea563..850e1742c480 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -5,6 +5,7 @@
*/
#include <linux/kernel.h>
+#include <linux/bits.h>
#include <linux/rmi.h>
#include <linux/input.h>
#include <linux/slab.h>
@@ -35,9 +36,9 @@
#define F54_FORCE_CAL 2
/* F54 capabilities */
-#define F54_CAP_BASELINE (1 << 2)
-#define F54_CAP_IMAGE8 (1 << 3)
-#define F54_CAP_IMAGE16 (1 << 6)
+#define F54_CAP_BASELINE BIT(2)
+#define F54_CAP_IMAGE8 BIT(3)
+#define F54_CAP_IMAGE16 BIT(6)
/**
* enum rmi_f54_report_type - RMI4 F54 report types
@@ -83,14 +84,13 @@ enum rmi_f54_report_type {
};
static const char * const rmi_f54_report_type_names[] = {
- [F54_REPORT_NONE] = "Unknown",
- [F54_8BIT_IMAGE] = "Normalized 8-Bit Image",
- [F54_16BIT_IMAGE] = "Normalized 16-Bit Image",
- [F54_RAW_16BIT_IMAGE] = "Raw 16-Bit Image",
- [F54_TRUE_BASELINE] = "True Baseline",
- [F54_FULL_RAW_CAP] = "Full Raw Capacitance",
- [F54_FULL_RAW_CAP_RX_OFFSET_REMOVED]
- = "Full Raw Capacitance RX Offset Removed",
+ [F54_REPORT_NONE] = "Unknown",
+ [F54_8BIT_IMAGE] = "Normalized 8-Bit Image",
+ [F54_16BIT_IMAGE] = "Normalized 16-Bit Image",
+ [F54_RAW_16BIT_IMAGE] = "Raw 16-Bit Image",
+ [F54_TRUE_BASELINE] = "True Baseline",
+ [F54_FULL_RAW_CAP] = "Full Raw Capacitance",
+ [F54_FULL_RAW_CAP_RX_OFFSET_REMOVED] = "Full Raw Capacitance RX Offset Removed",
};
struct f54_data {
@@ -109,8 +109,8 @@ struct f54_data {
int report_error;
bool is_busy;
- struct mutex status_mutex;
- struct mutex data_mutex;
+ struct mutex status_mutex; /* Protects is_busy and command state */
+ struct mutex data_mutex; /* Protects report_data buffer */
struct workqueue_struct *workqueue;
struct delayed_work work;
@@ -123,7 +123,7 @@ struct f54_data {
struct v4l2_pix_format format;
struct video_device vdev;
struct vb2_queue queue;
- struct mutex lock;
+ struct mutex lock; /* Serializes V4L2 device and queue access */
u32 sequence;
int input;
enum rmi_f54_report_type inputs[F54_MAX_REPORT_TYPE];
@@ -153,7 +153,7 @@ static bool is_f54_report_type_valid(struct f54_data *f54,
}
static enum rmi_f54_report_type rmi_f54_get_reptype(struct f54_data *f54,
- unsigned int i)
+ unsigned int i)
{
if (i >= F54_MAX_REPORT_TYPE)
return F54_REPORT_NONE;
@@ -193,7 +193,7 @@ static int rmi_f54_request_report(struct rmi_function *fn, u8 report_type)
/*
* Small delay after disabling interrupts to avoid race condition
- * in firmare. This value is a bit higher than absolutely necessary.
+ * in firmware. This value is a bit higher than absolutely necessary.
* Should be removed once issue is resolved in firmware.
*/
usleep_range(2000, 3000);
@@ -406,7 +406,7 @@ static int rmi_f54_vidioc_querycap(struct file *file, void *priv,
strscpy(cap->driver, F54_NAME, sizeof(cap->driver));
strscpy(cap->card, SYNAPTICS_INPUT_DEVICE_NAME, sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info),
- "rmi4:%s", dev_name(&f54->fn->dev));
+ "rmi4:%s", dev_name(&f54->fn->dev));
return 0;
}
@@ -563,7 +563,7 @@ static void rmi_f54_work(struct work_struct *work)
report_size = rmi_f54_get_report_size(f54);
if (report_size == 0) {
dev_err(&fn->dev, "Bad report size, report type=%d\n",
- f54->report_type);
+ f54->report_type);
error = -EINVAL;
goto out; /* retry won't help */
}
@@ -709,7 +709,7 @@ static int rmi_f54_probe(struct rmi_function *fn)
f54->max_report_size = array3_size(tx, rx, sizeof(u16));
f54->report_data = devm_kzalloc(&fn->dev, f54->max_report_size,
GFP_KERNEL);
- if (f54->report_data == NULL)
+ if (!f54->report_data)
return -ENOMEM;
INIT_DELAYED_WORK(&f54->work, rmi_f54_work);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 09/10] Input: synaptics-rmi4 - change report_size to size_t in F54
From: Dmitry Torokhov @ 2026-06-26 5:17 UTC (permalink / raw)
To: Bryam Vargas, Hans Verkuil; +Cc: linux-input, linux-kernel
In-Reply-To: <20260626051802.4033172-1-dmitry.torokhov@gmail.com>
Change report_size from int to size_t in struct f54_data and update all
its usages. This avoids signed/unsigned comparison warnings when
comparing with size_t variables and matches the signature of
rmi_read_block() which takes size_t for length.
Also move the declaration of the loop variable 'i' into the 'for' loop
header.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f54.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index 850e1742c480..5d045ece3c2f 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -105,7 +105,7 @@ struct f54_data {
enum rmi_f54_report_type report_type;
u8 *report_data;
size_t max_report_size;
- int report_size;
+ size_t report_size;
int report_error;
bool is_busy;
@@ -355,7 +355,7 @@ static void rmi_f54_buffer_queue(struct vb2_buffer *vb)
}
if (f54->report_size > vb2_plane_size(vb, 0)) {
- dev_err(&f54->fn->dev, "Buffer too small (%lu < %d)\n",
+ dev_err(&f54->fn->dev, "Buffer too small (%lu < %zu)\n",
vb2_plane_size(vb, 0), f54->report_size);
state = VB2_BUF_STATE_ERROR;
goto data_done;
@@ -553,10 +553,9 @@ static void rmi_f54_work(struct work_struct *work)
struct f54_data *f54 = container_of(work, struct f54_data, work.work);
struct rmi_function *fn = f54->fn;
u8 fifo[2];
- int report_size;
+ size_t report_size;
u8 command;
int error;
- int i;
mutex_lock(&f54->data_mutex);
@@ -569,7 +568,7 @@ static void rmi_f54_work(struct work_struct *work)
}
if (report_size > f54->max_report_size) {
- dev_err(&fn->dev, "Report size %d exceeds buffer size %zu\n",
+ dev_err(&fn->dev, "Report size %zu exceeds buffer size %zu\n",
report_size, f54->max_report_size);
error = -EINVAL;
goto out;
@@ -596,8 +595,8 @@ static void rmi_f54_work(struct work_struct *work)
rmi_dbg(RMI_DEBUG_FN, &fn->dev, "Get report command completed, reading data\n");
- for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
- int size = min(F54_REPORT_DATA_SIZE, report_size - i);
+ 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);
fifo[0] = i & 0xff;
fifo[1] = i >> 8;
@@ -613,7 +612,7 @@ static void rmi_f54_work(struct work_struct *work)
F54_REPORT_DATA_OFFSET,
f54->report_data + i, size);
if (error) {
- dev_err(&fn->dev, "%s: read [%d bytes] returned %d\n",
+ dev_err(&fn->dev, "%s: read [%zu bytes] returned %d\n",
__func__, size, error);
goto out;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH 10/10] Input: synaptics-rmi4 - use __le16 for FIFO offset in F54
From: Dmitry Torokhov @ 2026-06-26 5:17 UTC (permalink / raw)
To: Bryam Vargas, Hans Verkuil; +Cc: linux-input, linux-kernel
In-Reply-To: <20260626051802.4033172-1-dmitry.torokhov@gmail.com>
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.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/rmi4/rmi_f54.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index 5d045ece3c2f..3eeb189be18b 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -15,6 +15,7 @@
#include <media/v4l2-ioctl.h>
#include <media/videobuf2-v4l2.h>
#include <media/videobuf2-vmalloc.h>
+#include <asm/byteorder.h>
#include "rmi_driver.h"
#define F54_NAME "rmi4_f54"
@@ -552,7 +553,6 @@ static void rmi_f54_work(struct work_struct *work)
{
struct f54_data *f54 = container_of(work, struct f54_data, work.work);
struct rmi_function *fn = f54->fn;
- u8 fifo[2];
size_t report_size;
u8 command;
int error;
@@ -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));
if (error) {
dev_err(&fn->dev, "Failed to set fifo start offset\n");
goto out;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
From: Dmitry Torokhov @ 2026-06-26 5:19 UTC (permalink / raw)
To: hexlabsecurity
Cc: linux-input, linux-kernel, Guenter Roeck, Benjamin Tissoires
In-Reply-To: <20260613-b4-disp-6721686c-v1-1-4d5bb84ee520@proton.me>
Hi Bryam,
On Sat, Jun 13, 2026 at 11:01:16PM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> rmi_f54_work() reads a diagnostics report from the device into
> f54->report_data, sizing the transfer with rmi_f54_get_report_size():
>
> report_size = rmi_f54_get_report_size(f54);
> ...
> for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) {
> int size = min(F54_REPORT_DATA_SIZE, report_size - i);
> ...
> rmi_read_block(.., f54->report_data + i, size);
> }
>
> report_data is allocated once at probe from F54's own electrode counts
> (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))),
> but rmi_f54_get_report_size() computes the size from
> drv_data->num_*_electrodes when those are set, i.e. from the F55
> function's electrode counts. Both counts come straight from device
> queries (F54 and F55 each report up to 255 electrodes) and nothing
> constrains the F55 counts to the F54 ones.
>
> A malicious or malfunctioning RMI4 device that reports larger F55
> electrode counts than its F54 counts makes report_size exceed the
> allocation, so the read loop writes past report_data (and the V4L2
> dequeue memcpy() then reads past it). On conforming hardware the F55
> configured electrodes are a subset of the F54 physical electrodes, so
> report_size never exceeds the buffer and well-behaved devices are
> unaffected.
>
> Record the allocation size and reject a report that does not fit,
> mirroring the existing zero-size check.
>
> Fixes: c762cc68b6a1 ("Input: synaptics-rmi4 - propagate correct number of rx and tx electrodes to F54")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Thanks for the patch. It makes sense, but there are more changes needed
in F54. I incorporated it in the series I just posted, would appreviate
if you could review it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 05/10] Input: synaptics-rmi4 - block s_input when F54 queue is busy
From: sashiko-bot @ 2026-06-26 5:27 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-5-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Using `devm_kzalloc` for a structure containing a V4L2 `video_device` with `video_device_release_empty` leads to a Use-After-Free on unbind.
--
commit 49068cdcddfc12eacb30d46e9f92bd95fd14648f
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - block s_input when F54 queue is busy
Changing the input (diagnostic report type) mid-stream changes the report size.
Since V4L2 buffers are allocated based on the size at stream start, changing
the input while streaming could lead to a heap buffer overflow if the new size
is larger than the allocated buffers.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index aebe74d2032cd..e86dfc9ce7d9a 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -445,7 +445,12 @@ static int rmi_f54_set_input(struct f54_data *f54, unsigned int i)
>
> static int rmi_f54_vidioc_s_input(struct file *file, void *priv, unsigned int i)
> {
> - return rmi_f54_set_input(video_drvdata(file), i);
> + struct f54_data *f54 = video_drvdata(file);
[Severity: High]
This isn't a bug introduced by this patch, but could this f54 pointer
reference freed memory during a device unbind?
In rmi_f54_probe(), the f54_data structure is allocated with devm_kzalloc():
f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);
This ties its lifetime to the physical device rather than the V4L2 character
device reference count. The release callback for the video device is also set
to a dummy function in rmi_f54_video_device:
.release = video_device_release_empty,
During unbind, rmi_f54_remove() calls video_unregister_device(&f54->vdev) but
returns immediately. This unregisters the V4L2 device without synchronously
waiting for userspace to close open file descriptors, leaving ongoing V4L2
file descriptors pointing at memory that is about to be freed by devres.
If a userspace application keeps the V4L2 device node open, would subsequent
operations or closes (such as vb2_fop_release) attempt to access the vdev and
queue embedded within this already-freed f54_data memory?
> +
> + if (vb2_is_busy(&f54->queue))
> + return -EBUSY;
> +
> + return rmi_f54_set_input(f54, i);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 04/10] Input: synaptics-rmi4 - cancel delayed work on F54 remove
From: sashiko-bot @ 2026-06-26 5:28 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260626051802.4033172-4-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The `video_device` structure is embedded in a `devm`-allocated container with an empty release callback, leading to a Use-After-Free if the V4L2 device file is kept open after unbind.
- [High] Concurrent V4L2 ioctls are not synchronized or aborted during `rmi_f54_remove()`, leading to a Use-After-Free when an active ioctl times out or accesses a destroyed workqueue.
--
commit 169f0c9cee8746030206895c2135191d57259b56
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - cancel delayed work on F54 remove
This commit ensures that pending delayed work is cancelled before destroying
the workqueue in rmi_f54_remove() to prevent a potential Use-After-Free. It
fixes a race condition where a timer handler might run after the workqueue
is destroyed or the devm-allocated f54 structure is freed.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -749,6 +749,7 @@ static void rmi_f54_remove(struct rmi_function *fn)
>
> video_unregister_device(&f54->vdev);
[Severity: High]
This is a pre-existing issue, but the video_device structure is embedded in
a devm-allocated container with an empty release callback. This circumvents
the V4L2 core's mechanism to defer freeing the structure until all file
descriptors are closed:
drivers/input/rmi4/rmi_f54.c:rmi_f54_video_device {
...
.release = video_device_release_empty,
};
In rmi_f54_probe():
f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);
If a userspace application holds the V4L2 device file descriptor open while
an unbind occurs, video_unregister_device() returns and devm immediately
frees f54_data. Closing the file descriptor later or issuing ioctls will
access the freed f54_data container. Could this lead to a Use-After-Free?
> v4l2_device_unregister(&f54->v4l2);
> + cancel_delayed_work_sync(&f54->work);
> destroy_workqueue(f54->workqueue);
[Severity: High]
This isn't a bug introduced by this patch, but does this teardown sequence
destroy resources locklessly while V4L2 ioctls can still be executing?
During rmi_f54_remove(), we unregister the video device, cancel the work,
and destroy the workqueue without acquiring f54->lock.
If a concurrent VIDIOC_QBUF ioctl executing rmi_f54_buffer_queue() is
blocked:
drivers/input/rmi4/rmi_f54.c:rmi_f54_buffer_queue() {
...
if (!wait_for_completion_timeout(&f54->cmd_done,
msecs_to_jiffies(1000))) {
...
}
The remove() function cancels the delayed work (so cmd_done never completes)
and returns, allowing devm to free f54_data. When the timeout expires in the
blocked ioctl, it will access the freed f54 pointer.
Additionally, a concurrent ioctl might attempt to queue work:
drivers/input/rmi4/rmi_f54.c:rmi_f54_request_report() {
...
queue_delayed_work(f54->workqueue, &f54->work, 0);
...
}
If this runs right after rmi_f54_remove() has destroyed the workqueue, could
it cause a crash? Should the teardown sequence serialize with active V4L2
ioctls?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 08/10] Input: synaptics-rmi4 - F54 style and typo fixes
From: sashiko-bot @ 2026-06-26 5:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260626051802.4033172-8-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The newly added comments incorrectly describe the lock coverage for `status_mutex` and `data_mutex`.
Pre-existing issues:
- [High] Embedding a `struct video_device` in a `devm_kzalloc`-managed structure causes a use-after-free on device unbind.
--
commit 7a52e1aa5971437b387ed577aeae2fd8da17b2ba
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - F54 style and typo fixes
This commit cleans up style issues in rmi_f54.c reported by checkpatch.pl.
It converts bit shifts to BIT() macros, aligns assignments and arguments,
fixes typos, and adds mutex documentation comments.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 93526feea5636..850e1742c480a 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
[ ... ]
> @@ -109,8 +109,8 @@ struct f54_data {
> int report_error;
>
> bool is_busy;
> - struct mutex status_mutex;
> - struct mutex data_mutex;
> + struct mutex status_mutex; /* Protects is_busy and command state */
> + struct mutex data_mutex; /* Protects report_data buffer */
[Severity: Low]
Are these comments accurate regarding the lock coverage?
Looking at rmi_f54_request_report() and rmi_f54_work(), it appears that
is_busy, cmd_done, and timeout are explicitly modified while holding
data_mutex, not status_mutex.
status_mutex appears to be used to serialize calls to rmi_f54_buffer_queue()
instead.
[ ... ]
> @@ -709,7 +709,7 @@ static int rmi_f54_probe(struct rmi_function *fn)
> f54->max_report_size = array3_size(tx, rx, sizeof(u16));
> f54->report_data = devm_kzalloc(&fn->dev, f54->max_report_size,
> GFP_KERNEL);
> - if (f54->report_data == NULL)
> + if (!f54->report_data)
> return -ENOMEM;
>
> INIT_DELAYED_WORK(&f54->work, rmi_f54_work);
[Severity: High]
This isn't a bug introduced by this patch, but does allocating the f54_data
structure with devm_kzalloc() earlier in rmi_f54_probe() lead to a
use-after-free on device unbind?
If a userspace process opens the v4l2 device node, and concurrently the
physical device is hot-unplugged or unbound via sysfs, devm will
automatically free the f54_data memory.
However, since the release callback for the embedded struct video_device is
set to video_device_release_empty, the v4l2 core retains a reference to the
embedded video_device.
Could it then access the already-freed memory during ioctls or when the last
file descriptor is closed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH 09/10] Input: synaptics-rmi4 - change report_size to size_t in F54
From: sashiko-bot @ 2026-06-26 5:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260626051802.4033172-9-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The v4l2 device structure (vdev, queue, and lock) is embedded within devm-allocated f54_data, causing a use-after-free and locking of a freed mutex on device close if userspace holds the device open past removal.
--
commit f2033554c93a59d85d1cecf56a498ef9493e4022
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - change report_size to size_t in F54
Change report_size from int to size_t in struct f54_data and update all
its usages. This avoids signed/unsigned comparison warnings when
comparing with size_t variables and matches the signature of
rmi_read_block() which takes size_t for length.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 850e1742c480a..5d045ece3c2f2 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -105,7 +105,7 @@ struct f54_data {
> enum rmi_f54_report_type report_type;
> u8 *report_data;
> size_t max_report_size;
> - int report_size;
> + size_t report_size;
> int report_error;
>
> bool is_busy;
[Severity: High]
This is a pre-existing issue, but could embedding the V4L2 device structures
inside the devm-allocated f54_data lead to a use-after-free?
If a user holds the /dev/videoX node open during driver unbind,
rmi_f54_remove() completes and the devm framework frees the f54_data memory:
drivers/input/rmi4/rmi_f54.c:rmi_f54_remove() {
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);
}
When the user later closes the file descriptor, it triggers the V4L2
release path. v4l2_release() calling vb2_fop_release() accesses the
embedded queue and attempts to acquire the vdev->queue->lock, which
points to the freed f54->lock:
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;
f54->vdev.v4l2_dev = &f54->v4l2;
f54->vdev.lock = &f54->lock;
...
}
Should the video_device be dynamically allocated and reference counted rather
than relying on devm management?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=9
^ permalink raw reply
* 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
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