* Re: [PATCH v7 0/9] Add support for MT6392 PMIC
From: Rob Herring @ 2026-06-16 13:42 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260615071836.362883-1-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:06AM +0200, Luca Leonardo Scorcia wrote:
> The MediaTek MT6392 PMIC is usually found on devices powered by
> the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
>
> This series is mostly based around patches submitted a couple
> years ago by Fabien Parent and not merged and from Val Packett's
> submission from Jan 2025 that included extra cleanups, fixes, and a
> new dtsi file similar to ones that exist for other PMICs. Some
> comments weren't addressed and the series was ultimately not merged.
>
> These patches enable four functions: keys, regulator, pinctrl and RTC.
> Mono speaker amp will follow later as I need to work further on the
> audio codec.
>
> I added a handful of device tree improvements to fix some dtbs_check
> errors, added support for the pinctrl device and addressed the comments
> from last year's reviews.
>
> Please note that patch 0006 and 0008 depend on patch 0005 as they need the
> registers.h file, but belong to different driver areas. I'm not sure if
> I'm supposed to squash them even if they belong to different driver
> areas of if it's fine like this. Any advice is welcome.
>
> The series has been tested on Xiaomi Mi Smart Clock X04G and on the
> Lenovo Smart Clock 2 CD-24502F.
>
> Changes in v7:
> - Removed patch 0008 dependency on patch 0003.
> - Reintroduced the regulator driver. In earlier revisions of this series,
> it was proposed to remove the dedicated compatible for the regulator
> device [3]. The driver does not use actually it, but it is not possible
> at this time to remove it from the bindings since it's a required
> property.
>
> Making the regulator-required property conditional was NACKed in [5],
> with the suggestion to create a separate binding altogether for devices
> that do not require the compatible property. I tried implementing this,
> but since the parent device needs to be declared as compatible with
> mt6323, it leads to a warning in dt_binding_check since mt6323 would
> be declared as a compatible in both mt6392 and mt6397.
>
> In the end the only regulator driver from the mt6397 documentation that
> still declares an of_match is mt6397-regulator and it does not seem
> to be necessary, so it should be possible to remove it and make the
> regulator compatible optional for all regulators, but that change would
> probably deserve its own separate patch series.
I don't really follow what the issue is here, but compatible should
never be optional.
Rob
^ permalink raw reply
* Re: [PATCH v7 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Rob Herring (Arm) @ 2026-06-16 13:43 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Lee Jones, Mark Brown, linux-input, linux-pm, Louis-Alexis Eyraud,
linux-kernel, Julien Massot, Macpaul Lin, Krzysztof Kozlowski,
Liam Girdwood, Linus Walleij, Conor Dooley, Dmitry Torokhov,
Akari Tsuyukusa, AngeloGioacchino Del Regno, Chen Zhong,
Fabien Parent, linux-mediatek, Val Packett, linux-arm-kernel,
Matthias Brugger, devicetree, Sean Wang, Sen Chu, linux-gpio
In-Reply-To: <20260615071836.362883-2-l.scorcia@gmail.com>
On Mon, 15 Jun 2026 09:16:07 +0200, Luca Leonardo Scorcia wrote:
> Describe the MT6392 PMIC and its RTC and regulator devices. This device
> is mostly based on MT6323 with some similarities to MT6397 and is usually
> found on boards using the MT8516/MT8167 SoC.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/3] iio: hid-sensor-humidity: use u32 instead of unsigned int
From: sashiko-bot @ 2026-06-16 13:50 UTC (permalink / raw)
To: Sanjay Chitroda; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260616-16-jun-hid-iio-u32-api-type-v1-2-952c74195f46@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Directly dereferencing the `raw_data` pointer as an `s32` can cause unaligned access faults on architectures that strictly enforce alignment.
- [High] The driver unconditionally dereferences `raw_data` as a 32-bit integer, ignoring the `raw_len` parameter, leading to potential out-of-bounds memory reads and corrupted sensor data.
- [High] The `humidity_callbacks` structure is statically allocated but its `pdev` field is modified during `probe`. If multiple humidity sensors are probed, the last probed device overwrites `pdev`, causing callbacks for all instances to be routed to the last bound device's state.
--
commit 90e5b3ef32381e14224dfd5cf7711e2aa3c588a2
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>
iio: hid-sensor-humidity: use u32 instead of unsigned int
This commit updates the usage_id parameter type from unsigned int to u32
in callback functions to match the expected API. It is intended to improve
code clarity with no functional changes.
> diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
> index be2338d5f4070..c376a247b1372 100644
> --- a/drivers/iio/humidity/hid-sensor-humidity.c
> +++ b/drivers/iio/humidity/hid-sensor-humidity.c
[ ... ]
> @@ -141,7 +141,7 @@ static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned int usage_id, size_t raw_len,
> + u32 usage_id, size_t raw_len,
> char *raw_data, void *pdev)
> {
[Severity: High]
This is a pre-existing issue, but does casting the raw_data pointer directly to
an s32 pointer cause unaligned access faults on architectures that strictly
enforce alignment?
drivers/iio/humidity/hid-sensor-humidity.c:humidity_capture_sample() {
switch (usage_id) {
case HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY:
humid_st->scan.humidity_data = *(s32 *)raw_data;
...
}
The raw_data pointer points directly into the packed HID report byte stream,
which may be unaligned.
Could casting it directly to an s32 pointer and dereferencing it trigger
alignment faults on architectures that do not support hardware unaligned
accesses?
[Severity: High]
This is also a pre-existing issue, but does this function unconditionally read 4
bytes from raw_data, ignoring the raw_len parameter?
drivers/iio/humidity/hid-sensor-humidity.c:humidity_capture_sample() {
switch (usage_id) {
case HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY:
humid_st->scan.humidity_data = *(s32 *)raw_data;
...
}
By indiscriminately reading 4 bytes, the driver might access out-of-bounds
memory when raw_len is smaller than 4.
Could this trigger memory access faults near page boundaries and leak kernel
heap data to userspace if the upper bits contain adjacent memory garbage?
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> @@ -161,7 +161,7 @@ static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
> static int humidity_parse_report(struct platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> struct iio_chan_spec *channels,
> - unsigned int usage_id,
> + u32 usage_id,
> struct hid_humidity_state *st)
> {
> int ret;
[Severity: High]
This is a pre-existing issue, but does the shared static humidity_callbacks
structure get overwritten during probe?
drivers/iio/humidity/hid-sensor-humidity.c:
static struct hid_sensor_hub_callbacks humidity_callbacks = {
.send_event = &humidity_proc_event,
.capture_sample = &humidity_capture_sample,
};
drivers/iio/humidity/hid-sensor-humidity.c:hid_humidity_probe() {
...
humidity_callbacks.pdev = pdev;
...
}
If multiple humidity sensors are probed, the last probed device overwrites pdev.
When sensor_hub_raw_event() receives data, it invokes callback->capture_sample
with the overwritten pdev.
Could this cause platform_get_drvdata(pdev) to return the wrong IIO device,
corrupting its state and dropping data for all previously bound sensors?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-16-jun-hid-iio-u32-api-type-v1-0-952c74195f46@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v7 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Rob Herring @ 2026-06-16 13:50 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Val Packett, Julien Massot,
Louis-Alexis Eyraud, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260615071836.362883-4-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:09AM +0200, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 234 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 258 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..197041df4ba1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,234 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +maintainers:
> + - Luca Leonardo Scorcia <l.scorcia@gmail.com>
> +
> +description:
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
> +
> + vproc-supply:
> + description: Supply for buck regulator vproc
> + vcore-supply:
> + description: Supply for buck regulator vcore
> + vsys-supply:
> + description: Supply for buck regulator vsys
> + avddldo-supply:
> + description: |
Don't need '|' if no formatting to preserve. Elsewhere too.
> + Supply for AVDD LDOs (vm, vio18, vcn18, vcamd, vcamio). According to the data sheet
> + this is an internal supply derived from vsys.
> + ldo1-supply:
> + description: Supply for LDOs group 1 (vaud28, vxo22, vaud22, vadc18, vcama, vrtc)
> + ldo2-supply:
> + description: Supply for LDOs group 2 (vcn35, vio28, vmc, vmch, vefuse, vdig18)
> + ldo3-supply:
> + description: Supply for LDOs group 3 (vusb, vemc3v3, vcamaf, vgp1, vgp2, vm25)
> +
> +patternProperties:
> + "^v(core|proc|sys)$":
> + description: Buck regulators
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
minItems: 1
maxItems: 2
? Because if there are only 2 modes, can't have more entries than that,
right? Though wouldn't 2 entries be the same as no property present
because I would assume the default is all modes. I shouldn't have to
assume though.
> + unevaluatedProperties: false
Place this after $ref. Easier to read than after indented blocks.
> +
> + "^v(adc18|camio|cn18|io18|xo22|m25|aud28|io28|rtc|usb)$":
> + description: LDOs with fixed output and mode setting
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^v(cama|dig18)$":
> + description: LDOs with fixed output without mode setting
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> + "^v(aud22|camaf|camd|cn35|efuse|emc3v3|gp1|gp2|m|mc|mch)$":
> + description: LDOs with adjustable output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes: false
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + regulators {
> + compatible = "mediatek,mt6392-regulator";
Drop the example. Put 1 complete example in the MFD schema rather than
incomplete examples.
Rob
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Julian Braha @ 2026-06-16 14:37 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-3-d24e422de6b4@oss.qualcomm.com>
Hi Fenglin,
On 6/16/26 11:08, Fenglin Wu wrote:
> +config INPUT_QCOM_SPMI_HAPTICS
> + tristate "Qualcomm SPMI PMIC haptics support"
> + depends on INPUT && MFD_SPMI_PMIC
The dependency on INPUT is unnecessary, all config options in this
Kconfig file already depend on INPUT due to an 'if INPUT..endif' in
drivers/input/Kconfig
(Yes, a few of the other config options in this file also have this
duplicate dependency on INPUT due to an explicit 'depends on'
attribute, but this file is in need of a cleanup.)
- Julian Braha
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Luca Leonardo Scorcia @ 2026-06-16 15:32 UTC (permalink / raw)
To: Rob Herring
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260616133918.GA2335264-robh@kernel.org>
> > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
>
> Nothing is using this so it is a dead file that doesn't get tested.
Hi, it's not referenced as the dtsi inclusion was removed in the
original patch from 2019 for an easier merging of support for mt8516
pumpkin boards [1][2].
If you prefer in the next revision I can add another patch to readd it
to the existing pumpkin board.
I am working on a few boards with MT8167 (Xiaomi Mi Smart Clock,
Lenovo Smart Clock 2, Sony Playstation Classic) that reference it and
these have been used to test it locally too.
[1] https://lore.kernel.org/linux-mediatek/20190323211612.860-25-fparent@baylibre.com/
[2] https://lore.kernel.org/linux-mediatek/20200229170401.1287324-2-fparent@baylibre.com/
Thank you
Luca
^ permalink raw reply
* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Conor Dooley @ 2026-06-16 15:35 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+4EquYcUHEnoq0N_p7vCmDpPONEhVrmAfO1eX_RNMYbQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
On Mon, Jun 15, 2026 at 07:09:39PM +0200, Luca Leonardo Scorcia wrote:
> Hi,
> yes, sorry about that, series v6 has been superseded by v7 (I replied
> to the thread and marked it as archived in patchwork, please let me
> know if I have to do something else to mark it as obsolete).
> Sashiko was correct, the regulators node is required for this device.
I have no idea what regulator node you're referring to here or what
patchwork. Please don't delete context when you reply.
If it's the devicetree patchwork I don't you need to do anything.
> Sashiko also has suggestions for v7, a few pre existing issues and a
> few nits here and there but some are actual improvements. One bit that
> caught my eye is the use of the modeset register in the
> mt6392_ldo_get_mode function. I have to double check that with the
> data sheet and the android kernel sources. Not sure if I can do that
> before next week though.
>
> Is there any way I can trigger a Sashiko review before sending patches
> to the ML?
I don't know sorry.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [RFC] Adding device-initiated haptic feedback knobs for pressurepads
From: Rong Zhang @ 2026-06-16 15:34 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Peter Hutterer, Dmitry Torokhov
Cc: linux-input, LKML
Hi all,
A pressurepad is a MT touchpad that simulates haptic feedback. The
haptic feedback may be either device-initiated or host-initiated. While
drivers/hid/hid-haptic.c [1] provides comprehensive support for host-
initiated ones, device-initiated ones are currently not configurable at
all.
According to Microsoft's Input Device Haptics Implementation Guide [2],
pressurepads with device-initiated haptic feedback can support
SET_FEATURE reports to allow users to customize the intensity of the
haptic feedback (usage page 0x0e Haptics, usage 0x23 Intensity) and/or
the force required to trigger a button press (usage page 0x0d
Digitizers, usage 0xb0 Button Press Threshold). Each knob should occupy
a dedicated report ID.
The first knob maps to "ClickForceSensitivity" in Windows registry and
"Touchpad feedback" => "Intensity" in Windows Settings [3]. The second
knob maps to "ClickForceSensitivity" in Windows registry.
The pressurepad on my laptop supports the first knob:
# 0x05, 0x0e, // Usage Page (Haptic) 595
# 0x09, 0x01, // Usage (Simple Haptic Controller) 597
# 0xa1, 0x02, // Collection (Logical) 599
# 0x09, 0x23, // Usage (Intensity) 601
# 0x85, 0x09, // Report ID (9) 603
# 0x15, 0x00, // Logical Minimum (0) 605
# 0x25, 0x64, // Logical Maximum (100) 607
# 0x75, 0x08, // Report Size (8) 609
# 0x95, 0x01, // Report Count (1) 611
# 0xb1, 0x02, // Feature (Data,Var,Abs) 613
# 0xc0, // End Collection 615
I hardly use Windows but the last time I booted it I did see "Touchpad
feedback" => "Intensity" in Windows Settings.
On Linux, I can tune the knob by setting the corresponding feature
report via HIDRAW. The pressurepad remembers the knob value until it
loses power. However, getting the feature report returns garbage data
(probably from the last input report in the buffer), which makes some
sense as the implementation guide only requires SET_FEATURE support.
I'd like to add device-initiated haptic feedback configurations for
Linux. For now, I only focus on the first knob, i.e., Haptics Intensity,
since it's supported on my device. If I somehow get a device with the
second knob I may work on it too.
Therefore, I am here to ask about the preferred way to expose the knob
to userspace.
The first thing I thought of was sysfs. It's easy to implement, but may
be too obscure for userspace considering the layered structure (evdev,
input, hid, ...) of the input stack.
The second thing I thought of was EV_FF FF_GAIN, but I am not sure if it
matches the semantics of EV_FF. IIUC, since there's no way to initiate a
force feedback from the host, the device is not a true FF device and may
cause confusion.
The third thing I though of was a new EV_MSC event. I've seen some
drivers using EV_MSC events to tune the device as per userspace events.
Or... Perhaps there are some other reasonable ways? Looking forward to
your feedback! :-)
[1]: https://lore.kernel.org/all/20250818-support-forcepads-v3-0-e4f9ab0add84@google.com/
[2]: https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/input-haptics-implementation-guide
[3]: https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-tuning-guidelines
Thanks,
Rong
^ permalink raw reply
* [PATCH bpf-next 0/2] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-16 16:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
hid_bpf_get_data() exposes a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The helper currently checks that range with:
rdwr_buf_size + offset > ctx->allocated_size
Since both operands are unsigned, a very large size can wrap the sum and
make an out-of-range request look valid.
Patch 1 changes the helper to reject offset values beyond the allocation
and then compare the requested size against the remaining bytes.
Patch 2 adds a HID-BPF regression check that asks hid_bpf_get_data() for
offset 2 and size ~0ULL from an rdesc_fixup callback and expects NULL.
It also adds KHDR_INCLUDES to the HID selftest build so the userspace
test sees current kernel UAPI HID definitions.
Validation, rebased and tested on bpf-next master e4287bf34f97
("selftests/bpf: Work around llvm stack overflow in crypto progs"):
git diff --check origin/master..HEAD: OK
scripts/checkpatch.pl --strict -g origin/master..HEAD: OK
make O=/root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616 \
drivers/hid/bpf/hid_bpf_dispatch.o: OK
make -C tools/testing/selftests/hid \
O=/root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616 \
OUTPUT=/tmp/hid-selftest-026 \
VMLINUX_BTF=/root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616/vmlinux \
KHDR_INCLUDES=-isystem /root/ebpf-verifier-bug-detection/kernel-build/bpf-next-hidbpf-20260616/usr/include \
hid_bpf: OK
The sanitized UAPI headers were generated in the build tree with
headers_install. The final install/copy step reported missing rsync in
this environment, but the generated build-tree usr/include was present
and used for the selftest build.
Yiyang Chen (2):
HID: bpf: Fix hid_bpf_get_data() range check
selftests/hid: Cover hid_bpf_get_data() size overflow
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
tools/testing/selftests/hid/Makefile | 2 +-
tools/testing/selftests/hid/hid_bpf.c | 11 +++++++++++
tools/testing/selftests/hid/progs/hid.c | 18 ++++++++++++++++++
4 files changed, 32 insertions(+), 2 deletions(-)
base-commit: e4287bf34f97a88c7d9322f5bde828724c073a6b
--
2.34.1
^ permalink raw reply
* [PATCH bpf-next 1/2] HID: bpf: Fix hid_bpf_get_data() range check
From: Yiyang Chen @ 2026-06-16 16:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <cover.1781627122.git.chenyy23@mails.tsinghua.edu.cn>
hid_bpf_get_data() returns a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.
The current check adds rdwr_buf_size and offset before comparing the
result against ctx->allocated_size. Since both values are unsigned, a
very large size can wrap the sum below ctx->allocated_size and make the
helper return a pointer even though the requested range is not contained
in the backing buffer.
Use a non-wrapping range check instead: reject offsets beyond the
allocation, then compare the requested size with the remaining bytes
after the offset.
Fixes: 4171954f56fb ("HID: bpf/dispatch: regroup kfuncs definitions")
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index d0130658091b0..09b45c40d84f0 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
- if (rdwr_buf_size + offset > ctx->allocated_size)
+ if (offset > ctx->allocated_size ||
+ rdwr_buf_size > ctx->allocated_size - offset)
return NULL;
return ctx_kern->data + offset;
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next 2/2] selftests/hid: Cover hid_bpf_get_data() size overflow
From: Yiyang Chen @ 2026-06-16 16:35 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, bpf, linux-input
Cc: Yiyang Chen, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
linux-kselftest, linux-kernel
In-Reply-To: <cover.1781627122.git.chenyy23@mails.tsinghua.edu.cn>
Add a HID-BPF regression check for hid_bpf_get_data() requests whose
size would overflow when added to the offset.
The new rdesc fixup callback asks for offset 2 and size ~0ULL, then
records whether the helper returns NULL. A vulnerable kernel returns a
non-NULL pointer because the runtime check wraps the addition. A fixed
kernel rejects the request. The test only checks the helper result and
does not dereference the returned pointer.
Also add KHDR_INCLUDES to the HID selftest build so hid_bpf.c sees the
current kernel UAPI HID definitions on systems whose installed headers do
not provide enum hid_report_type.
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
---
tools/testing/selftests/hid/Makefile | 2 +-
tools/testing/selftests/hid/hid_bpf.c | 11 +++++++++++
tools/testing/selftests/hid/progs/hid.c | 18 ++++++++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/hid/Makefile b/tools/testing/selftests/hid/Makefile
index 50ec9e0406aba..357c6eb5ff5ee 100644
--- a/tools/testing/selftests/hid/Makefile
+++ b/tools/testing/selftests/hid/Makefile
@@ -24,7 +24,7 @@ CXX ?= $(CROSS_COMPILE)g++
HOSTPKG_CONFIG := pkg-config
-CFLAGS += -g -O0 -rdynamic -Wall -Werror -I$(OUTPUT)
+CFLAGS += -g -O0 -rdynamic -Wall -Werror -I$(OUTPUT) $(KHDR_INCLUDES)
CFLAGS += -I$(OUTPUT)/tools/include
LDLIBS += -lelf -lz -lrt -lpthread
diff --git a/tools/testing/selftests/hid/hid_bpf.c b/tools/testing/selftests/hid/hid_bpf.c
index 1e979fb3542ba..f0a210900e63d 100644
--- a/tools/testing/selftests/hid/hid_bpf.c
+++ b/tools/testing/selftests/hid/hid_bpf.c
@@ -887,6 +887,17 @@ TEST_F(hid_bpf, test_rdesc_fixup)
ASSERT_EQ(rpt_desc.value[4], 0x42);
}
+TEST_F(hid_bpf, test_rdesc_fixup_get_data_overflow)
+{
+ const struct test_program progs[] = {
+ { .name = "hid_rdesc_fixup_get_data_overflow" },
+ };
+
+ LOAD_PROGRAMS(progs);
+
+ ASSERT_EQ(self->skel->bss->get_data_overflow_check, 1);
+}
+
static int libbpf_print_fn(enum libbpf_print_level level,
const char *format, va_list args)
{
diff --git a/tools/testing/selftests/hid/progs/hid.c b/tools/testing/selftests/hid/progs/hid.c
index 5ecc845ef7921..c6ae2cd045b0e 100644
--- a/tools/testing/selftests/hid/progs/hid.c
+++ b/tools/testing/selftests/hid/progs/hid.c
@@ -13,6 +13,7 @@ struct attach_prog_args {
__u64 callback_check = 52;
__u64 callback2_check = 52;
+__u64 get_data_overflow_check;
SEC("?struct_ops/hid_device_event")
int BPF_PROG(hid_first_event, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
@@ -240,6 +241,23 @@ struct hid_bpf_ops rdesc_fixup = {
.hid_rdesc_fixup = (void *)hid_rdesc_fixup,
};
+SEC("?struct_ops.s/hid_rdesc_fixup")
+int BPF_PROG(hid_rdesc_fixup_get_data_overflow, struct hid_bpf_ctx *hid_ctx)
+{
+ __u8 *data;
+
+ data = hid_bpf_get_data(hid_ctx, 2 /* offset */, ~0ULL /* size */);
+ if (!data)
+ get_data_overflow_check = 1;
+
+ return 0;
+}
+
+SEC(".struct_ops.link")
+struct hid_bpf_ops rdesc_fixup_get_data_overflow = {
+ .hid_rdesc_fixup = (void *)hid_rdesc_fixup_get_data_overflow,
+};
+
SEC("?struct_ops/hid_device_event")
int BPF_PROG(hid_test_insert1, struct hid_bpf_ctx *hid_ctx, enum hid_report_type type)
{
--
2.34.1
^ permalink raw reply related
* [PATCH] Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)
From: Raphaël Larocque @ 2026-06-16 17:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Raphaël Larocque
The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a
Synaptics touchpad whose SMBus companion is not ready at boot and
takes roughly 200 seconds to appear. During this window the touchpad
and TrackPoint are completely unresponsive on approximately 50% of
boots, making the machine unusable until the companion finally
registers.
The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the
kernel attempts to use SMBus/RMI4 mode by default. When the companion
is not ready, psmouse_smbus_init() leaves breadcrumbs and returns
-EAGAIN, the PS/2 fallback path is taken, but the device does not
function properly until the companion appears and RMI4 takes over.
Disable SMBus InterTouch for board id 2722 so the touchpad and
TrackPoint work immediately via PS/2 from boot. Users can still force
SMBus with psmouse.synaptics_intertouch=1 if needed.
Tested-by: Raphaël Larocque <rlarocque@disroot.org>
Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
---
drivers/input/mouse/synaptics.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c70502e24031..8f38bc498798 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1837,6 +1837,14 @@ static int synaptics_setup_intertouch(struct psmouse *psmouse,
return -ENXIO;
}
+
+ /* Disable intertouch on known-broken board revisions */
+ if (info->board_id == 2722) {
+ psmouse_info(psmouse,
+ "Disabling intertouch for board id %d\n",
+ info->board_id);
+ return -ENXIO;
+ }
}
psmouse_info(psmouse, "Trying to set up SMBus access\n");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH bpf-next 1/2] HID: bpf: Fix hid_bpf_get_data() range check
From: bot+bpf-ci @ 2026-06-16 17:18 UTC (permalink / raw)
To: chenyy23, jikos, bentiss, bpf, linux-input
Cc: chenyy23, shuah, ast, daniel, andrii, martin.lau, eddyz87, memxor,
song, yonghong.song, jolsa, linux-kselftest, linux-kernel, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <783681f27625a11ed58f00221be046643232a2fc.1781627122.git.chenyy23@mails.tsinghua.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]
> commit 7c433bf4ab2de03b77e22dbd3984e39a386997a2
> Author: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
> Date: Tue Jun 16 16:35:06 2026 +0000
>
> HID: bpf: Fix hid_bpf_get_data() range check
>
> hid_bpf_get_data() returns a pointer into the HID-BPF context data when
> the caller-provided offset and size fit inside ctx->allocated_size.
>
> The current check adds rdwr_buf_size and offset before comparing the
> result against ctx->allocated_size. Since both values are unsigned, a
> very large size can wrap the sum below ctx->allocated_size and make the
> helper return a pointer even though the requested range is not contained
> in the backing buffer.
>
> Use a non-wrapping range check instead: reject offsets beyond the
> allocation, then compare the requested size with the remaining bytes
> after the offset.
>
> Fixes: 4171954f56fb ("HID: bpf/dispatch: regroup kfuncs definitions")
> Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
The Fixes tag points to commit 4171954f56fb, but that commit only moved
hid_bpf_get_data() without changing its logic. Its commit message states
"No code change, just move down the hid_bpf_get_data() kfunc definition".
The vulnerable addition pattern 'rdwr_buf_size + offset > ctx->allocated_size'
was actually introduced in commit 658ee5a64fcf ("HID: bpf: allocate data
memory for device_event BPF programs"), which changed the field from ctx->size
to ctx->allocated_size while keeping the same overflow-prone check.
Should the Fixes tag reference the commit that introduced the buggy code:
Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs")
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index d0130658091b..09b45c40d84f 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -299,7 +299,8 @@ hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr
>
> ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
>
> - if (rdwr_buf_size + offset > ctx->allocated_size)
> + if (offset > ctx->allocated_size ||
> + rdwr_buf_size > ctx->allocated_size - offset)
> return NULL;
>
> return ctx_kern->data + offset;
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27633665618
^ permalink raw reply
* Re: [PATCH] HID: wacom: handle kmemdup failure in Bluetooth IRQ path
From: Jason Gerecke @ 2026-06-16 18:27 UTC (permalink / raw)
To: Ruoyu Wang
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <20260606040344.4-1-ruoyuw560@gmail.com>
On Fri, Jun 5, 2026 at 9:04 PM Ruoyu Wang <ruoyuw560@gmail.com> wrote:
>
> wacom_intuos_bt_irq() duplicates the input report with kmemdup() and then
> uses data[0] to dispatch the report type. If the allocation fails, the
> switch statement dereferences a NULL pointer.
>
> Handle allocation failure by dropping the report. This keeps the
> interrupt path from dereferencing a NULL buffer while preserving the
> existing return convention for ignored or malformed reports.
>
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> drivers/hid/wacom_wac.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625d..c42af15e7dba0 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -1206,6 +1206,9 @@ static int wacom_intuos_bt_irq(struct wacom_wac *wacom, size_t len)
> int i = 1;
> unsigned power_raw, battery_capacity, bat_charging, ps_connected;
>
> + if (!data)
> + return 0;
> +
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Though, I think we should also (or instead?) entertain a change that
does away with the kmemdup entirely... Replacing this kmemdup and the
memcpy in wacom_intuos_bt_process_data with some simple pointer
manipulation should have the same effect with less work.
Jason (she/they)
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
> switch (data[0]) {
> case 0x04:
> if (len < 32) {
> --
> 2.34.1
>
>
^ permalink raw reply
* [PATCH] Input: xpad - replace symbolic permissions with octal
From: Jack Lee @ 2026-06-16 18:44 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Jack Lee
Symbolic permissions S_IRUGO and S_IWUSR are not preferred. Replace
with octal permissions 0444 and 0644 as recommended by checkpatch.
Signed-off-by: Jack Lee <skunkolee@gmail.com>
---
drivers/input/joystick/xpad.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index feb8f368f834..f6e02016a0c0 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -74,19 +74,19 @@
#define FLAG_DELAY_INIT BIT(0)
static bool dpad_to_buttons;
-module_param(dpad_to_buttons, bool, S_IRUGO);
+module_param(dpad_to_buttons, bool, 0444);
MODULE_PARM_DESC(dpad_to_buttons, "Map D-PAD to buttons rather than axes for unknown pads");
static bool triggers_to_buttons;
-module_param(triggers_to_buttons, bool, S_IRUGO);
+module_param(triggers_to_buttons, bool, 0444);
MODULE_PARM_DESC(triggers_to_buttons, "Map triggers to buttons rather than axes for unknown pads");
static bool sticks_to_null;
-module_param(sticks_to_null, bool, S_IRUGO);
+module_param(sticks_to_null, bool, 0444);
MODULE_PARM_DESC(sticks_to_null, "Do not map sticks at all for unknown pads");
static bool auto_poweroff = true;
-module_param(auto_poweroff, bool, S_IWUSR | S_IRUGO);
+module_param(auto_poweroff, bool, 0644);
MODULE_PARM_DESC(auto_poweroff, "Power off wireless controllers on suspend");
static const struct xpad_device {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] Input: synaptics - disable InterTouch on ThinkPad T440p (board id 2722)
From: Dmitry Torokhov @ 2026-06-16 18:49 UTC (permalink / raw)
To: Raphaël Larocque; +Cc: linux-input, linux-kernel
In-Reply-To: <20260616171137.19069-1-rlarocque@disroot.org>
Hi Raphaël,
On Tue, Jun 16, 2026 at 01:11:36PM -0400, Raphaël Larocque wrote:
> The Lenovo ThinkPad T440p (PNP ID LEN0036, board id 2722) has a
> Synaptics touchpad whose SMBus companion is not ready at boot and
> takes roughly 200 seconds to appear. During this window the touchpad
> and TrackPoint are completely unresponsive on approximately 50% of
> boots, making the machine unusable until the companion finally
> registers.
>
> The device is in the topbuttonpad_pnp_ids[] SMBus allowlist, so the
> kernel attempts to use SMBus/RMI4 mode by default. When the companion
> is not ready, psmouse_smbus_init() leaves breadcrumbs and returns
> -EAGAIN, the PS/2 fallback path is taken, but the device does not
> function properly until the companion appears and RMI4 takes over.
>
> Disable SMBus InterTouch for board id 2722 so the touchpad and
> TrackPoint work immediately via PS/2 from boot. Users can still force
> SMBus with psmouse.synaptics_intertouch=1 if needed.
Is this board ID unique to T440p? Or it may be used in other devices as
well?
I also wonder, if you try loading psmouse later in the initialization
cycle, after SMBus has been loaded, if that would help it detect the
touchpad quicker? Is there anything interested in DTS regarding device
interconnect/hierarchy that we might be missing?
>
> Tested-by: Raphaël Larocque <rlarocque@disroot.org>
> Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
> ---
> drivers/input/mouse/synaptics.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index c70502e24031..8f38bc498798 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1837,6 +1837,14 @@ static int synaptics_setup_intertouch(struct psmouse *psmouse,
>
> return -ENXIO;
> }
> +
> + /* Disable intertouch on known-broken board revisions */
> + if (info->board_id == 2722) {
> + psmouse_info(psmouse,
> + "Disabling intertouch for board id %d\n",
> + info->board_id);
> + return -ENXIO;
> + }
> }
>
> psmouse_info(psmouse, "Trying to set up SMBus access\n");
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC] Adding device-initiated haptic feedback knobs for pressurepads
From: Dmitry Torokhov @ 2026-06-16 18:56 UTC (permalink / raw)
To: Rong Zhang
Cc: Jiri Kosina, Benjamin Tissoires, Peter Hutterer, linux-input,
LKML
In-Reply-To: <bbee6e61a243a0ae4db6ea155909607326a80dac.camel@rong.moe>
Hi Rong,
On Tue, Jun 16, 2026 at 11:34:45PM +0800, Rong Zhang wrote:
> Hi all,
>
> A pressurepad is a MT touchpad that simulates haptic feedback. The
> haptic feedback may be either device-initiated or host-initiated. While
> drivers/hid/hid-haptic.c [1] provides comprehensive support for host-
> initiated ones, device-initiated ones are currently not configurable at
> all.
>
> According to Microsoft's Input Device Haptics Implementation Guide [2],
> pressurepads with device-initiated haptic feedback can support
> SET_FEATURE reports to allow users to customize the intensity of the
> haptic feedback (usage page 0x0e Haptics, usage 0x23 Intensity) and/or
> the force required to trigger a button press (usage page 0x0d
> Digitizers, usage 0xb0 Button Press Threshold). Each knob should occupy
> a dedicated report ID.
>
> The first knob maps to "ClickForceSensitivity" in Windows registry and
> "Touchpad feedback" => "Intensity" in Windows Settings [3]. The second
> knob maps to "ClickForceSensitivity" in Windows registry.
>
> The pressurepad on my laptop supports the first knob:
>
> # 0x05, 0x0e, // Usage Page (Haptic) 595
> # 0x09, 0x01, // Usage (Simple Haptic Controller) 597
> # 0xa1, 0x02, // Collection (Logical) 599
> # 0x09, 0x23, // Usage (Intensity) 601
> # 0x85, 0x09, // Report ID (9) 603
> # 0x15, 0x00, // Logical Minimum (0) 605
> # 0x25, 0x64, // Logical Maximum (100) 607
> # 0x75, 0x08, // Report Size (8) 609
> # 0x95, 0x01, // Report Count (1) 611
> # 0xb1, 0x02, // Feature (Data,Var,Abs) 613
> # 0xc0, // End Collection 615
>
> I hardly use Windows but the last time I booted it I did see "Touchpad
> feedback" => "Intensity" in Windows Settings.
>
> On Linux, I can tune the knob by setting the corresponding feature
> report via HIDRAW. The pressurepad remembers the knob value until it
> loses power. However, getting the feature report returns garbage data
> (probably from the last input report in the buffer), which makes some
> sense as the implementation guide only requires SET_FEATURE support.
>
> I'd like to add device-initiated haptic feedback configurations for
> Linux. For now, I only focus on the first knob, i.e., Haptics Intensity,
> since it's supported on my device. If I somehow get a device with the
> second knob I may work on it too.
The question is why would we want to support device-initiated feedback
instead of enhancing userspace to fully control it. For the record on
ChromeOS we tried implementing support for device-initiated feedback but
it made the kernel code very cumbersome and left a lot of gaps/rough
edges when combining device- and host-initiated haptic effects.
I'd prefer it all being driven from userspace.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Rob Herring @ 2026-06-16 18:57 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2LiMHnaTK6QnsLxJDtw0fZ_N9LELw0iCorOZwHuWXus0g@mail.gmail.com>
On Tue, Jun 16, 2026 at 10:32 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
> >
> > Nothing is using this so it is a dead file that doesn't get tested.
>
> Hi, it's not referenced as the dtsi inclusion was removed in the
> original patch from 2019 for an easier merging of support for mt8516
> pumpkin boards [1][2].
> If you prefer in the next revision I can add another patch to readd it
> to the existing pumpkin board.
That or move this patch to the series for the board(s). If the board
is already upstream, then add the include in *this* patch.
Rob
^ permalink raw reply
* Re: [RFC] Adding device-initiated haptic feedback knobs for pressurepads
From: Rong Zhang @ 2026-06-16 19:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, Peter Hutterer, linux-input,
LKML
In-Reply-To: <ajGbFNj73yxaEj0y@google.com>
Hi Dmitry,
On Tue, 2026-06-16 at 11:56 -0700, Dmitry Torokhov wrote:
> Hi Rong,
>
> On Tue, Jun 16, 2026 at 11:34:45PM +0800, Rong Zhang wrote:
> > Hi all,
> >
> > A pressurepad is a MT touchpad that simulates haptic feedback. The
> > haptic feedback may be either device-initiated or host-initiated. While
> > drivers/hid/hid-haptic.c [1] provides comprehensive support for host-
> > initiated ones, device-initiated ones are currently not configurable at
> > all.
> >
> > According to Microsoft's Input Device Haptics Implementation Guide [2],
> > pressurepads with device-initiated haptic feedback can support
> > SET_FEATURE reports to allow users to customize the intensity of the
> > haptic feedback (usage page 0x0e Haptics, usage 0x23 Intensity) and/or
> > the force required to trigger a button press (usage page 0x0d
> > Digitizers, usage 0xb0 Button Press Threshold). Each knob should occupy
> > a dedicated report ID.
> >
> > The first knob maps to "ClickForceSensitivity" in Windows registry and
> > "Touchpad feedback" => "Intensity" in Windows Settings [3]. The second
> > knob maps to "ClickForceSensitivity" in Windows registry.
> >
> > The pressurepad on my laptop supports the first knob:
> >
> > # 0x05, 0x0e, // Usage Page (Haptic) 595
> > # 0x09, 0x01, // Usage (Simple Haptic Controller) 597
> > # 0xa1, 0x02, // Collection (Logical) 599
> > # 0x09, 0x23, // Usage (Intensity) 601
> > # 0x85, 0x09, // Report ID (9) 603
> > # 0x15, 0x00, // Logical Minimum (0) 605
> > # 0x25, 0x64, // Logical Maximum (100) 607
> > # 0x75, 0x08, // Report Size (8) 609
> > # 0x95, 0x01, // Report Count (1) 611
> > # 0xb1, 0x02, // Feature (Data,Var,Abs) 613
> > # 0xc0, // End Collection 615
> >
> > I hardly use Windows but the last time I booted it I did see "Touchpad
> > feedback" => "Intensity" in Windows Settings.
> >
> > On Linux, I can tune the knob by setting the corresponding feature
> > report via HIDRAW. The pressurepad remembers the knob value until it
> > loses power. However, getting the feature report returns garbage data
> > (probably from the last input report in the buffer), which makes some
> > sense as the implementation guide only requires SET_FEATURE support.
> >
> > I'd like to add device-initiated haptic feedback configurations for
> > Linux. For now, I only focus on the first knob, i.e., Haptics Intensity,
> > since it's supported on my device. If I somehow get a device with the
> > second knob I may work on it too.
>
> The question is why would we want to support device-initiated feedback
> instead of enhancing userspace to fully control it. For the record on
> ChromeOS we tried implementing support for device-initiated feedback but
> it made the kernel code very cumbersome and left a lot of gaps/rough
> edges when combining device- and host-initiated haptic effects.
Sorry, I didn't explain it clearly enough.
Most Windows laptops shipping with a pressurepad don't support host-
initiated feedback at all. That's also the case of my device.
>
> I'd prefer it all being driven from userspace.
... so The only force feedback stuff we can control on these
pressurepads are the said one or two knobs, really :-(
Hopefully one day we will live in a host-initiated haptic world...
Thanks,
Rong
>
> Thanks.
^ permalink raw reply
* Re: [PATCH] Input: yealink - stop URB resubmission on completion error
From: Dmitry Torokhov @ 2026-06-16 19:17 UTC (permalink / raw)
To: Jie Wang
Cc: Henk Vergonet, linux-input, linux-kernel,
syzbot+039eab266c6321a174bd, syzkaller-bugs
In-Reply-To: <20260616110440.1073059-1-jie.wang@intel.com>
Hi Jie,
On Tue, Jun 16, 2026 at 11:04:40AM +0000, Jie Wang wrote:
> urb_irq_callback() and urb_ctl_callback() resubmit each other's URBs
> regardless of completion status. When the device returns a persistent
> error (-EPROTO), this creates an unthrottled resubmission loop that
> starves the CPU and triggers RCU stalls.
>
> Stop resubmitting on any non-zero URB status, following the standard
> completion pattern used by other USB input drivers.
>
> Reported-by: syzbot+039eab266c6321a174bd@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=039eab266c6321a174bd
> Signed-off-by: Jie Wang <jie.wang@intel.com>
It would be good to have a helper like
bool usb_is_permanent_error(struct urb *urb, struct device *dev);
instead of having this "switch" in all the drivers. It also unclear
whether we should not attempt to re-submit the URB on errors other than
ECONNRESET, ENOENT, or ESHUTDOWN.
> ---
> drivers/input/misc/yealink.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
> index 8786ed8b3565..bbfa1a9c23d1 100644
> --- a/drivers/input/misc/yealink.c
> +++ b/drivers/input/misc/yealink.c
> @@ -414,9 +414,20 @@ static void urb_irq_callback(struct urb *urb)
> struct yealink_dev *yld = urb->context;
> int ret, status = urb->status;
>
> - if (status)
> + switch (status) {
> + case 0:
> + break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + dev_dbg(&yld->intf->dev, "%s - urb shutting down with status %d\n",
> + __func__, status);
> + return;
> + default:
> dev_err(&yld->intf->dev, "%s - urb status %d\n",
> __func__, status);
> + return;
> + }
>
> switch (yld->irq_data->cmd) {
> case CMD_KEYPRESS:
> @@ -452,9 +463,20 @@ static void urb_ctl_callback(struct urb *urb)
> struct yealink_dev *yld = urb->context;
> int ret = 0, status = urb->status;
>
> - if (status)
> + switch (status) {
> + case 0:
> + break;
> + case -ECONNRESET:
> + case -ENOENT:
> + case -ESHUTDOWN:
> + dev_dbg(&yld->intf->dev, "%s - urb shutting down with status %d\n",
> + __func__, status);
> + return;
> + default:
> dev_err(&yld->intf->dev, "%s - urb status %d\n",
> __func__, status);
> + return;
> + }
>
> switch (yld->ctl_data->cmd) {
> case CMD_KEYPRESS:
> --
> 2.34.1
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Dmitry Torokhov @ 2026-06-16 19:22 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Fenglin Wu, linux-arm-msm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <eb693705-c0c3-427b-a924-5aa907fd65bb@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 12:25:55PM +0200, Konrad Dybcio wrote:
> On 6/16/26 12:08 PM, Fenglin Wu wrote:
> > Add an initial driver for the Qualcomm PMIH010x PMIC haptics module,
> > named as HAP530_HV. This module supports several play modes, including
> > DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
> > and hardware data handling logic. Currently, the driver provides support
> > for two play modes using the input force-feedback framework: FF_CONSTANT
> > effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
> > waveform for FIFO mode.
> >
> > Assisted-by: Claude:claude-4-6-sonnet
> > Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +static int cfg_write(struct qcom_haptics *h, u32 off, u32 val)
>
> static inline
No, let compiler do its job and decide whether it should be inlined or
not.
Thanks.
--
Dmitry
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 66725039f7090afe14c31bd259e2059a68f04023
From: kernel test robot @ 2026-06-16 20:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 66725039f7090afe14c31bd259e2059a68f04023 Input: mms114 - reject an oversized device packet size
elapsed time: 730m
configs tested: 292
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001 gcc-9.5.0
arc randconfig-001-20260616 gcc-9.5.0
arc randconfig-002 gcc-9.5.0
arc randconfig-002-20260616 gcc-9.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm lpc18xx_defconfig clang-23
arm randconfig-001 gcc-9.5.0
arm randconfig-001-20260616 gcc-9.5.0
arm randconfig-002 gcc-9.5.0
arm randconfig-002-20260616 gcc-9.5.0
arm randconfig-003 gcc-9.5.0
arm randconfig-003-20260616 gcc-9.5.0
arm randconfig-004 gcc-9.5.0
arm randconfig-004-20260616 gcc-9.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260616 clang-23
arm64 randconfig-001-20260616 gcc-13.4.0
arm64 randconfig-001-20260617 gcc-12.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260616 clang-23
arm64 randconfig-002-20260616 gcc-13.4.0
arm64 randconfig-002-20260617 gcc-12.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260616 clang-23
arm64 randconfig-003-20260616 gcc-13.4.0
arm64 randconfig-003-20260617 gcc-12.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260616 clang-23
arm64 randconfig-004-20260616 gcc-13.4.0
arm64 randconfig-004-20260617 gcc-12.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260616 clang-23
csky randconfig-001-20260616 gcc-13.4.0
csky randconfig-001-20260617 gcc-12.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260616 clang-23
csky randconfig-002-20260616 gcc-13.4.0
csky randconfig-002-20260617 gcc-12.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260616 clang-23
hexagon randconfig-001-20260616 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260616 clang-23
hexagon randconfig-002-20260616 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001 clang-22
i386 buildonly-randconfig-001-20260616 clang-22
i386 buildonly-randconfig-001-20260617 gcc-14
i386 buildonly-randconfig-002 clang-22
i386 buildonly-randconfig-002-20260616 clang-22
i386 buildonly-randconfig-002-20260617 gcc-14
i386 buildonly-randconfig-003 clang-22
i386 buildonly-randconfig-003-20260616 clang-22
i386 buildonly-randconfig-003-20260617 gcc-14
i386 buildonly-randconfig-004 clang-22
i386 buildonly-randconfig-004-20260616 clang-22
i386 buildonly-randconfig-004-20260617 gcc-14
i386 buildonly-randconfig-005 clang-22
i386 buildonly-randconfig-005-20260616 clang-22
i386 buildonly-randconfig-005-20260617 gcc-14
i386 buildonly-randconfig-006 clang-22
i386 buildonly-randconfig-006-20260616 clang-22
i386 buildonly-randconfig-006-20260617 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260616 gcc-14
i386 randconfig-002-20260616 gcc-14
i386 randconfig-003-20260616 gcc-14
i386 randconfig-004-20260616 gcc-14
i386 randconfig-005-20260616 gcc-14
i386 randconfig-006-20260616 gcc-14
i386 randconfig-007-20260616 gcc-14
i386 randconfig-011 clang-22
i386 randconfig-011-20260616 clang-22
i386 randconfig-012 clang-22
i386 randconfig-012-20260616 clang-22
i386 randconfig-013 clang-22
i386 randconfig-013-20260616 clang-22
i386 randconfig-014 clang-22
i386 randconfig-014-20260616 clang-22
i386 randconfig-015 clang-22
i386 randconfig-015-20260616 clang-22
i386 randconfig-016 clang-22
i386 randconfig-016-20260616 clang-22
i386 randconfig-017 clang-22
i386 randconfig-017-20260616 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260616 clang-23
loongarch randconfig-001-20260616 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260616 clang-23
loongarch randconfig-002-20260616 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
m68k hp300_defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips malta_kvm_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260616 clang-23
nios2 randconfig-001-20260616 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260616 clang-23
nios2 randconfig-002-20260616 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260616 gcc-8.5.0
parisc randconfig-001-20260617 gcc-15.2.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260616 gcc-8.5.0
parisc randconfig-002-20260617 gcc-15.2.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc mpc8315_rdb_defconfig clang-23
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260616 gcc-8.5.0
powerpc randconfig-001-20260617 gcc-15.2.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260616 gcc-8.5.0
powerpc randconfig-002-20260617 gcc-15.2.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260616 gcc-8.5.0
powerpc64 randconfig-001-20260617 gcc-15.2.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260616 gcc-8.5.0
powerpc64 randconfig-002-20260617 gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260616 gcc-16.1.0
riscv randconfig-001-20260617 gcc-16.1.0
riscv randconfig-002-20260616 gcc-16.1.0
riscv randconfig-002-20260617 gcc-16.1.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260616 gcc-16.1.0
s390 randconfig-001-20260617 gcc-16.1.0
s390 randconfig-002-20260616 gcc-16.1.0
s390 randconfig-002-20260617 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001-20260616 gcc-16.1.0
sh randconfig-001-20260617 gcc-16.1.0
sh randconfig-002-20260616 gcc-16.1.0
sh randconfig-002-20260617 gcc-16.1.0
sh sh7785lcr_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-8.5.0
sparc randconfig-001-20260616 gcc-8.5.0
sparc randconfig-002 gcc-8.5.0
sparc randconfig-002-20260616 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-8.5.0
sparc64 randconfig-001-20260616 gcc-8.5.0
sparc64 randconfig-002 gcc-8.5.0
sparc64 randconfig-002-20260616 gcc-8.5.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-8.5.0
um randconfig-001-20260616 gcc-8.5.0
um randconfig-002 gcc-8.5.0
um randconfig-002-20260616 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260616 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260616 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260616 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260616 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260616 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260616 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260616 clang-22
x86_64 randconfig-001-20260617 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260616 clang-22
x86_64 randconfig-002-20260617 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260616 clang-22
x86_64 randconfig-003-20260617 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260616 clang-22
x86_64 randconfig-004-20260617 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260616 clang-22
x86_64 randconfig-005-20260617 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260616 clang-22
x86_64 randconfig-006-20260617 clang-22
x86_64 randconfig-011 clang-22
x86_64 randconfig-011-20260616 clang-22
x86_64 randconfig-011-20260616 gcc-14
x86_64 randconfig-012 clang-22
x86_64 randconfig-012-20260616 clang-22
x86_64 randconfig-012-20260616 gcc-14
x86_64 randconfig-013 clang-22
x86_64 randconfig-013-20260616 clang-22
x86_64 randconfig-014 clang-22
x86_64 randconfig-014-20260616 clang-22
x86_64 randconfig-015 clang-22
x86_64 randconfig-015-20260616 clang-22
x86_64 randconfig-016 clang-22
x86_64 randconfig-016-20260616 clang-22
x86_64 randconfig-016-20260616 gcc-14
x86_64 randconfig-071 gcc-13
x86_64 randconfig-071-20260616 gcc-13
x86_64 randconfig-071-20260616 gcc-14
x86_64 randconfig-072 gcc-13
x86_64 randconfig-072-20260616 gcc-13
x86_64 randconfig-072-20260616 gcc-14
x86_64 randconfig-073 gcc-13
x86_64 randconfig-073-20260616 gcc-13
x86_64 randconfig-073-20260616 gcc-14
x86_64 randconfig-074 gcc-13
x86_64 randconfig-074-20260616 gcc-13
x86_64 randconfig-074-20260616 gcc-14
x86_64 randconfig-075 gcc-13
x86_64 randconfig-075-20260616 gcc-13
x86_64 randconfig-075-20260616 gcc-14
x86_64 randconfig-076 gcc-13
x86_64 randconfig-076-20260616 gcc-13
x86_64 randconfig-076-20260616 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260616 gcc-8.5.0
xtensa randconfig-002 gcc-8.5.0
xtensa randconfig-002-20260616 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-06-16 20:30 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
In-Reply-To: <CAPVz0n26H2t=pi_C+t8jP_cWXGSa5pk=1cpTZtkBh3=RQsUk2g@mail.gmail.com>
On Tue, Jun 16, 2026 at 09:45:25AM +0300, Svyatoslav Ryhel wrote:
>
> I have tested your code on my P895 and it works perfectly fine. Should
> I resend with these changes or you can integrate them while picking
> patchset?
I think there was an update requested by Rob for the bindings?
>
> Thank you for your suggestions and efforts!
Thank you for your patience.
--
Dmitry
^ permalink raw reply
* [PATCH v2 0/4] HID: sony: more cleanup
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
This series cleans up hid-sony by utilizing modern helper functions.
v2: the dependent patches have been included in this series
Rosalie Wanders (4):
HID: sony: use dedicated raw_event() handlers in sony_raw_event()
HID: sony: use guard() and scoped_guard()
HID: sony: remove unneeded which argument from sony_schedule_work()
HID: sony: use devm_kasprintf()
drivers/hid/hid-sony.c | 245 +++++++++++++++++++++--------------------
1 file changed, 126 insertions(+), 119 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/4] HID: sony: use dedicated raw_event() handlers in sony_raw_event()
From: Rosalie Wanders @ 2026-06-16 20:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Rosalie Wanders
In-Reply-To: <20260616205042.6671-2-rosalie@mailbox.org>
This commit changes the way sony_raw_event() works by adding a function
pointer to a raw_event() handler in the sc struct instead of manually
checking the quirk in order to call the right function, this simplifies
the sony_raw_event() function alongside making the raw_event() handlers
more self-contained, thus making the code more readable.
The raw_event() handler should be configured using the new
sony_init_raw_event_handler() function in sony_input_configured(), where
we already check for quirks and apply device specific workarounds.
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-sony.c | 145 +++++++++++++++++++++++++----------------
1 file changed, 90 insertions(+), 55 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index e75246d29e16..2d9a5261b63f 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -81,6 +81,7 @@
#define SONY_FF_SUPPORT (SIXAXIS_CONTROLLER | MOTION_CONTROLLER)
#define SONY_BT_DEVICE (SIXAXIS_CONTROLLER_BT | MOTION_CONTROLLER_BT | NAVIGATION_CONTROLLER_BT)
#define NSG_MRXU_REMOTE (NSG_MR5U_REMOTE_BT | NSG_MR7U_REMOTE_BT)
+#define RB4_GUITAR_PS4 (RB4_GUITAR_PS4_USB | RB4_GUITAR_PS4_BT)
#define MAX_LEDS 4
#define NSG_MRXU_MAX_X 1667
@@ -534,6 +535,7 @@ struct sony_sc {
struct input_dev *sensor_dev;
struct led_classdev *leds[MAX_LEDS];
unsigned long quirks;
+ int (*raw_event)(struct sony_sc *sc, u8 *rd, int size);
struct work_struct state_worker;
void (*send_output_report)(struct sony_sc *sc);
struct power_supply *battery;
@@ -946,7 +948,7 @@ static const u8 *sony_report_fixup(struct hid_device *hdev, u8 *rdesc,
return rdesc;
}
-static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int sixaxis_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
static const u8 sixaxis_battery_capacity[] = { 0, 1, 25, 50, 75, 100 };
unsigned long flags;
@@ -955,6 +957,31 @@ static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
u8 battery_capacity;
int battery_status;
+ if (unlikely(size != 49 || rd[0] != 0x01))
+ return 0;
+
+ if (sc->quirks & SIXAXIS_CONTROLLER) {
+ /*
+ * When connected via Bluetooth the Sixaxis occasionally sends
+ * a report with the second byte 0xff and the rest zeroed.
+ *
+ * This report does not reflect the actual state of the
+ * controller must be ignored to avoid generating false input
+ * events.
+ */
+ if (rd[1] == 0xff)
+ return -EINVAL;
+
+ /*
+ * Sixaxis HID report has acclerometers/gyro with MSByte first, this
+ * has to be BYTE_SWAPPED before passing up to joystick interface
+ */
+ swap(rd[41], rd[42]);
+ swap(rd[43], rd[44]);
+ swap(rd[45], rd[46]);
+ swap(rd[47], rd[48]);
+ }
+
/*
* The sixaxis is charging if the battery value is 0xee
* and it is fully charged if the value is 0xef.
@@ -993,13 +1020,18 @@ static void sixaxis_parse_report(struct sony_sc *sc, u8 *rd, int size)
input_sync(sc->sensor_dev);
}
+
+ return 0;
}
-static void nsg_mrxu_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int nsg_mrxu_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
int n, offset, relx, rely;
u8 active;
+ if (unlikely(size < 12 || rd[0] != 0x02))
+ return 0;
+
/*
* The NSG-MRxU multi-touch trackpad data starts at offset 1 and
* the touch-related data starts at offset 2.
@@ -1067,10 +1099,33 @@ static void nsg_mrxu_parse_report(struct sony_sc *sc, u8 *rd, int size)
input_mt_sync_frame(sc->touchpad);
input_sync(sc->touchpad);
+ return 0;
+}
+
+static int rb3_pro_instrument_raw_event(struct sony_sc *sc, u8 *rd, int size)
+{
+ /* Rock Band 3 PS3 Pro instruments set rd[24] to 0xE0 when they're
+ * sending full reports, and 0x02 when only sending navigation.
+ */
+ if (size < 25 || rd[24] != 0x02)
+ return 0;
+
+ /* Only attempt to enable full report every 8 seconds */
+ if (time_after(jiffies, sc->rb3_pro_poke_jiffies)) {
+ sc->rb3_pro_poke_jiffies = jiffies + secs_to_jiffies(8);
+ rb3_pro_instrument_enable_full_report(sc);
+ }
+
+ return 0;
}
-static void rb4_ps4_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int rb4_ps4_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
+ const int expected_size = (sc->quirks & RB4_GUITAR_PS4_BT) ? 78 : 64;
+
+ if (unlikely(size != expected_size || rd[0] != 0x01))
+ return 0;
+
/*
* Rock Band 4 PS4 guitars have whammy and
* tilt functionality, they're located at
@@ -1084,9 +1139,10 @@ static void rb4_ps4_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
input_report_abs(sc->input_dev, ABS_RZ, rd[45]);
input_sync(sc->input_dev);
+ return 0;
}
-static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
+static int rb4_ps5_guitar_raw_event(struct sony_sc *sc, u8 *rd, int size)
{
u8 charging_status;
u8 battery_data;
@@ -1094,6 +1150,9 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
u8 battery_status;
unsigned long flags;
+ if (unlikely(size != 64 || rd[0] != 0x01))
+ return 0;
+
/*
* Rock Band 4 PS5 guitars have whammy and
* tilt functionality, they're located at
@@ -1138,65 +1197,22 @@ static void rb4_ps5_guitar_parse_report(struct sony_sc *sc, u8 *rd, int size)
spin_unlock_irqrestore(&sc->lock, flags);
input_sync(sc->input_dev);
+ return 0;
}
static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
u8 *rd, int size)
{
struct sony_sc *sc = hid_get_drvdata(hdev);
+ int ret;
- /*
- * Sixaxis HID report has acclerometers/gyro with MSByte first, this
- * has to be BYTE_SWAPPED before passing up to joystick interface
- */
- if ((sc->quirks & SIXAXIS_CONTROLLER) && rd[0] == 0x01 && size == 49) {
- /*
- * When connected via Bluetooth the Sixaxis occasionally sends
- * a report with the second byte 0xff and the rest zeroed.
- *
- * This report does not reflect the actual state of the
- * controller must be ignored to avoid generating false input
- * events.
- */
- if (rd[1] == 0xff)
- return -EINVAL;
-
- swap(rd[41], rd[42]);
- swap(rd[43], rd[44]);
- swap(rd[45], rd[46]);
- swap(rd[47], rd[48]);
-
- sixaxis_parse_report(sc, rd, size);
- } else if ((sc->quirks & MOTION_CONTROLLER_BT) && rd[0] == 0x01 && size == 49) {
- sixaxis_parse_report(sc, rd, size);
- } else if ((sc->quirks & NAVIGATION_CONTROLLER) && rd[0] == 0x01 && size == 49) {
- sixaxis_parse_report(sc, rd, size);
- } else if ((sc->quirks & NSG_MRXU_REMOTE) && rd[0] == 0x02 && size >= 12) {
- nsg_mrxu_parse_report(sc, rd, size);
- return 1;
- } else if ((sc->quirks & RB4_GUITAR_PS4_USB) && rd[0] == 0x01 && size == 64) {
- rb4_ps4_guitar_parse_report(sc, rd, size);
- return 1;
- } else if ((sc->quirks & RB4_GUITAR_PS4_BT) && rd[0] == 0x01 && size == 78) {
- rb4_ps4_guitar_parse_report(sc, rd, size);
- return 1;
- } else if ((sc->quirks & RB4_GUITAR_PS5) && rd[0] == 0x01 && size == 64) {
- rb4_ps5_guitar_parse_report(sc, rd, size);
- return 1;
- }
-
- /* Rock Band 3 PS3 Pro instruments set rd[24] to 0xE0 when they're
- * sending full reports, and 0x02 when only sending navigation.
- */
- if ((sc->quirks & RB3_PRO_INSTRUMENT) && size >= 25 && rd[24] == 0x02) {
- /* Only attempt to enable full report every 8 seconds */
- if (time_after(jiffies, sc->rb3_pro_poke_jiffies)) {
- sc->rb3_pro_poke_jiffies = jiffies + secs_to_jiffies(8);
- rb3_pro_instrument_enable_full_report(sc);
- }
+ if (sc->raw_event) {
+ ret = sc->raw_event(sc, rd, size);
+ if (unlikely(ret < 0))
+ return ret;
}
- if (sc->defer_initialization) {
+ if (unlikely(sc->defer_initialization)) {
sc->defer_initialization = 0;
sony_schedule_work(sc, SONY_WORKER_STATE);
}
@@ -1256,7 +1272,7 @@ static int sony_mapping(struct hid_device *hdev, struct hid_input *hi,
if (sc->quirks & DJH_TURNTABLE)
return djh_turntable_mapping(hdev, hi, field, usage, bit, max);
- if (sc->quirks & (RB4_GUITAR_PS4_USB | RB4_GUITAR_PS4_BT))
+ if (sc->quirks & RB4_GUITAR_PS4)
return rb4_guitar_mapping(hdev, hi, field, usage, bit, max);
if (sc->quirks & RB4_GUITAR_PS5)
@@ -2110,6 +2126,12 @@ static void sony_release_device_id(struct sony_sc *sc)
}
}
+static inline void sony_init_raw_event_handler(struct sony_sc *sc,
+ int (*raw_event)(struct sony_sc *, u8 *, int))
+{
+ sc->raw_event = raw_event;
+}
+
static inline void sony_init_output_report(struct sony_sc *sc,
void (*send_output_report)(struct sony_sc *))
{
@@ -2185,6 +2207,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & NAVIGATION_CONTROLLER_BT) {
/*
@@ -2199,6 +2222,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & RB3_PRO_INSTRUMENT) {
/*
@@ -2213,6 +2237,8 @@ static int sony_input_configured(struct hid_device *hdev,
*/
hdev->quirks |= HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP;
hdev->quirks |= HID_QUIRK_SKIP_OUTPUT_REPORT_ID;
+
+ sony_init_raw_event_handler(sc, rb3_pro_instrument_raw_event);
} else if (sc->quirks & SIXAXIS_CONTROLLER_USB) {
/*
* The Sony Sixaxis does not handle HID Output Reports on the
@@ -2237,6 +2263,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & SIXAXIS_CONTROLLER_BT) {
/*
@@ -2258,6 +2285,7 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, sixaxis_send_output_report);
} else if (sc->quirks & NSG_MRXU_REMOTE) {
/*
@@ -2273,8 +2301,15 @@ static int sony_input_configured(struct hid_device *hdev,
goto err_stop;
}
+ sony_init_raw_event_handler(sc, nsg_mrxu_raw_event);
} else if (sc->quirks & MOTION_CONTROLLER) {
+ if (sc->quirks & MOTION_CONTROLLER_BT)
+ sony_init_raw_event_handler(sc, sixaxis_raw_event);
sony_init_output_report(sc, motion_send_output_report);
+ } else if (sc->quirks & RB4_GUITAR_PS4) {
+ sony_init_raw_event_handler(sc, rb4_ps4_guitar_raw_event);
+ } else if (sc->quirks & RB4_GUITAR_PS5) {
+ sony_init_raw_event_handler(sc, rb4_ps5_guitar_raw_event);
}
if (sc->quirks & SONY_LED_SUPPORT) {
--
2.54.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