* Re: [PATCH 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: Joshua Crofts @ 2026-06-08 6:37 UTC (permalink / raw)
To: Maxwell Doose
Cc: Sanjay Chitroda, Jiri Kosina, Jonathan Cameron,
Srinivas Pandruvada, David Lechner, Nuno Sá, Andy Shevchenko,
linux-input, linux-iio, linux-kernel
In-Reply-To: <CAKqfh0Efa1+VShSW76tqaV8XtAZToRfsCy0cTi5sXOUm_nwLiw@mail.gmail.com>
On Sun, 7 Jun 2026 at 22:54, Maxwell Doose <m32285159@gmail.com> wrote:
>
> On Sat, Jun 6, 2026 at 7:19 AM Sanjay Chitroda
> <sanjayembeddedse@gmail.com> wrote:
> >
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Prefer 'u32' instead of bare 'unsigned' variable to improve code
> > clarity and consistency with kernel style.
> >
> > Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > ---
> > drivers/iio/light/hid-sensor-als.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
>
> Do we *need* u32 though? Usually these types are for places where we
> require specific bit-widths for a reason (e.g., reading a hardware
> register) but I'm not sure that's the case here. I could be totally
> wrong, in that case please correct me but otherwise I unfortunately
> don't see much value in this. That's just my personal opinion though,
> Jonathan may think otherwise.
Aside from the array of usage ids that are u32 defined here:
https://elixir.bootlin.com/linux/v7.1-rc6/source/drivers/iio/light/hid-sensor-als.c#L46
there are additional structs used in the HID drivers that take u32 (I
had a similar
patch moving `unsigned` to `unsigned int`, but it was recommended to use the
types that the structs use, hence u32).
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: Joshua Crofts @ 2026-06-08 6:41 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260606-6-june-hid-iio-correct-usage-id-v1-3-dd4a6820b674@gmail.com>
On Sat, 6 Jun 2026 at 14:19, Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
>
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> Prefer 'u32' instead of bare 'unsigned' variable to improve code
> clarity and consistency with kernel style.
>
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---
> drivers/iio/light/hid-sensor-als.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index d72e260b8266..ae2fda8dc500 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -241,7 +241,7 @@ static const struct iio_info als_info = {
>
> /* Callback handler to send event after all samples are received and captured */
> static int als_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
Code-wise fine, however looking at this function, usage_id is never
actually used,
though not sure whether removing it would break the ABI... up to you
to check it.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Linus Walleij @ 2026-06-08 8:49 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
On Sun, May 10, 2026 at 7:21 AM Ethan Nelson-Moore
<enelsonmoore@gmail.com> wrote:
> To improve future maintainability, change the interrupt handling for
> mach-footbridge to use sparse IRQs.
>
> Since the number of possible interrupts is already fixed and relatively
> small, just make it use all legacy interrupts preallocated using the
> .nr_irqs field in the machine descriptor, rather than actually
> allocating domains on the fly.
>
> Many files had to be adjusted to include <mach/irqs.h>
> explicitly because it is no longer implicitly included with sparse
> IRQs.
>
> Description adapted from commit c78a41fc04f0 ("ARM: s3c24xx: convert
> to sparse-irq").
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Have you tested this on real hardware?
The commit doesn't really say.
I might have to dig out my NetWinder to test this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] HID: uhid: convert to hid_safe_input_report()
From: Lee Jones @ 2026-06-08 8:59 UTC (permalink / raw)
To: Carlos Llamas
Cc: David Rheinsberg, Jiri Kosina, Benjamin Tissoires, kernel-team,
linux-kernel, stable, open list:UHID USERSPACE HID IO DRIVER
In-Reply-To: <20260606181552.3095967-1-cmllamas@google.com>
On Sat, 06 Jun 2026, Carlos Llamas wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), added a check in hid_report_raw_event() to reject
> reports if the received data size is smaller than expected. This was
> intended to prevent OOB errors by no longer allowing zeroing-out of
> shorter reports due to the lack of buffer size information.
>
> However, this leads to regressions in hid_report_raw_event(), where
> shorter than expected reports are rejected, even though their buffers
> are sufficiently large to be zero-padded.
>
> To solve this issue, Benjamin introduced a safer alternative in commit
> 206342541fc8 ("HID: core: introduce hid_safe_input_report()"), which
> forwards the buffer size and allows hid_report_raw_event() to safely
> zero-pad the data.
>
> Convert uhid to use hid_safe_input_report() and pass UHID_DATA_MAX as
> the buffer size. This prevents the reported regressions [1], allowing
> hid core to zero-pad the shorter reports safely as expected.
>
> Cc: stable@vger.kernel.org
> Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> Closes: https://lore.kernel.org/all/ahsh0UtTX6e0ZeHa@google.com/ [1]
> Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Lee Jones <lee@kernel.org>
> ---
> drivers/hid/uhid.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
> index 524b53a3c87b..37b60c3aaf66 100644
> --- a/drivers/hid/uhid.c
> +++ b/drivers/hid/uhid.c
> @@ -595,8 +595,8 @@ static int uhid_dev_input(struct uhid_device *uhid, struct uhid_event *ev)
> if (!READ_ONCE(uhid->running))
> return -EINVAL;
>
> - hid_input_report(uhid->hid, HID_INPUT_REPORT, ev->u.input.data,
> - min_t(size_t, ev->u.input.size, UHID_DATA_MAX), 0);
> + hid_safe_input_report(uhid->hid, HID_INPUT_REPORT, ev->u.input.data, UHID_DATA_MAX,
> + min_t(size_t, ev->u.input.size, UHID_DATA_MAX), 0);
>
> return 0;
> }
> @@ -606,8 +606,8 @@ static int uhid_dev_input2(struct uhid_device *uhid, struct uhid_event *ev)
> if (!READ_ONCE(uhid->running))
> return -EINVAL;
>
> - hid_input_report(uhid->hid, HID_INPUT_REPORT, ev->u.input2.data,
> - min_t(size_t, ev->u.input2.size, UHID_DATA_MAX), 0);
> + hid_safe_input_report(uhid->hid, HID_INPUT_REPORT, ev->u.input2.data, UHID_DATA_MAX,
> + min_t(size_t, ev->u.input2.size, UHID_DATA_MAX), 0);
>
> return 0;
> }
> --
> 2.54.0.1032.g2f8565e1d1-goog
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen support
From: Konrad Dybcio @ 2026-06-08 9:58 UTC (permalink / raw)
To: Pradyot Kumar Nayak, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Peng, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, Abel Vesa
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel
In-Reply-To: <20260603-arm64-dts-glymur-crd-add-reset-gpio-to-v3-2-3453ef577bcf@oss.qualcomm.com>
On 6/3/26 5:11 AM, Pradyot Kumar Nayak wrote:
> The touchscreen module on Glymur/Mahua CRDs is different from
> the one used on Hamoa CRDs and requires the reset-gpios to be wired to
> the device. Without this in place the reset line will remain
> permanently asserted during resume leaving the device offline and causing
> all I2C transactions to fail with -ENXIO.
>
> i2c_hid_of 3-0038: failed to change power setting.
> i2c_hid_of 3-0038: PM: dpm_run_callback():
> i2c_hid_core_pm_resume [i2c_hid] returns -6
> i2c_hid_of 3-0038: PM: failed to resume async: error -6
>
> The touchscreen on Glymur/Mahua-CRD is a focaltech ft3d81,
> which is hardware-compatible with the ft8112.
> we have added the required change in DT.
>
> Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen")
> Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [linux-5.10.y 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
From: Lee Jones @ 2026-06-08 10:02 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Viresh Kumar, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, linux-input, linux-kernel,
greybus-dev, linux-staging
Cc: stable, Vicki Pfau, Jiri Kosina
From: Vicki Pfau <vi@endrift.com>
hid_warn_ratelimited() is needed. Add the others as part of the block.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
(cherry picked from commit 1d64624243af8329b4b219d8c39e28ea448f9929)
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit 3dc96d0b81eae69bf71e129e3f331c982c5c70fd)
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit 023f03a90d4fcc809ffbfc70e6927ce9889b2578)
Signed-off-by: Lee Jones <lee@kernel.org>
---
include/linux/hid.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 03627c96d814..ab56fffb74a2 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1217,4 +1217,15 @@ do { \
#define hid_dbg_once(hid, fmt, ...) \
dev_dbg_once(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_err_ratelimited(hid, fmt, ...) \
+ dev_err_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_notice_ratelimited(hid, fmt, ...) \
+ dev_notice_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_warn_ratelimited(hid, fmt, ...) \
+ dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_info_ratelimited(hid, fmt, ...) \
+ dev_info_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_dbg_ratelimited(hid, fmt, ...) \
+ dev_dbg_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+
#endif
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-5.10.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: Lee Jones @ 2026-06-08 10:02 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Viresh Kumar, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, linux-input, linux-kernel,
greybus-dev, linux-staging
Cc: stable, Benjamin Tissoires, Jiri Kosina, Sasha Levin
In-Reply-To: <20260608100236.2781796-1-lee@kernel.org>
From: Benjamin Tissoires <bentiss@kernel.org>
[ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ]
commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
bogus memset()") enforced the provided data to be at least the size of
the declared buffer in the report descriptor to prevent a buffer
overflow. However, we can try to be smarter by providing both the buffer
size and the data size, meaning that hid_report_raw_event() can make
better decision whether we should plaining reject the buffer (buffer
overflow attempt) or if we can safely memset it to 0 and pass it to the
rest of the stack.
Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 509c2605065004fc4cd86ee50a9350d402785307)
[Lee: Backported to linux-6.12.y and beyond]
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit f9393998660f146970047bda31526aeb96190f28)
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 29 ++++++++++++++++++++++-------
drivers/hid/hid-gfrm.c | 4 ++--
drivers/hid/hid-logitech-hidpp.c | 2 +-
drivers/hid/hid-multitouch.c | 2 +-
drivers/hid/hid-primax.c | 2 +-
drivers/hid/hid-vivaldi.c | 2 +-
drivers/hid/wacom_sys.c | 6 +++---
drivers/staging/greybus/hid.c | 2 +-
include/linux/hid.h | 4 ++--
9 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index aa9ae6ccb28a..c73f4ac16fdf 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1775,8 +1775,8 @@ int __hid_request(struct hid_device *hid, struct hid_report *report,
}
EXPORT_SYMBOL_GPL(__hid_request);
-int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
- int interrupt)
+int hid_report_raw_event(struct hid_device *hid, int type, u8 *data,
+ size_t bufsize, u32 size, int interrupt)
{
struct hid_report_enum *report_enum = hid->report_enum + type;
struct hid_report *report;
@@ -1784,16 +1784,24 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
int max_buffer_size = HID_MAX_BUFFER_SIZE;
unsigned int a;
u32 rsize, csize = size;
+ size_t bsize = bufsize;
u8 *cdata = data;
int ret = 0;
report = hid_get_report(report_enum, data);
if (!report)
- goto out;
+ return 0;
+
+ if (unlikely(bsize < csize)) {
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ report->id, csize, bsize);
+ return -EINVAL;
+ }
if (report_enum->numbered) {
cdata++;
csize--;
+ bsize--;
}
rsize = hid_compute_report_size(report);
@@ -1806,9 +1814,15 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
else if (rsize > max_buffer_size)
rsize = max_buffer_size;
+ if (bsize < rsize) {
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ report->id, rsize, bsize);
+ return -EINVAL;
+ }
+
if (csize < rsize) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
- csize, rsize);
+ csize, rsize);
memset(cdata + csize, 0, rsize - csize);
}
@@ -1817,7 +1831,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
if (hid->claimed & HID_CLAIMED_HIDRAW) {
ret = hidraw_report_event(hid, data, size);
if (ret)
- goto out;
+ return ret;
}
if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
@@ -1830,7 +1844,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_report_event(hid, report);
-out:
+
return ret;
}
EXPORT_SYMBOL_GPL(hid_report_raw_event);
@@ -1851,6 +1865,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, int i
struct hid_report_enum *report_enum;
struct hid_driver *hdrv;
struct hid_report *report;
+ size_t bufsize = size;
int ret = 0;
if (!hid)
@@ -1889,7 +1904,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, int i
goto unlock;
}
- ret = hid_report_raw_event(hid, type, data, size, interrupt);
+ ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
unlock:
up(&hid->driver_input_lock);
diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
index 699186ff2349..d2a56bf92b41 100644
--- a/drivers/hid/hid-gfrm.c
+++ b/drivers/hid/hid-gfrm.c
@@ -66,7 +66,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
switch (data[1]) {
case GFRM100_SEARCH_KEY_DOWN:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_dn,
- sizeof(search_key_dn), 1);
+ sizeof(search_key_dn), sizeof(search_key_dn), 1);
break;
case GFRM100_SEARCH_KEY_AUDIO_DATA:
@@ -74,7 +74,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
case GFRM100_SEARCH_KEY_UP:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_up,
- sizeof(search_key_up), 1);
+ sizeof(search_key_up), sizeof(search_key_up), 1);
break;
default:
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 98562a0ed0c3..d31f2737b13d 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3176,7 +3176,7 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
memcpy(&consumer_report[1], &data[3], 4);
/* We are called from atomic context */
hid_report_raw_event(hidpp->hid_dev, HID_INPUT_REPORT,
- consumer_report, 5, 1);
+ consumer_report, sizeof(consumer_report), 5, 1);
return 1;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 948bd59ab5d2..c3bcc23d7c7c 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -449,7 +449,7 @@ static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
- size, 0);
+ size, size, 0);
if (ret)
dev_warn(&hdev->dev, "failed to report feature\n");
}
diff --git a/drivers/hid/hid-primax.c b/drivers/hid/hid-primax.c
index 1e6413d07cae..16e2a811eda9 100644
--- a/drivers/hid/hid-primax.c
+++ b/drivers/hid/hid-primax.c
@@ -44,7 +44,7 @@ static int px_raw_event(struct hid_device *hid, struct hid_report *report,
data[0] |= (1 << (data[idx] - 0xE0));
data[idx] = 0;
}
- hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, 0);
+ hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, size, 0);
return 1;
default: /* unknown report */
diff --git a/drivers/hid/hid-vivaldi.c b/drivers/hid/hid-vivaldi.c
index d57ec1767037..fdfea1355ee7 100644
--- a/drivers/hid/hid-vivaldi.c
+++ b/drivers/hid/hid-vivaldi.c
@@ -126,7 +126,7 @@ static void vivaldi_feature_mapping(struct hid_device *hdev,
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, report_data,
- report_len, 0);
+ report_len, report_len, 0);
if (ret) {
dev_warn(&hdev->dev, "failed to report feature %d\n",
field->report->id);
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index abbfb53bb7dc..09b513812fff 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -79,7 +79,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
int err;
size = kfifo_out(fifo, buf, sizeof(buf));
- err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
+ err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
if (err) {
hid_warn(hdev, "%s: unable to flush event due to error %d\n",
__func__, err);
@@ -324,7 +324,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n && features->type == HID_GENERIC) {
ret = hid_report_raw_event(hdev,
- HID_FEATURE_REPORT, data, n, 0);
+ HID_FEATURE_REPORT, data, n, n, 0);
} else if (ret == 2 && features->type != HID_GENERIC) {
features->touch_max = data[1];
} else {
@@ -385,7 +385,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n) {
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT,
- data, n, 0);
+ data, n, n, 0);
} else {
hid_warn(hdev, "%s: could not retrieve sensor offsets\n",
__func__);
diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
index ed706f39e87a..d68f60da0dd1 100644
--- a/drivers/staging/greybus/hid.c
+++ b/drivers/staging/greybus/hid.c
@@ -201,7 +201,7 @@ static void gb_hid_init_report(struct gb_hid *ghid, struct hid_report *report)
* we just need to setup the input fields, so using
* hid_report_raw_event is safe.
*/
- hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, size, 1);
+ hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, ghid->bufsize, size, 1);
}
static void gb_hid_init_reports(struct gb_hid *ghid)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index ab56fffb74a2..aaae2fecd4ae 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1175,8 +1175,8 @@ static inline u32 hid_report_len(struct hid_report *report)
return DIV_ROUND_UP(report->size, 8) + (report->id > 0);
}
-int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
- int interrupt);
+int hid_report_raw_event(struct hid_device *hid, int type, u8 *data,
+ size_t bufsize, u32 size, int interrupt);
/* HID quirks API */
unsigned long hid_lookup_quirk(const struct hid_device *hdev);
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-5.10.y 3/3] HID: core: Fix size_t specifier in hid_report_raw_event()
From: Lee Jones @ 2026-06-08 10:02 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Viresh Kumar, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, linux-input, linux-kernel,
greybus-dev, linux-staging
Cc: stable, Nathan Chancellor, Miguel Ojeda, Linus Torvalds,
Sasha Levin
In-Reply-To: <20260608100236.2781796-1-lee@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit 4d3a2a466b8d68d852a1f3bbf11204b718428dc4 ]
When building for 32-bit platforms, for which 'size_t' is
'unsigned int', there are warnings around using the incorrect format
specifier to print bsize in hid_report_raw_event():
drivers/hid/hid-core.c:2054:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~~
| %zu
2054 | report->id, csize, bsize);
| ^~~~~
drivers/hid/hid-core.c:2076:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~~
| %zu
2076 | report->id, rsize, bsize);
| ^~~~~
Use the proper 'size_t' format specifier, '%zu', to clear up the
warnings.
Cc: stable@vger.kernel.org
Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/20260516020430.110135-1-ojeda@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3ab135238832446399614e7a4bb796d620717806)
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit 0f77a993b5426cca1b046c9ab4b2f8355a4d45dc)
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit 70333a8f866aad8cbd6956e2ec4ace159fa4243b)
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c73f4ac16fdf..918c66d5bc93 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1793,7 +1793,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data,
return 0;
if (unlikely(bsize < csize)) {
- hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %zu)\n",
report->id, csize, bsize);
return -EINVAL;
}
@@ -1815,7 +1815,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data,
rsize = max_buffer_size;
if (bsize < rsize) {
- hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %zu)\n",
report->id, rsize, bsize);
return -EINVAL;
}
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* Re: [linux-5.10.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: sashiko-bot @ 2026-06-08 10:30 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260608100236.2781796-2-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch introduces `bufsize` to `hid_report_raw_event` to allow safe zero-padding of short reports. However, it passes `size` (the received data length) instead of the actual buffer capacity in key call sites. Most notably, in `wacom_wac_queue_flush()`, the buffer has a fixed capacity (`u8 buf[WACOM_PKGLEN_MAX]`), but `size` is incorrectly passed as `bufsize`. In `hid_input_report()`, `bufsize` is hardcoded to `size`. This guarantees that `bsize == csize`, meaning any short report (`csize < rsize`) will unconditionally trigger the `if (bsize < rsize)` error check and be dropped with `-EINVAL`. The intended zero-padding mitigation (`memset`) is therefore completely unreachable for these paths.
- [Low] Format specifier mismatch in error logs: `bsize` is of type `size_t` but is printed using `%ld` instead of `%zu`. Additionally, unsigned 32-bit variables (`report->id`, `csize`, `rsize`) are printed using the signed `%d` specifier instead of `%u`.
--
commit acf01e17656800b6ab94002473e3b03a8259b323
Author: Benjamin Tissoires <bentiss@kernel.org>
HID: pass the buffer size to hid_report_raw_event
This commit updates hid_report_raw_event to accept both the buffer size and
the data size. This allows the function to make a better decision about
whether to reject a buffer to prevent an overflow, or to safely pad it with
zeroes.
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index aa9ae6ccb28a8..c73f4ac16fdf2 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1784,16 +1784,24 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
> int max_buffer_size = HID_MAX_BUFFER_SIZE;
> unsigned int a;
> u32 rsize, csize = size;
> + size_t bsize = bufsize;
> u8 *cdata = data;
> int ret = 0;
>
> report = hid_get_report(report_enum, data);
> if (!report)
> - goto out;
> + return 0;
> +
> + if (unlikely(bsize < csize)) {
> + hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
> + report->id, csize, bsize);
[Severity: Low]
This isn't a bug, but could the format specifiers cause compiler warnings on
32-bit architectures? bsize is a size_t and csize and report->id are unsigned,
so should they use %zu and %u instead of %ld and %d?
> + return -EINVAL;
> + }
>
> if (report_enum->numbered) {
> cdata++;
> csize--;
> + bsize--;
> }
>
> rsize = hid_compute_report_size(report);
> @@ -1806,9 +1814,15 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, u32 size,
> else if (rsize > max_buffer_size)
> rsize = max_buffer_size;
>
> + if (bsize < rsize) {
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
> + report->id, rsize, bsize);
[Severity: Low]
Similarly here, should this use %u for report->id and rsize, and %zu for
bsize instead of %d and %ld?
> + return -EINVAL;
> + }
[Severity: High]
If callers pass the incoming data length as both the size and bufsize
arguments, does this mean bsize will equal csize?
If bsize == csize, and we receive a short report where csize < rsize,
wouldn't the bsize < rsize check just above this evaluate to true and return
-EINVAL? Does this make the memset padding logic unreachable for those paths?
> +
> if (csize < rsize) {
> dbg_hid("report %d is too short, (%d < %d)\n", report->id,
> - csize, rsize);
> + csize, rsize);
> memset(cdata + csize, 0, rsize - csize);
> }
>
> @@ -1851,6 +1865,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, int i
> struct hid_report_enum *report_enum;
> struct hid_driver *hdrv;
> struct hid_report *report;
> + size_t bufsize = size;
> int ret = 0;
>
> if (!hid)
> @@ -1889,7 +1904,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, u32 size, int i
> goto unlock;
> }
>
> - ret = hid_report_raw_event(hid, type, data, size, interrupt);
> + ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
[Severity: High]
Does setting bufsize directly to size here defeat the padding mitigation?
This hardcodes bufsize to the received payload length, which propagates the
drop behavior to all transport drivers relying on hid_input_report().
[ ... ]
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index abbfb53bb7dc9..09b513812fff1 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -79,7 +79,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
> int err;
>
> size = kfifo_out(fifo, buf, sizeof(buf));
> - err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
> + err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
[Severity: High]
Could we pass sizeof(buf) here instead of size?
Since buf has a fixed capacity of WACOM_PKGLEN_MAX, passing size for
bufsize prevents the core from safely padding short reports and will
instead cause them to be dropped.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608100236.2781796-2-lee@kernel.org?part=1
^ permalink raw reply
* Re: [PATCH v3] HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver
From: Hans de Goede @ 2026-06-08 11:48 UTC (permalink / raw)
To: 谢致邦 (XIE Zhibang), linux-input,
dmitry.torokhov, bentiss
Cc: dianders, jikos, linux-kernel, sashiko-bot, sashiko-reviews,
superm1
In-Reply-To: <tencent_E0B44D3DB1D67A7F20CF82ED6D3F0881FE08@qq.com>
Hi,
On 6-Jun-26 6:06 PM, 谢致邦 (XIE Zhibang) wrote:
> Move the _DSM call that gets the HID descriptor address from
> i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI
> and the new PRP0001 driver can use it. While refactoring, move the
> blacklist check and the _DSM call to the top of probe() to avoid a
> pointless alloc when the device is blacklisted or does not implement the
> _DSM.
>
> Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3,
> are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but
> lack "hid-descr-addr" from the _DSD and provide the HID descriptor
> address only through an ACPI _DSM. The OF driver fails to probe them
> because it requires hid-descr-addr. Add a new driver that handles these
> devices by calling the shared _DSM helper.
>
> Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
Thank you for the new version.
> ---
> v2: Name the unused parameter and document why
> acpi_device_fix_up_power() is skipped.
> v3: Add a dev_warn() asking users to contact vendors for firmware
> updates, and use existing locals in devm_kzalloc() and
> acpi_device_fix_up_power().
>
> drivers/hid/i2c-hid/Kconfig | 18 ++++
> drivers/hid/i2c-hid/Makefile | 1 +
> drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c | 98 ++++++++++++++++++++++
> drivers/hid/i2c-hid/i2c-hid-acpi.c | 52 ++++--------
> drivers/hid/i2c-hid/i2c-hid-acpi.h | 32 +++++++
> 5 files changed, 163 insertions(+), 38 deletions(-)
> create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
> create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.h
>
> diff --git a/drivers/hid/i2c-hid/Kconfig b/drivers/hid/i2c-hid/Kconfig
> index e8d51f410cc1..7db8b2abff78 100644
> --- a/drivers/hid/i2c-hid/Kconfig
> +++ b/drivers/hid/i2c-hid/Kconfig
> @@ -22,6 +22,24 @@ config I2C_HID_ACPI
> will be called i2c-hid-acpi. It will also build/depend on the
> module i2c-hid.
>
> +config I2C_HID_ACPI_PRP0001
> + tristate "Driver for PRP0001 devices missing hid-descr-addr"
> + depends on ACPI
> + depends on DRM || !DRM
> + select I2C_HID_CORE
> + help
> + Say Y here if you want support for I2C HID touchpads that
> + are declared with _HID "PRP0001" and _DSD compatible
> + "hid-over-i2c" but lack the "hid-descr-addr" property from
> + the _DSD. The HID descriptor address is instead provided
> + through an ACPI _DSM. Known affected devices include the
> + Lenovo KaiTian N60d and Inspur CP300L3.
> +
> + If unsure, say N.
> +
> + This support is also available as a module. If so, the
> + module will be called i2c-hid-acpi-prp0001.
> +
> config I2C_HID_OF
> tristate "HID over I2C transport layer Open Firmware driver"
> # No "depends on OF" because this can also be used for manually
> diff --git a/drivers/hid/i2c-hid/Makefile b/drivers/hid/i2c-hid/Makefile
> index 55bd5e0f35af..da420c1a8ec6 100644
> --- a/drivers/hid/i2c-hid/Makefile
> +++ b/drivers/hid/i2c-hid/Makefile
> @@ -9,6 +9,7 @@ i2c-hid-objs = i2c-hid-core.o
> i2c-hid-$(CONFIG_DMI) += i2c-hid-dmi-quirks.o
>
> obj-$(CONFIG_I2C_HID_ACPI) += i2c-hid-acpi.o
> +obj-$(CONFIG_I2C_HID_ACPI_PRP0001) += i2c-hid-acpi-prp0001.o
> obj-$(CONFIG_I2C_HID_OF) += i2c-hid-of.o
> obj-$(CONFIG_I2C_HID_OF_ELAN) += i2c-hid-of-elan.o
> obj-$(CONFIG_I2C_HID_OF_GOODIX) += i2c-hid-of-goodix.o
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
> new file mode 100644
> index 000000000000..b54370a938ab
> --- /dev/null
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * HID over I2C driver for PRP0001 devices missing hid-descr-addr
> + *
> + * Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, use
> + * _HID "PRP0001" with _DSD compatible "hid-over-i2c" but lack "hid-descr-addr"
> + * from the _DSD. The HID descriptor address is provided only through an ACPI
> + * _DSM. The TPD0 node in the DSDT shows _DSM Function 1 returning 0x20.
> + *
> + * Copyright (C) 2026 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +
> +#include "i2c-hid.h"
> +#include "i2c-hid-acpi.h"
> +
> +static int i2c_hid_acpi_prp0001_power_up(struct i2chid_ops *ops)
> +{
> + /* give the device time to power up */
> + msleep(250);
> + return 0;
> +}
> +
> +static struct i2chid_ops i2c_hid_acpi_prp0001_ops = {
> + .power_up = i2c_hid_acpi_prp0001_power_up,
> + /*
> + * No .restore_sequence needed: the _DSM on these devices returns a
> + * constant (0x20) with no side effects, unlike some PNP0C50 _DSM
> + * implementations that switch the hardware between PS/2 and I2C modes.
> + */
> +};
> +
> +static int i2c_hid_acpi_prp0001_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct acpi_device *adev;
> + u16 hid_descriptor_address;
> + int ret;
> +
> + /* If hid-descr-addr is present, let i2c-hid-of handle it */
> + if (device_property_present(dev, "hid-descr-addr"))
> + return -ENODEV;
> +
> + adev = ACPI_COMPANION(dev);
> + if (!adev)
> + return -ENODEV;
> +
> + ret = i2c_hid_acpi_get_descriptor(adev);
> + if (ret < 0)
> + return ret;
> + dev_warn(dev,
> + "hid-descr-addr device property NOT found, using ACPI _DSM fallback. Contact vendor for firmware update!\n");
> + hid_descriptor_address = ret;
> +
> + /*
> + * No acpi_device_fix_up_power() needed: TPD0 has no _PS0, _PS3, _PSC
> + * or _PRx methods and follows I2C bus power.
> + */
> + return i2c_hid_core_probe(client, &i2c_hid_acpi_prp0001_ops,
> + hid_descriptor_address, 0);
> +}
> +
> +static const struct of_device_id i2c_hid_acpi_prp0001_of_match[] = {
> + { .compatible = "hid-over-i2c" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, i2c_hid_acpi_prp0001_of_match);
> +
> +static const struct i2c_device_id i2c_hid_acpi_prp0001_id[] = {
> + { .name = "hid-over-i2c" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, i2c_hid_acpi_prp0001_id);
> +
> +static struct i2c_driver i2c_hid_acpi_prp0001_driver = {
> + .driver = {
> + .name = "i2c_hid_acpi_prp0001",
> + .pm = &i2c_hid_core_pm,
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> + .of_match_table = of_match_ptr(i2c_hid_acpi_prp0001_of_match),
> + },
> +
> + .probe = i2c_hid_acpi_prp0001_probe,
> + .remove = i2c_hid_core_remove,
> + .shutdown = i2c_hid_core_shutdown,
> + .id_table = i2c_hid_acpi_prp0001_id,
> +};
> +
> +module_i2c_driver(i2c_hid_acpi_prp0001_driver);
> +
> +MODULE_DESCRIPTION("HID over I2C driver for PRP0001 devices missing hid-descr-addr");
> +MODULE_AUTHOR("谢致邦 (XIE Zhibang) <Yeking@Red54.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> index abd700a101f4..13f977d6aab6 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> @@ -25,9 +25,9 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/pm.h>
> -#include <linux/uuid.h>
>
> #include "i2c-hid.h"
> +#include "i2c-hid-acpi.h"
>
> struct i2c_hid_acpi {
> struct i2chid_ops ops;
> @@ -48,39 +48,11 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
> { }
> };
>
> -/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
> -static guid_t i2c_hid_guid =
> - GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
> - 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
> -
> -static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
> -{
> - struct acpi_device *adev = ihid_acpi->adev;
> - acpi_handle handle = acpi_device_handle(adev);
> - union acpi_object *obj;
> - u16 hid_descriptor_address;
> -
> - if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
> - return -ENODEV;
> -
> - obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
> - ACPI_TYPE_INTEGER);
> - if (!obj) {
> - acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
> - return -ENODEV;
> - }
> -
> - hid_descriptor_address = obj->integer.value;
> - ACPI_FREE(obj);
> -
> - return hid_descriptor_address;
> -}
> -
Instead of moving this to i2c-hid-acpi.h, please make it non static an
export it using EXPORT_SYMBOL_GPL() and only put a prototype in i2c-hid-acpi.h .
The change to make it take an acpi_device pointer instead of i2c_hid_acpi *ihid_acpi
should be kept, but without moving the function to the .h file.
Regards,
Hans
> static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
> {
> struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
>
> - i2c_hid_acpi_get_descriptor(ihid_acpi);
> + i2c_hid_acpi_get_descriptor(ihid_acpi->adev);
> }
>
> static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
> @@ -93,24 +65,28 @@ static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
> static int i2c_hid_acpi_probe(struct i2c_client *client)
> {
> struct device *dev = &client->dev;
> + struct acpi_device *adev = ACPI_COMPANION(dev);
> struct i2c_hid_acpi *ihid_acpi;
> u16 hid_descriptor_address;
> int ret;
>
> - ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
> + if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
> + return -ENODEV;
> +
> + ret = i2c_hid_acpi_get_descriptor(adev);
> + if (ret < 0)
> + return ret;
> + hid_descriptor_address = ret;
> +
> + ihid_acpi = devm_kzalloc(dev, sizeof(*ihid_acpi), GFP_KERNEL);
> if (!ihid_acpi)
> return -ENOMEM;
>
> - ihid_acpi->adev = ACPI_COMPANION(dev);
> + ihid_acpi->adev = adev;
> ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
> ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
>
> - ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
> - if (ret < 0)
> - return ret;
> - hid_descriptor_address = ret;
> -
> - acpi_device_fix_up_power(ihid_acpi->adev);
> + acpi_device_fix_up_power(adev);
>
> return i2c_hid_core_probe(client, &ihid_acpi->ops,
> hid_descriptor_address, 0);
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.h b/drivers/hid/i2c-hid/i2c-hid-acpi.h
> new file mode 100644
> index 000000000000..8cebbeebcc23
> --- /dev/null
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef _I2C_HID_ACPI_H
> +#define _I2C_HID_ACPI_H
> +
> +#include <linux/acpi.h>
> +#include <linux/uuid.h>
> +
> +static inline int i2c_hid_acpi_get_descriptor(struct acpi_device *adev)
> +{
> + /* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
> + static const guid_t i2c_hid_guid =
> + GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
> + 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
> +
> + acpi_handle handle = acpi_device_handle(adev);
> + union acpi_object *obj;
> + u16 addr;
> +
> + obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid,
> + 1, 1, NULL, ACPI_TYPE_INTEGER);
> + if (!obj) {
> + acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
> + return -ENODEV;
> + }
> +
> + addr = obj->integer.value;
> + ACPI_FREE(obj);
> + return addr;
> +}
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v3] HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver
From: Hans de Goede @ 2026-06-08 11:51 UTC (permalink / raw)
To: 谢致邦 (XIE Zhibang), linux-input,
dmitry.torokhov, bentiss
Cc: dianders, jikos, linux-kernel, sashiko-bot, sashiko-reviews,
superm1
In-Reply-To: <52c113ef-e81e-476a-a62c-3cd09e7fdcbf@kernel.org>
Hi,
On 8-Jun-26 1:48 PM, Hans de Goede wrote:
> Hi,
>
> On 6-Jun-26 6:06 PM, 谢致邦 (XIE Zhibang) wrote:
>> Move the _DSM call that gets the HID descriptor address from
>> i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI
>> and the new PRP0001 driver can use it. While refactoring, move the
>> blacklist check and the _DSM call to the top of probe() to avoid a
>> pointless alloc when the device is blacklisted or does not implement the
>> _DSM.
>>
>> Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3,
>> are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but
>> lack "hid-descr-addr" from the _DSD and provide the HID descriptor
>> address only through an ACPI _DSM. The OF driver fails to probe them
>> because it requires hid-descr-addr. Add a new driver that handles these
>> devices by calling the shared _DSM helper.
>>
>> Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
>> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
>
> Thank you for the new version.
>
>> ---
>> v2: Name the unused parameter and document why
>> acpi_device_fix_up_power() is skipped.
>> v3: Add a dev_warn() asking users to contact vendors for firmware
>> updates, and use existing locals in devm_kzalloc() and
>> acpi_device_fix_up_power().
>>
>> drivers/hid/i2c-hid/Kconfig | 18 ++++
>> drivers/hid/i2c-hid/Makefile | 1 +
>> drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c | 98 ++++++++++++++++++++++
>> drivers/hid/i2c-hid/i2c-hid-acpi.c | 52 ++++--------
>> drivers/hid/i2c-hid/i2c-hid-acpi.h | 32 +++++++
>> 5 files changed, 163 insertions(+), 38 deletions(-)
>> create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
>> create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.h
>>
>> diff --git a/drivers/hid/i2c-hid/Kconfig b/drivers/hid/i2c-hid/Kconfig
>> index e8d51f410cc1..7db8b2abff78 100644
>> --- a/drivers/hid/i2c-hid/Kconfig
>> +++ b/drivers/hid/i2c-hid/Kconfig
>> @@ -22,6 +22,24 @@ config I2C_HID_ACPI
>> will be called i2c-hid-acpi. It will also build/depend on the
>> module i2c-hid.
>>
>> +config I2C_HID_ACPI_PRP0001
>> + tristate "Driver for PRP0001 devices missing hid-descr-addr"
>> + depends on ACPI
>> + depends on DRM || !DRM
>> + select I2C_HID_CORE
>> + help
>> + Say Y here if you want support for I2C HID touchpads that
>> + are declared with _HID "PRP0001" and _DSD compatible
>> + "hid-over-i2c" but lack the "hid-descr-addr" property from
>> + the _DSD. The HID descriptor address is instead provided
>> + through an ACPI _DSM. Known affected devices include the
>> + Lenovo KaiTian N60d and Inspur CP300L3.
>> +
>> + If unsure, say N.
>> +
>> + This support is also available as a module. If so, the
>> + module will be called i2c-hid-acpi-prp0001.
>> +
>> config I2C_HID_OF
>> tristate "HID over I2C transport layer Open Firmware driver"
>> # No "depends on OF" because this can also be used for manually
>> diff --git a/drivers/hid/i2c-hid/Makefile b/drivers/hid/i2c-hid/Makefile
>> index 55bd5e0f35af..da420c1a8ec6 100644
>> --- a/drivers/hid/i2c-hid/Makefile
>> +++ b/drivers/hid/i2c-hid/Makefile
>> @@ -9,6 +9,7 @@ i2c-hid-objs = i2c-hid-core.o
>> i2c-hid-$(CONFIG_DMI) += i2c-hid-dmi-quirks.o
>>
>> obj-$(CONFIG_I2C_HID_ACPI) += i2c-hid-acpi.o
>> +obj-$(CONFIG_I2C_HID_ACPI_PRP0001) += i2c-hid-acpi-prp0001.o
>> obj-$(CONFIG_I2C_HID_OF) += i2c-hid-of.o
>> obj-$(CONFIG_I2C_HID_OF_ELAN) += i2c-hid-of-elan.o
>> obj-$(CONFIG_I2C_HID_OF_GOODIX) += i2c-hid-of-goodix.o
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
>> new file mode 100644
>> index 000000000000..b54370a938ab
>> --- /dev/null
>> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
>> @@ -0,0 +1,98 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * HID over I2C driver for PRP0001 devices missing hid-descr-addr
>> + *
>> + * Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, use
>> + * _HID "PRP0001" with _DSD compatible "hid-over-i2c" but lack "hid-descr-addr"
>> + * from the _DSD. The HID descriptor address is provided only through an ACPI
>> + * _DSM. The TPD0 node in the DSDT shows _DSM Function 1 returning 0x20.
>> + *
>> + * Copyright (C) 2026 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/device.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +
>> +#include "i2c-hid.h"
>> +#include "i2c-hid-acpi.h"
>> +
>> +static int i2c_hid_acpi_prp0001_power_up(struct i2chid_ops *ops)
>> +{
>> + /* give the device time to power up */
>> + msleep(250);
>> + return 0;
>> +}
>> +
>> +static struct i2chid_ops i2c_hid_acpi_prp0001_ops = {
>> + .power_up = i2c_hid_acpi_prp0001_power_up,
>> + /*
>> + * No .restore_sequence needed: the _DSM on these devices returns a
>> + * constant (0x20) with no side effects, unlike some PNP0C50 _DSM
>> + * implementations that switch the hardware between PS/2 and I2C modes.
>> + */
>> +};
>> +
>> +static int i2c_hid_acpi_prp0001_probe(struct i2c_client *client)
>> +{
>> + struct device *dev = &client->dev;
>> + struct acpi_device *adev;
>> + u16 hid_descriptor_address;
>> + int ret;
>> +
>> + /* If hid-descr-addr is present, let i2c-hid-of handle it */
>> + if (device_property_present(dev, "hid-descr-addr"))
>> + return -ENODEV;
>> +
>> + adev = ACPI_COMPANION(dev);
>> + if (!adev)
>> + return -ENODEV;
>> +
>> + ret = i2c_hid_acpi_get_descriptor(adev);
>> + if (ret < 0)
>> + return ret;
>> + dev_warn(dev,
>> + "hid-descr-addr device property NOT found, using ACPI _DSM fallback. Contact vendor for firmware update!\n");
>> + hid_descriptor_address = ret;
>> +
>> + /*
>> + * No acpi_device_fix_up_power() needed: TPD0 has no _PS0, _PS3, _PSC
>> + * or _PRx methods and follows I2C bus power.
>> + */
>> + return i2c_hid_core_probe(client, &i2c_hid_acpi_prp0001_ops,
>> + hid_descriptor_address, 0);
>> +}
>> +
>> +static const struct of_device_id i2c_hid_acpi_prp0001_of_match[] = {
>> + { .compatible = "hid-over-i2c" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, i2c_hid_acpi_prp0001_of_match);
>> +
>> +static const struct i2c_device_id i2c_hid_acpi_prp0001_id[] = {
>> + { .name = "hid-over-i2c" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, i2c_hid_acpi_prp0001_id);
>> +
>> +static struct i2c_driver i2c_hid_acpi_prp0001_driver = {
>> + .driver = {
>> + .name = "i2c_hid_acpi_prp0001",
>> + .pm = &i2c_hid_core_pm,
>> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>> + .of_match_table = of_match_ptr(i2c_hid_acpi_prp0001_of_match),
>> + },
>> +
>> + .probe = i2c_hid_acpi_prp0001_probe,
>> + .remove = i2c_hid_core_remove,
>> + .shutdown = i2c_hid_core_shutdown,
>> + .id_table = i2c_hid_acpi_prp0001_id,
>> +};
>> +
>> +module_i2c_driver(i2c_hid_acpi_prp0001_driver);
>> +
>> +MODULE_DESCRIPTION("HID over I2C driver for PRP0001 devices missing hid-descr-addr");
>> +MODULE_AUTHOR("谢致邦 (XIE Zhibang) <Yeking@Red54.com>");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
>> index abd700a101f4..13f977d6aab6 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
>> @@ -25,9 +25,9 @@
>> #include <linux/kernel.h>
>> #include <linux/module.h>
>> #include <linux/pm.h>
>> -#include <linux/uuid.h>
>>
>> #include "i2c-hid.h"
>> +#include "i2c-hid-acpi.h"
>>
>> struct i2c_hid_acpi {
>> struct i2chid_ops ops;
>> @@ -48,39 +48,11 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
>> { }
>> };
>>
>> -/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
>> -static guid_t i2c_hid_guid =
>> - GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
>> - 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
>> -
>> -static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
>> -{
>> - struct acpi_device *adev = ihid_acpi->adev;
>> - acpi_handle handle = acpi_device_handle(adev);
>> - union acpi_object *obj;
>> - u16 hid_descriptor_address;
>> -
>> - if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
>> - return -ENODEV;
>> -
>> - obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
>> - ACPI_TYPE_INTEGER);
>> - if (!obj) {
>> - acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
>> - return -ENODEV;
>> - }
>> -
>> - hid_descriptor_address = obj->integer.value;
>> - ACPI_FREE(obj);
>> -
>> - return hid_descriptor_address;
>> -}
>> -
>
> Instead of moving this to i2c-hid-acpi.h, please make it non static an
> export it using EXPORT_SYMBOL_GPL() and only put a prototype in i2c-hid-acpi.h .
I just noticed i2c-hid-acpi.h is a whole new file. No need to add that just for
the prototype (I think / IMHO).
So for the next version just export the function from i2c-hid-acpi.c and
add a prototype declaration directly in i2c-hid-acpi-prp0001.c
Regards,
Hans
>> static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
>> {
>> struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
>>
>> - i2c_hid_acpi_get_descriptor(ihid_acpi);
>> + i2c_hid_acpi_get_descriptor(ihid_acpi->adev);
>> }
>>
>> static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
>> @@ -93,24 +65,28 @@ static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
>> static int i2c_hid_acpi_probe(struct i2c_client *client)
>> {
>> struct device *dev = &client->dev;
>> + struct acpi_device *adev = ACPI_COMPANION(dev);
>> struct i2c_hid_acpi *ihid_acpi;
>> u16 hid_descriptor_address;
>> int ret;
>>
>> - ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
>> + if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
>> + return -ENODEV;
>> +
>> + ret = i2c_hid_acpi_get_descriptor(adev);
>> + if (ret < 0)
>> + return ret;
>> + hid_descriptor_address = ret;
>> +
>> + ihid_acpi = devm_kzalloc(dev, sizeof(*ihid_acpi), GFP_KERNEL);
>> if (!ihid_acpi)
>> return -ENOMEM;
>>
>> - ihid_acpi->adev = ACPI_COMPANION(dev);
>> + ihid_acpi->adev = adev;
>> ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
>> ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
>>
>> - ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
>> - if (ret < 0)
>> - return ret;
>> - hid_descriptor_address = ret;
>> -
>> - acpi_device_fix_up_power(ihid_acpi->adev);
>> + acpi_device_fix_up_power(adev);
>>
>> return i2c_hid_core_probe(client, &ihid_acpi->ops,
>> hid_descriptor_address, 0);
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.h b/drivers/hid/i2c-hid/i2c-hid-acpi.h
>> new file mode 100644
>> index 000000000000..8cebbeebcc23
>> --- /dev/null
>> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.h
>> @@ -0,0 +1,32 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +
>> +#ifndef _I2C_HID_ACPI_H
>> +#define _I2C_HID_ACPI_H
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/uuid.h>
>> +
>> +static inline int i2c_hid_acpi_get_descriptor(struct acpi_device *adev)
>> +{
>> + /* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
>> + static const guid_t i2c_hid_guid =
>> + GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
>> + 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
>> +
>> + acpi_handle handle = acpi_device_handle(adev);
>> + union acpi_object *obj;
>> + u16 addr;
>> +
>> + obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid,
>> + 1, 1, NULL, ACPI_TYPE_INTEGER);
>> + if (!obj) {
>> + acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
>> + return -ENODEV;
>> + }
>> +
>> + addr = obj->integer.value;
>> + ACPI_FREE(obj);
>> + return addr;
>> +}
>> +
>> +#endif
>
>
>
>
^ permalink raw reply
* Re: [PATCH 5/8] Input: cap11xx - add reset gpio support
From: Jun Yan @ 2026-06-08 13:20 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260606151346.8C5861F00893@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(=
> s) to consider:
> - [Low] Inefficient delay using usleep_range() for a large duration (400-50=
> 0ms).
> - [Low] Missing explicit inclusion of <linux/delay.h>.
> --
>
> commit 83de47341df3454fdb8216dc0a95948c3f158a40
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> Input: cap11xx - add reset gpio support
>
> This commit adds hardware reset support for CAP11xx devices by toggling a
> dedicated reset GPIO during the i2c probe phase. It incorporates specific
> timing requirements for the reset filter and active reset duration.
>
> > diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/ca=
> p11xx.c
> > index 686174722204c..7015aa7654ce7 100644
> > --- a/drivers/input/keyboard/cap11xx.c
> > +++ b/drivers/input/keyboard/cap11xx.c
>
> [ ... ]
>
> > @@ -452,6 +457,17 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_=
> client)
> > if (IS_ERR(priv->regmap))
> > return PTR_ERR(priv->regmap);
> > =20
> > + priv->reset_gpio =3D devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LO=
> W);
> > + if (IS_ERR(priv->reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> > + "Failed to get 'reset' GPIO\n");
> > + if (priv->reset_gpio) {
> > + gpiod_set_value_cansleep(priv->reset_gpio, 1);
> > + usleep_range(CAP11XX_T_RST_FILT_MIN, CAP11XX_T_RST_FILT_MIN * 2);
> > + gpiod_set_value_cansleep(priv->reset_gpio, 0);
> > + usleep_range(CAP11XX_T_RST_ON_MIN, CAP11XX_T_RST_ON_MAX);
>
> [Severity: Low]
> Does this regression introduce unnecessary overhead by using usleep_range()
> for a 400-500ms delay in cap11xx_i2c_probe()?
>
> According to kernel timer guidelines, usleep_range() is designed for short
> delays (10us to 20ms) and sets up high-resolution timers. For delays longer
> than 20ms, using msleep() or fsleep() avoids unnecessary overhead and
> expensive CPU wakeups.
>
Agreed. Will replace usleep_range() with msleep() in V2.
>
> [Severity: Low]
> Could this regression in header dependencies be avoided by explicitly
> including <linux/delay.h> since we are now calling usleep_range() here?
>
> While the code might compile due to implicit inclusion via other headers,
> relying on implicit includes can sometimes lead to build failures on other
> architectures or if intermediate headers are refactored in the future.
>
OK. Will add #include <linux/delay.h> in v2,
> > + }
> > +
> > error =3D regmap_read(priv->regmap, CAP11XX_REG_PRODUCT_ID, &val);
> > if (error)
> > return dev_err_probe(dev, error, "Failed to read product ID\n");
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260606150458.2506=
> 06-1-jerrysteve1101@gmail.com?part=3D5
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Jun Yan @ 2026-06-08 13:27 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260606151658.60E2C1F00893@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(=
> s) to consider:
> - [Medium] The new `microchip,cap1114` compatible string was omitted from t=
> he `if-then` conditional block that restricts `microchip,signal-guard` and =
> `microchip,calib-sensitivity` for prior CAP11xx generations.
> --
>
> commit 5c58a6baee363da7434a9782efa913c250015130
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> dt-bindings: input: microchip,cap11xx: Add CAP1114 support
>
> This commit adds device tree binding support for the CAP1114 capacitive
> touch sensor. It updates the compatible string list, maximum LED channel
> counts, and keycode entries.
>
> > diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.ya=
> ml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > index e307628350c24..08233386a4336 100644
> > --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> [ ... ]
> > @@ -26,6 +27,7 @@ properties:
> > compatible:
> > enum:
> > - microchip,cap1106
> > + - microchip,cap1114
> > - microchip,cap1126
> > - microchip,cap1188
> > - microchip,cap1203
>
> [Severity: Medium]
> Since microchip,cap1114 is being added here, could this validation
> regression be avoided by also appending it to the if-then conditional
> block further down the schema that restricts microchip,signal-guard and
> microchip,calib-sensitivity?
>
Good catch. CAP1114 doesn't support these features, so I'll add it to the if-then block in v2.
>
> Documentation/devicetree/bindings/input/microchip,cap11xx.yaml:
> - if:
> properties:
> compatible:
> contains:
> enum:
> - microchip,cap1106
> - microchip,cap1126
> - microchip,cap1188
> - microchip,cap1203
> - microchip,cap1206
> then:
> properties:
> microchip,signal-guard: false
> microchip,calib-sensitivity: false
>
> Since the maxItems for these properties remains at 8 (and CAP1114 has 14
> channels), it appears CAP1114 does not support them either. Omitting the
> new compatible string from this block allows device trees with these
> unsupported properties to pass schema validation.
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260606150458.2506=
> 06-1-jerrysteve1101@gmail.com?part=3D7
^ permalink raw reply
* Re: [PATCH 8/8] Input: cap11xx - add support for CAP1114
From: Jun Yan @ 2026-06-08 13:37 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260606152056.B77161F00893@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 3 potential issue(=
> s) to consider:
> - [High] Buffer overflow when reading the 'microchip,calib-sensitivity' dev=
> ice tree property for devices with >8 channels.
> - [High] Failure to mask `STATUS1` before ORing `STATUS2` can cause phantom=
> key presses for channels 7 and 8.
> - [Low] Bitmask calculation for 'microchip,signal-guard' truncates settings=
> for channels 8 and above.
> --
>
> commit 8885b1d0f98cb8d5ca53ba5fd9a458743481d5be
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> Input: cap11xx - add support for CAP1114
>
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support. The CAP1114 uses two separate control registers
> for LED output management and requires two button status registers for touch
> input state reporting.
>
> > diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/ca=
> p11xx.c
> > index 408880cf65167..2aba3b508947d 100644
> > --- a/drivers/input/keyboard/cap11xx.c
> > +++ b/drivers/input/keyboard/cap11xx.c
>
> [ ... ]
>
> > @@ -311,6 +337,20 @@ static irqreturn_t cap11xx_thread_func(int irq_num, =
> void *data)
> > if (ret < 0)
> > goto out;
> > =20
> > + if (priv->model->num_channels > 8) {
> > + unsigned int status2;
> > +
> > + ret =3D regmap_read(priv->regmap, priv->model->sensor_input_reg_base +=
> 1, &status2);
> > + if (ret < 0)
> > + goto out;
> > +
> > + /*
> > + * CAP1114 STATUS1 register only contains data for the first 6 channel=
> s.
> > + * the remaining channels is stored in STATUS2.
> > + */
> > + status |=3D FIELD_PREP(GENMASK(13, 6), status2);
>
> [Severity: High]
> If the hardware sets reserved bits 6 or 7 in the first status register to 1,
> will they be preserved and incorrectly reported as touch events for channels
> 7 and 8?
>
> Since the status variable (which holds STATUS1) is not masked before this OR
> operation, any reserved bits set in STATUS1 could overlap with the shifted
> status2 values.
>
> Should the status variable be masked to clear bits 6 and 7 before ORing in
> status2?
>
Thanks. Will mask bits 6/7 via status &= GENMASK(5, 0) after reading STATUS1 in v2.
> > + }
> > +
> > for (i =3D 0; i < priv->idev->keycodemax; i++)
>
> [ ... ]
>
> > @@ -572,6 +625,14 @@ static const struct cap11xx_hw_model cap1106_model =
> =3D {
> > .has_repeat_en =3D true,
> > };
> > =20
> > +static const struct cap11xx_hw_model cap1114_model =3D {
> > + .product_id =3D 0x3a,
> > + .led_output_control_reg_base =3D CAP1114_REG_LED_OUTPUT_CONTROL1,
> > + .sensor_input_reg_base =3D CAP1114_REG_BUTTON_STATUS1,
> > + .num_channels =3D 14, .num_leds =3D 11, .num_sensor_thresholds =3D 8,
>
> [Severity: High]
> Does configuring num_channels to 14 cause a buffer overflow when parsing the
> device tree?
>
> In struct cap11xx_priv, calib_sensitivities is defined as a fixed 8-element
> array:
>
> struct cap11xx_priv {
> ...
> u32 calib_sensitivities[8];
> u32 keycodes[];
> };
>
> When cap11xx_init_keys() parses the microchip,calib-sensitivity property, it
> requests num_channels elements:
>
> of_property_read_u32_array(node, "microchip,calib-sensitivity",
> priv->calib_sensitivities,
> priv->model->num_channels)
>
> If the device tree provides 14 elements, won't this write 56 bytes into the
> 32-byte array, overflowing into the adjacent keycodes flexible array?
>
> [Severity: Low]
> Additionally, does setting num_channels to 14 cause truncation in the
> microchip,signal-guard bitmask logic?
>
> In cap11xx_init_keys(), priv->signal_guard_inputs_mask is typed as a u8, but
> the initialization loop runs up to num_channels:
I will exclude CAP1114 from using microchip,calib-sensitivity and microchip,
signal-guard in the dt-bindings to resolve these two issues in V2.
>
> if (u32_val)
> priv->signal_guard_inputs_mask |=3D 0x01 << i;
>
> For i >=3D 8, does the shifted bit exceed the 8-bit width and get silently
> truncated to 0 during the assignment?
>
> > + .has_grouped_sensors =3D true,
> > +};
> > +
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260606150458.2506=
> 06-1-jerrysteve1101@gmail.com?part=3D8
^ permalink raw reply
* Re: [PATCH 0/9] HID: iio: Fix race condition between callback registration and device exposure
From: Andy Shevchenko @ 2026-06-08 13:56 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, Archana Patni, Song Hongyan,
linux-input, linux-iio, linux-kernel, srinivas pandruvada
In-Reply-To: <20260606-5-june-hid-iio-race-fixes-v1-0-27a848c5758f@gmail.com>
On Sat, Jun 06, 2026 at 05:07:09PM +0530, Sanjay Chitroda wrote:
> Hi all,
>
> This series fixes a race condition in HID IIO drivers related to the
> ordering between callback registration and device exposure.
>
> Currently, several HID IIO drivers register the IIO device (making it
> visible to userspace and other kernel consumers) before all required
> callbacks and resources are fully initialized, or rely on devm-based
> cleanup in a way that does not guarantee correct teardown ordering.
> This creates a window where the device can be accessed while it is
> not fully initialized or is being torn down, potentially leading NULL
> dereference or use-after-free.
>
> To address this, the series ensures that:
> - All required callbacks and resources are set up before the device
> is registered with the IIO core
> - Resource cleanup is performed explicitly where ordering matters
>
> PS: This is prepratory series to convert all HID IIO driver to devm.
I haven't found anything problematic, but still would be nice if somebody can
reproduce the issue and test this fix. Code wise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/7] iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned
From: Andy Shevchenko @ 2026-06-08 13:58 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260606-6-june-hid-iio-correct-usage-id-v1-1-dd4a6820b674@gmail.com>
On Sat, Jun 06, 2026 at 05:47:42PM +0530, Sanjay Chitroda wrote:
> Prefer 'u32' instead of bare 'unsigned' variable to improve code
> clarity and consistency with kernel style.
...
> /* Callback handler to send event after all samples are received and captured */
> static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
It still has an indentation issue and I dunno if it's okay to solve at the same
time. Jonathan?
...
> static int gyro_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
Ditto.
...
> static int gyro_3d_parse_report(struct platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> struct iio_chan_spec *channels,
> - unsigned usage_id,
> + u32 usage_id,
> struct gyro_3d_state *st)
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/9] iio: orientation: hid-sensor-incl-3d: Fix race between callback registration and device exposure
From: Pandruvada, Srinivas @ 2026-06-08 15:34 UTC (permalink / raw)
To: dlechner@baylibre.com, archana.patni@linux.intel.com,
hongyan.song@intel.com, nuno.sa@analog.com, jic23@kernel.org,
jikos@kernel.org, andy@kernel.org, sanjayembeddedse@gmail.com
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
In-Reply-To: <20260606-5-june-hid-iio-race-fixes-v1-2-27a848c5758f@gmail.com>
On Sat, 2026-06-06 at 17:07 +0530, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> The driver registers the IIO device before completing sensor hub
> callback registration and unregisters callbacks while the IIO device
> is still exposed during teardown.
>
> This creates race windows in both probe and remove paths, which can
> lead to NULL pointer dereferences or use-after-free.
Reordering is fine, but can you show how this use after free is
possible?
Thanks,
Srinivas
>
> Fix this by correct ordering of callback registration and
> IIO device registration in probe and remove paths.
>
> Fixes: 098d3beccfb6 ("iio: hid-sensors: Added Inclinometer 3D")
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---
> drivers/iio/orientation/hid-sensor-incl-3d.c | 20 ++++++++++--------
> --
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c
> b/drivers/iio/orientation/hid-sensor-incl-3d.c
> index 4e23a598a3fb..5e3d2bb9b5bf 100644
> --- a/drivers/iio/orientation/hid-sensor-incl-3d.c
> +++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
> @@ -356,12 +356,6 @@ static int hid_incl_3d_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> - ret = iio_device_register(indio_dev);
> - if (ret) {
> - dev_err(&pdev->dev, "device register failed\n");
> - goto error_remove_trigger;
> - }
> -
> incl_state->callbacks.send_event = incl_3d_proc_event;
> incl_state->callbacks.capture_sample =
> incl_3d_capture_sample;
> incl_state->callbacks.pdev = pdev;
> @@ -370,13 +364,19 @@ static int hid_incl_3d_probe(struct
> platform_device *pdev)
> &incl_state->callbacks);
> if (ret) {
> dev_err(&pdev->dev, "callback reg failed\n");
> - goto error_iio_unreg;
> + goto error_remove_trigger;
> + }
> +
> + ret = iio_device_register(indio_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "device register failed\n");
> + goto error_remove_callback;
> }
>
> return 0;
>
> -error_iio_unreg:
> - iio_device_unregister(indio_dev);
> +error_remove_callback:
> + sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_INCLINOMETER_3D);
> error_remove_trigger:
> hid_sensor_remove_trigger(indio_dev, &incl_state-
> >common_attributes);
> return ret;
> @@ -389,8 +389,8 @@ static void hid_incl_3d_remove(struct
> platform_device *pdev)
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> struct incl_3d_state *incl_state = iio_priv(indio_dev);
>
> - sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_INCLINOMETER_3D);
> iio_device_unregister(indio_dev);
> + sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_INCLINOMETER_3D);
> hid_sensor_remove_trigger(indio_dev, &incl_state-
> >common_attributes);
> }
>
^ permalink raw reply
* [PATCH] HID: hiddev: Use kref to track struct hiddev lifetime
From: Heitor Alves de Siqueira @ 2026-06-08 16:33 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: kernel-dev, linux-usb, linux-input, linux-kernel,
syzbot+563191a4939ddbfe73d4
If a USB HID device is disconnected while userspace still holds the
hiddev node open, hiddev_disconnect() and hiddev_release() can race on
the embedded existancelock mutex. Syzbot has triggered this with kfree()
happening during the mutex slow path.
Fix by introducing a kref in struct hiddev, and moving kfree() into a
dedicated release callback. This way, struct hiddev will only be freed
after both hiddev_release() and hiddev_disconnect() are done.
Fixes: 6cb4b040795c ("HID: hiddev: fix race between hiddev_disconnect and hiddev_release")
Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com>
---
drivers/hid/usbhid/hiddev.c | 36 ++++++++++++++++++++++++------------
include/linux/hiddev.h | 1 +
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 6378801b22c6..1f2802920bee 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -46,6 +46,13 @@ struct hiddev_list {
struct mutex thread_lock;
};
+static void hiddev_kref_free(struct kref *kref)
+{
+ struct hiddev *hiddev = container_of(kref, struct hiddev, kref);
+
+ kfree(hiddev);
+}
+
/*
* Find a report, given the report's type and ID. The ID can be specified
* indirectly by REPORT_ID_FIRST (which returns the first report of the given
@@ -227,15 +234,11 @@ static int hiddev_release(struct inode * inode, struct file * file)
if (list->hiddev->exist) {
hid_hw_close(list->hiddev->hid);
hid_hw_power(list->hiddev->hid, PM_HINT_NORMAL);
- } else {
- mutex_unlock(&list->hiddev->existancelock);
- kfree(list->hiddev);
- vfree(list);
- return 0;
}
}
-
mutex_unlock(&list->hiddev->existancelock);
+
+ kref_put(&list->hiddev->kref, hiddev_kref_free);
vfree(list);
return 0;
@@ -298,10 +301,20 @@ static int hiddev_open(struct inode *inode, struct file *file)
hid = usb_get_intfdata(intf);
hiddev = hid->hiddev;
+ /*
+ * kref_get_unless_zero() checks if we've already dropped
+ * the last reference; bail out early in this case
+ */
+ if (!hiddev || !kref_get_unless_zero(&hiddev->kref))
+ return -ENODEV;
+
mutex_lock(&hiddev->existancelock);
res = hiddev->exist ? __hiddev_open(hiddev, file) : -ENODEV;
mutex_unlock(&hiddev->existancelock);
+ if (res < 0)
+ kref_put(&hiddev->kref, hiddev_kref_free);
+
return res;
}
@@ -893,6 +906,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
if (!(hiddev = kzalloc_obj(struct hiddev)))
return -ENOMEM;
+ kref_init(&hiddev->kref);
init_waitqueue_head(&hiddev->wait);
INIT_LIST_HEAD(&hiddev->list);
spin_lock_init(&hiddev->list_lock);
@@ -904,7 +918,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
if (retval) {
hid_err(hid, "Not able to get a minor for this device\n");
hid->hiddev = NULL;
- kfree(hiddev);
+ kref_put(&hiddev->kref, hiddev_kref_free);
return retval;
}
@@ -933,13 +947,11 @@ void hiddev_disconnect(struct hid_device *hid)
mutex_lock(&hiddev->existancelock);
hiddev->exist = 0;
-
if (hiddev->open) {
hid_hw_close(hiddev->hid);
wake_up_interruptible(&hiddev->wait);
- mutex_unlock(&hiddev->existancelock);
- } else {
- mutex_unlock(&hiddev->existancelock);
- kfree(hiddev);
}
+ mutex_unlock(&hiddev->existancelock);
+
+ kref_put(&hiddev->kref, hiddev_kref_free);
}
diff --git a/include/linux/hiddev.h b/include/linux/hiddev.h
index 2164c03d2c72..1613c9c37ab7 100644
--- a/include/linux/hiddev.h
+++ b/include/linux/hiddev.h
@@ -24,6 +24,7 @@ struct hiddev {
int minor;
int exist;
int open;
+ struct kref kref;
struct mutex existancelock;
wait_queue_head_t wait;
struct hid_device *hid;
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20260603-hiddev_kref-52f5507d4e42
Best regards,
--
Heitor Alves de Siqueira <halves@igalia.com>
^ permalink raw reply related
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 16:40 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <CAD++jLmUW4KjxEjwv7_an_dEMTSOtvG=q2MjhqKvnuGrWaaCsQ@mail.gmail.com>
Hi, Linus,
On Mon, Jun 8, 2026 at 1:50 AM Linus Walleij <linusw@kernel.org> wrote:
> Have you tested this on real hardware?
> The commit doesn't really say.
No, I haven't. I can try to test it in GXemul, but I'm not sure if it
can boot Linux. The developer only lists it as capable of booting
NetBSD.
Ethan
^ permalink raw reply
* Re: [PATCH] input: ipaq-micro-keys: simplify allocation
From: Dmitry Torokhov @ 2026-06-08 16:49 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-input, open list
In-Reply-To: <20260608045041.4664-1-rosenp@gmail.com>
Hi Rosen,
On Sun, Jun 07, 2026 at 09:50:41PM -0700, Rosen Penev wrote:
> Use a flexible array member to have a single allocation.
Why does it have to be flexible? The size is known.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/input/keyboard/ipaq-micro-keys.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/keyboard/ipaq-micro-keys.c b/drivers/input/keyboard/ipaq-micro-keys.c
> index ca7ec054b1ce..0fc5b5dcdef5 100644
> --- a/drivers/input/keyboard/ipaq-micro-keys.c
> +++ b/drivers/input/keyboard/ipaq-micro-keys.c
> @@ -23,7 +23,7 @@
> struct ipaq_micro_keys {
> struct ipaq_micro *micro;
> struct input_dev *input;
> - u16 *codes;
> + u16 codes[];
> };
>
> static const u16 micro_keycodes[] = {
> @@ -90,10 +90,11 @@ static int micro_key_probe(struct platform_device *pdev)
> int error;
> int i;
>
> - keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
> + keys = devm_kzalloc(&pdev->dev, struct_size(keys, codes, ARRAY_SIZE(micro_keycodes)), GFP_KERNEL);
Please keep to the limits for the kernel. 100 columns is acceptable when
leads to better readability, but I prefer 80 when it makes sense.
checkpatch.pl would have warned you.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: hiddev: Use kref to track struct hiddev lifetime
From: sashiko-bot @ 2026-06-08 16:52 UTC (permalink / raw)
To: Heitor Alves de Siqueira; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260608-hiddev_kref-v1-1-cd240c95423f@igalia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Use-After-Free in hiddev_send_event due to race between hid_disconnect and usbhid_irq_in.
--
commit a4056f7ab6df2200de09a38f314eabfb8dd4a066
Author: Heitor Alves de Siqueira <halves@igalia.com>
HID: hiddev: Use kref to track struct hiddev lifetime
This commit fixes a race between hiddev_disconnect() and hiddev_release()
by introducing a kref in struct hiddev. It moves the deallocation into a
dedicated release callback, ensuring the structure is only freed after both
functions are complete.
Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> index 6378801b22c6d..1f2802920beee 100644
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
[ ... ]
> @@ -933,13 +947,11 @@ void hiddev_disconnect(struct hid_device *hid)
>
> mutex_lock(&hiddev->existancelock);
> hiddev->exist = 0;
> -
> if (hiddev->open) {
> hid_hw_close(hiddev->hid);
> wake_up_interruptible(&hiddev->wait);
> - mutex_unlock(&hiddev->existancelock);
> - } else {
> - mutex_unlock(&hiddev->existancelock);
> - kfree(hiddev);
> }
> + mutex_unlock(&hiddev->existancelock);
> +
> + kref_put(&hiddev->kref, hiddev_kref_free);
[Severity: Critical]
This isn't a bug introduced by this patch, but is there a use-after-free
race condition when freeing struct hiddev while URBs are still active?
When a USB HID device is disconnected, usbhid_disconnect() eventually calls
hid_hw_stop(), which tears down the high-level structures before stopping
the low-level driver:
drivers/hid/hid-core.c:hid_hw_stop() {
hid_disconnect(hdev);
hdev->ll_driver->stop(hdev);
}
Because hid_disconnect() calls hiddev_disconnect() (which drops the kref
here), if no userspace process holds the file open, struct hiddev will be
freed immediately.
Since the input URBs have not yet been killed by hdev->ll_driver->stop(),
can an URB complete concurrently on another CPU?
If the URB completes, the completion handler usbhid_irq_in() propagates to
hid_input_report() -> hid_input_field() -> hiddev_send_event(), which then
dereferences the freed hiddev pointer:
drivers/hid/usbhid/hiddev.c:hiddev_send_event() {
struct hiddev *hiddev = hid->hiddev;
struct hiddev_list *list;
unsigned long flags;
spin_lock_irqsave(&hiddev->list_lock, flags);
Would this cause a use-after-free panic in interrupt context when it tries
to acquire list_lock?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-hiddev_kref-v1-1-cd240c95423f@igalia.com?part=1
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-08 16:56 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Jiri Slaby,
Russell King (Oracle), Linus Walleij, Kees Cook,
Nathan Chancellor, Sebastian Andrzej Siewior, Steven Rostedt,
Thomas Weissschuh, Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
Hi Ethan,
On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
> index a8f4b2d70e59..cea72bd888af 100644
> --- a/drivers/input/serio/i8042-io.h
> +++ b/drivers/input/serio/i8042-io.h
> @@ -15,9 +15,9 @@
> * IRQs.
> */
>
> -#if defined(__arm__)
> -/* defined in include/asm-arm/arch-xxx/irqs.h */
> -#include <asm/irq.h>
> +#ifdef CONFIG_ARCH_FOOTBRIDGE
> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
> +#include <mach/irqs.h>
> #elif defined(CONFIG_PPC)
> extern int of_i8042_kbd_irq;
> extern int of_i8042_aux_irq;
This does not look right. Did you mean to drop inclusion of asm/irq.h
for all other arms?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Arnd Bergmann @ 2026-06-08 17:11 UTC (permalink / raw)
To: Dmitry Torokhov, Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Greg Kroah-Hartman, Jiri Slaby, Russell King, Linus Walleij,
Kees Cook, Nathan Chancellor, Sebastian Andrzej Siewior,
Steven Rostedt, Thomas Weißschuh, Peter Zijlstra
In-Reply-To: <aibz3auoiq4CFa9l@google.com>
On Mon, Jun 8, 2026, at 18:56, Dmitry Torokhov wrote:
> On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
>> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
>> index a8f4b2d70e59..cea72bd888af 100644
>>
>> -#if defined(__arm__)
>> -/* defined in include/asm-arm/arch-xxx/irqs.h */
>> -#include <asm/irq.h>
>> +#ifdef CONFIG_ARCH_FOOTBRIDGE
>> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
>> +#include <mach/irqs.h>
>> #elif defined(CONFIG_PPC)
>> extern int of_i8042_kbd_irq;
>> extern int of_i8042_aux_irq;
>
> This does not look right. Did you mean to drop inclusion of asm/irq.h
> for all other arms?
I think this is correct, as footbridge is the only one that selects
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
Arnd
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 17:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Torokhov, linux-arm-kernel, linux-input, linux-serial,
Russell King, Greg Kroah-Hartman, Jiri Slaby, Russell King,
Linus Walleij, Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weißschuh,
Peter Zijlstra
In-Reply-To: <86765df4-0d2d-435e-85d8-b9bd4f3ea85d@app.fastmail.com>
Hi, Arnd,
On Mon, Jun 8, 2026 at 10:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
> I think this is correct, as footbridge is the only one that selects
> CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
I came to the same conclusion.
Ethan
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-08 17:38 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260606150458.250606-8-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
On Sat, Jun 06, 2026 at 11:04:00PM +0800, Jun Yan wrote:
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support.
>
> Add the compatible string for CAP1114, include its datasheet URL,
> and update the maximum count of LED channels and linux,keycodes entries.
>
> Add description for microchip,input-threshold: CAP1114 only provides eight
> threshold entries, which does not match its total channel count.
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../bindings/input/microchip,cap11xx.yaml | 21 +++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index e307628350c2..08233386a433 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> @@ -12,6 +12,7 @@ description: |
>
> For more product information please see the links below:
> CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
> + CAP1114: https://ww1.microchip.com/downloads/en/DeviceDoc/00002444A.pdf
> CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
> CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
> CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
> @@ -26,6 +27,7 @@ properties:
> compatible:
> enum:
> - microchip,cap1106
> + - microchip,cap1114
> - microchip,cap1126
> - microchip,cap1188
> - microchip,cap1203
> @@ -62,7 +64,7 @@ properties:
>
> linux,keycodes:
> minItems: 3
> - maxItems: 8
> + maxItems: 14
> description: |
> Specifies an array of numeric keycode values to
> be used for the channels. If this property is
> @@ -122,6 +124,8 @@ properties:
> is required for a touch to be registered, making the touch sensor less
> sensitive.
> The number of entries must correspond to the number of channels.
> + CAP1114 is an exception where channels 8~14 reuse the eighth entry's
> + threshold, so counts differ.
>
> microchip,calib-sensitivity:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -149,7 +153,7 @@ patternProperties:
> reg:
> description: LED channel number
> minimum: 0
> - maximum: 7
> + maximum: 10
>
> required:
> - reg
> @@ -199,6 +203,19 @@ allOf:
> reg:
> maximum: 1
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - microchip,cap1188
I don't understand this restriction, shouldn't this be
if: properties: compatible: not: contains: microchip,cap1114
so that the constraints before your change are retained?
Also, you don't add a new constraint for linux,keycodes, so now it is
permitted to have > 8 entries for existing devices.
pw-bot: changes-requested
Thanks,
Conor.
> + then:
> + patternProperties:
> + "^led@":
> + properties:
> + reg:
> + maximum: 7
> +
> - if:
> properties:
> compatible:
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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