* Re: [PATCH v2 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:47 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-3-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Directly casting the `raw_data` byte array to `u32*` and `s64*` in capture callbacks causes unaligned memory accesses, incorrect endianness handling, and potential out-of-bounds reads.
--
commit 8c6bb48eb0d753aea033d76922dc45a105550e60
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: light: hid-sensor-als: use u32 instead of unsigned
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index d72e260b82668..ae2fda8dc500a 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
[ ... ]
> @@ -263,7 +263,7 @@ static int als_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but does the direct cast in this function cause
unaligned memory accesses or endianness issues?
Just a few lines down in als_capture_sample(), raw_data is cast directly:
int ret = -EINVAL;
u32 sample_data = *(u32 *)raw_data;
The HID sensor hub core passes a byte pointer raw_data which points directly
into the raw HID report. In sensor_hub_report(), the pointer is incremented
by 1 to skip the report ID, making it immediately unaligned.
Dereferencing this unaligned pointer directly via *(u32 *) or *(s64 *) can
cause unaligned memory access faults on architectures that do not support
them.
Additionally, since HID reports are strictly little-endian, a direct
cast on a big-endian host might result in corrupted sensor data.
Should this code use get_unaligned_le32() and get_unaligned_le64() instead,
and also validate that raw_len is sufficient to prevent out-of-bounds reads?
The same direct cast pattern appears to be present in other HID sensors,
such as accel_3d_capture_sample() and gyro_3d_capture_sample().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 6/7] iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:47 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-6-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds read and unaligned access in `dev_rot_capture_sample`
- [High] Use-After-Free (UAF) race condition between device removal and raw event processing
--
commit de9f9c2c99851d2c61cb3fce183da2297778f18f
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.
No functional change.
> diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
> index 4a11e45550991..20563d8efaf6c 100644
> --- a/drivers/iio/orientation/hid-sensor-rotation.c
> +++ b/drivers/iio/orientation/hid-sensor-rotation.c
[ ... ]
> @@ -209,7 +209,7 @@ static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int dev_rot_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This isn't a bug introduced by this patch, but does dev_rot_capture_sample()
blindly trust raw_len and raw_data derived from the HID device's report
descriptors?
If a malicious or faulty USB device provides a descriptor with a small report
size (e.g., 4 bytes), raw_len / 4 == sizeof(s16) evaluates to false. This
leads the code to execute:
memcpy(&rot_state->scan.sampled_vals, raw_data,
sizeof(rot_state->scan.sampled_vals));
Can this read out-of-bounds heap memory which is then pushed to IIO buffers
and leaked to userspace?
Furthermore, for HID_USAGE_SENSOR_TIME_TIMESTAMP, the code directly casts
and dereferences raw_data as a 64-bit integer:
rot_state->timestamp = hid_sensor_convert_timestamp(
&rot_state->common_attributes, *(s64 *)raw_data);
As HID reports are packed, raw_data can be unaligned. Could this cause a
kernel panic (unaligned access exception) on architectures with strict
alignment requirements?
[Severity: High]
This is also a pre-existing issue, but is there a use-after-free race
condition between device removal and raw event processing?
During removal, hid_dev_rot_remove() calls sensor_hub_remove_callback(),
which deletes the callback from the list using dyn_callback_lock but does
not synchronize with active or concurrent readers:
drivers/hid/hid-sensor-hub.c:sensor_hub_remove_callback() {
...
list_del(&callback->list);
kfree(callback);
...
}
Meanwhile, in sensor_hub_raw_event(), sensor_hub_get_callback() fetches the
callback pointer and drops the lock. The function then continues to invoke
callback->capture_sample() without any locks or reference counting:
drivers/hid/hid-sensor-hub.c:sensor_hub_raw_event() {
...
callback->capture_sample(hsdev, report->field[i]->logical, sz, ptr,
callback->pdev);
...
}
If device removal completes and devres frees indio_dev and dev_rot_state
before sensor_hub_raw_event() finishes execution on another CPU, will the
event handler dereference a freed function pointer or access the freed driver
state structure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH 0/4] HID: wacom: add report length validation in irq handlers
From: Jiri Kosina @ 2026-06-10 15:47 UTC (permalink / raw)
To: Jinmo Yang
Cc: linux-input, benjamin.tissoires, linux-kernel, stable, Ping Cheng,
Jason Gerecke
In-Reply-To: <20260517135215.2220117-1-jinmo44.yang@gmail.com>
On Sun, 17 May 2026, Jinmo Yang wrote:
> Several wacom IRQ handler sub-functions access fixed offsets in the raw
> HID report buffer without validating the buffer length. wacom_wac_irq()
> receives the length from wacom_raw_event() but does not validate it
> before dispatching to the sub-functions, which do not receive the length
> parameter.
>
> A malicious USB device can declare a small HID report in its descriptor
> and send a matching short report that passes the HID core size check
> (csize >= rsize), but the driver assumes a full-size hardware report
> layout, leading to slab-out-of-bounds reads.
>
> Note: this is not mitigated by the recent HID core bounds checking
> series which validates actual_size >= declared_size. An attacker
> controls both the descriptor (declared size) and the sent data (actual
> size), so the core check passes. Driver-level validation against the
> expected hardware report layout is still necessary.
>
> Tested with KASAN on Linux 7.1-rc3 (slab-out-of-bounds confirmed) and
> verified kernel panic on a production device via uhid.
>
> Jinmo Yang (4):
> HID: wacom: validate report length for PL and PTU handlers
> HID: wacom: validate report length for DTU handler
> HID: wacom: validate report length for DTUS handler
> HID: wacom: validate report length for 24HDT and 27QHDT handlers
>
> drivers/hid/wacom_wac.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
CCing Ping and Jason for their review. Thanks in advance,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 4/7] iio: light: hid-sensor-prox: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:47 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-4-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unaligned and endian-dependent memory access from raw HID report buffer
--
commit 15de0e06ef54de0333e9e716c38314e57230ae3f
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: light: hid-sensor-prox: use u32 instead of unsigned
This commit changes the type of the usage_id parameter from unsigned to u32
in the callback functions of the HID sensor proximity driver. This matches
the expected API and improves code clarity, with no functional changes
intended.
> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
> index edc9274a2c076..9059f00f0cedf 100644
> --- a/drivers/iio/light/hid-sensor-prox.c
> +++ b/drivers/iio/light/hid-sensor-prox.c
[ ... ]
> @@ -183,7 +183,7 @@ static int prox_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int prox_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but does this function safely access the raw
data from the HID report?
Since raw_data points into a packed HID report buffer, the data might not be
naturally aligned for 16-bit or 32-bit boundaries. It looks like we cast
directly to u16* and u32* later in this function:
drivers/iio/light/hid-sensor-prox.c:prox_capture_sample() {
...
case 2:
prox_state->human_presence[chan] = *(u16 *)raw_data * multiplier;
return 0;
case 4:
prox_state->human_presence[chan] = *(u32 *)raw_data * multiplier;
...
}
Could this trigger unaligned memory access faults on architectures that do
not support them in hardware?
Also, since HID reports encode data in little-endian format, would using the
host's native byte order here cause incorrect sensor readings on big-endian
architectures?
Would it be safer to use get_unaligned_le16() and get_unaligned_le32()
instead of direct casting?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2] HID: wacom: fix NULL pointer dereference in wacom_intuos_pad()
From: Jiri Kosina @ 2026-06-10 15:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jinmo Yang, Ping Cheng, Jason Gerecke, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <ahoH87pet5BUQwfD@google.com>
On Fri, 29 May 2026, Dmitry Torokhov wrote:
> I think there are many more places in the driver where it used
> wacom->pad_input without verifying that it exists.
Absolutely correct observation, thanks :)
Jinmo, are you planning to submit extended version of the patch, please?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: wacom: stop hardware after post-start probe failures
From: Jiri Kosina @ 2026-06-10 15:49 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, linux-input,
linux-kernel, stable, Ijae Kim, Dmitry Torokhov
In-Reply-To: <20260604045710.25512-1-mhun512@gmail.com>
On Thu, 4 Jun 2026, Myeonghun Pak wrote:
> wacom_parse_and_register() starts HID hardware before registering inputs
> and initializing pad LEDs/remotes. Those later steps can fail, but their
> error paths currently release Wacom resources without stopping the HID
> hardware.
>
> Route post-hid_hw_start() failures through hid_hw_stop() before
> releasing driver resources.
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start")
> Cc: stable@vger.kernel.org
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> Changes in v2:
> - Drop fail_quirks and use fail_hw_stop for every post-hid_hw_start()
> failure path, as suggested by Dmitry.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 5/7] iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:51 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-5-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unconditional pointer casts in `incl_3d_capture_sample` cause unaligned memory access, endianness mismatch, and out-of-bounds field reads.
--
commit ffa9a4c020f23415f0ba3c3eae4063a4d5e16403
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
This commit replaces the bare 'unsigned' type with 'u32' for the usage_id
variable in several callback handlers. This change aligns the code with the
expected callback API types and improves clarity. There are no functional
changes introduced by this patch.
> diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c b/drivers/iio/orientation/hid-sensor-incl-3d.c
> index 4e23a598a3fb9..c7fbff498be7a 100644
> --- a/drivers/iio/orientation/hid-sensor-incl-3d.c
> +++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
[ ... ]
> /* Capture samples in local storage */
> static int incl_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is a pre-existing issue, but while reviewing this signature update I
noticed a potential memory access problem.
Looking further down in incl_3d_capture_sample(), raw_data is directly cast
and dereferenced:
switch (usage_id) {
case HID_USAGE_SENSOR_ORIENT_TILT_X:
incl_state->scan.incl_val[CHANNEL_SCAN_INDEX_X] = *(u32 *)raw_data;
And for timestamps:
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
incl_state->timestamp =
hid_sensor_convert_timestamp(&incl_state->common_attributes,
*(s64 *)raw_data);
Can this direct pointer casting trigger unaligned memory access exceptions on
architectures that do not natively support them?
Additionally, since HID report data is explicitly little-endian, does casting
the byte stream to a native u32 or s64 pointer cause it to read reversed
bytes on big-endian architectures?
Finally, the callback does not appear to check the raw_len parameter. If the
HID field is 16-bit or a 32-bit timestamp, will the unconditional 32-bit or
64-bit dereference fetch adjacent HID fields or uninitialized buffer padding,
potentially corrupting the reported sensor value?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 0/7] ASUS Zenbook Duo keyboard support
From: Jiri Kosina @ 2026-06-10 15:54 UTC (permalink / raw)
To: Paolo Pisati; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20260513163248.16483-1-p.pisati@gmail.com>
On Wed, 13 May 2026, Paolo Pisati wrote:
> Add support for the ASUS Zenbook Duo line of usb/BT wireless convertible keyboards.
>
> This patchset is a collective effort, gathered here:
>
> https://github.com/NeroReflex/asusctl/issues/25
Applied to hid.git#for-7.2/asus, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 7/7] iio: pressure: hid-sensor-press: use u32 instead of unsigned
From: sashiko-bot @ 2026-06-10 15:55 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260610-6-june-hid-iio-correct-usage-id-v2-7-c3c5f0720493@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Unsafe casting and blind dereferencing of `raw_data` causes unaligned memory accesses and Endianness data corruption.
- [High] Failure to reset the timestamp variable causes stale timestamps to be pushed continuously.
--
commit e758a7e12e760b133513494eca06c038aeaa377a
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: pressure: hid-sensor-press: use u32 instead of unsigned
This patch changes the usage_id parameter type from unsigned to u32 in
callback functions. This aligns the signature with the expected callback
API and improves code clarity without making functional changes.
> diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
> index a039b99d9851d..3e47a10d72a89 100644
> --- a/drivers/iio/pressure/hid-sensor-press.c
> +++ b/drivers/iio/pressure/hid-sensor-press.c
> @@ -155,7 +155,7 @@ static const struct iio_info press_info = {
>
> /* Callback handler to send event after all samples are received and captured */
> static int press_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(priv);
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing issue
with how the timestamp is handled in press_proc_event().
If the timestamp is zero, it gets populated with the current system time:
press_proc_event() {
...
if (atomic_read(&press_state->common_attributes.data_ready)) {
if (!press_state->timestamp)
press_state->timestamp = iio_get_time_ns(indio_dev);
iio_push_to_buffers_with_ts(indio_dev, &press_state->scan,
sizeof(press_state->scan),
press_state->timestamp);
}
...
}
However, the driver doesn't seem to reset press_state->timestamp back to zero
after pushing the buffer. Will this cause the first recorded software timestamp
to be continuously reused for all subsequent readings if the hardware does not
provide its own timestamp?
[ ... ]
> @@ -176,7 +176,7 @@ static int press_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int press_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
[Severity: High]
This is also a pre-existing issue, but while looking at press_capture_sample(),
could the direct cast of raw_data cause memory alignment or endianness problems?
press_capture_sample() {
...
switch (usage_id) {
case HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE:
press_state->scan.press_data = *(u32 *)raw_data;
ret = 0;
break;
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
press_state->timestamp = hid_sensor_convert_timestamp(
&press_state->common_attributes, *(s64 *)raw_data);
break;
...
}
Since raw_data points directly into the packed HID report buffer, which is
unaligned, does directly casting it to a u32 or s64 pointer violate C
alignment rules and risk kernel panics on architectures without unaligned
memory access support?
Additionally, since HID reports are little endian, wouldn't casting directly
on a big endian platform reverse the byte order? For example, if reading a
16-bit field on a big endian system, could this place the actual data into
the upper 16 bits of the u32, resulting in garbage data being sent to
userspace?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH] HID: pidff: Use correct effect type in effect update
From: Jiri Kosina @ 2026-06-10 16:00 UTC (permalink / raw)
To: Oleg Makarenko
Cc: bentiss, stable, Oliver Roundtree, Ryno Kotzé,
Tomasz Pakuła, Anssi Hannula, Dmitry Torokhov, linux-input,
linux-usb, linux-kernel
In-Reply-To: <20260609160031.493353-1-oleg@makarenk.ooo>
On Tue, 9 Jun 2026, Oleg Makarenko wrote:
> When updating an existing effect, the effect type from the last created
> effect was sent to the device instead of the updated one.
> This caused incorrect reports when a game creates multiple different
> effects and updates only one that is not the last created.
>
> Fixes FFB in multiple games that create multiple simultaneous effects
> (Forza Horizon 5/6).
>
> Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices")
> Cc: <stable@vger.kernel.org>
> Tested-by: Oliver Roundtree <oroundtree1@gmail.com>
> Co-developed-by: Ryno Kotzé <lemon.xah@gmail.com>
> Signed-off-by: Ryno Kotzé <lemon.xah@gmail.com>
> Signed-off-by: Oleg Makarenko <oleg@makarenk.ooo>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v5 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Jiri Kosina @ 2026-06-10 16:18 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Dmitry Torokhov, Benjamin Tissoires, linux-input
In-Reply-To: <20260512200051.2534081-1-vi@endrift.com>
On Tue, 12 May 2026, Vicki Pfau wrote:
> This series adds preliminary support for Switch 2 controllers using the
> same split-driver model as previous versions. This is a minor iteration on
> v4, fixing some leaked input_dev objects in error paths as well as fixing a
> merge/rebase error when CONFIG_PM ifdefs got removed in 7.0.
>
> Vicki Pfau (3):
> HID: nintendo: Add preliminary Switch 2 controller driver
> HID: nintendo: Add rumble support for Switch 2 controllers
> HID: nintendo: Add unified report format support
>
> MAINTAINERS | 1 +
> drivers/hid/Kconfig | 19 +-
> drivers/hid/hid-ids.h | 4 +
> drivers/hid/hid-nintendo.c | 1504 ++++++++++++++++-
> drivers/hid/hid-nintendo.h | 72 +
> drivers/input/joystick/Kconfig | 11 +
> drivers/input/joystick/Makefile | 1 +
> drivers/input/joystick/nintendo-switch2-usb.c | 353 ++++
> 8 files changed, 1951 insertions(+), 14 deletions(-)
> create mode 100644 drivers/hid/hid-nintendo.h
> create mode 100644 drivers/input/joystick/nintendo-switch2-usb.c
Dmitry, do you have any review comments to the changes under
drivers/input/joystick, please?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: magicmouse: add haptic click configuration for Magic Trackpad 2
From: Jiri Kosina @ 2026-06-10 16:26 UTC (permalink / raw)
To: Christian Fressl; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260514171524.110189-1-christian@fressl.at>
On Thu, 14 May 2026, Christian Fressl wrote:
> Apple Magic Trackpad 2 devices support persistent haptic feedback
> configuration through feature reports 0x22 and 0x23. Add an opt-in
> module parameter to select either the verified silent-low profile or to
> disable haptic feedback.
>
> The default remains unchanged. The report payload format is
> reverse-engineered, so keep the existing payload bytes fixed and vary
> only the known 24-bit feedback value.
>
> The USB-C Trackpad exposes multiple HID interfaces. Use the one-shot
> actuator output report 0x53 only to identify the interface that accepts
> the persistent configuration reports; do not use it for the persistent
> setting itself.
>
> Tested on Apple Magic Trackpad USB-C 05ac:0324 with Ubuntu
> 6.17.0-23-generic. Compile-tested against HID for-next.
>
> Protocol information was derived from public reverse-engineering notes,
> then independently tested with local hardware.
>
> Link: https://github.com/mwyborski/Linux-Magic-Trackpad-2-Driver/issues/28#issuecomment-451625504
> Signed-off-by: Christian Fressl <christian@fressl.at>
> ---
> Changes in v2:
> - Cache haptic_click with READ_ONCE() before applying the setting.
[ ... snip ... ]
> +static int magicmouse_apply_haptic_click(struct hid_device *hdev)
> +{
> + unsigned int click = READ_ONCE(haptic_click);
Can you please elaborate on why the READ_ONCE() is needed specifically
here? I don't get it.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts
From: Jiri Kosina @ 2026-06-10 16:28 UTC (permalink / raw)
To: Dave Carey; +Cc: linux-input, Benjamin Tissoires
In-Reply-To: <CALPvRORBFHpbos=_xpBVchK-oSZF9EnY6n5-sAQGr=qiL13FbQ@mail.gmail.com>
On Thu, 14 May 2026, Dave Carey wrote:
> The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10
> does not clear stale contact slots when fingers are lifted. Each
> HID report contains up to 10 finger slots, but only the first
> ContactCount slots represent valid contacts; the remaining slots
> retain TipSwitch=1 with positions from previous touches.
>
> Raw HID capture confirms this: across a 60-second capture with
> repeated multi-finger gestures, 90% of frames had more TipSwitch=1
> slots than the reported ContactCount. The ContactCount field itself
> is always accurate.
>
> Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so
> the driver stops processing slots once ContactCount valid contacts
> have been consumed, discarding the stale ghost entries per HID
> specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in
> the class) ensures that any slot skipped by this guard is released
> via INPUT_MT_DROP_UNUSED at frame sync.
>
> Signed-off-by: Dave Carey <carvsdriver@gmail.com>
> Tested-by: Dave Carey <carvsdriver@gmail.com>
> ---
> This follows commit 108ac841 ("HID: multitouch: Fix Yoga Book 9 14IAH10
> touchscreen misclassification"), applied to hid/for-next on 2026-05-12,
> which established MT_CLS_YOGABOOK9I and added MT_QUIRK_NOT_SEEN_MEANS_UP.
>
> That fix made the touchscreens fully functional. With three or more
> fingers and repeated on/off gestures, ghost contacts then began appearing
> because the firmware leaves stale TipSwitch=1 data in slots beyond
> ContactCount. The capture showed patterns like cc=1 with 7 active slots,
> or cc=3 with 8 active slots, consistently across all gesture cycles.
> ContactCount was always the correct count. Verified ghost-free after this
> change across 6+ repeated three-finger swipe sequences.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: nintendo: add support for HORI Wireless Switch Pad
From: Jiri Kosina @ 2026-06-10 16:32 UTC (permalink / raw)
To: Hector Zelaya
Cc: Benjamin Tissoires, Daniel J. Ogorchock, linux-input,
linux-kernel, Joshua Peisach
In-Reply-To: <20260527-hori-support-v2-1-195c2f832112@hectorzelaya.dev>
On Wed, 27 May 2026, Hector Zelaya wrote:
> Add support for the HORI Wireless Switch Pad (vendor 0x0f0d, product
> 0x00f6), a licensed third-party Nintendo Switch Pro Controller.
>
> The controller reports controller type 0x06 (vs 0x03 for first-party
> Pro Controllers) and has the following quirks:
>
> - SPI flash calibration data is incompatible; use default stick
> calibration values instead.
> - X and Y button bits are swapped compared to first-party controllers;
> add a dedicated button mapping table.
> - Rumble and IMU enable may timeout (no vibration motor in hardware);
> treat as non-fatal for licensed controllers.
>
> Tested over Bluetooth on NixOS with kernel 7.0.5 and 7.0.10:
> - All 14 buttons map correctly
> - Player LED sets on connect
> - Sticks report correctly with default calibration
> - IMU/gyro data streams at 60Hz
> - D-pad reports on ABS_HAT0X/HAT0Y
>
> Device information:
> Bluetooth name: Lic Pro Controller
> Bluetooth HID: 0005:0F0D:00F6
>
> Assisted-by: Kiro:Auto [Amazon Kiro IDE]
> Signed-off-by: Hector Zelaya <hector@hectorzelaya.dev>
> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Jiri Kosina @ 2026-06-10 16:33 UTC (permalink / raw)
To: Helge Bahmann
Cc: Nehal Bakulchandra Shah, Sandeep Singh, Basavaraj Natikar,
Benjamin Tissoires, linux-hid, linux-input
In-Reply-To: <6879487.lOV4Wx5bFT@lothlorien>
On Mon, 27 Apr 2026, Helge Bahmann wrote:
> Add an input driver that interprets the "operation mode" sensor offered
> by the amd sfh on some laptop models.
>
> Add a quirk to make the driver work again with the Asus VivoBook
> VivoBook (turn off the "disable interrupts" flag).
>
> Expose the intr_disable flag as a module parameter in case it turns out
> to be needed on further laptop models.
>
> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
Basavaraj, could you please review this one? Thanks.
> ---
> drivers/hid/amd-sfh-hid/amd_sfh_client.c | 25 ++++++++------
> drivers/hid/amd-sfh-hid/amd_sfh_hid.c | 43 ++++++++++++++++++++++++
> drivers/hid/amd-sfh-hid/amd_sfh_hid.h | 6 ++++
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 9 +++++
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.h | 3 ++
> 5 files changed, 75 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> index 7017bfa59093..a24757c5a203 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> @@ -128,10 +128,16 @@ void amd_sfh_work_buffer(struct work_struct *work)
> guard(mutex)(&mp2->lock);
> for (i = 0; i < cli_data->num_hid_devices; i++) {
> if (cli_data->sensor_sts[i] == SENSOR_ENABLED) {
> - report_size = mp2->mp2_ops->get_in_rep(i, cli_data->sensor_idx[i],
> - cli_data->report_id[i], in_data);
> - hid_input_report(cli_data->hid_sensor_hubs[i], HID_INPUT_REPORT,
> - in_data->input_report[i], report_size, 0);
> + if (cli_data->hid_sensor_hubs[i]) {
> + report_size = mp2->mp2_ops->get_in_rep(i, cli_data->sensor_idx[i],
> + cli_data->report_id[i],
> + in_data);
> + hid_input_report(cli_data->hid_sensor_hubs[i], HID_INPUT_REPORT,
> + in_data->input_report[i], report_size, 0);
> + } else if (cli_data->sensor_idx[i] == op_idx &&
> + cli_data->modeswitch_input) {
> + amdtp_modeswitch_report(i, cli_data->modeswitch_input, in_data);
> + }
> }
> }
> schedule_delayed_work(&cli_data->work_buffer, msecs_to_jiffies(AMD_SFH_IDLE_LOOP));
> @@ -327,15 +333,12 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
>
> for (i = 0; i < cl_data->num_hid_devices; i++) {
> cl_data->cur_hid_dev = i;
> - if (cl_data->sensor_idx[i] == op_idx) {
> - dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
> - cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
> - cl_data->sensor_sts[i]);
> - continue;
> - }
>
> if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
> - rc = amdtp_hid_probe(i, cl_data);
> + if (cl_data->sensor_idx[i] != op_idx)
> + rc = amdtp_hid_probe(i, cl_data);
> + else
> + rc = amdtp_modeswitch_probe(i, cl_data);
> if (rc)
> goto cleanup;
> } else {
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.c b/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> index 81f3024b7b1b..44008c02b63c 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> @@ -181,4 +181,47 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data)
> cli_data->hid_sensor_hubs[i] = NULL;
> }
> }
> +
> + /* note: cli_data->modeswitch_input implicitly cleaned by devres */
> +}
> +
> +int amdtp_modeswitch_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data)
> +{
> + struct amd_mp2_dev *mp2 = container_of(cli_data->in_data, struct amd_mp2_dev, in_data);
> + struct device *dev = &mp2->pdev->dev;
> + struct input_dev *input;
> + int rc;
> +
> + input = devm_input_allocate_device(dev);
> + if (IS_ERR(input))
> + return PTR_ERR(input);
> +
> + input->name = "AMD SFH tablet mode switch sensor";
> + input->id.bustype = BUS_PCI;
> +
> + input_set_capability(input, EV_SW, SW_TABLET_MODE);
> +
> + rc = input_register_device(input);
> + if (rc)
> + goto cleanup;
> +
> + cli_data->modeswitch_input = input;
> +
> + return 0;
> +
> +cleanup:
> + return rc;
> +}
> +
> +void amdtp_modeswitch_report(u32 index, struct input_dev *input, struct amd_input_data *in_data)
> +{
> + u32 *sensor_virt_addr = in_data->sensor_virt_addr[index];
> + u32 value = sensor_virt_addr[0];
> +
> + if (value == AMD_SFH_OP_IDX_MODE_TABLET)
> + input_report_switch(input, SW_TABLET_MODE, 1);
> + else
> + input_report_switch(input, SW_TABLET_MODE, 0);
> +
> + input_sync(input);
> }
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> index 7452b0302953..20aff7b75fbd 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> @@ -11,6 +11,8 @@
> #ifndef AMDSFH_HID_H
> #define AMDSFH_HID_H
>
> +#include <linux/input.h>
> +
> #define MAX_HID_DEVICES 7
> #define AMD_SFH_HID_VENDOR 0x1022
> #define AMD_SFH_HID_PRODUCT 0x0001
> @@ -50,6 +52,7 @@ struct amdtp_cl_data {
> u8 sensor_idx[MAX_HID_DEVICES];
> u8 *feature_report[MAX_HID_DEVICES];
> u8 request_done[MAX_HID_DEVICES];
> + struct input_dev *modeswitch_input;
> struct amd_input_data *in_data;
> struct delayed_work work;
> struct delayed_work work_buffer;
> @@ -78,4 +81,7 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data);
> int amd_sfh_get_report(struct hid_device *hid, int report_id, int report_type);
> void amd_sfh_set_report(struct hid_device *hid, int report_id, int report_type);
> void amdtp_hid_wakeup(struct hid_device *hid);
> +int amdtp_modeswitch_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data);
> +void amdtp_modeswitch_report(u32 index, struct input_dev *input, struct amd_input_data *in_data);
> +
> #endif
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> index 1d9f955573aa..cd9cff75f114 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> @@ -39,6 +39,8 @@ module_param_named(sensor_mask, sensor_mask_override, int, 0444);
> MODULE_PARM_DESC(sensor_mask, "override the detected sensors mask");
>
> static bool intr_disable = true;
> +module_param_named(intr_disable, intr_disable, bool, 0444);
> +MODULE_PARM_DESC(intr_disable, "override the interrupt disable sensor bit");
>
> static int amd_sfh_wait_response_v2(struct amd_mp2_dev *mp2, u8 sid, u32 sensor_sts)
> {
> @@ -317,6 +319,13 @@ static const struct dmi_system_id dmi_sfh_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook x360 435 G7"),
> },
> },
> + {
> + .callback = mp2_disable_intr,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "VivoBook_ASUSLaptop TP420UA_TM420UA"),
> + }
> + },
> {}
> };
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> index 2eb61f4e8434..5e968894ebe4 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> @@ -83,6 +83,9 @@ enum sensor_idx {
> als_idx = 19
> };
>
> +#define AMD_SFH_OP_IDX_MODE_LAPTOP 1
> +#define AMD_SFH_OP_IDX_MODE_TABLET 3
> +
> enum mem_use_type {
> USE_DRAM,
> USE_C2P_REG,
> --
> 2.47.3
>
>
>
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-10 16:34 UTC (permalink / raw)
To: Jun Yan
Cc: conor+dt, devicetree, dmitry.torokhov, krzk+dt, linux-input,
linux-kernel, robh
In-Reply-To: <20260610133458.970174-1-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On Wed, Jun 10, 2026 at 09:34:58PM +0800, Jun Yan wrote:
> > > > > + threshold, so counts differ.
> > > > > =3D20
> > > > > 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
> > > > > =3D20
> > > > > required:
> > > > > - reg
> > > > > @@ -199,6 +203,19 @@ allOf:
> > > > > reg:
> > > > > maximum: 1
> > > > > =3D20
> > > > > + - if:
> > > > > + properties:
> > > > > + compatible:
> > > > > + contains:
> > > > > + enum:
> > > > > + - microchip,cap1188
> > > >=20
> > > > 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?
> > > >=20
> > >=20
> > > Previously, the LED reg property had a default maximum of 7 for CAP1188.=
> > =20
> > > With the addition of CAP1114, the default maximum is now 11.=20
> > > An if-then constraint is added to limit the LED count for CAP1188.
> >
> > Ah, is this because cap1188 is the only existing device in the binding
> > that actually has LEDs?
>
> - CAP1126: max 2 LED channels (0-1)
> - CAP1188: max 8 LED channels (0-7)
> - CAP1106, CAP12xx: no LED support
>
> The LED reg property constraints for CAP1126 were added in Patch 3 [1].
>
> [1] https://lore.kernel.org/linux-input/20260606150458.250606-4-jerrysteve1101@gmail.com/
Okay, that makes more sense now. Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: hid-goodix-spi: validate report size to prevent stack buffer overflow
From: Jiri Kosina @ 2026-06-10 16:35 UTC (permalink / raw)
To: Tianchu Chen; +Cc: bentiss, linux-input, linux-kernel, stable
In-Reply-To: <f7e444a3facbe5fb2627167ab205771476e46bc8@linux.dev>
On Fri, 29 May 2026, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
>
> goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack
> buffer (tmp_buf), writing an 11-12 byte header followed by the
> caller-supplied report data. The HID core caps report size at
> HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set
> hid_ll_driver.max_buffer_size and performs no bounds checking before
> copying the payload:
>
> memcpy(tmp_buf + tx_len, buf, len);
>
> A hidraw SET_REPORT ioctl with a report larger than ~116 bytes
> overflows the stack buffer.
>
> Add a size check after constructing the header, rejecting reports that
> would exceed the buffer capacity.
>
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
>
> Fixes: 75e16c8ce283 ("HID: hid-goodix: Add Goodix HID-over-SPI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Applied, thanks and sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads
From: Jiri Kosina @ 2026-06-10 16:41 UTC (permalink / raw)
To: Zhang Lixu
Cc: Jonathan Cameron, Srinivas Pandruvada, Benjamin Tissoires,
David Lechner, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260610082911.157232-2-lixu.zhang@intel.com>
On Wed, 10 Jun 2026, Zhang Lixu wrote:
> From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
> sensor_hub_input_attr_get_raw_value() is limited to returning a single
> 32-bit value, which is insufficient for sensors that report data larger
> than 32 bits, such as a quaternion with four s16 elements.
>
> Add sensor_hub_input_attr_read_values() that accepts a caller-provided
> buffer and accumulates incoming data until the buffer is full. The two
> paths are distinguished in sensor_hub_raw_event() by pending.max_raw_size
> being non-zero, preserving backward compatibility.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Co-developed-by: Zhang Lixu <lixu.zhang@intel.com>
> Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Jiri Kosina <jkosina@suse.com>
Jonathan, will you take the whole lot through your tree?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1] Input: Drop unused assignments from pnp_device_id arrays
From: Dmitry Torokhov @ 2026-06-10 16:57 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Kees Cook, Werner Sembach, Christoffer Sandberg, feng, gongqi,
linux-input, linux-kernel
In-Reply-To: <ailQutR_TfyCQ-SP@monoceros>
On Wed, Jun 10, 2026 at 01:58:17PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello Dmitry,
>
> On Tue, Jun 09, 2026 at 11:12:49PM -0700, Dmitry Torokhov wrote:
> > On Tue, Jun 09, 2026 at 04:53:25PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > Explicitly assigning .driver_data in drivers that don't use this member
> > > is silly and a bit irritating. Drop these. Also simplify the list
> > > terminator entry to be just empty to match what most other device_id
> > > tables do.
> > >
> > > There is no changed semantic, not even a change in the compiled result.
> > >
> > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> > > ---
> > > drivers/input/gameport/ns558.c | 46 +++++++++++-----------
> > > drivers/input/serio/i8042-acpipnpio.h | 56 +++++++++++++--------------
> > > 2 files changed, 51 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/drivers/input/gameport/ns558.c b/drivers/input/gameport/ns558.c
> > > index fdece6ec1df3..f70a96c4f1fd 100644
> > > --- a/drivers/input/gameport/ns558.c
> > > +++ b/drivers/input/gameport/ns558.c
> > > @@ -148,29 +148,29 @@ static int ns558_isa_probe(int io)
> > > #ifdef CONFIG_PNP
> > >
> > > static const struct pnp_device_id pnp_devids[] = {
> > > - [...]
> > > - { .id = "", },
> > > + [...]
> > > + { }
> >
> > This goes BOOOM! You have to keep empty .id string as terminator.
>
> How so? Given that my patch doesn't modify the resulting ns558.o I doubt
> that. If .id was a char *, I'd agree, but it's a char[], so there should
> be no difference (and the compiler agrees).
Sorry, brain fart on my part.
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-10 17:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Arnd Bergmann, 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: <CADkSEUhh1NdOMTHVsErhqzyCpDGFA-FkNFaWp94e9LnB3njxqw@mail.gmail.com>
On Mon, Jun 08, 2026 at 10:13:50AM -0700, Ethan Nelson-Moore wrote:
> 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.
I see. In this case:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Basavaraj Natikar @ 2026-06-10 17:12 UTC (permalink / raw)
To: Helge Bahmann, Jiri Kosina, linux-input; +Cc: Basavaraj Natikar, bentiss
In-Reply-To: <2632507.ElGaqSPkdT@lothlorien>
On 5/14/2026 1:29 PM, Helge Bahmann wrote:
> [You don't often get email from hcb@chaoticmind.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Tue, 12 May 2026, Jiri Kosina wrote:
>> On Mon, 27 Apr 2026, Helge Bahmann wrote:
>>
>>> Add an input driver that interprets the "operation mode" sensor offered
>>> by the amd sfh on some laptop models.
>>>
>>> Add a quirk to make the driver work again with the Asus VivoBook
>>> VivoBook (turn off the "disable interrupts" flag).
>>>
>>> Expose the intr_disable flag as a module parameter in case it turns out
>>> to be needed on further laptop models.
>>>
>>> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
>> Basavaraj, can you please review this one?
> Some additional context, maybe helpful for review:
>
> 1. The numbers and behavior were extracted from the ACPI tables
> (WMI driver of sorts) of the notebook; I don't have access to any
> official AMD / ASUS docs or similar.
>
> 2. I have an alternate version of this change that is more indirect:
> - create a HID driver providing an "abstract table mode" message
> - have an input driver attaching to this newly defined HID driver
>
> While that is keeping "more in line" with the current driver
> architecture, I am not sure this indirection really helps. Particularly,
> there is no "canonical" HID tablet mode switch message defined,
> so it all remains completely bespoke. I am happy to change it if
> you prefer, but would need your input.
>
> 3. Since this is based on Asus VivoBook and its ACPI tables,
> there is a possibility that this "op sensor / tablet mode" behavior
> is not as universal as I surmise. A point could be made to make this
> entire behavior model-dependent (with a mod param to override
> / activate for other models). Happy to take input / advice.
Thanks Helge.
I'd like to go with the dedicated input-driver approach (your option with
a standalone input driver) rather than the HID-message indirection -- it
keeps clean subsystem boundaries.
For splitting the work, either of these works for me -- whichever you
prefer:
Option 1: I create the new input driver
drivers/input/misc/amd_sfh_tabletmode.c and once done we will review your ASUS VivoBook
quirk + intr_disable module-param patches on top of it.
Option 2: If you'd rather keep ownership of it, you write
drivers/input/misc/amd_sfh_tabletmode.c consuming the mode exposed by
amd-sfh, and I'll review and help.
Let me know which option you'd like and I'll proceed.
Thanks,
--
Basavaraj
^ permalink raw reply
* Re: [PATCH] input: remove changelogs, tracked in git
From: Dmitry Torokhov @ 2026-06-10 18:05 UTC (permalink / raw)
To: Elliot Tester; +Cc: linux-input, linux-kernel
In-Reply-To: <20260514193302.117488-1-elliotctester1@gmail.com>
On Thu, May 14, 2026 at 09:33:02PM +0200, Elliot Tester wrote:
> Signed-off-by: Elliot Tester <elliotctester1@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/7] ASUS Zenbook Duo keyboard support
From: Jiri Kosina @ 2026-06-10 18:06 UTC (permalink / raw)
To: Paolo Pisati; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <5sn10614-2s0s-7r22-s9p9-5np4921p047n@xreary.bet>
On Wed, 10 Jun 2026, Jiri Kosina wrote:
> > Add support for the ASUS Zenbook Duo line of usb/BT wireless convertible keyboards.
> >
> > This patchset is a collective effort, gathered here:
> >
> > https://github.com/NeroReflex/asusctl/issues/25
>
> Applied to hid.git#for-7.2/asus, thanks.
And now dropped due to build breakage reported by Benjamin's CI:
https://gitlab.freedesktop.org/bentiss/hid/-/jobs/102074691
Please fix that and resubmit, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - consolidate coordinate filtering logic
From: Aaro Koskinen @ 2026-06-10 18:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Kris Bahnsen, linux-input, Mark Featherston, Marek Vasut,
linux-kernel
In-Reply-To: <afzo03UP-shPfNMe@google.com>
Hi,
On Thu, May 07, 2026 at 12:35:04PM -0700, Dmitry Torokhov wrote:
> I think if you pull 'next' branch of my tree, then the following patches
> seem to apply cleanly on 7.0:
>
> c68bc840f06c ("Input: ads7846 - restore half-duplex support")
> 011bdf9f3a9d ("Input: ads7846 - consolidate coordinate filtering logic")
>
> I hope they also build ;)
>
> c68bc840f06c should appear in linux-next soon too.
Did you forgot to push this, or was it dropped? Because I fail to see
it any any tree...
A.
^ permalink raw reply
* Re: [PATCH] HID: uhid: convert to hid_safe_input_report()
From: Jiri Kosina @ 2026-06-10 18:32 UTC (permalink / raw)
To: Carlos Llamas
Cc: David Rheinsberg, Benjamin Tissoires, Lee Jones, kernel-team,
linux-kernel, stable, open list:UHID USERSPACE HID IO DRIVER
In-Reply-To: <20260606181552.3095967-1-cmllamas@google.com>
On Sat, 6 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>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ 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