* Re: [PATCH] Input: ims-pcu - bound frame parser write index against read_buf size
From: Dmitry Torokhov @ 2026-04-26 5:12 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <2026042414-demeanor-dimple-83b0@gregkh>
On Fri, Apr 24, 2026 at 06:16:57AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 23, 2026 at 10:24:08AM -0700, Dmitry Torokhov wrote:
> > On Thu, Apr 23, 2026 at 06:52:23AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Apr 22, 2026 at 06:36:24PM -0700, Dmitry Torokhov wrote:
> > > > Hi Greg,
> > > >
> > > > On Mon, Apr 20, 2026 at 09:05:31PM +0200, Greg Kroah-Hartman wrote:
> > > > > ims_pcu_process_data() implements a STX/DLE/ETX byte-stuffing parser
> > > > > that accumulates frame payload into pcu->read_buf[] using the running
> > > > > index pcu->read_pos. read_buf is IMS_PCU_BUF_SIZE (128) bytes and
> > > > > read_pos is u8 but of course, we don't check the index before actually
> > > > > writing the data :(
> > > > >
> > > > > Fix this up by properly rejecting the frame at the first attempt to
> > > > > write past read_buf and resync on the next STX, mirroring how the parser
> > > > > handles short and bad-checksum frames on ETX.
> > > > >
> > > > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > > > Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
> > > > > Cc: stable <stable@kernel.org>
> > > > > Assisted-by: gkh_clanker_t1000
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > I already have a patch for this, thanks.
> > >
> > > Ah, missed that, sorry, I was working against Linus's tree. I am
> > > guessing you are referring to commit 875115b82c29 ("Input: ims-pcu - fix
> > > heap-buffer-overflow in ims_pcu_process_data()")? If so, why wasn't
> > > that tagged for stable inclusion?
> >
> > I do not believe it is worth it. The driver is for specialized hardware,
> > so common distros will not be enabling it, and systems where it is used
> > likely do not allow plugging weird stuff into them and probably do not
> > use stable either.
>
> Android allows a lot of odd things to be plugged into it :(
Well, that's on them. Do they enable drivers blindly?
>
> > I actually wonder if we need to carry the driver or if we should simply
> > drop it. The only non-cleanup change to it was done in 2014.
>
> I'll gladly send a patch to delete it if you want me to.
Sure, let's do it. It's easy to restore it if it is actually needed.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: elan_i2c - validate firmware size before use
From: Dmitry Torokhov @ 2026-04-26 5:07 UTC (permalink / raw)
To: linux-input, Jingle Wu 吳金國; +Cc: linux-kernel
Ensure that the firmware file is large enough to contain the expected
number of pages and the signature (which resides at the end of the
firmware blob) before accessing them to prevent potential out-of-bounds
reads.
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/elan_i2c_core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index fee1796da3d0..74f822cd8774 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -645,6 +645,11 @@ static ssize_t elan_sysfs_update_fw(struct device *dev,
return error;
}
+ if (fw->size < data->fw_signature_address + sizeof(signature)) {
+ dev_err(dev, "firmware file too small\n");
+ return -EBADF;
+ }
+
/* Firmware file must match signature data */
fw_signature = &fw->data[data->fw_signature_address];
if (memcmp(fw_signature, signature, sizeof(signature)) != 0) {
--
2.54.0.545.g6539524ca2-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Dmitry Torokhov @ 2026-04-26 4:51 UTC (permalink / raw)
To: Kris Bahnsen
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <20260424192534.3504976-1-kris@embeddedTS.com>
Hi Kris,
On Fri, Apr 24, 2026 at 07:25:34PM +0000, Kris Bahnsen wrote:
> The workaround for XPT2046 clears the command register, giving the
> touchscreen controller a NOP. The change incorrectly re-uses the
> req->scratch variable which is used as rx_buf for xfer[5], so by
> the time xfer[6] occurs, the contents of req->scratch may not be
> 0. It was found that the touchscreen controller can end up in
> a completely unresponsive state due to it being given a command
> the driver does not expect.
>
> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
> transmit all 0 bits, moving the 3 bytes to a single message.
>
> This change was tested on real TSC2046 and ADS7843 controllers,
> but not the XPT2046 the workaround was originally created for.
> Confirming that the original modification to clear the command
> register does not impact either real controller.
>
> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
> Cc: stable@vger.kernel.org
> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
> ---
> drivers/input/touchscreen/ads7846.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
> index 4b39f7212d35c..599793d27129e 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -327,7 +327,7 @@ struct ser_req {
> u8 ref_off;
> u16 scratch;
> struct spi_message msg;
> - struct spi_transfer xfer[8];
> + struct spi_transfer xfer[7];
> /*
> * DMA (thus cache coherency maintenance) requires the
> * transfer buffers to live in their own cache lines.
> @@ -403,16 +403,11 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
> spi_message_add_tail(&req->xfer[5], &req->msg);
>
> /* clear the command register */
> - req->scratch = 0;
> - req->xfer[6].tx_buf = &req->scratch;
> - req->xfer[6].len = 1;
> + req->xfer[6].rx_buf = &req->scratch;
> + req->xfer[6].len = 3;
Doesn't this overflow "scratch" which is only 2 bytes? I guess there is
a hole in ser_req between "scratch" and "msg" but I do not think we
should rely on this.
Can we also set rx_buf to NULL to discard incoming data?
[credit to sashiko].
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-04-26 4:28 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAPVz0n2-JE6E10O_rFZYPSET62HfAz3Zw8vyNa8xoALQQJR7Xw@mail.gmail.com>
Hi Svyatoslav,
On Sat, Apr 25, 2026 at 08:26:00PM +0300, Svyatoslav Ryhel wrote:
> Hello Dmitry!
>
> I have a question regarding this sashiko comment
>
> > +static void isa1200_play_work(struct work_struct *work)
> > +{
> > + struct isa1200 *isa =
> > + container_of(work, struct isa1200, play_work);
> > +
> > + if (isa->level)
> > + isa1200_start(isa);
> > + else
> > + isa1200_stop(isa);
> > +}
> Because the driver tracks isa->level locklessly, if an effect starts
> and quickly stops, the workqueue might only execute once. When it
> executes, it sees isa->level == 0 and calls isa1200_stop(). Since
> isa1200_start() was never called for this effect,
> clk_disable_unprepare(isa->clk) will be invoked on an un-enabled
> clock. Does this unbalance the clock reference count?
>
> This is a valid comment, but I cannot find how this should be handled
> among all available haptic drivers. Maybe you can point me in the
> right direction?
Maybe have a flag reflecting the true (committed) state of the
controller that is both checked and updated in the work entity?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: bpf: Add Huion Inspiroy Frego M button quirk
From: Nikhil Chatterjee @ 2026-04-26 3:18 UTC (permalink / raw)
To: jikos; +Cc: bentiss, linux-input, Nikhil Chatterjee
The Huion Inspiroy Frego M pen report descriptor exposes the second
side button as Secondary Tip Switch instead of Secondary Barrel Switch.
This makes userspace see the control as the wrong pen button.
Add a HID-BPF report descriptor fixup for the Bluetooth 256c:8251
device and USB 256c:2012 L610 variant. The fixup matches the expected
pen descriptor and rewrites the offending usage from Secondary Tip
Switch to Secondary Barrel Switch.
Tested by building the HID-BPF object with:
make -C drivers/hid/bpf/progs Huion__Inspiroy-Frego-M.bpf.o
Signed-off-by: Nikhil Chatterjee <nikhilc1527@gmail.com>
---
.../bpf/progs/Huion__Inspiroy-Frego-M.bpf.c | 87 +++++++++++++++++++
1 file changed, 87 insertions(+)
create mode 100644 drivers/hid/bpf/progs/Huion__Inspiroy-Frego-M.bpf.c
diff --git a/drivers/hid/bpf/progs/Huion__Inspiroy-Frego-M.bpf.c b/drivers/hid/bpf/progs/Huion__Inspiroy-Frego-M.bpf.c
new file mode 100644
index 000000000000..e6ba2295dc77
--- /dev/null
+++ b/drivers/hid/bpf/progs/Huion__Inspiroy-Frego-M.bpf.c
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include "vmlinux.h"
+#include "hid_bpf.h"
+#include "hid_bpf_helpers.h"
+#include <bpf/bpf_tracing.h>
+
+/*
+ * Huion Inspiroy Frego M Pen Tablet
+ * Model L610
+ * 256c:8251 (Bluetooth)
+ * 256c:2012 (USB)
+ */
+#define VID_HUION 0x256C
+#define PID_INSPIROY_FREGO_M 0x8251
+#define PID_L610 0x2012
+
+#define PEN_RDESC_SIZE 125
+#define SECONDARY_SWITCH_OFFSET 17
+
+HID_BPF_CONFIG(
+ HID_DEVICE(BUS_BLUETOOTH, HID_GROUP_GENERIC, VID_HUION, PID_INSPIROY_FREGO_M),
+ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, VID_HUION, PID_L610)
+);
+
+/*
+ * The pen descriptor reports the second side button as Secondary Tip Switch
+ * instead of Secondary Barrel Switch.
+ *
+ * Relevant part of the original pen report descriptor:
+ *
+ * 0x09, 0x42, // Usage (Tip Switch) 12
+ * 0x09, 0x44, // Usage (Barrel Switch) 14
+ * 0x09, 0x43, // Usage (Secondary Tip Switch) 16 <- change to 0x5a
+ * 0x09, 0x3c, // Usage (Invert) 18
+ * 0x09, 0x45, // Usage (Eraser) 20
+ * 0x15, 0x00, // Logical Minimum (0) 22
+ * 0x25, 0x01, // Logical Maximum (1) 24
+ */
+SEC(HID_BPF_RDESC_FIXUP)
+int BPF_PROG(fix_secondary_barrel_rdesc, struct hid_bpf_ctx *hctx)
+{
+ __u8 *data = hid_bpf_get_data(hctx, 0 /* offset */, HID_MAX_DESCRIPTOR_SIZE /* size */);
+
+ if (!data)
+ return 0; /* EPERM check */
+
+ if (hctx->size != PEN_RDESC_SIZE)
+ return 0;
+
+ if (data[0] != 0x05 || data[1] != 0x0d || /* Usage Page (Digitizers) */
+ data[2] != 0x09 || data[3] != 0x02 || /* Usage (Pen) */
+ data[16] != 0x09 ||
+ data[SECONDARY_SWITCH_OFFSET] != 0x43) /* Secondary Tip Switch */
+ return 0;
+
+ data[SECONDARY_SWITCH_OFFSET] = 0x5a;
+
+ return 0;
+}
+
+HID_BPF_OPS(fix_secondary_barrel) = {
+ .hid_rdesc_fixup = (void *)fix_secondary_barrel_rdesc,
+};
+
+SEC("syscall")
+int probe(struct hid_bpf_probe_args *ctx)
+{
+ ctx->retval = ctx->rdesc_size != PEN_RDESC_SIZE;
+ if (ctx->retval) {
+ ctx->retval = -EINVAL;
+ return 0;
+ }
+
+ if (ctx->rdesc[0] != 0x05 || ctx->rdesc[1] != 0x0d || /* Usage Page (Digitizers) */
+ ctx->rdesc[2] != 0x09 || ctx->rdesc[3] != 0x02 || /* Usage (Pen) */
+ ctx->rdesc[16] != 0x09 ||
+ ctx->rdesc[SECONDARY_SWITCH_OFFSET] != 0x43) { /* Secondary Tip Switch */
+ ctx->retval = -EINVAL;
+ return 0;
+ }
+
+ ctx->retval = 0;
+
+ return 0;
+}
+
+char _license[] SEC("license") = "GPL";
--
2.53.0
^ permalink raw reply related
* [BUG] Intel ISH (Lunar Lake) firmware rejected on ASUS Vivobook 16 Flip TP3607SH
From: יוני ביטון @ 2026-04-26 2:00 UTC (permalink / raw)
To: linux-input
Hi,
I'm reporting a bug with ISH firmware loading on a Lunar Lake-based
2-in-1
laptop (ASUS Vivobook 16 Flip TP3607SH).
== Hardware ==
Vendor: ASUSTeK COMPUTER INC.
Product: ASUS Vivobook 16 Flip TP3607SH_TP3607SH
Family: ASUS Vivobook 16 Flip
CPU: Intel Core Ultra 7 258V (Lunar Lake)
Kernel: 6.19.13-200.fc43.x86_64
ISH: 00:12.0 (intel_ish_ipc loaded)
== Symptom ==
On every boot, the ISH firmware loader fails with:
intel_ish_ipc 0000:00:12.0: ISH loader: load firmware:
intel/ish/ish_lnlm.bin cmd 2 failed 10
(repeated 3 times, then ISH gives up)
The generic ish_lnlm.bin from linux-firmware is loaded into memory
but the
ISH bootloader rejects it (cmd 2 = START, error 10 = rejected).
== Impact ==
Without a working ISH:
- No IIO sensors visible under /sys/bus/iio/devices/
- iio-sensor-proxy cannot detect orientation
- No SW_TABLET_MODE events from Intel HID driver
- Screen rotation and tablet mode are completely non-functional
The DSDT _QAC method (EC query 0xAC, triggered on hinge fold) reads
hinge
angle from EC RAM 0x90CF — a value populated by the ISH. Without ISH,
the
entire tablet detection chain is broken.
== What I tried ==
The Windows driver package for this device ships two ISH firmwares:
- ishheci.inf.../FwImage/0003/ishS_SI_5.8.0.7725.bin (991 KB)
- ishheciextensiontemplate.inf.../FwImage/0003/ishS_SI.bin (523
KB)
Both are $CPD/$ISHM format (verified with hexdump). I renamed the
larger
one to ish_lnlm_ef534c00_621ac0c8.bin (using DMI CRC32 values: vendor
ef534c00, product 621ac0c8) and installed it to
/lib/firmware/intel/ish/.
Result: same "cmd 2 failed 10" failure. After rmmod/modprobe, a
different
error appeared ("Timed out waiting for HW ready"), likely a hardware
state
issue from the hot-reload. After a full reboot: back to "cmd 2 failed
10".
== Root cause hypothesis ==
Based on the similar report for Samsung Galaxy Book5 (also Lunar
Lake), and
feedback from Intel engineer Zhang Lixu, the understanding is:
The ISH bootloader on Lunar Lake is baked into ME/BIOS and
validates the
signature of the loaded firmware. The Windows firmware is signed for the
Windows HECI loading protocol. The Linux ISHTP FW-Loader uses a
different
mechanism and requires an OEM-signed firmware specifically
built/signed for
Linux.
ASUS has not contributed such a firmware to linux-firmware.git. The
only
vendor-specific Lunar Lake ISH firmwares currently in linux-firmware are
for CRC prefix 53c4ffad (HP/Lenovo?), not ef534c00 (ASUSTeK).
== Request ==
1. Can anyone confirm whether my root-cause analysis is correct —
i.e., that
the Windows firmware is genuinely incompatible with the Linux ISHTP loader
due to signing, not just naming?
2. Is there a known process for requesting that ASUS contribute the
correct
firmware? I'm happy to open a bug on ASUS's Linux tracker or
contact their
developer relations if that would help.
3. Are there other Lunar Lake ASUS users hitting this? I'd like to
know if
it's device-specific or affects the entire ASUSTeK Lunar Lake lineup.
DMI info for reference:
sys_vendor CRC32: ef534c00 ("ASUSTeK COMPUTER INC.")
product_name CRC32: 621ac0c8 ("ASUS Vivobook 16 Flip
TP3607SH_TP3607SH")
product_family CRC32: f25e936f ("ASUS Vivobook 16 Flip")
Thanks, jony....
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Marek Vasut @ 2026-04-26 0:51 UTC (permalink / raw)
To: Kris Bahnsen, Dmitry Torokhov
Cc: stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <20260424192534.3504976-1-kris@embeddedTS.com>
On 4/24/26 9:25 PM, Kris Bahnsen wrote:
> The workaround for XPT2046 clears the command register, giving the
> touchscreen controller a NOP. The change incorrectly re-uses the
> req->scratch variable which is used as rx_buf for xfer[5], so by
> the time xfer[6] occurs, the contents of req->scratch may not be
> 0. It was found that the touchscreen controller can end up in
> a completely unresponsive state due to it being given a command
> the driver does not expect.
>
> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
> transmit all 0 bits, moving the 3 bytes to a single message.
>
> This change was tested on real TSC2046 and ADS7843 controllers,
> but not the XPT2046 the workaround was originally created for.
> Confirming that the original modification to clear the command
> register does not impact either real controller.
>
> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
> Cc: stable@vger.kernel.org
> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
Tested-by: Marek Vasut <marex@nabladev.com> # XPT2046
^ permalink raw reply
* Re: [PATCH v1 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-04-25 17:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAPVz0n1POe_YuA+RyvLLUdO2D526hb_YQUXJb72Y1h6mW8M6kQ@mail.gmail.com>
пт, 24 квіт. 2026 р. о 19:01 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> пт, 24 квіт. 2026 р. о 18:31 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > On Fri, Apr 24, 2026 at 10:13:05AM +0300, Svyatoslav Ryhel wrote:
> > > From: Linus Walleij <linusw@kernel.org>
> > >
> > > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > > motors for haptic feedback in mobile phones. Used in many mobile devices
> > > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> > >
> > > The exact datasheet for the ISA1200 is not available; all data was modeled
> > > based on available downstream kernel sources for various devices and
> > > fragments of information scattered across the internet.
> > >
> > > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> >
> > There are a bunch of valid sashiko comments, please address them:
> >
> > https://sashiko.dev/#/patchset/20260424071305.89503-1-clamor95%40gmail.com
> >
> > Thanks.
> >
>
> Acknowledged, thank you.
>
Hello Dmitry!
I have a question regarding this sashiko comment
> +static void isa1200_play_work(struct work_struct *work)
> +{
> + struct isa1200 *isa =
> + container_of(work, struct isa1200, play_work);
> +
> + if (isa->level)
> + isa1200_start(isa);
> + else
> + isa1200_stop(isa);
> +}
Because the driver tracks isa->level locklessly, if an effect starts
and quickly stops, the workqueue might only execute once. When it
executes, it sees isa->level == 0 and calls isa1200_stop(). Since
isa1200_start() was never called for this effect,
clk_disable_unprepare(isa->clk) will be invoked on an un-enabled
clock. Does this unbalance the clock reference count?
This is a valid comment, but I cannot find how this should be handled
among all available haptic drivers. Maybe you can point me in the
right direction?
> > --
> > Dmitry
^ permalink raw reply
* [PATCH] platform/x86/lenovo: Add Yoga Book 9 keyboard dock detection driver
From: Dave Carey @ 2026-04-25 13:23 UTC (permalink / raw)
To: platform-driver-x86
Cc: linux-kernel, linux-input, Hans de Goede, Ilpo Järvinen,
Dave Carey
The Lenovo Yoga Book 9 14IAH10 ships with a detachable Bluetooth keyboard
that magnetically attaches to the bottom (secondary) screen in one of two
positions. The Embedded Controller tracks the attachment state in a 2-bit
field called BKBD and signals changes via WMI event GUID
806BD2A2-177B-481D-BFB5-3BA0BB4A2285 (notify ID 0xEB on the WM10 ACPI
device).
The current BKBD state is read via WMI query GUID
E7F300FA-21CD-4003-ADAC-2696135982E6 (WQAF method), which returns an
8-byte buffer: bytes [0..3] hold the LFID constant 0x00060000 and bytes
[4..7] hold the BKBD value.
BKBD encoding:
0 = keyboard detached
1 = keyboard docked on top half of bottom screen
2 = keyboard docked on bottom half of bottom screen
3 = reserved (not observed in practice)
This driver:
- Registers as a WMI driver on the event GUID.
- Queries BKBD state on probe and on each WMI notification.
- Reports SW_TABLET_MODE=1 when detached, SW_TABLET_MODE=0 when docked
in either position (a physical keyboard is present in both cases).
- Exposes the raw BKBD value via a read-only sysfs attribute
"keyboard_position" for use by userspace (e.g. to distinguish between
the two docked positions for different UI layouts).
Tested on: Lenovo Yoga Book 9 14IAH10 (model 83KJ), kernel 6.19.
Signed-off-by: Dave Carey <carvsdriver@gmail.com>
---
.../testing/sysfs-driver-lenovo-yb9-kbdock | 21 ++
MAINTAINERS | 6 +
drivers/platform/x86/lenovo/Kconfig | 14 ++
drivers/platform/x86/lenovo/Makefile | 1 +
drivers/platform/x86/lenovo/yb9-kbdock.c | 216 ++++++++++++++++++
5 files changed, 258 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
create mode 100644 MAINTAINERS
create mode 100644 drivers/platform/x86/lenovo/yb9-kbdock.c
diff --git a/Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock b/Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
new file mode 100644
index 0000000..bb57690
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
@@ -0,0 +1,21 @@
+What: /sys/bus/wmi/drivers/lenovo-yb9-kbdock/<guid>/keyboard_position
+Date: April 2026
+KernelVersion: 6.10
+Contact: Dave Carey <carvsdriver@gmail.com>
+Description:
+ Read-only attribute reporting the current keyboard dock position
+ as reported by the Embedded Controller on the Lenovo Yoga Book 9
+ 14IAH10.
+
+ Possible values:
+
+ == ============================================================
+ 0 detached — keyboard is not docked to any screen
+ 1 top-half — keyboard docked on the top half of the bottom screen
+ 2 bottom-half — keyboard docked on the bottom half of the bottom screen
+ == ============================================================
+
+ The value is formatted as "<n> (<name>)\n", e.g. "1 (top-half)\n".
+
+ SW_TABLET_MODE input events are also emitted: 0 when the keyboard
+ is docked (either position), 1 when detached.
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0000000..cb765b4
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,6 @@
+LENOVO YOGA BOOK 9 KEYBOARD DOCK DRIVER
+M: Dave Carey <carvsdriver@gmail.com>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: Documentation/ABI/testing/sysfs-driver-lenovo-yb9-kbdock
+F: drivers/platform/x86/lenovo/yb9-kbdock.c
diff --git a/drivers/platform/x86/lenovo/Kconfig b/drivers/platform/x86/lenovo/Kconfig
index 9c48487..938b361 100644
--- a/drivers/platform/x86/lenovo/Kconfig
+++ b/drivers/platform/x86/lenovo/Kconfig
@@ -43,6 +43,20 @@ config LENOVO_WMI_CAMERA
To compile this driver as a module, choose M here: the module
will be called lenovo-wmi-camera.
+config LENOVO_YB9_KBDOCK
+ tristate "Lenovo Yoga Book 9 keyboard dock detection"
+ depends on ACPI_WMI
+ depends on DMI
+ depends on INPUT
+ help
+ Say Y here to enable keyboard dock detection on the Lenovo Yoga Book 9
+ 14IAH10. The detachable Bluetooth keyboard magnetically attaches to
+ either screen; this driver reports SW_TABLET_MODE input events based
+ on the attachment state and exposes the raw position in sysfs.
+
+ To compile this driver as a module, choose M here: the module will be
+ called lenovo-yb9-kbdock.
+
config LENOVO_YMC
tristate "Lenovo Yoga Tablet Mode Control"
depends on ACPI_WMI
diff --git a/drivers/platform/x86/lenovo/Makefile b/drivers/platform/x86/lenovo/Makefile
index 7b2128e..2842d7d 100644
--- a/drivers/platform/x86/lenovo/Makefile
+++ b/drivers/platform/x86/lenovo/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_THINKPAD_LMI) += think-lmi.o
obj-$(CONFIG_THINKPAD_ACPI) += thinkpad_acpi.o
lenovo-target-$(CONFIG_LENOVO_WMI_HOTKEY_UTILITIES) += wmi-hotkey-utilities.o
+lenovo-target-$(CONFIG_LENOVO_YB9_KBDOCK) += yb9-kbdock.o
lenovo-target-$(CONFIG_LENOVO_YMC) += ymc.o
lenovo-target-$(CONFIG_YOGABOOK) += yogabook.o
lenovo-target-$(CONFIG_YT2_1380) += yoga-tab2-pro-1380-fastcharger.o
diff --git a/drivers/platform/x86/lenovo/yb9-kbdock.c b/drivers/platform/x86/lenovo/yb9-kbdock.c
new file mode 100644
index 0000000..693e287
--- /dev/null
+++ b/drivers/platform/x86/lenovo/yb9-kbdock.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Lenovo Yoga Book 9 keyboard-dock detection
+ *
+ * The Yoga Book 9 ships with a detachable Bluetooth keyboard that magnetically
+ * attaches to the bottom screen in one of two positions. The EC tracks
+ * attachment state in a 2-bit field called BKBD and signals changes via WMI
+ * event 0xEB on the WM10 ACPI device.
+ *
+ * BKBD values:
+ * 0 = keyboard detached
+ * 1 = keyboard docked on the top half of the bottom screen
+ * 2 = keyboard docked on the bottom half of the bottom screen
+ * 3 = reserved / not observed
+ *
+ * This driver registers for the WMI event GUID, queries BKBD on probe and on
+ * each event, reports SW_TABLET_MODE=0 when the keyboard is docked (either
+ * position) and SW_TABLET_MODE=1 when detached, and exposes the raw BKBD
+ * value in sysfs as "keyboard_position".
+ *
+ * Copyright (C) 2026 Dave Carey <carvsdriver@gmail.com>
+ */
+
+#include <linux/acpi.h>
+#include <linux/dmi.h>
+#include <linux/input.h>
+#include <linux/module.h>
+#include <linux/wmi.h>
+
+/*
+ * WM10 ACPI device (_UID "GMZN"):
+ * Event GUID — notify ID 0xEB fires on keyboard attachment change.
+ * Query GUID — object "AF", maps to WQAF(); returns 8-byte buffer
+ * {LFID=0x00060000, BKBD[31:0]}.
+ */
+#define YB9_KBDOCK_EVENT_GUID "806BD2A2-177B-481D-BFB5-3BA0BB4A2285"
+#define YB9_KBDOCK_QUERY_GUID "E7F300FA-21CD-4003-ADAC-2696135982E6"
+
+#define YB9_KBDOCK_QUERY_INSTANCE 0
+
+/* BKBD encoding — keyboard always docks on the bottom screen */
+#define BKBD_DETACHED 0
+#define BKBD_TOP_HALF 1 /* docked on top half of bottom screen */
+#define BKBD_BOTTOM_HALF 2 /* docked on bottom half of bottom screen */
+
+static const struct dmi_system_id yb9_kbdock_dmi_table[] = {
+ {
+ /* Lenovo Yoga Book 9 14IAH10 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "83KJ"),
+ },
+ },
+ { }
+};
+
+struct yb9_kbdock_priv {
+ struct input_dev *input_dev;
+ unsigned int bkbd; /* last read BKBD value (0-3) */
+};
+
+/* Read current BKBD state via WQAF. Returns 0-3 or -errno. */
+static int yb9_kbdock_query(struct wmi_device *wdev)
+{
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ acpi_status status;
+ u32 bkbd;
+
+ status = wmi_query_block(YB9_KBDOCK_QUERY_GUID,
+ YB9_KBDOCK_QUERY_INSTANCE, &out);
+ if (ACPI_FAILURE(status)) {
+ dev_warn(&wdev->dev, "WQAF query failed: %s\n",
+ acpi_format_exception(status));
+ return -EIO;
+ }
+
+ obj = out.pointer;
+ if (!obj) {
+ dev_warn(&wdev->dev, "WQAF returned NULL\n");
+ return -EIO;
+ }
+
+ /*
+ * WQAF returns an 8-byte buffer: bytes [0..3] = LFID (0x00060000),
+ * bytes [4..7] = BKBD value. Guard against short buffers.
+ */
+ if (obj->type == ACPI_TYPE_BUFFER && obj->buffer.length >= 8) {
+ memcpy(&bkbd, obj->buffer.pointer + 4, sizeof(bkbd));
+ bkbd &= 0x3;
+ } else if (obj->type == ACPI_TYPE_INTEGER) {
+ bkbd = obj->integer.value & 0x3;
+ } else {
+ dev_warn(&wdev->dev,
+ "WQAF: unexpected result type %d len %u\n",
+ obj->type,
+ obj->type == ACPI_TYPE_BUFFER
+ ? obj->buffer.length : 0);
+ kfree(obj);
+ return -EIO;
+ }
+
+ kfree(obj);
+ return (int)bkbd;
+}
+
+static void yb9_kbdock_update(struct wmi_device *wdev)
+{
+ struct yb9_kbdock_priv *priv = dev_get_drvdata(&wdev->dev);
+ int bkbd;
+ int tablet_mode;
+
+ bkbd = yb9_kbdock_query(wdev);
+ if (bkbd < 0)
+ return;
+
+ priv->bkbd = bkbd;
+
+ /*
+ * Report tablet mode only when the keyboard is fully detached.
+ * Both docked positions (top-half and bottom-half of the bottom screen)
+ * indicate a physical keyboard is present — report laptop mode.
+ */
+ tablet_mode = (bkbd == BKBD_DETACHED) ? 1 : 0;
+
+ input_report_switch(priv->input_dev, SW_TABLET_MODE, tablet_mode);
+ input_sync(priv->input_dev);
+
+ dev_dbg(&wdev->dev, "BKBD=%u tablet_mode=%d\n", bkbd, tablet_mode);
+}
+
+static void yb9_kbdock_notify(struct wmi_device *wdev, union acpi_object *data)
+{
+ yb9_kbdock_update(wdev);
+}
+
+/* sysfs: keyboard_position — exposes raw BKBD value */
+static ssize_t keyboard_position_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct yb9_kbdock_priv *priv = dev_get_drvdata(dev);
+ static const char * const names[] = {
+ "detached", "top-half", "bottom-half", "unknown"
+ };
+ unsigned int bkbd = priv->bkbd;
+
+ if (bkbd > 3)
+ bkbd = 3;
+ return sysfs_emit(buf, "%u (%s)\n", bkbd, names[bkbd]);
+}
+static DEVICE_ATTR_RO(keyboard_position);
+
+static struct attribute *yb9_kbdock_attrs[] = {
+ &dev_attr_keyboard_position.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(yb9_kbdock);
+
+static int yb9_kbdock_probe(struct wmi_device *wdev, const void *ctx)
+{
+ struct yb9_kbdock_priv *priv;
+ struct input_dev *input_dev;
+ int err;
+
+ if (!dmi_check_system(yb9_kbdock_dmi_table)) {
+ dev_dbg(&wdev->dev, "not a Yoga Book 9, skipping\n");
+ return -ENODEV;
+ }
+
+ priv = devm_kzalloc(&wdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ input_dev = devm_input_allocate_device(&wdev->dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ input_dev->name = "Lenovo Yoga Book 9 keyboard dock switch";
+ input_dev->phys = YB9_KBDOCK_EVENT_GUID "/input0";
+ input_dev->id.bustype = BUS_HOST;
+ input_set_capability(input_dev, EV_SW, SW_TABLET_MODE);
+
+ err = input_register_device(input_dev);
+ if (err) {
+ dev_err(&wdev->dev, "failed to register input device: %d\n", err);
+ return err;
+ }
+
+ priv->input_dev = input_dev;
+ dev_set_drvdata(&wdev->dev, priv);
+
+ /* Report initial state */
+ yb9_kbdock_update(wdev);
+ return 0;
+}
+
+static const struct wmi_device_id yb9_kbdock_wmi_id_table[] = {
+ { .guid_string = YB9_KBDOCK_EVENT_GUID },
+ { }
+};
+MODULE_DEVICE_TABLE(wmi, yb9_kbdock_wmi_id_table);
+
+static struct wmi_driver yb9_kbdock_driver = {
+ .driver = {
+ .name = "lenovo-yb9-kbdock",
+ .dev_groups = yb9_kbdock_groups,
+ },
+ .id_table = yb9_kbdock_wmi_id_table,
+ .probe = yb9_kbdock_probe,
+ .notify = yb9_kbdock_notify,
+};
+module_wmi_driver(yb9_kbdock_driver);
+
+MODULE_AUTHOR("Dave Carey <carvsdriver@gmail.com>");
+MODULE_DESCRIPTION("Lenovo Yoga Book 9 keyboard dock detection");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Kris Bahnsen @ 2026-04-24 19:25 UTC (permalink / raw)
To: Dmitry Torokhov, Marek Vasut
Cc: Kris Bahnsen, stable, Mark Featherston, linux-input, linux-kernel
The workaround for XPT2046 clears the command register, giving the
touchscreen controller a NOP. The change incorrectly re-uses the
req->scratch variable which is used as rx_buf for xfer[5], so by
the time xfer[6] occurs, the contents of req->scratch may not be
0. It was found that the touchscreen controller can end up in
a completely unresponsive state due to it being given a command
the driver does not expect.
Instead, rely on the spi_transfer behavior of tx_buf being NULL to
transmit all 0 bits, moving the 3 bytes to a single message.
This change was tested on real TSC2046 and ADS7843 controllers,
but not the XPT2046 the workaround was originally created for.
Confirming that the original modification to clear the command
register does not impact either real controller.
Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
Cc: stable@vger.kernel.org
Co-developed-by: Mark Featherston <mark@embeddedTS.com>
Signed-off-by: Mark Featherston <mark@embeddedTS.com>
Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
---
drivers/input/touchscreen/ads7846.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 4b39f7212d35c..599793d27129e 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -327,7 +327,7 @@ struct ser_req {
u8 ref_off;
u16 scratch;
struct spi_message msg;
- struct spi_transfer xfer[8];
+ struct spi_transfer xfer[7];
/*
* DMA (thus cache coherency maintenance) requires the
* transfer buffers to live in their own cache lines.
@@ -403,16 +403,11 @@ static int ads7846_read12_ser(struct device *dev, unsigned command)
spi_message_add_tail(&req->xfer[5], &req->msg);
/* clear the command register */
- req->scratch = 0;
- req->xfer[6].tx_buf = &req->scratch;
- req->xfer[6].len = 1;
+ req->xfer[6].rx_buf = &req->scratch;
+ req->xfer[6].len = 3;
+ CS_CHANGE(req->xfer[6]);
spi_message_add_tail(&req->xfer[6], &req->msg);
- req->xfer[7].rx_buf = &req->scratch;
- req->xfer[7].len = 2;
- CS_CHANGE(req->xfer[7]);
- spi_message_add_tail(&req->xfer[7], &req->msg);
-
scoped_guard(mutex, &ts->lock) {
ads7846_stop(ts);
status = spi_sync(spi, &req->msg);
base-commit: dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/7] iio: HID: Add helper method hid_sensor_adjust_channel_bit_mask()
From: Jonathan Cameron @ 2026-04-24 19:23 UTC (permalink / raw)
To: Natália Salvino André
Cc: andy, bentiss, dlechner, jikos, nuno.sa, srinivas.pandruvada,
Pietro Di Consolo Gregorio, linux-iio, linux-input
In-Reply-To: <20260421222210.16016-2-natalia.andre@ime.usp.br>
On Tue, 21 Apr 2026 19:20:33 -0300
Natália Salvino André <natalia.andre@ime.usp.br> wrote:
> Add helper method to deduplicate code in HID sensors.
>
> Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
> Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
> Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
> ---
> .../iio/common/hid-sensors/hid-sensor-attributes.c | 12 ++++++++++++
> include/linux/hid-sensor-hub.h | 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> index c115a72832b2..3ee6e83c6cac 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> @@ -3,6 +3,7 @@
> * HID Sensors Driver
> * Copyright (c) 2012, Intel Corporation.
> */
> +#include <linux/bits.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/time.h>
> @@ -589,6 +590,17 @@ int hid_sensor_parse_common_attributes(struct hid_sensor_hub_device *hsdev,
> }
> EXPORT_SYMBOL_NS(hid_sensor_parse_common_attributes, "IIO_HID");
>
> +void hid_sensor_adjust_channel_bit_mask(struct iio_chan_spec *channels,
> + int channel, int size)
> +{
> + channels[channel].scan_type.format = 's';
> + /* Real storage bits will change based on the report desc. */
> + channels[channel].scan_type.realbits = size * BITS_PER_BYTE;
> + /* Maximum size of a sample to capture is u32 */
> + channels[channel].scan_type.storagebits = sizeof(u32) * BITS_PER_BYTE;
> +}
> +EXPORT_SYMBOL_NS(hid_sensor_adjust_channel_bit_mask, "IIO_HID");
> +
Looking at this again:
This feels like a helper that doesn't necessarily add much value.
channels[CHANNEL_SCAN_INDEX_X + i].scan_type = (struct iio_scan_type) {
.format = 's',
.real_bits = BYTES_TO_BITS(st->accel[CHANNEL_SCAN_INDEX_X + i].size),
.storage_bits = BITS_PER_TYPE(u32),
};
Maybe with local variables to help a touch. such as
unsigned int ch = CHANNEL_SCAN_INDEX_X + i];
channels[ch].scan_type = (struct iio_scan_type) {
.format = 's',
.real_bits = BYTES_TO_BITS(st->accel[ch].size),
.storage_bits = BITS_PER_TYPE(u32),
};
Whilst it technically sets other parts of scan_type to 0, they are 0 anyway
so that's harmless given readability improvements.
There is another two uses for ch just above as well so makes this even easier to
argue in favour of as a change as it'll be (this is effectively replacing patch 2)
for (unsigned int i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
unsigned int ch = CHANNEL_SCAN_INDEX_X + i;
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id, ch,
&st->accel[ch]);
if (ret < 0)
break;
channels[ch].scan_type = (struct iio_scan_type) {
.format = 's',
.real_bits = BYTES_TO_BITS(st->accel[ch].size),
.storage_bits = BITS_PER_TYPE(u32),
};
}
Hmm. That's also an odd loop as the use assumes CHANNEL_SCAN_INDEX_X = 0
(which is true) but then uses an offset that implies it isn't. Clearer to
just loop over the actual enum values.
So probably wants to be something like.
for (unsigned int ch = CHANNEL_SCAN_INDEX_X;
i <= CHANNEL_SCAN_INDEX_Z; ch++) { //maybe on a long single line.
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id, ch,
&st->accel[ch]);
if (ret < 0)
break;
channels[ch].scan_type = (struct iio_scan_type) {
.format = 's',
.real_bits = BYTES_TO_BITS(st->accel[ch].size),
.storage_bits = BITS_PER_TYPE(u32),
};
}
> MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@intel.com>");
> MODULE_DESCRIPTION("HID Sensor common attribute processing");
> MODULE_LICENSE("GPL");
> diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
> index e71056553108..6523d46c63e0 100644
> --- a/include/linux/hid-sensor-hub.h
> +++ b/include/linux/hid-sensor-hub.h
> @@ -281,4 +281,7 @@ bool hid_sensor_batch_mode_supported(struct hid_sensor_common *st);
> int hid_sensor_set_report_latency(struct hid_sensor_common *st, int latency);
> int hid_sensor_get_report_latency(struct hid_sensor_common *st);
>
> +void hid_sensor_adjust_channel_bit_mask(struct iio_chan_spec *channels,
> + int channel, int size);
> +
> #endif
^ permalink raw reply
* Re: [PATCH v2 2/7] iio: accel: HID: Replace method accel_3d_adjust_channel_bit_mask()
From: Jonathan Cameron @ 2026-04-24 19:08 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Natália Salvino André, andy, bentiss, dlechner, jikos,
nuno.sa, srinivas.pandruvada, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <aeiPuxj2TRLNRbv1@ashevche-desk.local>
On Wed, 22 Apr 2026 12:07:07 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Apr 21, 2026 at 07:20:34PM -0300, Natália Salvino André wrote:
> > Replace method accel_3d_adjust_channel_bit_mask()
> > with helper method hid_sensor_adjust_channel_bit_mask().
>
> ...
>
> > - accel_3d_adjust_channel_bit_mask(channels,
> > - CHANNEL_SCAN_INDEX_X + i,
> > - st->accel[CHANNEL_SCAN_INDEX_X + i].size);
> > + hid_sensor_adjust_channel_bit_mask(channels,
> > + CHANNEL_SCAN_INDEX_X + i,
> > + st->accel[CHANNEL_SCAN_INDEX_X + i].size);
>
> Indentation is broken. Taking into account that the last line is too long when
> properly indented, perhaps
>
> hid_sensor_adjust_channel_bit_mask(channels,
> CHANNEL_SCAN_INDEX_X + i,
> st->accel[CHANNEL_SCAN_INDEX_X + i].size);
>
> Which makes it most right and under 80 limit.
Hi Andy,
Why the double tab? Maybe just go long on this one and align after the (
^ permalink raw reply
* Re: [PATCH v2 1/7] iio: HID: Add helper method hid_sensor_adjust_channel_bit_mask()
From: Jonathan Cameron @ 2026-04-24 19:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Natália Salvino André, andy, bentiss, dlechner, jikos,
nuno.sa, srinivas.pandruvada, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <aeiO0JRGW0oKdcON@ashevche-desk.local>
On Wed, 22 Apr 2026 12:03:12 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Apr 21, 2026 at 07:20:33PM -0300, Natália Salvino André wrote:
> > Add helper method to deduplicate code in HID sensors.
>
> ...
>
> > +#include <linux/bits.h>
>
> Will need bitops.h instead (see below why).
>
> ...
>
> > +void hid_sensor_adjust_channel_bit_mask(struct iio_chan_spec *channels,
> > + int channel, int size)
> > +{
> > + channels[channel].scan_type.format = 's';
> > + /* Real storage bits will change based on the report desc. */
> > + channels[channel].scan_type.realbits = size * BITS_PER_BYTE;
>
> BITS_TO_BYTES(size)
BYTES_TO_BITS(size)
>
> > + /* Maximum size of a sample to capture is u32 */
> > + channels[channel].scan_type.storagebits = sizeof(u32) * BITS_PER_BYTE;
>
> BITS_PER_TYPE(u32)
>
> > +}
>
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Svyatoslav Ryhel @ 2026-04-24 16:11 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, linux-input, Dmitry Torokhov, devicetree,
Conor Dooley, Krzysztof Kozlowski, Linus Walleij
In-Reply-To: <CAL_JsqKxCdeXDEMirnsBPUnV=3KPFaEeK=PJ+T1_izw5+YsfUQ@mail.gmail.com>
пт, 24 квіт. 2026 р. о 17:58 Rob Herring <robh@kernel.org> пише:
>
> On Fri, Apr 24, 2026 at 7:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > пт, 24 квіт. 2026 р. о 14:55 Rob Herring <robh@kernel.org> пише:
> > >
> > > On Fri, Apr 24, 2026 at 3:57 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > >
> > > > пт, 24 квіт. 2026 р. о 11:30 Rob Herring (Arm) <robh@kernel.org> пише:
> > > > >
> > > > >
> > > > > On Fri, 24 Apr 2026 10:13:04 +0300, Svyatoslav Ryhel wrote:
> > > > > > Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> > > > > > handheld devices and capable of supporting up to two motors.
> > > > > >
> > > > > > The exact datasheet for the ISA1200 is not available; all data was modeled
> > > > > > based on available downstream kernel sources for various devices and
> > > > > > fragments of information scattered across the internet.
> > > > > >
> > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > > ---
> > > > > > .../bindings/input/imagis,isa1200.yaml | 145 ++++++++++++++++++
> > > > > > include/dt-bindings/input/isa1200.h | 16 ++
> > > > > > 2 files changed, 161 insertions(+)
> > > > > > create mode 100644 Documentation/devicetree/bindings/input/imagis,isa1200.yaml
> > > > > > create mode 100644 include/dt-bindings/input/isa1200.h
> > > > > >
> > > > >
> > > > > My bot found errors running 'make dt_binding_check' on your patch:
> > > > >
> > > > > yamllint warnings/errors:
> > > > >
> > > > > dtschema/dtc warnings/errors:
> > > > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/imagis,isa1200.example.dtb: haptic-engine@49 (imagis,isa1200): enable-gpios: [[4294967295, 22, 0], [4294967295, 23, 0]] is too long
> > > > > from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer-common.yaml
> > > > >
> > > > > doc reference errors (make refcheckdocs):
> > > > >
> > > > > See https://patchwork.kernel.org/project/devicetree/patch/20260424071305.89503-2-clamor95@gmail.com
> > > > >
> > > > > The base for the series is generally the latest rc1. A different dependency
> > > > > should be noted in *this* patch.
> > > > >
> > > > > If you already ran 'make dt_binding_check' and didn't see the above
> > > > > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > > > > date:
> > > > >
> > > > > pip3 install dtschema --upgrade
> > > > >
> > > > > Please check and re-submit after running the above command yourself. Note
> > > > > that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> > > > > your schema. However, it must be unset to test all examples with your schema.
> > > > >
> > > >
> > > > I am not sure what is going on here. I have installed dtschema-2026.4
> > > > which seems to be the latest. Running the check with this schema gives
> > > > a clean result, no errors produced.
> > > >
> > > > SCHEMA Documentation/devicetree/bindings/processed-schema.json
> > > > CHKDT ./Documentation/devicetree/bindings
> > > > LINT ./Documentation/devicetree/bindings
> > > > DTEX Documentation/devicetree/bindings/input/imagis,isa1200.example.dts
> > > > DTC [C] Documentation/devicetree/bindings/input/imagis,isa1200.example.dtb
> > >
> > > Let me guess, you have DT_SCHEMA_FILES set? Then you are only
> > > validating against the schemas that match and not all of them. There's
> > > a single binding target now. See commit 400fbf4b5870 ("dt-bindings:
> > > kbuild: Support single binding targets"). Of course, changes in this
> > > schema could affect any other example, so you ultimately have to check
> > > everything with just 'make dt_binding_check'.
> > >
> >
> > Thank you for explanation. That is unfortunate.
> >
> > > The issue here is enable-gpios is defined as a standard property name
> > > with 1 GPIO. I don't think we want to extend that because with more
> > > than 1 you have to know what each signal is and the relationship
> > > between them which will vary.
> > >
> >
> > Is it still possible to use enable-gpios for 2 gpios in local cases
> > (like this one) or I have to use some non-standard naming like
> > en-gpios or control-gpios etc.? This device has 2 pins called hen and
> > len, usually they are hooked to a single gpio, but that is not
> > universally true.
>
> Just do hen-gpios and len-gpios.
>
That would require reworking all gpio handling. Would you mind if I
use control-gpios? It is not standard and does not cause that
complain.
Additionally, is it acceptable to use header defines in imagis,clk-div
or should it use direct values instead. Thank you.
> Rob
^ permalink raw reply
* Re: [PATCH v1 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-04-24 16:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <aeuMn2w3kSUl-wxF@google.com>
пт, 24 квіт. 2026 р. о 18:31 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
>
> On Fri, Apr 24, 2026 at 10:13:05AM +0300, Svyatoslav Ryhel wrote:
> > From: Linus Walleij <linusw@kernel.org>
> >
> > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > motors for haptic feedback in mobile phones. Used in many mobile devices
> > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>
> There are a bunch of valid sashiko comments, please address them:
>
> https://sashiko.dev/#/patchset/20260424071305.89503-1-clamor95%40gmail.com
>
> Thanks.
>
Acknowledged, thank you.
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
From: Zhao mengmeng @ 2026-04-24 15:50 UTC (permalink / raw)
To: Benjamin Tissoires, Alexei Starovoitov
Cc: Jiri Kosina, linux-input, linux-kernel, bpf, Zhao Mengmeng
In-Reply-To: <aeuDkTryZfgjzdcS@beelink>
On April 24, 2026 10:54:45 PM GMT+08:00, Benjamin Tissoires <bentiss@kernel.org> wrote:
>On Apr 24 2026, Alexei Starovoitov wrote:
>> On Fri Apr 24, 2026 at 3:22 AM PDT, Zhao Mengmeng wrote:
>> > From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
>> >
>> > Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
>> > KF_SLEEPABLE may drops the flags globally. sync this flags in
>> > hid_bpf_syscall_kfuncs set to enforce consistency and safety.
>>
>> Makes no sense.
>> These kfuncs are not sleepable.
>
>I'm not sure I parse correctly the reason for the dropping of the flags
>by pahole, but all of those kfuncs are actually sleepable, except for
>hid_bpf_input_report, which is *not* sleepable.
>
>Cheers,
>Benjamin
Hi Benjamin,
Sorry for the noise. I misunderstood the difference between KF_SLEEPABLE
and other KF_XX flags. The initial reason to send the patch is l found a
function signature change after a kfunc in two kfuncs sets, one with KF_IMPLICIT_ARGS,
while the other one without it. So I naively think that all kfuncs should
keep consistant declaration. Alexei is right, l will do more background work
before sending patches next time.
^ permalink raw reply
* Re: [PATCH v1 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-04-24 15:31 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260424071305.89503-3-clamor95@gmail.com>
On Fri, Apr 24, 2026 at 10:13:05AM +0300, Svyatoslav Ryhel wrote:
> From: Linus Walleij <linusw@kernel.org>
>
> The ISA1200 is a haptic feedback unit from Imagis Technology using two
> motors for haptic feedback in mobile phones. Used in many mobile devices
> c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
>
> The exact datasheet for the ISA1200 is not available; all data was modeled
> based on available downstream kernel sources for various devices and
> fragments of information scattered across the internet.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
There are a bunch of valid sashiko comments, please address them:
https://sashiko.dev/#/patchset/20260424071305.89503-1-clamor95%40gmail.com
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Rob Herring @ 2026-04-24 14:57 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-kernel, linux-input, Dmitry Torokhov, devicetree,
Conor Dooley, Krzysztof Kozlowski, Linus Walleij
In-Reply-To: <CAPVz0n1Pmq+fKFw5sPG7Gxjxs59jsA2s64ChnWt2SqkjGon2Aw@mail.gmail.com>
On Fri, Apr 24, 2026 at 7:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> пт, 24 квіт. 2026 р. о 14:55 Rob Herring <robh@kernel.org> пише:
> >
> > On Fri, Apr 24, 2026 at 3:57 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > пт, 24 квіт. 2026 р. о 11:30 Rob Herring (Arm) <robh@kernel.org> пише:
> > > >
> > > >
> > > > On Fri, 24 Apr 2026 10:13:04 +0300, Svyatoslav Ryhel wrote:
> > > > > Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> > > > > handheld devices and capable of supporting up to two motors.
> > > > >
> > > > > The exact datasheet for the ISA1200 is not available; all data was modeled
> > > > > based on available downstream kernel sources for various devices and
> > > > > fragments of information scattered across the internet.
> > > > >
> > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > > ---
> > > > > .../bindings/input/imagis,isa1200.yaml | 145 ++++++++++++++++++
> > > > > include/dt-bindings/input/isa1200.h | 16 ++
> > > > > 2 files changed, 161 insertions(+)
> > > > > create mode 100644 Documentation/devicetree/bindings/input/imagis,isa1200.yaml
> > > > > create mode 100644 include/dt-bindings/input/isa1200.h
> > > > >
> > > >
> > > > My bot found errors running 'make dt_binding_check' on your patch:
> > > >
> > > > yamllint warnings/errors:
> > > >
> > > > dtschema/dtc warnings/errors:
> > > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/imagis,isa1200.example.dtb: haptic-engine@49 (imagis,isa1200): enable-gpios: [[4294967295, 22, 0], [4294967295, 23, 0]] is too long
> > > > from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer-common.yaml
> > > >
> > > > doc reference errors (make refcheckdocs):
> > > >
> > > > See https://patchwork.kernel.org/project/devicetree/patch/20260424071305.89503-2-clamor95@gmail.com
> > > >
> > > > The base for the series is generally the latest rc1. A different dependency
> > > > should be noted in *this* patch.
> > > >
> > > > If you already ran 'make dt_binding_check' and didn't see the above
> > > > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > > > date:
> > > >
> > > > pip3 install dtschema --upgrade
> > > >
> > > > Please check and re-submit after running the above command yourself. Note
> > > > that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> > > > your schema. However, it must be unset to test all examples with your schema.
> > > >
> > >
> > > I am not sure what is going on here. I have installed dtschema-2026.4
> > > which seems to be the latest. Running the check with this schema gives
> > > a clean result, no errors produced.
> > >
> > > SCHEMA Documentation/devicetree/bindings/processed-schema.json
> > > CHKDT ./Documentation/devicetree/bindings
> > > LINT ./Documentation/devicetree/bindings
> > > DTEX Documentation/devicetree/bindings/input/imagis,isa1200.example.dts
> > > DTC [C] Documentation/devicetree/bindings/input/imagis,isa1200.example.dtb
> >
> > Let me guess, you have DT_SCHEMA_FILES set? Then you are only
> > validating against the schemas that match and not all of them. There's
> > a single binding target now. See commit 400fbf4b5870 ("dt-bindings:
> > kbuild: Support single binding targets"). Of course, changes in this
> > schema could affect any other example, so you ultimately have to check
> > everything with just 'make dt_binding_check'.
> >
>
> Thank you for explanation. That is unfortunate.
>
> > The issue here is enable-gpios is defined as a standard property name
> > with 1 GPIO. I don't think we want to extend that because with more
> > than 1 you have to know what each signal is and the relationship
> > between them which will vary.
> >
>
> Is it still possible to use enable-gpios for 2 gpios in local cases
> (like this one) or I have to use some non-standard naming like
> en-gpios or control-gpios etc.? This device has 2 pins called hen and
> len, usually they are hooked to a single gpio, but that is not
> universally true.
Just do hen-gpios and len-gpios.
Rob
^ permalink raw reply
* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
From: Benjamin Tissoires @ 2026-04-24 14:54 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Zhao Mengmeng, Jiri Kosina, linux-input, linux-kernel, bpf,
Zhao Mengmeng
In-Reply-To: <DI1FOWOLC37Y.3DK99VJZDMWKI@gmail.com>
On Apr 24 2026, Alexei Starovoitov wrote:
> On Fri Apr 24, 2026 at 3:22 AM PDT, Zhao Mengmeng wrote:
> > From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
> >
> > Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
> > KF_SLEEPABLE may drops the flags globally. sync this flags in
> > hid_bpf_syscall_kfuncs set to enforce consistency and safety.
>
> Makes no sense.
> These kfuncs are not sleepable.
I'm not sure I parse correctly the reason for the dropping of the flags
by pahole, but all of those kfuncs are actually sleepable, except for
hid_bpf_input_report, which is *not* sleepable.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
From: Alexei Starovoitov @ 2026-04-24 13:53 UTC (permalink / raw)
To: Zhao Mengmeng, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, bpf, Zhao Mengmeng
In-Reply-To: <20260424-btf-define-v1-1-0f52dffad5aa@kylinos.cn>
On Fri Apr 24, 2026 at 3:22 AM PDT, Zhao Mengmeng wrote:
> From: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
>
> Pahole intersects flags across BTF_ID_FLAGS() occurrences, so omitting
> KF_SLEEPABLE may drops the flags globally. sync this flags in
> hid_bpf_syscall_kfuncs set to enforce consistency and safety.
Makes no sense.
These kfuncs are not sleepable.
pw-bot: cr
^ permalink raw reply
* [PATCH 6.6 072/166] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-24 13:29 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260424132532.812258529@linuxfoundation.org>
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1356,6 +1356,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.6 071/166] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-24 13:29 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260424132532.812258529@linuxfoundation.org>
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.
Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* [PATCH] HID: u2fzero: free allocated URB on probe errors
From: Myeonghun Pak @ 2026-04-24 13:21 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel, Myeonghun Pak
u2fzero_fill_in_urb() allocates dev->urb with usb_alloc_urb(), but
u2fzero_probe() ignored its return value and only freed the URB from
u2fzero_remove().
If LED or hwrng registration fails after the URB allocation, probe returns
an error and the driver core does not call .remove(), leaking the URB. A
failed URB setup was also allowed to continue probing with an unusable
device.
Check the URB setup result and add the missing probe-error unwind so the
URB is freed before returning from later errors.
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
drivers/hid/hid-u2fzero.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/hid-u2fzero.c b/drivers/hid/hid-u2fzero.c
index 744a91e6e7..82404b6e2d 100644
--- a/drivers/hid/hid-u2fzero.c
+++ b/drivers/hid/hid-u2fzero.c
@@ -341,29 +341,33 @@ static int u2fzero_probe(struct hid_device *hdev,
if (ret)
return ret;
- u2fzero_fill_in_urb(dev);
+ ret = u2fzero_fill_in_urb(dev);
+ if (ret)
+ goto err_hid_hw_stop;
dev->present = true;
minor = ((struct hidraw *) hdev->hidraw)->minor;
ret = u2fzero_init_led(dev, minor);
- if (ret) {
- hid_hw_stop(hdev);
- return ret;
- }
+ if (ret)
+ goto err_free_urb;
hid_info(hdev, "%s LED initialised\n", hw_configs[dev->hw_revision].name);
ret = u2fzero_init_hwrng(dev, minor);
- if (ret) {
- hid_hw_stop(hdev);
- return ret;
- }
+ if (ret)
+ goto err_free_urb;
hid_info(hdev, "%s RNG initialised\n", hw_configs[dev->hw_revision].name);
return 0;
+
+err_free_urb:
+ usb_free_urb(dev->urb);
+err_hid_hw_stop:
+ hid_hw_stop(hdev);
+ return ret;
}
static void u2fzero_remove(struct hid_device *hdev)
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Svyatoslav Ryhel @ 2026-04-24 12:58 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, linux-input, Dmitry Torokhov, devicetree,
Conor Dooley, Krzysztof Kozlowski, Linus Walleij
In-Reply-To: <CAL_Jsq+dekx_vVFXxLb3oFQ7MM6xkPSSB7vyTV0YWh9BPLhEDw@mail.gmail.com>
пт, 24 квіт. 2026 р. о 14:55 Rob Herring <robh@kernel.org> пише:
>
> On Fri, Apr 24, 2026 at 3:57 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > пт, 24 квіт. 2026 р. о 11:30 Rob Herring (Arm) <robh@kernel.org> пише:
> > >
> > >
> > > On Fri, 24 Apr 2026 10:13:04 +0300, Svyatoslav Ryhel wrote:
> > > > Document the Imagis ISA1200 haptic motor driver, used primarily in mobile
> > > > handheld devices and capable of supporting up to two motors.
> > > >
> > > > The exact datasheet for the ISA1200 is not available; all data was modeled
> > > > based on available downstream kernel sources for various devices and
> > > > fragments of information scattered across the internet.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > .../bindings/input/imagis,isa1200.yaml | 145 ++++++++++++++++++
> > > > include/dt-bindings/input/isa1200.h | 16 ++
> > > > 2 files changed, 161 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/input/imagis,isa1200.yaml
> > > > create mode 100644 include/dt-bindings/input/isa1200.h
> > > >
> > >
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/imagis,isa1200.example.dtb: haptic-engine@49 (imagis,isa1200): enable-gpios: [[4294967295, 22, 0], [4294967295, 23, 0]] is too long
> > > from schema $id: http://devicetree.org/schemas/gpio/gpio-consumer-common.yaml
> > >
> > > doc reference errors (make refcheckdocs):
> > >
> > > See https://patchwork.kernel.org/project/devicetree/patch/20260424071305.89503-2-clamor95@gmail.com
> > >
> > > The base for the series is generally the latest rc1. A different dependency
> > > should be noted in *this* patch.
> > >
> > > If you already ran 'make dt_binding_check' and didn't see the above
> > > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > > date:
> > >
> > > pip3 install dtschema --upgrade
> > >
> > > Please check and re-submit after running the above command yourself. Note
> > > that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> > > your schema. However, it must be unset to test all examples with your schema.
> > >
> >
> > I am not sure what is going on here. I have installed dtschema-2026.4
> > which seems to be the latest. Running the check with this schema gives
> > a clean result, no errors produced.
> >
> > SCHEMA Documentation/devicetree/bindings/processed-schema.json
> > CHKDT ./Documentation/devicetree/bindings
> > LINT ./Documentation/devicetree/bindings
> > DTEX Documentation/devicetree/bindings/input/imagis,isa1200.example.dts
> > DTC [C] Documentation/devicetree/bindings/input/imagis,isa1200.example.dtb
>
> Let me guess, you have DT_SCHEMA_FILES set? Then you are only
> validating against the schemas that match and not all of them. There's
> a single binding target now. See commit 400fbf4b5870 ("dt-bindings:
> kbuild: Support single binding targets"). Of course, changes in this
> schema could affect any other example, so you ultimately have to check
> everything with just 'make dt_binding_check'.
>
Thank you for explanation. That is unfortunate.
> The issue here is enable-gpios is defined as a standard property name
> with 1 GPIO. I don't think we want to extend that because with more
> than 1 you have to know what each signal is and the relationship
> between them which will vary.
>
Is it still possible to use enable-gpios for 2 gpios in local cases
(like this one) or I have to use some non-standard naming like
en-gpios or control-gpios etc.? This device has 2 pins called hen and
len, usually they are hooked to a single gpio, but that is not
universally true.
> Rob
^ permalink raw reply
* [PATCH] HID: google: hammer: stop hardware on devres action failure
From: 박명훈 @ 2026-04-24 12:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel, Myeonghun Pak
From: Myeonghun Pak <mhun512@gmail.com>
hammer_probe() starts the HID hardware before registering the devres
action that stops it. If devm_add_action() fails, probe returns an
error with the hardware still started because the cleanup action was
never registered and the driver's remove callback is not called after a
failed probe.
Use devm_add_action_or_reset() so the stop action runs immediately on
registration failure while preserving the existing devres-managed cleanup
path for later probe failures and remove.
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
drivers/hid/hid-google-hammer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 1af477e584..c99c3c0d44 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -496,7 +496,7 @@ static int hammer_probe(struct hid_device *hdev,
if (error)
return error;
- error = devm_add_action(&hdev->dev, hammer_stop, hdev);
+ error = devm_add_action_or_reset(&hdev->dev, hammer_stop, hdev);
if (error)
return error;
--
2.50.1
^ 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