* 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 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
* [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 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
* 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 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: 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 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 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 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
* [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] 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
* Re: [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Linus Walleij @ 2026-05-11 20:12 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Gary Bisson,
Val Packett, Julien Massot, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-5-l.scorcia@gmail.com>
On Mon, Apr 20, 2026 at 11:37 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
> the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This patch 4/9 applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler
From: Mark Pearson @ 2026-05-11 17:52 UTC (permalink / raw)
To: Kean, Derek J . Clark
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260511132854.1351379-1-rh_king@163.com>
On Mon, May 11, 2026, at 9:28 AM, Kean wrote:
> 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.
>
> Signed-off-by: Kean <rh_king@163.com>
> ---
> drivers/hid/hid-lenovo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
> index a6b73e03c16b..4686ecb6cfa8 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));
>
> return 0;
> --
> 2.53.0
Looks good to me. Thanks!
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Mark
^ permalink raw reply
* Re: [PATCH v3 7/9] iio: humidity: hid-sensor-humidity: use common device for devres
From: Jonathan Cameron @ 2026-05-11 16:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, jikos, srinivas.pandruvada, dlechner, nuno.sa,
andy, sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <agAo6fXUaoTwl326@ashevche-desk.local>
On Sun, 10 May 2026 09:42:49 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Sat, May 09, 2026 at 03:40:38PM +0530, Sanjay Chitroda wrote:
>
> > kmemdup() is used for memory that is logically tied to the HID
> > platform device, even though the driver binds into the IIO framework.
> >
> > Using &indio_dev->dev for devres allocations works functionally, but it
> > results in two separate devres ownership trees—one for the HID
> > platform device (pdev) and another for the IIO device (indio_dev).
> >
> > The devres framework is intended to have a single, well-defined parent
> > device. Since the memory originates from HID sensor probing and is not
> > IIO-specific, &pdev->dev is the correct and logical owner.
> >
> > Switch to using the platform device for devm_kmemdup() so that all
> > resources are released deterministically and consistently.
>
> This patch sounds like a required fix and has to be placed in the beginning of
> the series along with the Fixes tag.
Hmm. I always find these hard to prove...
Ultimately for a device for which no driver is ever bound I believe
the call to devres_release_all() in device_release() catches these.
That should I think happen when the last reference to the iio_dev->dev
is dropped (for the device we care about in the 'buggy' code).
Now that may well be at a different time to when it would happen on
the underlying bus device unbind. However here we are talking about
an allocation so as long as we release it at somepoint and that's late
enough (which it will be either way) then it's not a bug - it just makes
the code harder to reason about.
Jonathan
p.s. I remember testing the releases on some other drivers years ago
to figure out if they had an actual bug based on the pattern we have
here. It 'works' but yuk.
^ permalink raw reply
* Re: [PATCH v3 3/9] iio: hid-sensors: introduce device managed API
From: Jonathan Cameron @ 2026-05-11 16:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sanjay Chitroda, jikos, srinivas.pandruvada, dlechner, nuno.sa,
andy, sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <agAngXqFb5L2--AN@ashevche-desk.local>
On Sun, 10 May 2026 09:36:49 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Sat, May 09, 2026 at 03:40:34PM +0530, Sanjay Chitroda wrote:
>
> > hid_sensor_setup_trigger() is common API used for the HID IIO drivers,
> > prepare devm API devm_hid_sensor_setup_trigger() to acquire resource
> > during setup and release using device managed framework during drivers
> > fail, unbind or remove path.
> >
> > Register action with devm_add_action_or_reset() to release resource with
> > devres framework.
>
> ...
>
> > +int devm_hid_sensor_setup_trigger(struct device *dev, struct iio_dev *indio_dev,
> > + const char *name, struct hid_sensor_common *attrb)
>
> At this point don't we have indio_dev->dev.parent == dev?
yes probably but I'd rather we didn't use that. For devm calls it's nicer to have the
owner device explicit.
>
> > +{
> > + int ret;
> > +
> > + ret = hid_sensor_setup_trigger(indio_dev, name, attrb);
> > + if (ret)
> > + return ret;
> > +
> > + return devm_add_action_or_reset(dev, hid_sensor_remove_trigger_action, attrb);
> > +}
>
^ permalink raw reply
* Re: [PATCH v3 0/4] ROCK 4D audio enablement
From: Nicolas Frattaroli @ 2026-05-11 16:21 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Krzysztof Kozlowski, Cristian Ciocaltea
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
Hi Alexandre, and other maintainers,
On Wednesday, 8 April 2026 19:49:38 Central European Summer Time Nicolas Frattaroli wrote:
> The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
> no mic) and a headset (i.e., with mic). After some searching, it appears
> that the closest we can get to modelling this is by sending a particular
> switch input event.
>
> So this series modifies the adc-keys bindings, extends the adc-keys
> driver to allow sending other input types as well, and then adds the
> analog audio nodes to ROCK 4D's device tree.
>
> It should be noted that analog capture from the TRRS jack currently
> results in completely digitally silent audio for me, i.e. no data other
> than 0xFF. There's a few reasons why this could happen, chief among them
> that my SAI driver is broken or that the ES8328 codec driver is once
> again broken. The DAPM routes when graphed out look fine though. So the
> DTS part is correct, and I can fix the broken capture in a separate
> follow-up patch that doesn't have to include DT people.
>
> Another possibility is that my phone headset, despite being 4 rings and
> having a little pin hole at the back of the volume doodad, does not
> actually have a microphone, but in that case I'd still expect some noise
> in the PCM. Maybe it's just shy.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> Changes in v3:
> - bindings: use unevaluatedProperties instead of explicitly mentioning
> linux,input-type.
> - Link to v2: https://lore.kernel.org/r/20251215-rock4d-audio-v2-0-82a61de39b4c@collabora.com
>
> Changes in v2:
> - Drop HDMI audio patch, as it was already merged.
> - adc-keys: rename "keycode" to "code".
> - adc-keys: make the keycode (now "code") local a u32 instead of an int
> - adc-keys: only allow EV_KEY and EV_SW for now. Rename patch
> accordingly.
> - adc-keys: Add another patch to rework probe function error logging.
> - Link to v1: https://lore.kernel.org/r/20250630-rock4d-audio-v1-0-0b3c8e8fda9c@collabora.com
>
> ---
> Nicolas Frattaroli (4):
> dt-bindings: input: adc-keys: allow all input properties
> Input: adc-keys - support EV_SW as well, not just EV_KEY.
> Input: adc-keys - Use dev_err_probe in probe function
> arm64: dts: rockchip: add analog audio to ROCK 4D
>
> .../devicetree/bindings/input/adc-keys.yaml | 17 ++--
> arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 ++++++++++++++++++++++
> drivers/input/keyboard/adc-keys.c | 88 ++++++++++-----------
> 3 files changed, 147 insertions(+), 48 deletions(-)
> ---
> base-commit: 8de395f35e79d9168a78504fed495578ec7bac52
> change-id: 20250627-rock4d-audio-cfc07f168a08
>
> Best regards,
> --
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
>
What's the path forward here? All the patches are reviewed, but it
has been almost a month without them being applied now.
Which tree(s) would this be applied to, and who should I poke?
Thanks :)
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* [PATCH v1 5/8] hid: Pen battery quirk for Surface Pro 12in
From: Harrison Vanderbyl @ 2026-05-11 14:40 UTC (permalink / raw)
To: linux-arm-msm, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <cover.1778498477.git.harrison.vanderbyl@gmail.com>
The pen setup for this device uses bluetooth for
communicating battery levels and status instead of
reporting it over i2c.
Without this quirk, the device either reports an
extra, broken phantom battery, or hangs.
Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0cf63742315b..d16f55479786 100644
--- 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
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index d73cfa2e73d3..61ecd840d0bd 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -395,6 +395,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_AVOID_QUERY },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_CHROMEBOOK_TROGDOR_POMPOM),
HID_BATTERY_QUIRK_AVOID_QUERY },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_SURFACE_PRO_12IN),
+ HID_BATTERY_QUIRK_IGNORE },
/*
* Elan HID touchscreens seem to all report a non present battery,
* set HID_BATTERY_QUIRK_IGNORE for all Elan I2C and USB HID devices.
--
2.53.0
^ permalink raw reply related
* [PATCH] HID: lenovo: Fix buffer over-read in X12 Tab raw_event handler
From: Kean @ 2026-05-11 13:28 UTC (permalink / raw)
To: derekjohn.clark, mpearson-lenovo
Cc: jikos, bentiss, linux-input, linux-kernel, Kean
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.
Signed-off-by: Kean <rh_king@163.com>
---
drivers/hid/hid-lenovo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index a6b73e03c16b..4686ecb6cfa8 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));
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC 4/4] arm64: dts: qcom: milos-fairphone-fp6: add supply for Hall Effect sensor
From: Konrad Dybcio @ 2026-05-11 11:46 UTC (permalink / raw)
To: Griffin Kroah-Hartman, Dmitry Torokhov, Liam Girdwood, Mark Brown,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Luca Weiss
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20260508-gpiokeys-vdd-supply-v1-4-0bb32e8e6428@fairphone.com>
On 5/8/26 2:53 PM, Griffin Kroah-Hartman wrote:
> Add vdd-supply for the Hall Effect sensor in gpio-keys so that power for
> the sensor will be enabled when it's in use.
>
> With this, we can drop the regulator-always-on for vreg_l10b.
>
> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
> ---
Modulo whatever the supply name ends up being:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Thanks for shaving this yak!
Konrad
^ permalink raw reply
* Re: (subset) [PATCH 0/9] MT6365 PMIC support cleanup
From: AngeloGioacchino Del Regno @ 2026-05-11 9:36 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Louis-Alexis Eyraud
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-0-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:13 +0200, Louis-Alexis Eyraud wrote:
> Several Mediatek and Radxa boards, based on MT8370, MT8390 or MT8395
> SoC, integrate the MT6365 PMIC, that is a MT6359P variant:
> - Mediatek Genio 1200-EVK
> - Mediatek Genio 700-EVK
> - Mediatek Genio 510-EVK
> - Radxa NIO-12L
> It is compatible with the MT6359 PMIC.
>
> [...]
Applied to v7.1-next/dts64, thanks!
[6/9] arm64: dts: mediatek: add MT6365 PMIC include
commit: dd85b476c5bb164e5978e42867e1f4deb23b23fd
[7/9] arm64: dts: mediatek: mt8390-genio-common: use MT6365 PMIC definitions
commit: 38c2adaccd3618882e3c5b8ec76ef77a1ecb8de9
[8/9] arm64: dts: mediatek: mt8395-genio-common: use MT6365 PMIC definitions
commit: c264c7958a36ceedebedf8a437fa719906e4e1af
[9/9] arm64: dts: mediatek: mt8395-radxa-nio-12l: use MT6365 PMIC definitions
commit: 4d2b8fcd8bbd7f00335a52b86189d85686fdc707
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
From: AngeloGioacchino Del Regno @ 2026-05-11 9:25 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-3-6f43838be92f@collabora.com>
On 4/29/26 11:44, Louis-Alexis Eyraud wrote:
> Add compatible string for the pmic keys block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
From: AngeloGioacchino Del Regno @ 2026-05-11 9:25 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-2-6f43838be92f@collabora.com>
On 4/29/26 11:44, Louis-Alexis Eyraud wrote:
> MT6365 PMIC is compatible with MT6359, so add the compatible strings
> for the main and sub devices (regulator, rtc, audio codec).
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
From: AngeloGioacchino Del Regno @ 2026-05-11 9:25 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Dmitry Torokhov, Chen Zhong, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-4-6f43838be92f@collabora.com>
On 4/29/26 11:44, Louis-Alexis Eyraud wrote:
> Add compatible string for the AuxADC block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* [PATCH] Input: tsc2007 - fix resistance calculation when A/D value is saturated
From: Yuki Horii @ 2026-05-11 5:40 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: andreas, clamor95, linux-input, yuuki198708, Yuki Horii
The A/D conversion sequence starts with reading the Y position
immediately after the A/D converter is powered on. This makes
the Y position measurement more susceptible to instability due
to noise and mechanical bounce compared to the X position, and
may result in a saturated value (MAX_12BIT = 0xFFF).
While the Y position is not used in equation #1 of the datasheet
for touch resistance calculation, it is required for equation #2.
A saturated Y A/D value, like a saturated X A/D value, indicates
that the touch resistance calculation is invalid.
Only the saturation of the X A/D value was checked, while the
saturation of the Y A/D value was not. Additionally, modifying
tc->x directly had an unintended side effect of corrupting the
caller's data.
The function now returns 0 when either X or Y A/D value is
saturated to indicate that the touch resistance calculation
is invalid.
Signed-off-by: Yuki Horii <horiiyuk@ishida.co.jp>
---
drivers/input/touchscreen/tsc2007_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007_core.c b/drivers/input/touchscreen/tsc2007_core.c
index 524f14eb3da2..ce82163da4ff 100644
--- a/drivers/input/touchscreen/tsc2007_core.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -71,9 +71,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)
+ return 0;
if (likely(tc->x && tc->z1)) {
/* compute touch resistance using equation #1 */
--
2.51.0
^ permalink raw reply related
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