* Re: [PATCH] Input: ads7846 - consolidate coordinate filtering logic
From: Kris Bahnsen @ 2026-05-11 20:20 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Aaro Koskinen, Mark Featherston, Marek Vasut,
linux-kernel
In-Reply-To: <afzo03UP-shPfNMe@google.com>
Dmitry,
On 5/7/26 12:35 PM, Dmitry Torokhov wrote:
> Hi Kris,
>
> On Thu, May 07, 2026 at 10:48:57AM -0700, Kris Bahnsen wrote:
>> On 5/4/26 9:54 PM, Dmitry Torokhov wrote:
>>> The ads7846 driver has two separate filtering functions,
>>> ads7846_filter() and ads7846_filter_one(), for the full-duplex and
>>> half-duplex SPI paths, respectively.
>>>
>>> They can be consolidated by extracting the core filtering logic for a
>>> single command into a helper function, ads7846_filter_cmd(), which
>>> iterates from l->skip to l->count. The half-duplex setup function is
>>> updated to set l->skip = l->count - 1 so that the helper only processes
>>> the last sample, preserving the original half-duplex behavior.
>>>
>>> Assisted-by: Gemini:gemini-3.1-pro
>>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>> ---
>>>
>>> Not tested so will appreciate if someone could give it a spin.
>>
>> Forgive my ignorance, but I am unsure of the base commit this applies
>> to and I'm unable to apply it to current HEAD of linux, linux-next,
>> or your input tree.
>>
>> I also am not easily able to test this if it doesn't cleanly apply
>> to the latest LTS, but will do what I can once I know what other
>> patches I would need to pull in to our tree.
>
> 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")
Please confirm that the referenced commits are pushed and that I
am using the correct remote URLs. I am unable to find the referenced
commits still:
$ git remote -v
input git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git (fetch)
input git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git (push)
next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch)
next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push)
[...]
$ git fetch next
$ git fetch input
$ git show c68bc840f06c
fatal: ambiguous argument 'c68bc840f06c': unknown revision or path not in the working tree.
$ git show 011bdf9f3a9d
fatal: ambiguous argument '011bdf9f3a9d': unknown revision or path not in the working tree.
Apologies in advance if I am missing something obvious.
> I hope they also build ;)
>
> c68bc840f06c should appear in linux-next soon too.
>
> Thanks.
>
--
Kris Bahnsen
Software Engineer
embeddedTS
^ permalink raw reply
* [PATCH] HID: magicmouse: add haptic click configuration for Magic Trackpad 2
From: Christian Fressl @ 2026-05-11 20:31 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Christian Fressl
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>
---
drivers/hid/hid-magicmouse.c | 101 ++++++++++++++++++++++++++++++++++-
1 file changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index e70bd3dc07ab..31002cb1f108 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -51,6 +51,10 @@ static bool report_undeciphered;
module_param(report_undeciphered, bool, 0644);
MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state field using a MSC_RAW event");
+static unsigned int haptic_click;
+module_param(haptic_click, uint, 0644);
+MODULE_PARM_DESC(haptic_click, "Haptic click feedback: 0=unchanged, 1=silent-low, 2=off");
+
#define TRACKPAD2_2021_BT_VERSION 0x110
#define TRACKPAD_2024_BT_VERSION 0x314
@@ -62,6 +66,17 @@ MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state fie
#define DOUBLE_REPORT_ID 0xf7
#define USB_BATTERY_TIMEOUT_SEC 60
+#define TRACKPAD2_HAPTIC_CLICK_REPORT_ID 0x22
+#define TRACKPAD2_HAPTIC_RELEASE_REPORT_ID 0x23
+#define TRACKPAD2_HAPTIC_ACTUATOR_REPORT_ID 0x53
+#define TRACKPAD2_HAPTIC_REPORT_LEN 14
+#define TRACKPAD2_HAPTIC_CLICK_UNCHANGED 0
+#define TRACKPAD2_HAPTIC_CLICK_SILENT_LOW 1
+#define TRACKPAD2_HAPTIC_CLICK_OFF 2
+#define TRACKPAD2_HAPTIC_SILENT_CLICK 0x000015
+#define TRACKPAD2_HAPTIC_SILENT_RELEASE 0x000010
+#define TRACKPAD2_HAPTIC_OFF 0x000000
+
/* These definitions are not precise, but they're close enough. (Bits
* 0x03 seem to indicate the aspect ratio of the touch, bits 0x70 seem
* to be some kind of bit mask -- 0x20 may be a near-field reading,
@@ -812,6 +827,81 @@ static bool is_usb_magictrackpad2(__u32 vendor, __u32 product)
product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2_USBC;
}
+static bool magicmouse_is_haptic_interface(struct hid_device *hdev)
+{
+ struct hid_report_enum *report_enum;
+
+ report_enum = &hdev->report_enum[HID_OUTPUT_REPORT];
+
+ /*
+ * The persistent haptic configuration reports are accepted as feature
+ * reports, but are not advertised in the feature report descriptor.
+ * Report 0x53 is the one-shot actuator output report and identifies
+ * the HID interface that accepts the persistent reports.
+ */
+ return report_enum->report_id_hash[TRACKPAD2_HAPTIC_ACTUATOR_REPORT_ID];
+}
+
+static int magicmouse_send_haptic_report(struct hid_device *hdev, u8 report_id,
+ u32 feedback)
+{
+ static const u8 report_template[TRACKPAD2_HAPTIC_REPORT_LEN] = {
+ 0x00, 0x01, 0x00, 0x78, 0x02, 0x00, 0x24,
+ 0x30, 0x06, 0x01, 0x00, 0x18, 0x48, 0x13,
+ };
+ u8 *buf;
+ int ret;
+
+ buf = kmemdup(report_template, sizeof(report_template), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = report_id;
+ buf[2] = feedback & 0xff;
+ buf[5] = (feedback >> 8) & 0xff;
+ buf[10] = (feedback >> 16) & 0xff;
+
+ ret = hid_hw_raw_request(hdev, buf[0], buf, TRACKPAD2_HAPTIC_REPORT_LEN,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+ kfree(buf);
+
+ return ret;
+}
+
+static int magicmouse_apply_haptic_click(struct hid_device *hdev)
+{
+ u32 click_feedback;
+ u32 release_feedback;
+ int ret;
+
+ if (haptic_click == TRACKPAD2_HAPTIC_CLICK_UNCHANGED)
+ return 0;
+
+ switch (haptic_click) {
+ case TRACKPAD2_HAPTIC_CLICK_SILENT_LOW:
+ click_feedback = TRACKPAD2_HAPTIC_SILENT_CLICK;
+ release_feedback = TRACKPAD2_HAPTIC_SILENT_RELEASE;
+ break;
+ case TRACKPAD2_HAPTIC_CLICK_OFF:
+ click_feedback = TRACKPAD2_HAPTIC_OFF;
+ release_feedback = TRACKPAD2_HAPTIC_OFF;
+ break;
+ default:
+ hid_warn(hdev, "invalid haptic_click value %u\n", haptic_click);
+ return -EINVAL;
+ }
+
+ ret = magicmouse_send_haptic_report(hdev,
+ TRACKPAD2_HAPTIC_CLICK_REPORT_ID,
+ click_feedback);
+ if (ret < 0)
+ return ret;
+
+ return magicmouse_send_haptic_report(hdev,
+ TRACKPAD2_HAPTIC_RELEASE_REPORT_ID,
+ release_feedback);
+}
+
static int magicmouse_fetch_battery(struct hid_device *hdev)
{
#ifdef CONFIG_HID_BATTERY_STRENGTH
@@ -894,8 +984,17 @@ static int magicmouse_probe(struct hid_device *hdev,
if (is_usb_magicmouse2(id->vendor, id->product) ||
(is_usb_magictrackpad2(id->vendor, id->product) &&
- hdev->type != HID_TYPE_USBMOUSE))
+ hdev->type != HID_TYPE_USBMOUSE)) {
+ if (is_usb_magictrackpad2(id->vendor, id->product) &&
+ magicmouse_is_haptic_interface(hdev)) {
+ ret = magicmouse_apply_haptic_click(hdev);
+ if (ret < 0)
+ hid_warn(hdev,
+ "unable to apply haptic click setting (%d)\n",
+ ret);
+ }
return 0;
+ }
if (!msc->input) {
hid_err(hdev, "magicmouse input not registered\n");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/4] HID: hid-msi-claw: Add M-key mapping attributes
From: sashiko-bot @ 2026-05-11 20:51 UTC (permalink / raw)
To: Derek J. Clark; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260510043510.442807-3-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Data race on `drvdata->profile_pending` and lack of transaction atomicity during concurrent sysfs accesses.
--
commit b9bc6d29326e3dd3ed065aca7059668a1b674bc8
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi-claw: Add M-key mapping attributes
Adds sysfs attributes to remap the M1 and M2 rear buttons to up to 5 events
(gamepad, keyboard, or mouse) when in macro mode.
> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
> index 7a3cd940ec49e..60694d075d56f 100644
> --- a/drivers/hid/hid-msi-claw.c
> +++ b/drivers/hid/hid-msi-claw.c
[ ... ]
> +static int claw_buttons_store(struct device *dev, const char *buf, u8 mkey_idx)
> +{
[ ... ]
> +set_buttons:
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_WRITE_PROFILE_DATA, data, len, 8);
> + if (ret < 0)
> + goto err_free;
> +
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_SYNC_TO_ROM, NULL, 0, 0);
Is it possible for concurrent writers to interleave these commands?
Looking at mcu_property_out(), it takes the cfg_mutex internally, but there
is no lock held across both calls here. If a second writer executes its
WRITE_PROFILE_DATA before the first writer executes SYNC_TO_ROM, could the MCU
be left in an inconsistent state?
[ ... ]
> +static int claw_buttons_show(struct device *dev, char *buf, enum claw_key_index m_key)
> +{
[ ... ]
> + codes = (m_key == CLAW_KEY_M1) ? drvdata->m1_codes : drvdata->m2_codes;
> + drvdata->profile_pending = (m_key == CLAW_KEY_M1) ? CLAW_M1_PENDING : CLAW_M2_PENDING;
> +
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, len, 8);
Can concurrent reads of button_m1 and button_m2 race and corrupt the
profile_pending state?
If Thread A and Thread B access the sysfs attributes simultaneously,
profile_pending is updated locklessly here before mcu_property_out() takes
the cfg_mutex.
Could Thread B overwrite profile_pending to CLAW_M2_PENDING before Thread A's
command executes? If so, when the hardware replies to Thread A's M1 command,
claw_profile_event() might route Thread A's data into Thread B's m2_codes
buffer and clear the state to CLAW_NO_PENDING.
This would cause Thread B's subsequent reply to be dropped and trigger the
"Got profile event without changes pending" warning.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510043510.442807-1-derekjohn.clark@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2] HID: pidff: Fix integer overflow in pidff_rescale
From: sashiko-bot @ 2026-05-11 20:56 UTC (permalink / raw)
To: Tomasz Pakuła; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260510122352.1161826-1-tomasz.pakula.oficjalny@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The subtraction `field->logical_maximum - field->logical_minimum` is evaluated in 32-bit arithmetic, allowing it to overflow before being promoted to `s64`.
- [High] The adjacent function `pidff_rescale_signed()` suffers from the exact same integer overflow vulnerability but was completely missed by the patch.
- [High] This problem wasn't introduced by this patch, but missing bounds check on `unit_exponent` in `pidff_rescale_time()` allows a kernel stall via a malicious HID descriptor.
--
commit d365813aa395ac1ce1eeffd147aa3beb65aba60b
Author: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
HID: pidff: Fix integer overflow in pidff_rescale
This commit attempts to fix an integer overflow in pidff_rescale by using a
64-bit signed integer for calculations. It addresses an issue where rescaling
values close to the maximum could temporarily exceed the 32-bit signed
integer range.
Closes: https://github.com/JacKeTUs/universal-pidff/issues/116
> diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
> index aee8a44433059..c45f182d04480 100644
> --- a/drivers/hid/usbhid/hid-pidff.c
> +++ b/drivers/hid/usbhid/hid-pidff.c
[ ... ]
> @@ -326,8 +327,10 @@ static s32 pidff_clamp(s32 i, struct hid_field *field)
> */
> static int pidff_rescale(int i, int max, struct hid_field *field)
> {
> - return i * (field->logical_maximum - field->logical_minimum) / max +
> - field->logical_minimum;
> + /* 64 bits needed for big values during rescale */
> + s64 result = field->logical_maximum - field->logical_minimum;
Since both logical_maximum and logical_minimum are 32-bit signed integers,
does the subtraction field->logical_maximum - field->logical_minimum evaluate
in 32-bit arithmetic and potentially overflow before being promoted to s64?
If an untrusted USB device provides a descriptor with extreme limits,
this difference could exceed the capacity of a 32-bit signed integer and wrap
around to a negative value. Should at least one operand be explicitly cast
to s64 before the subtraction?
> +
> + return div_s64(result * i, max) + field->logical_minimum;
> }
>
> /*
This isn't a regression introduced by this patch, but looking at the
adjacent pidff_rescale_signed() function:
drivers/hid/usbhid/hid-pidff.c:pidff_rescale_signed() {
...
if (i > 0)
return i * field->logical_maximum / S16_MAX;
...
}
Does the multiplication i * field->logical_maximum suffer from a similar
overflow?
Since both operands fit into an int, they evaluate in 32-bit signed
arithmetic. If a device advertises a logical_maximum greater than 65535,
could this multiplication silently overflow yielding a wrapped-around
negative value before the division takes place?
Also not introduced by this patch, but looking at pidff_rescale_time():
drivers/hid/usbhid/hid-pidff.c:pidff_rescale_time() {
...
int exponent = field->unit_exponent;
pr_debug("time field exponent: %d\n", exponent);
for (; exponent < FF_TIME_EXPONENT; exponent++)
scaled_time *= 10;
for (; exponent > FF_TIME_EXPONENT; exponent--)
scaled_time /= 10;
...
}
Are there any bounds checks on field->unit_exponent before it is used
in these loops?
The field->unit_exponent is parsed from untrusted USB device descriptors.
If a USB device provides a large 32-bit exponent value, could
this execute up to 2.14 billion iterations doing multiplications or
divisions without any early break checks?
Could this trigger a kernel stall or soft lockup when a user uploads a
force-feedback effect?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510122352.1161826-1-tomasz.pakula.oficjalny@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v5 3/6] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-05-11 21:19 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, linux-input, robh, krzk+dt, devicetree, dmitry.torokhov
In-Reply-To: <20260510110804.33045-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The YAML schema enforces a `ports` wrapper node for `audio-codec`, breaking validation for existing device trees.
- [Medium] The power button subnode name `key-power` conflicts with existing device trees, causing validation failures.
- [Medium] The `spi-cs-high` property was dropped from the `required` list during YAML conversion.
- [Low] The schema uses `additionalProperties: false` alongside a `$ref` in `allOf`, which is a dt-schema anti-pattern.
--
commit f0e021d94a5e3dc2af4a93b58f8cc3b052099a76
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..7f257f3a1a5a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -0,0 +1,414 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/motorola,cpcap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC MFD
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
[ ... ]
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
[ ... ]
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: port connected to the Stereo HiFi DAC
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: port connected to the Voice DAC
Will this cause validation failures for existing device trees?
The new YAML schema defines additionalProperties: false on the
audio-codec node and expects OF graph ports to be nested strictly
inside a ports child node. The original TXT binding example and existing
device trees place port@0 directly under the audio-codec node without
a ports wrapper.
[ ... ]
> + battery:
> + $ref: /schemas/power/supply/cpcap-battery.yaml#
> +
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
Is this node name conflict expected?
The schema strictly defines the power button child node as key-power,
but existing upstream device trees name this node button. Since button
is not explicitly defined in the YAML properties, will it be rejected by
dtbs_check?
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
> + - "#address-cells"
> + - "#size-cells"
Was spi-cs-high intentionally omitted from the required list?
The original TXT binding explicitly listed it under required properties,
and the hardware requires an active-high SPI chip select to function
correctly.
> +
> +additionalProperties: false
Should this be unevaluatedProperties: false instead?
In JSON schema, additionalProperties: false ignores properties inherited
from $ref inclusions inside allOf. This rejects standard SPI properties
unless they are manually duplicated in the local properties block.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510110804.33045-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 3/4] HID: hid-msi-claw: Add RGB control interface
From: sashiko-bot @ 2026-05-11 21:22 UTC (permalink / raw)
To: Derek J. Clark; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260510043510.442807-4-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] `speed_show()` incorrectly casts the LED class device pointer to a `hid_device`, leading to an out-of-bounds memory read and kernel crash.
- [High] Deadlock and missing return in `cfg_setup_fn` when handling initialization errors.
- [High] Sysfs attributes re-arm the cancelled delayed work after device teardown, leading to a Use-After-Free.
- [High] Racy nullification of `brightness_set` causes a TOCTOU NULL pointer dereference.
- [Medium] Communication failure in `claw_read_rgb_config` leaves the profile parser in a corrupted state.
--
commit 9663adbabcba6be0b443e7073133d650a790c871
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi-claw: Add RGB control interface
Adds RGB control interface for MSI Claw devices with 9 total zones and
supports up to 8 sequential frames of RGB zone data.
> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
> index 60694d075d56f..f4fe74a784c29 100644
> --- a/drivers/hid/hid-msi-claw.c
> +++ b/drivers/hid/hid-msi-claw.c
[ ... ]
> @@ -743,6 +836,389 @@ static const struct attribute_group claw_gamepad_attr_group = {
> .is_visible = claw_gamepad_attr_is_visible,
> };
>
> +/* Read RGB config from device */
> +static int claw_read_rgb_config(struct hid_device *hdev)
> +{
> + u8 data[4] = { 0x01, 0x00, 0x00, CLAW_RGB_FRAME_OFFSET };
> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
> + u16 read_addr = drvdata->rgb_addr;
> + size_t len = ARRAY_SIZE(data);
> + int ret, i;
> +
> + if (!drvdata->rgb_addr)
> + return -ENODEV;
> +
> + /* Loop through all 8 pages of RGB data */
> + for (i = 0; i < 8; i++) {
> + drvdata->profile_pending = CLAW_RGB_PENDING;
> + data[1] = (read_addr >> 8) & 0xff;
> + data[2] = read_addr & 0x00ff;
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, len, 8);
> + if (ret)
> + return ret;
If mcu_property_out() fails here, does drvdata->profile_pending remain set
to CLAW_RGB_PENDING? If a subsequent unrelated profile event or stray ACK
arrives, could claw_profile_event() incorrectly parse its payload as an RGB
frame?
[ ... ]
> +static ssize_t speed_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct hid_device *hdev = to_hid_device(dev);
> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
Since the rgb_attr_group attributes are attached to the LED class device
rather than the HID device, does to_hid_device(dev) result in an invalid
pointer dereference here? Other sysfs functions in this patch seem to
correctly use dev_get_drvdata(dev) to retrieve the led_classdev.
[ ... ]
> @@ -758,6 +1234,13 @@ static void cfg_setup_fn(struct work_struct *work)
> claw_remove(drvdata->hdev);
> }
>
> + ret = claw_read_rgb_config(drvdata->hdev);
> + if (ret) {
> + dev_err(drvdata->led_mc.led_cdev.dev,
> + "Failed to setup device, can't read RGB config: %d\n", ret);
> + claw_remove(drvdata->hdev);
> + }
If claw_remove() is called from within the cfg_setup worker thread, and
claw_remove() calls cancel_delayed_work_sync(&drvdata->cfg_setup), won't
this deadlock waiting for itself to complete?
Also, since there is no return statement after claw_remove() is called in
these error blocks, will this proceed to execute the rest of the function on
a stopped device?
[ ... ]
> @@ -881,6 +1405,9 @@ static void claw_remove(struct hid_device *hdev)
>
> if (drvdata->endpoint == CLAW_XINPUT_CFG_INTF_IN ||
> drvdata->endpoint == CLAW_DINPUT_CFG_INTF_IN) {
> + /* Block writes to brightness/multi_intensity during teardown */
> + drvdata->led_mc.led_cdev.brightness_set = NULL;
Is it safe to dynamically nullify the brightness_set callback here? If a
concurrent brightness update in the LED core checks the pointer, sees it as
valid, and then this nullification happens before the actual function call,
could it result in a NULL pointer dereference?
> + cancel_delayed_work_sync(&drvdata->rgb_queue);
Since the LED class device is registered with devres
(devm_led_classdev_multicolor_register), the sysfs attributes like effect,
speed, and enabled remain accessible until after claw_remove() completes.
If userspace writes to any of those attributes in this window, could
mod_delayed_work() re-arm rgb_queue, leading to a use-after-free when
drvdata is subsequently freed?
> sysfs_remove_group(&hdev->dev.kobj, &claw_gamepad_attr_group);
> cancel_delayed_work_sync(&drvdata->cfg_setup);
> cancel_delayed_work_sync(&drvdata->cfg_resume);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510043510.442807-1-derekjohn.clark@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v5 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: sashiko-bot @ 2026-05-11 21:37 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, dmitry.torokhov, linux-input, conor+dt, devicetree, krzk+dt
In-Reply-To: <20260510110804.33045-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The schema prevents the use of the generic `motorola,cpcap` fallback for the new compatible strings, which will break device probing.
--
commit 43b55cbad252ef116a236dfd195512e35a6f5c82
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> index 7f257f3a1a5a2..542d149d2b39c 100644
> --- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> @@ -14,9 +14,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: motorola,cpcap
> - - const: st,6556002
> + oneOf:
> + - enum:
> + - motorola,mapphone-cpcap
> + - motorola,mot-cpcap
Will this prevent the use of motorola,cpcap as a fallback for the new
compatible strings? It looks like this branch of the schema requires devices
to provide only a single compatible string.
Looking at the OMAP4 board code for Mapphone devices, it explicitly matches
against the generic motorola,cpcap string:
arch/arm/mach-omap2/pmic-cpcap.c:cpcap_init() {
...
if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
return -ENODEV;
...
}
By forbidding motorola,cpcap as a fallback in the bindings, will device trees
updated to pass schema validation (by using only the new specific compatibles)
fail to find the node at runtime in the board code?
If the node is not found, does this prevent the initialization of the CPCAP
PMIC voltage regulators on OMAP4 devices, breaking power management and
voltage scaling?
Could the schema permit motorola,cpcap as a fallback for the new compatible
strings, perhaps by using an items list with the new strings as the first
item and motorola,cpcap as the const fallback?
> +
> + - items:
> + - const: motorola,cpcap
> + - const: st,6556002
>
> reg:
> maxItems: 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510110804.33045-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 3/4] HID: hid-msi-claw: Add RGB control interface
From: Derek J. Clark @ 2026-05-11 21:55 UTC (permalink / raw)
To: sashiko, sashiko-bot; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260511212230.21800C2BCB0@smtp.kernel.org>
On May 11, 2026 2:22:29 PM PDT, sashiko-bot@kernel.org wrote:
>Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
>- [High] `speed_show()` incorrectly casts the LED class device pointer to a `hid_device`, leading to an out-of-bounds memory read and kernel crash.
>- [High] Deadlock and missing return in `cfg_setup_fn` when handling initialization errors.
>- [High] Sysfs attributes re-arm the cancelled delayed work after device teardown, leading to a Use-After-Free.
>- [High] Racy nullification of `brightness_set` causes a TOCTOU NULL pointer dereference.
>- [Medium] Communication failure in `claw_read_rgb_config` leaves the profile parser in a corrupted state.
>--
>
>commit 9663adbabcba6be0b443e7073133d650a790c871
>Author: Derek J. Clark <derekjohn.clark@gmail.com>
>
>HID: hid-msi-claw: Add RGB control interface
>
>Adds RGB control interface for MSI Claw devices with 9 total zones and
>supports up to 8 sequential frames of RGB zone data.
>
>> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
>> index 60694d075d56f..f4fe74a784c29 100644
>> --- a/drivers/hid/hid-msi-claw.c
>> +++ b/drivers/hid/hid-msi-claw.c
>
>[ ... ]
>
>> @@ -743,6 +836,389 @@ static const struct attribute_group claw_gamepad_attr_group = {
>> .is_visible = claw_gamepad_attr_is_visible,
>> };
>>
>> +/* Read RGB config from device */
>> +static int claw_read_rgb_config(struct hid_device *hdev)
>> +{
>> + u8 data[4] = { 0x01, 0x00, 0x00, CLAW_RGB_FRAME_OFFSET };
>> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
>> + u16 read_addr = drvdata->rgb_addr;
>> + size_t len = ARRAY_SIZE(data);
>> + int ret, i;
>> +
>> + if (!drvdata->rgb_addr)
>> + return -ENODEV;
>> +
>> + /* Loop through all 8 pages of RGB data */
>> + for (i = 0; i < 8; i++) {
>> + drvdata->profile_pending = CLAW_RGB_PENDING;
>> + data[1] = (read_addr >> 8) & 0xff;
>> + data[2] = read_addr & 0x00ff;
>> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, len, 8);
>> + if (ret)
>> + return ret;
>
>If mcu_property_out() fails here, does drvdata->profile_pending remain set
>to CLAW_RGB_PENDING? If a subsequent unrelated profile event or stray ACK
>arrives, could claw_profile_event() incorrectly parse its payload as an RGB
>frame?
>
Hi AI bot,
I am responding for the humans that will be reading this.
Valid. Pending should be reset after errors. TBS, I need to find a way to push pending assignment into the mutex, or there will be issues as found in the other message.
>[ ... ]
>
>> +static ssize_t speed_show(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct hid_device *hdev = to_hid_device(dev);
>> + struct claw_drvdata *drvdata = hid_get_drvdata(hdev);
>
>Since the rgb_attr_group attributes are attached to the LED class device
>rather than the HID device, does to_hid_device(dev) result in an invalid
>pointer dereference here? Other sysfs functions in this patch seem to
>correctly use dev_get_drvdata(dev) to retrieve the led_classdev.
>
Also valid, though it doesn't crash when run it would be more proper to treat the led cdev as the parent.
>
>> @@ -758,6 +1234,13 @@ static void cfg_setup_fn(struct work_struct *work)
>> claw_remove(drvdata->hdev);
>> }
>>
>> + ret = claw_read_rgb_config(drvdata->hdev);
>> + if (ret) {
>> + dev_err(drvdata->led_mc.led_cdev.dev,
>> + "Failed to setup device, can't read RGB config: %d\n", ret);
>> + claw_remove(drvdata->hdev);
>> + }
>
>If claw_remove() is called from within the cfg_setup worker thread, and
>claw_remove() calls cancel_delayed_work_sync(&drvdata->cfg_setup), won't
>this deadlock waiting for itself to complete?
Since it's a void function I can't return an error. I suppose it can just dev_err and return without initializing any sysfs attributes.
>Also, since there is no return statement after claw_remove() is called in
>these error blocks, will this proceed to execute the rest of the function on
>a stopped device?
>
>[ ... ]
>
>> @@ -881,6 +1405,9 @@ static void claw_remove(struct hid_device *hdev)
>>
>> if (drvdata->endpoint == CLAW_XINPUT_CFG_INTF_IN ||
>> drvdata->endpoint == CLAW_DINPUT_CFG_INTF_IN) {
>> + /* Block writes to brightness/multi_intensity during teardown */
>> + drvdata->led_mc.led_cdev.brightness_set = NULL;
>
>Is it safe to dynamically nullify the brightness_set callback here? If a
>concurrent brightness update in the LED core checks the pointer, sees it as
>valid, and then this nullification happens before the actual function call,
>could it result in a NULL pointer dereference?
This was done specifically to address a timing issue with the LED core and userspace writing to brightness during teardown. Without this we will get a null pointer dereference when the brightness function calls mcu_property_out.
>> + cancel_delayed_work_sync(&drvdata->rgb_queue);
>
>Since the LED class device is registered with devres
>(devm_led_classdev_multicolor_register), the sysfs attributes like effect,
>speed, and enabled remain accessible until after claw_remove() completes.
>
>If userspace writes to any of those attributes in this window, could
>mod_delayed_work() re-arm rgb_queue, leading to a use-after-free when
>drvdata is subsequently freed?
>
Swapping this and the sysfs remove after should solve it.
-
>> sysfs_remove_group(&hdev->dev.kobj, &claw_gamepad_attr_group);
>> cancel_delayed_work_sync(&drvdata->cfg_setup);
>> cancel_delayed_work_sync(&drvdata->cfg_resume);
>
^ permalink raw reply
* Re: [PATCH 2/4] HID: hid-msi-claw: Add M-key mapping attributes
From: Derek J. Clark @ 2026-05-11 21:59 UTC (permalink / raw)
To: sashiko, sashiko-bot; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260511205107.C2030C2BCB0@smtp.kernel.org>
On May 11, 2026 1:51:07 PM PDT, sashiko-bot@kernel.org wrote:
>Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>- [High] Data race on `drvdata->profile_pending` and lack of transaction atomicity during concurrent sysfs accesses.
>--
>
>commit b9bc6d29326e3dd3ed065aca7059668a1b674bc8
>Author: Derek J. Clark <derekjohn.clark@gmail.com>
>
>HID: hid-msi-claw: Add M-key mapping attributes
>
>Adds sysfs attributes to remap the M1 and M2 rear buttons to up to 5 events
>(gamepad, keyboard, or mouse) when in macro mode.
>
>> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
>> index 7a3cd940ec49e..60694d075d56f 100644
>> --- a/drivers/hid/hid-msi-claw.c
>> +++ b/drivers/hid/hid-msi-claw.c
>[ ... ]
>> +static int claw_buttons_store(struct device *dev, const char *buf, u8 mkey_idx)
>> +{
>[ ... ]
>> +set_buttons:
>> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_WRITE_PROFILE_DATA, data, len, 8);
>> + if (ret < 0)
>> + goto err_free;
>> +
>> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_SYNC_TO_ROM, NULL, 0, 0);
>
>Is it possible for concurrent writers to interleave these commands?
>
>Looking at mcu_property_out(), it takes the cfg_mutex internally, but there
>is no lock held across both calls here. If a second writer executes its
>WRITE_PROFILE_DATA before the first writer executes SYNC_TO_ROM, could the MCU
>be left in an inconsistent state?
>
No, the sync to rom simply writes the state to permanent memory so it remains in the same configuration after a power cycle. The first call writes it to temporary storage.
>[ ... ]
>> +static int claw_buttons_show(struct device *dev, char *buf, enum claw_key_index m_key)
>> +{
>[ ... ]
>> + codes = (m_key == CLAW_KEY_M1) ? drvdata->m1_codes : drvdata->m2_codes;
>> + drvdata->profile_pending = (m_key == CLAW_KEY_M1) ? CLAW_M1_PENDING : CLAW_M2_PENDING;
>> +
>> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, len, 8);
>
>Can concurrent reads of button_m1 and button_m2 race and corrupt the
>profile_pending state?
>
>If Thread A and Thread B access the sysfs attributes simultaneously,
>profile_pending is updated locklessly here before mcu_property_out() takes
>the cfg_mutex.
>
>Could Thread B overwrite profile_pending to CLAW_M2_PENDING before Thread A's
>command executes? If so, when the hardware replies to Thread A's M1 command,
>claw_profile_event() might route Thread A's data into Thread B's m2_codes
>buffer and clear the state to CLAW_NO_PENDING.
>
>This would cause Thread B's subsequent reply to be dropped and trigger the
>"Got profile event without changes pending" warning.
>
Possible. I'll look at improving this pattern by managing the pending flag with a mutex.
- Derek
^ permalink raw reply
* [BUG] ALSA: usb-audio: use-after-free in snd_dualsense_ih_match during rapid USB reconnect
From: Sean Brar @ 2026-05-11 21:58 UTC (permalink / raw)
To: linux-input, linux-sound
Cc: roderick.colenbrander, jikos, bentiss, perex, tiwai
A rapid USB disconnect/reconnect cycle on a DualSense controller
(054c:0ce6) triggers a use-after-free in snd_dualsense_ih_match()
(sound/usb/mixer_quirks.c), resulting in a general protection fault
and leaving the USB subsystem in an unrecoverable state requiring a
hard reboot.
Kernel version: 7.0.5-arch1-1 (also reproduced the trigger on
7.0.3-arch1-2; affected code in sound/usb/mixer_quirks.c is
unchanged on current mainline)
Hardware:
- Sony DualSense Wireless Controller (054c:0ce6, bcdDevice=1.00)
- hw_version=0x00000711, fw_version=0x0110002a
- Host: Gigabyte B550 AORUS PRO AC, BIOS F17 03/22/2024
Trigger condition:
When connected to a degraded USB port (intermittent electrical
contact), the DualSense enters a rapid disconnect/reconnect cycle.
snd_usb_audio times out (ETIMEDOUT, -110) querying mixer controls
during probe, each timeout triggers a USB reset, and the device
reconnects every 1–2 seconds. This is not a driver bug, it's the
expected kernel behavior when USB communication is unreliable, but
it creates a race window for the use-after-free described below.
The bug:
In sound/usb/mixer_quirks.c, snd_dualsense_ih_match() is invoked as
an input handler match callback from input_register_device() during
ps_probe() (hid_playstation). At line 575, it obtains a pointer to
the USB device struct:
snd_dev = mei->info.head.mixer->chip->dev;
It then uses this pointer in dev_warn() calls at lines 579 and 585:
dev_warn(&snd_dev->dev, "Failed to get input dev path\n");
dev_warn(&snd_dev->dev, "Failed to get USB dev path\n");
No reference is taken on snd_dev. If the USB device is concurrently
disconnected and freed while snd_dualsense_ih_match() is executing,
snd_dev becomes a dangling pointer. The dev_warn() call dereferences
snd_dev->dev.kobj.name via dev_vprintk_emit() → strnlen(), faulting
on the freed memory.
The OOPS offset (snd_dualsense_ih_match.cold+0xf/0x2b) corresponds
to the first dev_warn() at line 579. The compiler placed both error
branches in a cold section, and the offset is consistent with the
earlier branch.
OOPS:
Oops: general protection fault, probably for non-canonical address
0x441f0ffa1e0ff3: 0000 [#1] SMP NOPTI
CPU: 14 UID: 0 PID: 108 Comm: kworker/14:0 Not tainted 7.0.5-arch1-1
#1 PREEMPT(full)
Hardware name: Gigabyte Technology Co., Ltd. B550 AORUS PRO AC/B550
AORUS PRO AC, BIOS F17 03/22/2024
Workqueue: usb_hub_wq hub_event
RIP: 0010:strnlen+0x29/0x40
RSP: 0018:ffffce3f40537378 EFLAGS: 00010202
RAX: 00441f0ffa1e0ff3 RBX: 00441f0ffa1e0ff3 RCX: 0000000000000000
RDX: 00441f0ffa1e1003 RSI: 0000000000000010 RDI: 00441f0ffa1e0ff3
RBP: ffffce3f40537408 R08: 0000000000000000 R09: ffffce3f40537478
R10: 0000000000000004 R11: ffffffffc20ebe12 R12: ffff8943511c80b0
R13: ffff8943511c80b0 R14: ffff894345daf028 R15: ffffce3f40537418
FS: 0000000000000000(0000) GS:ffff8962144e7000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055e7f9dc3c18 CR3: 0000000135ffe000 CR4: 0000000000f50ef0
Stack trace:
Call Trace:
<TASK>
dev_vprintk_emit+0x70/0x1b0
dev_printk_emit+0x61/0x7b
__dev_printk+0x2d/0x70
_dev_warn+0x7f/0x99
snd_dualsense_ih_match.cold+0xf/0x2b [snd_usb_audio
a3e71fdbdb8c7ccfdfdb57dadc854b1d1e18445c]
input_attach_handler.isra.0+0x4b/0xa0
input_register_device.cold+0xf8/0x1f0
ps_probe+0xf79/0x10dc [hid_playstation
0cc5feea5231aa914fe418c8a06b14588cd5f064]
hid_device_probe+0x1b8/0x270
hid_add_device+0xcd/0x130
usbhid_probe+0x49b/0x6c0
usb_probe_interface+0xf8/0x2f0
usb_set_configuration+0x738/0x920
usb_generic_driver_probe+0x4a/0x70
usb_probe_device+0x44/0x170
usb_new_device.cold+0x154/0x3fd
hub_event+0x129d/0x1ad0
process_one_work+0x19c/0x3a0
worker_thread+0x1b1/0x310
kthread+0xe1/0x120
ret_from_fork+0x2bc/0x350
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---
Analysis:
The race is between two concurrent paths:
1. Probe: hub_event → usb_new_device → ... → ps_probe →
input_register_device → input_attach_handler →
snd_dualsense_ih_match (accesses USB device struct at line 575)
2. Disconnect: hub_event → usb_disconnect → ... → USB device
struct freed
snd_dualsense_ih_match() retrieves snd_dev via the mixer→chip→dev
chain at line 575 without taking a reference. A concurrent disconnect
can free the USB device struct before the subsequent dev_warn() call
dereferences it. The faulting RDI value (0x441f0ffa1e0ff3) is
non-canonical and consistent with SLUB freed-object poisoning,
confirming a use-after-free.
Impact:
After the OOPS, the USB subsystem is left in an unrecoverable state:
all USB ports stop enumerating devices (including ports not involved
in the reconnect cycle), and a clean shutdown hangs in USB driver
teardown. A hard reset is required. The trigger condition (rapid USB
reconnection due to a degraded port) is a normal hardware failure
mode.
Workaround:
# /etc/modprobe.d/dualsense.conf
options snd_usb_audio ignore_ctl_error=1
This suppresses the mixer control timeouts that drive the reconnect
cycle, preventing the race window from opening. DualSense headphone
jack audio controls may not function correctly with this option.
Steps to reproduce:
Disconnect/reconnect loop (the trigger condition):
1. Load hid_playstation and snd_usb_audio (default on standard
desktop kernels)
2. Connect a DualSense (054c:0ce6) via USB to a port with
unreliable electrical contact
3. Observe rapid disconnect/reconnect in dmesg -w, with device
number incrementing each cycle
The OOPS:
The OOPS was observed after the loop ran for several minutes. Exact
timing-dependent reproduction beyond triggering the loop is not
confirmed; this was observed once and not retested to avoid the
unrecoverable USB hang.
Kernel .config (7.0.5-arch1-1):
https://gist.github.com/seanbrar/d97a577efc3f48098d300105c4de398b
dmesg with OOPS (7.0.5-arch1-1):
https://gist.github.com/seanbrar/994ed882ca6f25b93e4763a8906d0fd5
dmesg with reconnect loop (7.0.3-arch1-2):
https://gist.github.com/seanbrar/188a75bf69fffe0d089f7aa82c6aebb6
^ permalink raw reply
* Re: [PATCH v5 5/6] mfd: motorola-cpcap: diverge configuration per-board
From: sashiko-bot @ 2026-05-11 22:08 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, linux-input, krzk+dt, robh, conor+dt, devicetree
In-Reply-To: <20260510110804.33045-6-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Device Tree ABI breakage for existing Mapphone boards and legacy compatibles
- [Low] Compiler warning (-Wpointer-to-int-cast) on 64-bit architectures due to direct pointer-to-enum cast
--
commit 31f4e82a2615f7d51f1707bf1ca43b9d741b3c90
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: motorola-cpcap: diverge configuration per-board
This commit separates the CPCAP subdevice configuration to support
different board-specific settings. It introduces a default composition
and renames the existing one for Mapphone boards.
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index d8243b956f875..f5a7fdd89dd5e 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
> @@ -195,20 +197,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
> return 0;
> }
>
> -static const struct of_device_id cpcap_of_match[] = {
> - { .compatible = "motorola,cpcap", },
> - { .compatible = "st,6556002", },
> - {},
> -};
Will existing device trees relying on the st,6556002 compatible string
fail to probe since it was removed from the match tables?
[ ... ]
> static int cpcap_probe(struct spi_device *spi)
> {
> struct cpcap_ddata *cpcap;
> + const struct mfd_cell *cells;
> + unsigned int num_cells;
> int ret;
>
> cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
> if (!cpcap)
> return -ENOMEM;
>
> + cpcap->variant = (enum cpcap_variant)spi_get_device_match_data(spi);
Could this direct cast from a pointer to an enum cause a compiler warning
(-Wpointer-to-int-cast) on 64-bit architectures?
spi_get_device_match_data() returns a const void *, which is 64 bits wide on
architectures like arm64, while enum cpcap_variant is typically a 32-bit
integer. Casting through a pointer-sized integer first might prevent this.
[ ... ]
> +static const struct of_device_id cpcap_of_match[] = {
> + {
> + .compatible = "motorola,cpcap",
> + .data = (void *)CPCAP_DEFAULT
> + }, {
Will this mapping break backwards compatibility for existing Mapphone boards?
Existing device trees use compatible = "motorola,cpcap" for the parent MFD
node, but define their child nodes with Mapphone-specific compatibles like
motorola,mapphone-cpcap-adc.
By mapping motorola,cpcap to CPCAP_DEFAULT, the driver now expects child
cells to use motorola,cpcap-adc. This means mfd_add_devices() might fail
to bind child platform devices to their DT nodes since
of_device_is_compatible() won't match.
If this happens, the child platform devices will be created with
pdev->dev.of_node == NULL, completely breaking driver probing for subdevices
on existing boards.
Could motorola,cpcap continue to map to the historical CPCAP_MAPPHONE
configuration to preserve the ABI?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510110804.33045-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH 4/4] HID: hid-msi-claw: Add Rumble Intensity Attributes
From: sashiko-bot @ 2026-05-11 22:09 UTC (permalink / raw)
To: Derek J. Clark; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260510043510.442807-5-derekjohn.clark@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] The underlying `mcu_property_out()` function uses an improperly scoped `guard(mutex)`, breaking all driver synchronization.
- [High] Unprotected modification of `drvdata->profile_pending` causes race conditions during concurrent sysfs reads.
- [High] Torn transactions in sysfs store handlers lead to state mismatch between hardware and software.
- [Medium] Failure to reset `drvdata->profile_pending` on `mcu_property_out()` error paths corrupts state machine.
--
commit 2a92587430af9e91f5af5fbf2205fea99b2d1000
Author: Derek J. Clark <derekjohn.clark@gmail.com>
HID: hid-msi-claw: Add Rumble Intensity Attributes
This commit adds intensity adjustment for the left and right rumble motors
via new sysfs attributes.
> diff --git a/drivers/hid/hid-msi-claw.c b/drivers/hid/hid-msi-claw.c
> index f4fe74a784c29..6d089f49abdb4 100644
> --- a/drivers/hid/hid-msi-claw.c
> +++ b/drivers/hid/hid-msi-claw.c
[ ... ]
> @@ -795,6 +811,116 @@ static ssize_t button_mapping_options_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(button_mapping_options);
>
> +static ssize_t rumble_intensity_left_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
[ ... ]
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_WRITE_PROFILE_DATA,
> + data, ARRAY_SIZE(data), 8);
> + if (ret)
> + return ret;
> +
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_SYNC_TO_ROM, NULL, 0, 0);
> + if (ret)
> + return ret;
> +
> + drvdata->rumble_intensity_left = val;
> +
> + return count;
> +}
Could this sequence introduce a regression if interrupted by concurrent sysfs
stores?
Since there doesn't appear to be a lock held across this sequence, concurrent
writes could interleave their WRITE_PROFILE_DATA and SYNC_TO_ROM commands.
This could cause the hardware to synchronize an unintended state or cause the
local driver state to fall out of sync with the actual hardware value.
Also, regarding the underlying mcu_property_out() function: does it use an
improperly scoped guard(mutex)? If the configuration mutex is acquired
strictly inside a limited scope, the lock would be released before
hid_hw_output_report() and wait_for_completion_interruptible_timeout() are
executed. This could leave all concurrent sysfs calls unprotected, causing a
regression with overlapping USB output reports.
> +static ssize_t rumble_intensity_left_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
[ ... ]
> + drvdata->profile_pending = CLAW_RUMBLE_LEFT_PENDING;
> + ret = mcu_property_out(hdev, CLAW_COMMAND_TYPE_READ_PROFILE, data, ARRAY_SIZE(data), 8);
> + if (ret)
> + return ret;
Is it possible for concurrent sysfs reads to cause a regression here?
Since drvdata->profile_pending is modified without any locking, if two sysfs
attributes are read concurrently, one thread's modification could overwrite
the other's state. When the asynchronous USB response later arrives,
claw_profile_event() might rely on this clobbered value to route the incoming
data, which could result in userspace reading incorrect data.
Additionally, if mcu_property_out() returns an error, the function returns
immediately but leaves drvdata->profile_pending set to the pending state.
Could this stale state cause a regression where a subsequent unrelated
asynchronous profile event is incorrectly intercepted by claw_profile_event()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260510043510.442807-1-derekjohn.clark@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH] Input: tsc2007 - fix resistance calculation when A/D value is saturated
From: sashiko-bot @ 2026-05-12 0:04 UTC (permalink / raw)
To: Yuki Horii; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260511054003.1205-1-horiiyuk@ishida.co.jp>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Uninitialized stack variable read in the IIO raw read path.
- [High] Returning 0 to invalidate saturated A/D values causes phantom touches with maximum pressure or premature pen-up events.
--
commit 8a6bcc1904d4e8b8d9d219e6c086925c53bfc4cb
Author: Yuki Horii <yuuki198708@gmail.com>
Input: tsc2007 - fix resistance calculation when A/D value is saturated
This patch modifies the touch resistance calculation to return 0 when either
the X or Y A/D value is saturated. This is intended to indicate that the
touch resistance calculation is invalid.
> diff --git a/drivers/input/touchscreen/tsc2007_core.c b/drivers/input/touchscreen/tsc2007_core.c
> index f9b3d2598933c..7d3bc0c396113 100644
> --- a/drivers/input/touchscreen/tsc2007_core.c
> +++ b/drivers/input/touchscreen/tsc2007_core.c
> @@ -69,9 +69,9 @@ u32 tsc2007_calculate_resistance(struct tsc2007 *tsc, struct ts_event *tc)
> {
> u64 rt = 0;
>
> - /* range filtering */
> - if (tc->x == MAX_12BIT)
> - tc->x = 0;
> + /* invalidate touch resistance if X or Y coordinate is saturated */
> + if (tc->x == MAX_12BIT || tc->y == MAX_12BIT)
Does this code read uninitialized stack memory? The IIO path initializes
tc.x, tc.z1, and tc.z2, but it does not initialize tc.y before passing the
struct to tsc2007_calculate_resistance():
drivers/input/touchscreen/tsc2007_iio.c:tsc2007_read_raw() {
...
case 5: {
struct ts_event tc;
tc.x = tsc2007_xfer(tsc, READ_X);
tc.z1 = tsc2007_xfer(tsc, READ_Z1);
tc.z2 = tsc2007_xfer(tsc, READ_Z2);
*val = tsc2007_calculate_resistance(tsc, &tc);
break;
}
...
}
> + return 0;
Is it safe to return 0 to invalidate the sample?
In tsc2007_soft_irq(), if there is no pendown GPIO, !rt evaluates to true
and prematurely breaks the polling loop, causing an early pen-up event.
If there is a pendown GPIO, rt <= ts->max_rt evaluates to true. Then the
driver calculates pressure as ts->max_rt - rt, which maps rt = 0 to the
maximum possible pressure. This results in a valid touch being reported at
the saturated coordinates with maximum pressure, rather than ignoring the
sample.
Should this instead return a value strictly greater than ts->max_rt (such as
U32_MAX) so the debouncing logic safely ignores the invalid sample?
>
> if (likely(tc->x && tc->z1)) {
> /* compute touch resistance using equation #1 */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511054003.1205-1-horiiyuk@ishida.co.jp?part=1
^ permalink raw reply
* [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, linux-iio, linux-input
This series refactors the HID sensor drivers to standardize the
initialization of the iio_chan_spec scan_type structure.
Direct initialization using compound literals was used.
This change improves code readability and ensures that all fields
of the scan_type structure are properly zero-initialized.
Additionally, for the hid-sensor-accel-3d driver, the channel
initialization loop was refactored to iterate directly over the
scan indices, eliminating redundant logic.
Natália Salvino André (6):
iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
iio: light: HID: hid-sensor-als: Refactor channel initialization
iio: light: HID: hid-sensor-prox: Refactor channel initialization
iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
initialization
iio: pressure: HID: hid-sensor-press: Refactor channel initialization
drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
drivers/iio/gyro/hid-sensor-gyro-3d.c | 24 +++++++----------
drivers/iio/light/hid-sensor-als.c | 18 +++++--------
drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
6 files changed, 42 insertions(+), 85 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH v3 1/6] iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
Clean up the channel initialization loop and replace the local
accel_3d_adjust_channel_bit_mask() function with a compound literal
to improve code readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++++----------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 2ff591b3458f..99ca67732bbe 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -119,17 +120,6 @@ static const struct iio_chan_spec gravity_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP),
};
-/* Adjust channel real bits based on report descriptor */
-static void accel_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int accel_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -297,19 +287,20 @@ static int accel_3d_parse_report(struct platform_device *pdev,
struct accel_3d_state *st)
{
int ret;
- int i;
- for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+ for (unsigned int ch = CHANNEL_SCAN_INDEX_X; ch <= CHANNEL_SCAN_INDEX_Z; ch++) {
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id,
- HID_USAGE_SENSOR_ACCEL_X_AXIS + i,
- &st->accel[CHANNEL_SCAN_INDEX_X + i]);
+ ch,
+ &st->accel[ch]);
if (ret < 0)
break;
- accel_3d_adjust_channel_bit_mask(channels,
- CHANNEL_SCAN_INDEX_X + i,
- st->accel[CHANNEL_SCAN_INDEX_X + i].size);
+ channels[ch].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->accel[ch].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
dev_dbg(&pdev->dev, "accel_3d %x:%x, %x:%x, %x:%x\n",
st->accel[0].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v3 2/6] iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
Replace the local gyro_3d_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index c340cc899a7c..4cbe4d93a0a1 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -82,17 +83,6 @@ static const struct iio_chan_spec gyro_3d_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
-/* Adjust channel real bits based on report descriptor */
-static void gyro_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int gyro_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -251,16 +241,20 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
int i;
for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+ unsigned int ch = CHANNEL_SCAN_INDEX_X + i;
+
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id,
HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + i,
- &st->gyro[CHANNEL_SCAN_INDEX_X + i]);
+ &st->gyro[ch]);
if (ret < 0)
break;
- gyro_3d_adjust_channel_bit_mask(channels,
- CHANNEL_SCAN_INDEX_X + i,
- st->gyro[CHANNEL_SCAN_INDEX_X + i].size);
+ channels[ch].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->gyro[ch].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
dev_dbg(&pdev->dev, "gyro_3d %x:%x, %x:%x, %x:%x\n",
st->gyro[0].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v3 3/6] iio: light: HID: hid-sensor-als: Refactor channel initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
Replace the local als_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/light/hid-sensor-als.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 384572844162..d72e260b8266 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -117,17 +118,6 @@ static const struct iio_chan_spec als_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
-/* Adjust channel real bits based on report descriptor */
-static void als_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int als_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -335,7 +325,11 @@ static int als_parse_report(struct platform_device *pdev,
channels[index] = als_channels[i];
st->als_scan_mask[0] |= BIT(i);
- als_adjust_channel_bit_mask(channels, index, st->als[i].size);
+ channels[index].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->als[i].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
++index;
dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v3 4/6] iio: light: HID: hid-sensor-prox: Refactor channel initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
Replace the local prox_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/light/hid-sensor-prox.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
index efa904a70d0e..edc9274a2c07 100644
--- a/drivers/iio/light/hid-sensor-prox.c
+++ b/drivers/iio/light/hid-sensor-prox.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2014, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -67,17 +68,6 @@ static const struct iio_chan_spec prox_channels[] = {
PROX_CHANNEL(false, 0),
};
-/* Adjust channel real bits based on report descriptor */
-static void prox_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int prox_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -250,8 +240,11 @@ static int prox_parse_report(struct platform_device *pdev,
st->scan_mask[0] |= BIT(index);
channels[index] = prox_channels[i];
channels[index].scan_index = index;
- prox_adjust_channel_bit_mask(channels, index,
- st->prox_attr[index].size);
+ channels[index].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->prox_attr[index].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
dev_dbg(&pdev->dev, "prox %x:%x\n", st->prox_attr[index].index,
st->prox_attr[index].report_id);
st->scale_precision[index] =
--
2.51.0
^ permalink raw reply related
* [PATCH v3 5/6] iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
Replace the local magn_3d_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 ++++++-------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index c673f9323e47..3b26dc41dd4c 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -132,17 +133,6 @@ static const struct iio_chan_spec magn_3d_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(7)
};
-/* Adjust channel real bits based on report descriptor */
-static void magn_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int magn_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -418,9 +408,11 @@ static int magn_3d_parse_report(struct platform_device *pdev,
if (i != CHANNEL_SCAN_INDEX_TIMESTAMP) {
/* Set magn_val_addr to iio value address */
st->magn_val_addr[i] = &st->iio_vals[*chan_count];
- magn_3d_adjust_channel_bit_mask(_channels,
- *chan_count,
- st->magn[i].size);
+ _channels[*chan_count].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->magn[i].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
(*chan_count)++;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v3 6/6] iio: pressure: HID: hid-sensor-press: Refactor channel initialization
From: Natália Salvino André @ 2026-05-12 1:16 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
Replace the local press_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/pressure/hid-sensor-press.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
index 5f1d6abda3e4..a039b99d9851 100644
--- a/drivers/iio/pressure/hid-sensor-press.c
+++ b/drivers/iio/pressure/hid-sensor-press.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2014, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -53,17 +54,6 @@ static const struct iio_chan_spec press_channels[] = {
};
-/* Adjust channel real bits based on report descriptor */
-static void press_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int press_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -225,8 +215,11 @@ static int press_parse_report(struct platform_device *pdev,
&st->press_attr);
if (ret < 0)
return ret;
- press_adjust_channel_bit_mask(channels, CHANNEL_SCAN_INDEX_PRESSURE,
- st->press_attr.size);
+ channels[CHANNEL_SCAN_INDEX_PRESSURE].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->press_attr.size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
dev_dbg(&pdev->dev, "press %x:%x\n", st->press_attr.index,
st->press_attr.report_id);
--
2.51.0
^ permalink raw reply related
* [PATCH] HID: quirks: Add ALWAYS_POLL quirk for SIGMACHIP USB mouse
From: hlleng @ 2026-05-12 1:57 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel, hlleng, stable
The SIGMACHIP USB mouse with VID/PID 1c4f:0034 can disconnect and
re-enumerate repeatedly after it has been enumerated if its interrupt
endpoint is not continuously polled.
This was observed with the device reporting itself as "SIGMACHIP Usb
Mouse". Keeping the input event device open avoids the disconnects.
Add HID_QUIRK_ALWAYS_POLL for this device so the HID core keeps polling
it even when there is no userspace input consumer.
Cc: stable@vger.kernel.org
Signed-off-by: hlleng <a909204013@gmail.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0cf637423..c07e90dbd 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1280,6 +1280,7 @@
#define USB_VENDOR_ID_SIGMA_MICRO 0x1c4f
#define USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD 0x0002
+#define USB_DEVICE_ID_SIGMA_MICRO_USB_MOUSE 0x0034
#define USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD2 0x0059
#define USB_VENDOR_ID_SIGMATEL 0x066F
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 9e88c9d6c..800b8f76d 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -187,6 +187,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SENNHEISER, USB_DEVICE_ID_SENNHEISER_BTD500USB), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD), HID_QUIRK_NO_INIT_REPORTS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_USB_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_SIGMATEL, USB_DEVICE_ID_SIGMATEL_STMP3780), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_SIS_TOUCH, USB_DEVICE_ID_SIS1030_TOUCH), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_SIS_TOUCH, USB_DEVICE_ID_SIS817_TOUCH), HID_QUIRK_NOGET },
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] Input: tsc2007 - fix resistance calculation when A/D value is saturated
From: 堀井裕樹 @ 2026-05-12 3:23 UTC (permalink / raw)
To: sashiko; +Cc: dmitry.torokhov, linux-input, andreas
In-Reply-To: <20260512000455.44AB2C2BCB0@smtp.kernel.org>
Thank you for AI review
> Does this code read uninitialized stack memory? The IIO path initializes
> tc.x, tc.z1, and tc.z2, but it does not initialize tc.y before passing the
> struct to tsc2007_calculate_resistance():
I knew this code existed, but I didn't realize it hadn't been initialized.
I'll fix it.
> Is it safe to return 0 to invalidate the sample?
>
> In tsc2007_soft_irq(), if there is no pendown GPIO, !rt evaluates to true
> and prematurely breaks the polling loop, causing an early pen-up event.
I'll fix it.
In the original code, I had set touch input to be disabled when the
value was 0, but after submitting the patch,
I realized that setting the resistance to infinity—rather than
disabling it at 0—would allow the interrupt handling to continue.
^ permalink raw reply
* Re: [PATCH] HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler
From: sashiko-bot @ 2026-05-12 4:49 UTC (permalink / raw)
To: Kean; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260511132854.1351379-1-rh_king@163.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unaligned memory access via direct pointer cast in raw event handler.
- [High] Missing input capability registration causes hotkey events to be silently dropped.
--
commit a1525e53f7f5fe161ed804808d59755ff69c771f
Author: Kean <rh_king@163.com>
HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler
In lenovo_raw_event(), the X12 Tab keyboard handler reads a 4-byte
little-endian value via *(__le32 *)data but only guards the access
with a size >= 3 check. If a 3-byte report with ID 0x03 is received,
the code reads one byte beyond the end of the buffer.
Change the size check to >= 4 to match the actual access width.
> diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
> index a6b73e03c16b3..4686ecb6cfa8e 100644
> --- a/drivers/hid/hid-lenovo.c
> +++ b/drivers/hid/hid-lenovo.c
> @@ -793,7 +793,7 @@ static int lenovo_raw_event(struct hid_device *hdev,
> */
> if (unlikely((hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB
> || hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB2)
> - && size >= 3 && report->id == 0x03))
> + && size >= 4 && report->id == 0x03))
> return lenovo_raw_event_TP_X12_tab(hdev, le32_to_cpu(*(__le32 *)data));
This isn't a regression from this patch, but could this direct pointer cast
lead to unaligned memory access exceptions?
The data pointer provided by the HID core can have arbitrary alignment
depending on the transport layer. For instance, if injected via uhid using
UHID_INPUT2, the payload data starts at an offset of 6 bytes from the start
of the uhid_event struct, which is 2-byte aligned but not 4-byte aligned.
On architectures that do not natively support unaligned memory access,
dereferencing an unaligned pointer triggers an unaligned access exception.
Would it be safer to use get_unaligned_le32(data) to safely extract the
value?
Also, another issue not introduced by this patch: do the hotkey events
processed by lenovo_raw_event_TP_X12_tab() get silently dropped by the input
core?
The lenovo_raw_event_TP_X12_tab() handler reports events for keys like
KEY_RFKILL, KEY_PERFORMANCE, and KEY_BOOKMARKS:
drivers/hid/hid-lenovo.c:lenovo_raw_event_TP_X12_tab() {
...
case TP_X12_RAW_HOTKEY_FN_F8:
if (hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB) {
report_key_event(input, KEY_RFKILL);
return 1;
}
report_key_event(input, KEY_PERFORMANCE);
return 1;
...
}
However, if these key capabilities are not registered in the input_dev's
keybit array during device initialization, the kernel's input core checks
is_event_supported(code, dev->keybit, KEY_MAX) and drops the events when
report_key_event() is called.
Are these custom hotkey capabilities properly registered during device setup
to prevent them from being filtered out?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511132854.1351379-1-rh_king@163.com?part=1
^ permalink raw reply
* Re: [PATCH v1 5/8] hid: Pen battery quirk for Surface Pro 12in
From: sashiko-bot @ 2026-05-12 6:07 UTC (permalink / raw)
To: Harrison Vanderbyl; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <2702fbde567457ea0835ba12cc29421590e688aa.1778498477.git.harrison.vanderbyl@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Macro value alignment uses spaces instead of a tab.
--
commit c48c3082a15452ea3cc6ed81c88834aa52ab9d60
Author: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
hid: Pen battery quirk for Surface Pro 12in
This commit adds a quirk to ignore the battery on the Surface Pro 12in
pen, which uses Bluetooth for battery reporting instead of I2C. This
prevents a phantom battery or device hang.
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -459,6 +459,7 @@
> #define USB_DEVICE_ID_HP_X2 0x074d
> #define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
> #define I2C_DEVICE_ID_CHROMEBOOK_TROGDOR_POMPOM 0x2F81
> +#define I2C_DEVICE_ID_SURFACE_PRO_12IN 0x4376
This isn't a bug, but it looks like spaces were used here instead of a tab
to align the macro value.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778498477.git.harrison.vanderbyl@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: skip autoconf on unregistering devices
From: Xu Rao @ 2026-05-12 9:24 UTC (permalink / raw)
To: jikos, bentiss; +Cc: linux-input, linux-kernel, raoxu
Hi Eric,
Thanks for the review.
> 1) I presume this targets the net tree, rather than net-next?
Yes, this is intended for the net tree. I will keep the subject as
"[PATCH net v2]".
> 2) Please add a Fixes: tag
I looked for a Fixes target, but I could not identify a single commit
which introduced this exact bug with enough confidence. The path which
can create an IPv6 link-local address from NETDEV_UP/NETDEV_CHANGE is
very old, while the failure depends on an unregister-time race between
rtnetlink flag changes, addrconf autoconfiguration, and netdev teardown.
Because this looks like a long-standing lifecycle gap exposed by this
race rather than a clear regression from one commit, I did not want to
add a misleading Fixes tag. If you prefer a historical Fixes tag for
netdev requirements, I can add the closest addrconf change you think is
appropriate in v2.
> 3) Why READ_ONCE() are needed there?
I used READ_ONCE() in v1 because dev->reg_state is written with
WRITE_ONCE() in the unregister path and netdev_reg_state() also reads it
with READ_ONCE(). However, addrconf_notify() is called from the
netdevice notifier path and does not need lockless access semantics for
this check. I will switch this to a plain dev->reg_state load in v2.
> 4) Make sure in V2 to CC netdev@ mailing list
> 5) Please wait ~24 hours before sending a V2.
I will also make sure to CC netdev@vger.kernel.org on v2 and will wait
about 24 hours before sending it, as requested.
Thanks,
Xu Rao
^ 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