* [PATCH v7 0/2] Add support for Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-05-01 12:40 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Hendrik Noack, Ferass El Hafidi, linux-input, devicetree,
linux-kernel
Add devicetree bindings and a driver for the Wacom W9000-series penabled
touchscreens.
The driver currently only contains the information for the W9002 and
W9007A, which I or Ferass could test on devices. It should also work with
other chips, such as W9001 or W9010. However, I couldn't test it on these
and the message length would need to be added.
Signed-off-by: Hendrik Noack <hendrik-noack@gmx.de>
---
Changes in v2:
- remove pdct-gpios, as it's unnecessary
- fix devicetree example
- adopt to kernel coding style
---
Changes in v3:
- fix missing include (thanks lkp@intel.com)
---
Changes in v4:
- adopt to feedback (thanks dmitry.torokhov@gmail.com)
- add W9002 support (thanks funderscore@postmarketos.org)
- add reset-gpios, necessary for some chips
- remove R-b from krzk due to changes in dt-bindings
---
Changes in v5:
- adopt dt-bindings format to suggestion (thanks krzk@kernel.org)
- remove pen-inserted functionality as suggested (thanks dmitry.torokhov@gmail.com)
---
Changes in v6:
- add info on difference between variants
- add A-b from conor
- add warning for out of range pressure
---
Changes in v7:
- address feedback of sashiko (thanks dmitry.torokhov@gmail.com)
---
Hendrik Noack (2):
dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
Input: Add support for Wacom W9000-series penabled touchscreens
.../input/touchscreen/wacom,w9007a-lt03.yaml | 73 +++
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/wacom_w9000.c | 446 ++++++++++++++++++
4 files changed, 532 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml
create mode 100644 drivers/input/touchscreen/wacom_w9000.c
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: hid-sensors: introduce device managed API
From: Andy Shevchenko @ 2026-05-01 12:34 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Andy Shevchenko, jikos, jic23, srinivas.pandruvada, dlechner,
nuno.sa, andy, sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <D8E78026-517D-4CE8-927E-6F4AC7E21454@gmail.com>
On Thu, Apr 30, 2026 at 10:30 PM Sanjay Chitroda
<sanjayembeddedse@gmail.com> wrote:
> On 30 April 2026 1:01:27 am IST, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >On Wed, Apr 29, 2026 at 11:29:16PM +0530, Sanjay Chitroda wrote:
...
> >> +static void hid_sensor_remove_trigger_action(void *ptr)
> >> +{
> >> + struct hid_sensor_common *attrb = ptr;
> >> +
> >> + hid_sensor_remove_trigger(attrb);
> >> +}
> >
> >Casting is not needed here.
> >
> >static void hid_sensor_remove_trigger_action(void *attrb)
> >{
> > hid_sensor_remove_trigger(attrb);
> >}
>
> True, the cast isn’t required. I kept the typed variable for clarity and type checking on devm_add.. API which pass void * callback and remove trigger API which has struct hid_sensor_common.
>
> Happy to simplify if preferred.
Please, do.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and cleanup
From: srinivas pandruvada @ 2026-05-01 11:53 UTC (permalink / raw)
To: Sanjay Chitroda, jikos, jic23
Cc: dlechner, nuno.sa, andy, sakari.ailus, linux-input, linux-iio,
linux-kernel, Zhang Lixu
In-Reply-To: <20260429175918.2541914-1-sanjayembedded@gmail.com>
+ Lixu
On Wed, 2026-04-29 at 23:29 +0530, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> Key highlights:
> - Prepare change as pre-requisite for devm conversion for HID IIO
> drivers by removing redundant argument
> - Add devm API to setup trigger and clenaup resource using
> devm_add_action_or_reset()
> - few sample driver update using devm conversion to auto release
> resource
>
devm_* calls are fine but needs tests particularly when forces ISH PCI
drivers unbind, while iio-sensor-proxy has open sessions.
Lixu, Please check.
Thanks,
Srinivas
> changes in v2:
> - Following input from Jonathan and Andy, squash initial patch v1
> series in single change as individual change should not break
> anything
> - Add devm API support and two driver using the same
> - v1 series ->
> https://lore.kernel.org/all/20260428071613.1134053-1-sanjayembedded@gmail.com/
>
> Testing:
> - Compiled with W=1
> - Build-tested on QEMU x86_64
>
> Based on further feedback and reviews, I would extend this series to
> convert all HID IIO driver to use devm_* API.
>
> Thanks,
> Sanjay Chitroda
>
> Sanjay Chitroda (4):
> iio: hid-sensors: drop redundant iio_dev argument
> iio: hid-sensors: introduce device managed API
> iio: gyro: drop hid_sensor_remove_trigger() using devm API
> iio: humidity: drop hid_sensor_remove_trigger() using devm API
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 4 +--
> .../common/hid-sensors/hid-sensor-trigger.c | 27
> +++++++++++++++++--
> .../common/hid-sensors/hid-sensor-trigger.h | 5 ++--
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 10 +++----
> drivers/iio/humidity/hid-sensor-humidity.c | 10 +++----
> drivers/iio/light/hid-sensor-als.c | 4 +--
> drivers/iio/light/hid-sensor-prox.c | 4 +--
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 4 +--
> drivers/iio/orientation/hid-sensor-incl-3d.c | 4 +--
> drivers/iio/orientation/hid-sensor-rotation.c | 4 +--
> .../position/hid-sensor-custom-intel-hinge.c | 4 +--
> drivers/iio/pressure/hid-sensor-press.c | 4 +--
> .../iio/temperature/hid-sensor-temperature.c | 4 +--
> 13 files changed, 52 insertions(+), 36 deletions(-)
>
>
> base-commit: eade2b843d9b1f668fc1775f15611bb0a1999cd9
^ permalink raw reply
* Re: [PATCH resend] xpad: Add "Nova 2 Lite" from GameSir
From: Dmitry Torokhov @ 2026-05-01 4:58 UTC (permalink / raw)
To: Qbeliw Tanaka; +Cc: linux-input
In-Reply-To: <20260429.162040.930225048583399359.q.tanaka@gmx.com>
On Wed, Apr 29, 2026 at 04:20:40PM +0900, Qbeliw Tanaka wrote:
> Add support for the gamepad "Nova 2 Lite" from GameSir, compatible with the Xbox 360 gamepad.
>
> Signed-off-by: Qbeliw Tanaka <q.tanaka@gmx.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: xpad - add support for ASUS ROG RAIKIRI II
From: Dmitry Torokhov @ 2026-05-01 4:40 UTC (permalink / raw)
To: Dmitriy Zharov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260430183522.122151-1-contact@zharov.dev>
On Thu, Apr 30, 2026 at 10:35:22PM +0400, Dmitriy Zharov wrote:
> Add the VID/PIDs for the ASUS ROG RAIKIRI II controller to xpad_device
> and the VID to xpad_table. The controller has a physical PC/XBOX toggle
> which switches between XBOX360 and XBOXONE protocols.
>
> Signed-off-by: Dmitriy Zharov <contact@zharov.dev>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: pcap_keys: remove unused driver
From: Dmitry Torokhov @ 2026-05-01 4:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Arnd Bergmann, Lee Jones, linux-kernel, linux-input
In-Reply-To: <20260430164326.2766500-1-arnd@kernel.org>
On Thu, Apr 30, 2026 at 06:42:47PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Support for the ezx series of phones was removed in 2022, this
> driver is just dead code.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] input: pcap_ts - remove unused driver
From: Dmitry Torokhov @ 2026-05-01 4:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Arnd Bergmann, linux-kernel, linux-input
In-Reply-To: <20260430164326.2766500-2-arnd@kernel.org>
On Thu, Apr 30, 2026 at 06:42:48PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Support for the ezx series of phones was removed in 2022, this
> driver is just dead code.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you!
From sashiko:
"Does removing this config leave a dangling CONFIG_TOUCHSCREEN_PCAP=m
entry in arch/arm/configs/pxa_defconfig? Would it be better to clean up
that entry as well to avoid a defconfig warning?"
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/2] Input: analog: fix coding style violations
From: Akash Sukhavasi @ 2026-05-01 2:25 UTC (permalink / raw)
To: akash.sukhavasi; +Cc: dmitry.torokhov, linux-input, linux-kernel
In-Reply-To: <20260413221928.21748-1-akash.sukhavasi@gmail.com>
Hi Dmitry,
Gentle ping on this patch series now that the merge window
has closed. Let me know if you need me to rebase it.
Thanks,
Akash Sukhavasi
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: hid-sensors: introduce device managed API
From: Sanjay Chitroda @ 2026-04-30 19:30 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <afJcj34Fc_aUMVhe@ashevche-desk.local>
On 30 April 2026 1:01:27 am IST, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>On Wed, Apr 29, 2026 at 11:29:16PM +0530, Sanjay Chitroda wrote:
>
>> hid_sensor_setup_trigger() is common API used for the HID IIO drivers,
>> prepare devm API devm_hid_sensor_setup_trigger() to acquire resource
>> during setup and release using device managed framework during drivers
>> fail, unbind or remove path.
>>
>> Register action with devm_add_action_or_reset() to release resource with
>> devres framework.
>
>...
>
>> +static void hid_sensor_remove_trigger_action(void *ptr)
>> +{
>> + struct hid_sensor_common *attrb = ptr;
>> +
>> + hid_sensor_remove_trigger(attrb);
>> +}
>
>Casting is not needed here.
>
>static void hid_sensor_remove_trigger_action(void *attrb)
>{
> hid_sensor_remove_trigger(attrb);
>}
>
True, the cast isn’t required. I kept the typed variable for clarity and type checking on devm_add.. API which pass void * callback and remove trigger API which has struct hid_sensor_common.
Happy to simplify if preferred.
>...
>
>> +int devm_hid_sensor_setup_trigger(struct device *dev, struct iio_dev *indio_dev,
>> + const char *name, struct hid_sensor_common *attrb)
>> +{
>> + int ret;
>> +
>> + ret = hid_sensor_setup_trigger(indio_dev, name, attrb);
>> + if (ret)
>> + return ret;
>
>> + ret = devm_add_action_or_reset(dev, hid_sensor_remove_trigger_action, attrb);
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>
> return devm_add_action_or_reset(dev, hid_sensor_remove_trigger_action, attrb);
>
Agree, will update in next series.
Thanks,
Sanjay Chitroda
>> +}
>
^ permalink raw reply
* Re: [PATCH v2 4/4] iio: humidity: drop hid_sensor_remove_trigger() using devm API
From: Sanjay Chitroda @ 2026-04-30 19:21 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <afJdJIQS1vwOcaGT@ashevche-desk.local>
On 30 April 2026 1:03:56 am IST, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>On Wed, Apr 29, 2026 at 11:29:18PM +0530, Sanjay Chitroda wrote:
>
>> Use devm_hid_sensor_setup_trigger() to automatically release resource
>> during fail, unbind or removal of driver using devres framework.
>>
>> This simplify the setup, remove goto, avoid manual resource cleanup in
>> teardown path.
>
>...
>
>> - ret = hid_sensor_setup_trigger(indio_dev, name,
>> - &humid_st->common_attributes);
>> + ret = devm_hid_sensor_setup_trigger(&indio_dev->dev, indio_dev, name,
>> + &humid_st->common_attributes);
>
>I believe the first parameter is utterly wrong here.
>Or other way around, same issue but in the previous patch.
>
Thank you Andy for the review comment.
It looks in same humidity probe of hid sensor with devm API two device pointer are used &pdev->dev and &indio_dev->dev; ideally all devm should have same parent device for devres resource framework and over here preferable and consistent device should be &pdev->dev;
I would first update existing devm_* API to have consistent device and on top of that will use same device in devm conversation.
While for gyro change device is consistent as &pdev->dev across all devm API.
Thanks,
Sanjay Chitroda
>> if (ret)
>> return ret;
>
^ permalink raw reply
* [PATCH] Input: xpad - add support for ASUS ROG RAIKIRI II
From: Dmitriy Zharov @ 2026-04-30 18:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Dmitriy Zharov
Add the VID/PIDs for the ASUS ROG RAIKIRI II controller to xpad_device
and the VID to xpad_table. The controller has a physical PC/XBOX toggle
which switches between XBOX360 and XBOXONE protocols.
Signed-off-by: Dmitriy Zharov <contact@zharov.dev>
---
drivers/input/joystick/xpad.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 0549fdc5a985..f64c07d0ea38 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -186,6 +186,10 @@ static const struct xpad_device {
{ 0x07ff, 0xffff, "Mad Catz GamePad", 0, XTYPE_XBOX360 },
{ 0x0b05, 0x1a38, "ASUS ROG RAIKIRI", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
{ 0x0b05, 0x1abb, "ASUS ROG RAIKIRI PRO", 0, XTYPE_XBOXONE },
+ { 0x0b05, 0x1c91, "ASUS ROG RAIKIRI II", 0, XTYPE_XBOX360 },
+ { 0x0b05, 0x1c92, "ASUS ROG RAIKIRI II WIRELESS", 0, XTYPE_XBOX360 },
+ { 0x0b05, 0x1c96, "ASUS ROG RAIKIRI II XBOX", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
+ { 0x0b05, 0x1d04, "ASUS ROG RAIKIRI II XBOX WIRELESS", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
{ 0x0c12, 0x0005, "Intec wireless", 0, XTYPE_XBOX },
{ 0x0c12, 0x8801, "Nyko Xbox Controller", 0, XTYPE_XBOX },
{ 0x0c12, 0x8802, "Zeroplus Xbox Controller", 0, XTYPE_XBOX },
@@ -507,6 +511,7 @@ static const struct usb_device_id xpad_table[] = {
{ USB_DEVICE(0x0738, 0x4540) }, /* Mad Catz Beat Pad */
XPAD_XBOXONE_VENDOR(0x0738), /* Mad Catz FightStick TE 2 */
XPAD_XBOX360_VENDOR(0x07ff), /* Mad Catz Gamepad */
+ XPAD_XBOX360_VENDOR(0x0b05), /* ASUS controllers */
XPAD_XBOXONE_VENDOR(0x0b05), /* ASUS controllers */
XPAD_XBOX360_VENDOR(0x0c12), /* Zeroplus X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x0db0), /* Micro Star International X-Box 360 controllers */
--
2.54.0
^ permalink raw reply related
* [PATCH v3] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Kris Bahnsen @ 2026-04-30 17:37 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 and use the scratch variable for the rx_buf for
both the 1 byte command to and 2 byte response from the controller.
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>
---
V1 -> V2: Don't use rx_buf when clearing command reg
V2 -> V3: Modify original 2 xfer command to eliminate dev_err()
output on xfer with len and NULL buffers
drivers/input/touchscreen/ads7846.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 4b39f7212d35c..488bcc8393293 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -403,8 +403,7 @@ 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].rx_buf = &req->scratch;
req->xfer[6].len = 1;
spi_message_add_tail(&req->xfer[6], &req->msg);
base-commit: dd6c438c3e64a5ff0b5d7e78f7f9be547803ef1b
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Kris Bahnsen @ 2026-04-30 16:54 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <afJZSCXeoSO502o1@google.com>
Dmitry,
On 4/29/26 12:19 PM, Dmitry Torokhov wrote:
> On Mon, Apr 27, 2026 at 05:46:57PM +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. Also set rx_buf to NULL because the value
>> returned does not matter. Thus moving the 3 byte pattern to clear
>> the command register to a single message.
>
> Unfortunately my suggestion was flawed: I think this will flood the logs
> with "Bufferless transfer has length %3". We need to have either tx or
> rx buffer :(
Ah. I do see that dev_err() line in spi_transfer_one_message().
All of my testing up to this point has been with an SPI host driver
that implements its own transfer_one() operation so that error
was never actually reached.
I'll send a v3 today that reverts back to the two separate xfers,
using scratch for the rx_buf, and then NULL for tx_buf. That
sounds like that should be the path of least resistance.
>
> Thanks.
>
--
Kris Bahnsen
Software Engineer
embeddedTS
^ permalink raw reply
* [PATCH 2/2] input: pcap_ts - remove unused driver
From: Arnd Bergmann @ 2026-04-30 16:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Arnd Bergmann, linux-kernel, linux-input
In-Reply-To: <20260430164326.2766500-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Support for the ezx series of phones was removed in 2022, this
driver is just dead code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/touchscreen/Kconfig | 10 --
drivers/input/touchscreen/Makefile | 1 -
drivers/input/touchscreen/pcap_ts.c | 252 ----------------------------
3 files changed, 263 deletions(-)
delete mode 100644 drivers/input/touchscreen/pcap_ts.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index aeaf9a9cbb41..484522d8d675 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1178,16 +1178,6 @@ config TOUCHSCREEN_TSC2007_IIO
or ambient light monitoring), temperature and raw input
values.
-config TOUCHSCREEN_PCAP
- tristate "Motorola PCAP touchscreen"
- depends on EZX_PCAP
- help
- Say Y here if you have a Motorola EZX telephone and
- want to enable support for the built-in touchscreen.
-
- To compile this driver as a module, choose M here: the
- module will be called pcap_ts.
-
config TOUCHSCREEN_RM_TS
tristate "Raydium I2C Touchscreen"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index f2b002abebe8..6d397268d2e3 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -74,7 +74,6 @@ obj-$(CONFIG_TOUCHSCREEN_HP7XX) += jornada720_ts.o
obj-$(CONFIG_TOUCHSCREEN_IPAQ_MICRO) += ipaq-micro-ts.o
obj-$(CONFIG_TOUCHSCREEN_HTCPEN) += htcpen.o
obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE) += usbtouchscreen.o
-obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
obj-$(CONFIG_TOUCHSCREEN_RM_TS) += raydium_i2c_ts.o
diff --git a/drivers/input/touchscreen/pcap_ts.c b/drivers/input/touchscreen/pcap_ts.c
deleted file mode 100644
index 7b89eb74b9de..000000000000
--- a/drivers/input/touchscreen/pcap_ts.c
+++ /dev/null
@@ -1,252 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Driver for Motorola PCAP2 touchscreen as found in the EZX phone platform.
- *
- * Copyright (C) 2006 Harald Welte <laforge@openezx.org>
- * Copyright (C) 2009 Daniel Ribeiro <drwyrm@gmail.com>
- */
-
-#include <linux/module.h>
-#include <linux/fs.h>
-#include <linux/string.h>
-#include <linux/slab.h>
-#include <linux/pm.h>
-#include <linux/timer.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/input.h>
-#include <linux/mfd/ezx-pcap.h>
-
-struct pcap_ts {
- struct pcap_chip *pcap;
- struct input_dev *input;
- struct delayed_work work;
- u16 x, y;
- u16 pressure;
- u8 read_state;
-};
-
-#define SAMPLE_DELAY 20 /* msecs */
-
-#define X_AXIS_MIN 0
-#define X_AXIS_MAX 1023
-#define Y_AXIS_MAX X_AXIS_MAX
-#define Y_AXIS_MIN X_AXIS_MIN
-#define PRESSURE_MAX X_AXIS_MAX
-#define PRESSURE_MIN X_AXIS_MIN
-
-static void pcap_ts_read_xy(void *data, u16 res[2])
-{
- struct pcap_ts *pcap_ts = data;
-
- switch (pcap_ts->read_state) {
- case PCAP_ADC_TS_M_PRESSURE:
- /* pressure reading is unreliable */
- if (res[0] > PRESSURE_MIN && res[0] < PRESSURE_MAX)
- pcap_ts->pressure = res[0];
- pcap_ts->read_state = PCAP_ADC_TS_M_XY;
- schedule_delayed_work(&pcap_ts->work, 0);
- break;
- case PCAP_ADC_TS_M_XY:
- pcap_ts->y = res[0];
- pcap_ts->x = res[1];
- if (pcap_ts->x <= X_AXIS_MIN || pcap_ts->x >= X_AXIS_MAX ||
- pcap_ts->y <= Y_AXIS_MIN || pcap_ts->y >= Y_AXIS_MAX) {
- /* pen has been released */
- input_report_abs(pcap_ts->input, ABS_PRESSURE, 0);
- input_report_key(pcap_ts->input, BTN_TOUCH, 0);
-
- pcap_ts->read_state = PCAP_ADC_TS_M_STANDBY;
- schedule_delayed_work(&pcap_ts->work, 0);
- } else {
- /* pen is touching the screen */
- input_report_abs(pcap_ts->input, ABS_X, pcap_ts->x);
- input_report_abs(pcap_ts->input, ABS_Y, pcap_ts->y);
- input_report_key(pcap_ts->input, BTN_TOUCH, 1);
- input_report_abs(pcap_ts->input, ABS_PRESSURE,
- pcap_ts->pressure);
-
- /* switch back to pressure read mode */
- pcap_ts->read_state = PCAP_ADC_TS_M_PRESSURE;
- schedule_delayed_work(&pcap_ts->work,
- msecs_to_jiffies(SAMPLE_DELAY));
- }
- input_sync(pcap_ts->input);
- break;
- default:
- dev_warn(&pcap_ts->input->dev,
- "pcap_ts: Warning, unhandled read_state %d\n",
- pcap_ts->read_state);
- break;
- }
-}
-
-static void pcap_ts_work(struct work_struct *work)
-{
- struct delayed_work *dw = to_delayed_work(work);
- struct pcap_ts *pcap_ts = container_of(dw, struct pcap_ts, work);
- u8 ch[2];
-
- pcap_set_ts_bits(pcap_ts->pcap,
- pcap_ts->read_state << PCAP_ADC_TS_M_SHIFT);
-
- if (pcap_ts->read_state == PCAP_ADC_TS_M_STANDBY)
- return;
-
- /* start adc conversion */
- ch[0] = PCAP_ADC_CH_TS_X1;
- ch[1] = PCAP_ADC_CH_TS_Y1;
- pcap_adc_async(pcap_ts->pcap, PCAP_ADC_BANK_1, 0, ch,
- pcap_ts_read_xy, pcap_ts);
-}
-
-static irqreturn_t pcap_ts_event_touch(int pirq, void *data)
-{
- struct pcap_ts *pcap_ts = data;
-
- if (pcap_ts->read_state == PCAP_ADC_TS_M_STANDBY) {
- pcap_ts->read_state = PCAP_ADC_TS_M_PRESSURE;
- schedule_delayed_work(&pcap_ts->work, 0);
- }
- return IRQ_HANDLED;
-}
-
-static int pcap_ts_open(struct input_dev *dev)
-{
- struct pcap_ts *pcap_ts = input_get_drvdata(dev);
-
- pcap_ts->read_state = PCAP_ADC_TS_M_STANDBY;
- schedule_delayed_work(&pcap_ts->work, 0);
-
- return 0;
-}
-
-static void pcap_ts_close(struct input_dev *dev)
-{
- struct pcap_ts *pcap_ts = input_get_drvdata(dev);
-
- cancel_delayed_work_sync(&pcap_ts->work);
-
- pcap_ts->read_state = PCAP_ADC_TS_M_NONTS;
- pcap_set_ts_bits(pcap_ts->pcap,
- pcap_ts->read_state << PCAP_ADC_TS_M_SHIFT);
-}
-
-static int pcap_ts_probe(struct platform_device *pdev)
-{
- struct input_dev *input_dev;
- struct pcap_ts *pcap_ts;
- int err = -ENOMEM;
-
- pcap_ts = kzalloc_obj(*pcap_ts);
- if (!pcap_ts)
- return err;
-
- pcap_ts->pcap = dev_get_drvdata(pdev->dev.parent);
- platform_set_drvdata(pdev, pcap_ts);
-
- input_dev = input_allocate_device();
- if (!input_dev)
- goto fail;
-
- INIT_DELAYED_WORK(&pcap_ts->work, pcap_ts_work);
-
- pcap_ts->read_state = PCAP_ADC_TS_M_NONTS;
- pcap_set_ts_bits(pcap_ts->pcap,
- pcap_ts->read_state << PCAP_ADC_TS_M_SHIFT);
-
- pcap_ts->input = input_dev;
- input_set_drvdata(input_dev, pcap_ts);
-
- input_dev->name = "pcap-touchscreen";
- input_dev->phys = "pcap_ts/input0";
- input_dev->id.bustype = BUS_HOST;
- input_dev->id.vendor = 0x0001;
- input_dev->id.product = 0x0002;
- input_dev->id.version = 0x0100;
- input_dev->dev.parent = &pdev->dev;
- input_dev->open = pcap_ts_open;
- input_dev->close = pcap_ts_close;
-
- input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
- input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
- input_set_abs_params(input_dev, ABS_X, X_AXIS_MIN, X_AXIS_MAX, 0, 0);
- input_set_abs_params(input_dev, ABS_Y, Y_AXIS_MIN, Y_AXIS_MAX, 0, 0);
- input_set_abs_params(input_dev, ABS_PRESSURE, PRESSURE_MIN,
- PRESSURE_MAX, 0, 0);
-
- err = input_register_device(pcap_ts->input);
- if (err)
- goto fail_allocate;
-
- err = request_irq(pcap_to_irq(pcap_ts->pcap, PCAP_IRQ_TS),
- pcap_ts_event_touch, 0, "Touch Screen", pcap_ts);
- if (err)
- goto fail_register;
-
- return 0;
-
-fail_register:
- input_unregister_device(input_dev);
- goto fail;
-fail_allocate:
- input_free_device(input_dev);
-fail:
- kfree(pcap_ts);
-
- return err;
-}
-
-static void pcap_ts_remove(struct platform_device *pdev)
-{
- struct pcap_ts *pcap_ts = platform_get_drvdata(pdev);
-
- free_irq(pcap_to_irq(pcap_ts->pcap, PCAP_IRQ_TS), pcap_ts);
- cancel_delayed_work_sync(&pcap_ts->work);
-
- input_unregister_device(pcap_ts->input);
-
- kfree(pcap_ts);
-}
-
-#ifdef CONFIG_PM
-static int pcap_ts_suspend(struct device *dev)
-{
- struct pcap_ts *pcap_ts = dev_get_drvdata(dev);
-
- pcap_set_ts_bits(pcap_ts->pcap, PCAP_ADC_TS_REF_LOWPWR);
- return 0;
-}
-
-static int pcap_ts_resume(struct device *dev)
-{
- struct pcap_ts *pcap_ts = dev_get_drvdata(dev);
-
- pcap_set_ts_bits(pcap_ts->pcap,
- pcap_ts->read_state << PCAP_ADC_TS_M_SHIFT);
- return 0;
-}
-
-static const struct dev_pm_ops pcap_ts_pm_ops = {
- .suspend = pcap_ts_suspend,
- .resume = pcap_ts_resume,
-};
-#define PCAP_TS_PM_OPS (&pcap_ts_pm_ops)
-#else
-#define PCAP_TS_PM_OPS NULL
-#endif
-
-static struct platform_driver pcap_ts_driver = {
- .probe = pcap_ts_probe,
- .remove = pcap_ts_remove,
- .driver = {
- .name = "pcap-ts",
- .pm = PCAP_TS_PM_OPS,
- },
-};
-module_platform_driver(pcap_ts_driver);
-
-MODULE_DESCRIPTION("Motorola PCAP2 touchscreen driver");
-MODULE_AUTHOR("Daniel Ribeiro / Harald Welte");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:pcap_ts");
--
2.39.5
^ permalink raw reply related
* [PATCH 1/2] Input: pcap_keys: remove unused driver
From: Arnd Bergmann @ 2026-04-30 16:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Arnd Bergmann, Lee Jones, linux-kernel, linux-input
From: Arnd Bergmann <arnd@arndb.de>
Support for the ezx series of phones was removed in 2022, this
driver is just dead code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/misc/Kconfig | 10 ---
drivers/input/misc/Makefile | 1 -
drivers/input/misc/pcap_keys.c | 125 ---------------------------------
3 files changed, 136 deletions(-)
delete mode 100644 drivers/input/misc/pcap_keys.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 94a753fcb64f..1f6c57dba030 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -745,16 +745,6 @@ config INPUT_WM831X_ON
To compile this driver as a module, choose M here: the module
will be called wm831x_on.
-config INPUT_PCAP
- tristate "Motorola EZX PCAP misc input events"
- depends on EZX_PCAP
- help
- Say Y here if you want to use Power key and Headphone button
- on Motorola EZX phones.
-
- To compile this driver as a module, choose M here: the
- module will be called pcap_keys.
-
config INPUT_ADXL34X
tristate "Analog Devices ADXL34x Three-Axis Digital Accelerometer"
default n
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415fc4e2918b..2281d6803fce 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -60,7 +60,6 @@ obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
obj-$(CONFIG_INPUT_MMA8450) += mma8450.o
obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
-obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
obj-$(CONFIG_INPUT_PCF8574) += pcf8574_keypad.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
obj-$(CONFIG_INPUT_PF1550_ONKEY) += pf1550-onkey.o
diff --git a/drivers/input/misc/pcap_keys.c b/drivers/input/misc/pcap_keys.c
deleted file mode 100644
index b19899b50d0b..000000000000
--- a/drivers/input/misc/pcap_keys.c
+++ /dev/null
@@ -1,125 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Input driver for PCAP events:
- * * Power key
- * * Headphone button
- *
- * Copyright (c) 2008,2009 Ilya Petrov <ilya.muromec@gmail.com>
- */
-
-#include <linux/module.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
-#include <linux/input.h>
-#include <linux/mfd/ezx-pcap.h>
-#include <linux/slab.h>
-
-struct pcap_keys {
- struct pcap_chip *pcap;
- struct input_dev *input;
-};
-
-/* PCAP2 interrupts us on keypress */
-static irqreturn_t pcap_keys_handler(int irq, void *_pcap_keys)
-{
- struct pcap_keys *pcap_keys = _pcap_keys;
- int pirq = irq_to_pcap(pcap_keys->pcap, irq);
- u32 pstat;
-
- ezx_pcap_read(pcap_keys->pcap, PCAP_REG_PSTAT, &pstat);
- pstat &= 1 << pirq;
-
- switch (pirq) {
- case PCAP_IRQ_ONOFF:
- input_report_key(pcap_keys->input, KEY_POWER, !pstat);
- break;
- case PCAP_IRQ_MIC:
- input_report_key(pcap_keys->input, KEY_HP, !pstat);
- break;
- }
-
- input_sync(pcap_keys->input);
-
- return IRQ_HANDLED;
-}
-
-static int pcap_keys_probe(struct platform_device *pdev)
-{
- int err = -ENOMEM;
- struct pcap_keys *pcap_keys;
- struct input_dev *input_dev;
-
- pcap_keys = kmalloc_obj(*pcap_keys);
- if (!pcap_keys)
- return err;
-
- pcap_keys->pcap = dev_get_drvdata(pdev->dev.parent);
-
- input_dev = input_allocate_device();
- if (!input_dev)
- goto fail;
-
- pcap_keys->input = input_dev;
-
- platform_set_drvdata(pdev, pcap_keys);
- input_dev->name = pdev->name;
- input_dev->phys = "pcap-keys/input0";
- input_dev->id.bustype = BUS_HOST;
- input_dev->dev.parent = &pdev->dev;
-
- __set_bit(EV_KEY, input_dev->evbit);
- __set_bit(KEY_POWER, input_dev->keybit);
- __set_bit(KEY_HP, input_dev->keybit);
-
- err = input_register_device(input_dev);
- if (err)
- goto fail_allocate;
-
- err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
- pcap_keys_handler, 0, "Power key", pcap_keys);
- if (err)
- goto fail_register;
-
- err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
- pcap_keys_handler, 0, "Headphone button", pcap_keys);
- if (err)
- goto fail_pwrkey;
-
- return 0;
-
-fail_pwrkey:
- free_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF), pcap_keys);
-fail_register:
- input_unregister_device(input_dev);
- goto fail;
-fail_allocate:
- input_free_device(input_dev);
-fail:
- kfree(pcap_keys);
- return err;
-}
-
-static void pcap_keys_remove(struct platform_device *pdev)
-{
- struct pcap_keys *pcap_keys = platform_get_drvdata(pdev);
-
- free_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF), pcap_keys);
- free_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC), pcap_keys);
-
- input_unregister_device(pcap_keys->input);
- kfree(pcap_keys);
-}
-
-static struct platform_driver pcap_keys_device_driver = {
- .probe = pcap_keys_probe,
- .remove = pcap_keys_remove,
- .driver = {
- .name = "pcap-keys",
- }
-};
-module_platform_driver(pcap_keys_device_driver);
-
-MODULE_DESCRIPTION("Motorola PCAP2 input events driver");
-MODULE_AUTHOR("Ilya Petrov <ilya.muromec@gmail.com>");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:pcap_keys");
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 1/1] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID
From: Lee Jones @ 2026-04-30 14:01 UTC (permalink / raw)
To: Günther Noack
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <aeDwkQ-S6QQuK_RL@google.com>
On Thu, 16 Apr 2026, Günther Noack wrote:
> On Thu, Apr 16, 2026 at 02:16:54PM +0100, Lee Jones wrote:
> > It is currently possible for a malicious or misconfigured USB device to
> > cause an out-of-bounds (OOB) read when submitting reports using
> > DOUBLE_REPORT_ID by specifying a large report length and providing a
> > smaller one.
> >
> > Let's prevent that by comparing the specified report length with the
> > actual size of the data read in from userspace. If the actual data
> > length ends up being smaller than specified, we'll politely warn the
> > user and prevent any further processing.
> >
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > v1 => v2: Add more size checks to protect against issues during recursion
> >
> > drivers/hid/hid-magicmouse.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> > index 91f621ceb924..e84e6b21d113 100644
> > --- a/drivers/hid/hid-magicmouse.c
> > +++ b/drivers/hid/hid-magicmouse.c
> > @@ -390,6 +390,10 @@ static int magicmouse_raw_event(struct hid_device *hdev,
> > struct input_dev *input = msc->input;
> > int x = 0, y = 0, ii, clicks = 0, npoints;
> >
> > + /* Protect against zero sized recursive calls from DOUBLE_REPORT_ID */
> > + if (size < 1)
> > + return 0;
> > +
> > switch (data[0]) {
> > case TRACKPAD_REPORT_ID:
> > case TRACKPAD2_BT_REPORT_ID:
> > @@ -490,6 +494,18 @@ static int magicmouse_raw_event(struct hid_device *hdev,
> > /* Sometimes the trackpad sends two touch reports in one
> > * packet.
> > */
> > +
> > + /* Ensure that we have at least 2 elements (report type and size) */
> > + if (size < 2)
> > + return 0;
> > +
> > + if (size < data[1] + 2) {
> > + hid_warn(hdev,
> > + "received report length (%d) was smaller than specified (%d)",
> > + size, data[1] + 2);
> > + return 0;
> > + }
> > +
> > magicmouse_raw_event(hdev, report, data + 2, data[1]);
> > magicmouse_raw_event(hdev, report, data + 2 + data[1],
> > size - 2 - data[1]);
> > --
> > 2.54.0.rc1.513.gad8abe7a5a-goog
> >
>
> Thank you! This looks correct now.
>
> Reviewed-by: Günther Noack <gnoack@google.com>
Contentless ping. =:-)
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v2 0/2] input: misc: add support for Imagis ISA1200 haptic motor driver
From: Svyatoslav Ryhel @ 2026-04-30 9:52 UTC (permalink / raw)
To: Linus Walleij
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAD++jLmNKWwHAxV8OLK5wupwj4dT1TWEn2Dmd6gP-Ez9Pgk0tw@mail.gmail.com>
чт, 30 квіт. 2026 р. о 12:16 Linus Walleij <linusw@kernel.org> пише:
>
> On Tue, Apr 28, 2026 at 1:43 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > 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.
>
> I applied a patch to the Janice devicetree like this:
>
> + /* Haptic feedback unit Immersion ISA1200 */
> + haptic-engine@49 {
> + compatible = "immersion,isa1200";
> + reg = <0x49>;
> +
> + /* clkout1 from ACLK divided by 8 */
> + clocks = <&clkout_clk DB8500_CLKOUT_1
> DB8500_CLKOUT_SRC_ACLK 8>;
> +
> + /*
> + * GPIO194 pin HEN (motor hardware enable)
> + * GPIO195 pin LEN (motor LDO enable)
> + */
> + control-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>,
> <&gpio6 3 GPIO_ACTIVE_HIGH>;
> +
> + imagis,clk-div = <256>;
> + imagis,pll-div = <2>;
> +
> + imagis,mode = <0>; /* LRA_MODE */
> +
> + imagis,period-ns = <1340000>;
Hello Linus!
May you please try with imagis,period-ns = <12900>; and <11900> which
one will fit better.
> + imagis,duty-cycle-ns = <100>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&isa1200_janice_default>;
> +
> + ldo {
> + regulator-name = "vdd_vib";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + };
> + };
>
> It works, I get rumble on the keys.
>
> Tested-by: Linus Walleij <linusw@kernel.org>
>
Very nice! Thank you for testing!
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-04-30 9:46 UTC (permalink / raw)
To: Linus Walleij
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAD++jLkU-G38xtzzfAV_otiYuM2G5NHdCdtjFjsy2AjpG22_rg@mail.gmail.com>
чт, 30 квіт. 2026 р. о 12:22 Linus Walleij <linusw@kernel.org> пише:
>
> Hi Svyatoslav,
>
> I just saw this thing:
>
> On Tue, Apr 28, 2026 at 1:43 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > +/* HCTRL5 controls the PWM high duty cycle of internal channel */
> > +#define ISA1200_HCTRL5 0x35
> (...)
> > +struct isa1200_config {
> (...)
> > + u32 duty;
> > +};
> > + /* Duty cycle */
> > + regmap_write(isa->map, ISA1200_HCTRL5, config->period >> 1);
> (...)
> > + if (isa->clk)
> > + regmap_write(isa->map, ISA1200_HCTRL5, config->duty);
> (..)
> > + if (isa->clk) {
> > + ret = device_property_read_u32(dev, "imagis,period-ns",
> > + &config->period);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to get period\n");
> > +
> > + config->period /= ISA1200_HCTRL6_PERIOD_SCALE;
> > + config->duty = config->period >> 1;
> > + }
> > +
> > + if (isa->pwm) {
> > + struct pwm_state state;
> > +
> > + pwm_init_state(isa->pwm, &state);
> > +
> > + if (!state.period)
> > + return dev_err_probe(dev, -EINVAL,
> > + "PWM period cannot be zero\n");
> > +
> > + config->freq = div64_u64(NANO, state.period * config->clkdiv);
> > + config->duty = state.period >> 1;
>
> So you don't need the same code writing
> regmap_write(isa->map, ISA1200_HCTRL5, config->period >> 1);
> above, just use confg->duty which contains config->period >> 1
> (...)
No this is intended. It seems that isa1200 uses period >> 1 (aka 1/2
of period for some type of pre-enable). Setting duty as 1/2 period be
default is a safe fallback but it will not trigger haptics.
> > + device_property_read_u32(dev, "imagis,duty-cycle-ns", &config->duty);
>
> I'm not sure about this, it works for me when I set this to 100
> resulting in a register write of 100 to ISA1200_HCTRL5. But are
> we sure that this register is expressed in nanoseconds? I think
> some calculation is needed here (and probably another value
> in my device tree).
>
I do are that this most likely is somehow mapped, but I have no clue
how to transfer this into actual nanoseconds. That is very
unfortunate.
In you original code
/*
* This is done in the vendor tree with the commment
* "Duty 0x64 == nForce 90", and no force feedback happens
* unless we do this.
*/
if (isa->clk)
regmap_write(isa->map, ISA1200_HCTRL5, 0x64);
0x64 is actually some conversion of duty cycle, you got this accurately.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Linus Walleij @ 2026-04-30 9:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260428114308.113253-3-clamor95@gmail.com>
Hi Svyatoslav,
I just saw this thing:
On Tue, Apr 28, 2026 at 1:43 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> +/* HCTRL5 controls the PWM high duty cycle of internal channel */
> +#define ISA1200_HCTRL5 0x35
(...)
> +struct isa1200_config {
(...)
> + u32 duty;
> +};
> + /* Duty cycle */
> + regmap_write(isa->map, ISA1200_HCTRL5, config->period >> 1);
(...)
> + if (isa->clk)
> + regmap_write(isa->map, ISA1200_HCTRL5, config->duty);
(..)
> + if (isa->clk) {
> + ret = device_property_read_u32(dev, "imagis,period-ns",
> + &config->period);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to get period\n");
> +
> + config->period /= ISA1200_HCTRL6_PERIOD_SCALE;
> + config->duty = config->period >> 1;
> + }
> +
> + if (isa->pwm) {
> + struct pwm_state state;
> +
> + pwm_init_state(isa->pwm, &state);
> +
> + if (!state.period)
> + return dev_err_probe(dev, -EINVAL,
> + "PWM period cannot be zero\n");
> +
> + config->freq = div64_u64(NANO, state.period * config->clkdiv);
> + config->duty = state.period >> 1;
So you don't need the same code writing
regmap_write(isa->map, ISA1200_HCTRL5, config->period >> 1);
above, just use confg->duty which contains config->period >> 1
(...)
> + device_property_read_u32(dev, "imagis,duty-cycle-ns", &config->duty);
I'm not sure about this, it works for me when I set this to 100
resulting in a register write of 100 to ISA1200_HCTRL5. But are
we sure that this register is expressed in nanoseconds? I think
some calculation is needed here (and probably another value
in my device tree).
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 0/2] input: misc: add support for Imagis ISA1200 haptic motor driver
From: Linus Walleij @ 2026-04-30 9:16 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260428114308.113253-1-clamor95@gmail.com>
On Tue, Apr 28, 2026 at 1:43 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> 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.
I applied a patch to the Janice devicetree like this:
+ /* Haptic feedback unit Immersion ISA1200 */
+ haptic-engine@49 {
+ compatible = "immersion,isa1200";
+ reg = <0x49>;
+
+ /* clkout1 from ACLK divided by 8 */
+ clocks = <&clkout_clk DB8500_CLKOUT_1
DB8500_CLKOUT_SRC_ACLK 8>;
+
+ /*
+ * GPIO194 pin HEN (motor hardware enable)
+ * GPIO195 pin LEN (motor LDO enable)
+ */
+ control-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>,
<&gpio6 3 GPIO_ACTIVE_HIGH>;
+
+ imagis,clk-div = <256>;
+ imagis,pll-div = <2>;
+
+ imagis,mode = <0>; /* LRA_MODE */
+
+ imagis,period-ns = <1340000>;
+ imagis,duty-cycle-ns = <100>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&isa1200_janice_default>;
+
+ ldo {
+ regulator-name = "vdd_vib";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+ };
It works, I get rumble on the keys.
Tested-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] platform/x86: asus-wmi: fix fn-lock on platforms where WMI DEVS is a no-op
From: Marcus Grenängen @ 2026-04-30 8:05 UTC (permalink / raw)
To: platform-driver-x86
Cc: linux-input, linux-kernel, luke, denis.benato, hansg,
ilpo.jarvinen, jikos, bentiss, corentin.chary,
Marcus Grenängen
Some ASUS laptops (e.g. ProArt P16, N-Key keyboard 0B05:19B6) advertise
the WMI fn-lock DEVID (0x00100023) as present but the DEVS call has no
effect. On these machines fn-lock must be toggled via a HID feature report
sent directly to the N-Key keyboard, which is handled by hid-asus.
Add a DMI quirk flag fnlock_use_hid for such platforms. When set,
asus_wmi_has_fnlock_key() checks for a registered hid-asus listener that
supports fnlock instead of querying DEVS, and asus_wmi_fnlock_update()
dispatches to asus_hid_set_fnlock().
Extend struct asus_hid_listener with a fnlock_set callback and wire it up
in hid-asus for QUIRK_ROG_NKEY_KEYBOARD + QUIRK_HID_FN_LOCK devices.
Initialize fn_lock_sync_work and register the listener in the probe path
for these keyboards (previously the early return for ROG N-Key devices
skipped asus_input_configured where this was done).
Also add a fnlock_status sysfs attribute (RW) under the asus-wmi platform
device so userspace (e.g. asusctl) can read and set fn-lock state without
needing to open /dev/hidraw directly.
Fix a NULL pointer dereference in do_kbd_led_set(): brightness_set was
called unconditionally on all listeners, but listeners that only implement
fnlock_set leave brightness_set NULL.
Signed-off-by: Marcus Grenängen <marcus@grenangen.se>
---
drivers/hid/hid-asus.c | 24 ++++-
drivers/platform/x86/asus-nb-wmi.c | 13 +++
drivers/platform/x86/asus-wmi.c | 101 ++++++++++++++++++++-
drivers/platform/x86/asus-wmi.h | 5 +
include/linux/platform_data/x86/asus-wmi.h | 7 +-
5 files changed, 143 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index d34d74df3dc0..71ced03c0f7e 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -143,6 +143,7 @@ struct asus_drvdata {
unsigned long battery_next_query;
struct work_struct fn_lock_sync_work;
bool fn_lock;
+ struct asus_hid_listener fn_lock_listener;
};
static int asus_report_battery(struct asus_drvdata *, u8 *, int);
@@ -584,6 +585,15 @@ static void asus_sync_fn_lock(struct work_struct *work)
asus_kbd_set_fn_lock(drvdata->hdev, drvdata->fn_lock);
}
+static void asus_hid_fnlock_set(struct asus_hid_listener *listener, bool enabled)
+{
+ struct asus_drvdata *drvdata =
+ container_of(listener, struct asus_drvdata, fn_lock_listener);
+
+ drvdata->fn_lock = enabled;
+ schedule_work(&drvdata->fn_lock_sync_work);
+}
+
static void asus_schedule_work(struct asus_kbd_leds *led)
{
unsigned long flags;
@@ -1319,8 +1329,16 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
* For ROG keyboards, skip rename for consistency and ->input check as
* some devices do not have inputs.
*/
- if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD)
+ if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
+ if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
+ drvdata->fn_lock = true;
+ INIT_WORK(&drvdata->fn_lock_sync_work, asus_sync_fn_lock);
+ asus_kbd_set_fn_lock(hdev, true);
+ drvdata->fn_lock_listener.fnlock_set = asus_hid_fnlock_set;
+ asus_hid_register_listener(&drvdata->fn_lock_listener);
+ }
return 0;
+ }
/*
* Check that input registration succeeded. Checking that
@@ -1362,8 +1380,10 @@ static void asus_remove(struct hid_device *hdev)
cancel_work_sync(&drvdata->kbd_backlight->work);
}
- if (drvdata->quirks & QUIRK_HID_FN_LOCK)
+ if (drvdata->quirks & QUIRK_HID_FN_LOCK) {
+ asus_hid_unregister_listener(&drvdata->fn_lock_listener);
cancel_work_sync(&drvdata->fn_lock_sync_work);
+ }
hid_hw_stop(hdev);
}
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index b4677c5bba5b..44e4cf68ff70 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -155,6 +155,10 @@ static struct quirk_entry quirk_asus_z13 = {
.tablet_switch_mode = asus_wmi_kbd_dock_devid,
};
+static struct quirk_entry quirk_asus_proart_p16 = {
+ .fnlock_use_hid = true,
+};
+
static int dmi_matched(const struct dmi_system_id *dmi)
{
pr_info("Identified laptop model '%s'\n", dmi->ident);
@@ -553,6 +557,15 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = &quirk_asus_z13,
},
+ {
+ .callback = dmi_matched,
+ .ident = "ASUS ProArt P16",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "ProArt P16"),
+ },
+ .driver_data = &quirk_asus_proart_p16,
+ },
{},
};
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 80144c412b90..70758a20551d 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1759,6 +1759,24 @@ int asus_hid_event(enum asus_hid_event event)
}
EXPORT_SYMBOL_GPL(asus_hid_event);
+/*
+ * Called by asus-wmi to propagate an fn-lock state change to all registered
+ * hid-asus listeners. Used on platforms where the WMI DEVS path for fn-lock
+ * (0x00100023) is a no-operation and the HID feature report path must be used
+ * instead (e.g. ASUS ProArt P16, USB keyboard product ID 0x19B6).
+ */
+void asus_hid_set_fnlock(bool enabled)
+{
+ struct asus_hid_listener *listener;
+
+ guard(spinlock_irqsave)(&asus_ref.lock);
+ list_for_each_entry(listener, &asus_ref.listeners, list) {
+ if (listener->fnlock_set)
+ listener->fnlock_set(listener, enabled);
+ }
+}
+EXPORT_SYMBOL_GPL(asus_hid_set_fnlock);
+
/*
* These functions actually update the LED's, and are called from a
* workqueue. By doing this as separate work rather than when the LED
@@ -1852,7 +1870,8 @@ static void do_kbd_led_set(struct led_classdev *led_cdev, int value)
scoped_guard(spinlock_irqsave, &asus_ref.lock) {
list_for_each_entry(listener, &asus_ref.listeners, list)
- listener->brightness_set(listener, asus->kbd_led_wk);
+ if (listener->brightness_set)
+ listener->brightness_set(listener, asus->kbd_led_wk);
}
}
@@ -4495,21 +4514,64 @@ static void asus_screenpad_exit(struct asus_wmi *asus)
/* Fn-lock ********************************************************************/
+static bool asus_hid_has_fnlock_listener(void)
+{
+ struct asus_hid_listener *listener;
+
+ guard(spinlock_irqsave)(&asus_ref.lock);
+ list_for_each_entry(listener, &asus_ref.listeners, list) {
+ if (listener->fnlock_set)
+ return true;
+ }
+ return false;
+}
+
static bool asus_wmi_has_fnlock_key(struct asus_wmi *asus)
{
u32 result;
+ /* Some platforms have a non-functional WMI path — use HID directly */
+ if (asus->driver->quirks->fnlock_use_hid)
+ return asus_hid_has_fnlock_listener();
+
asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FNLOCK, &result);
- return (result & ASUS_WMI_DSTS_PRESENCE_BIT) &&
- !(result & ASUS_WMI_FNLOCK_BIOS_DISABLED);
+ if ((result & ASUS_WMI_DSTS_PRESENCE_BIT) &&
+ !(result & ASUS_WMI_FNLOCK_BIOS_DISABLED))
+ return true;
+
+ /*
+ * Some platforms (e.g. ASUS ProArt P16) have a non-functional WMI
+ * DEVS path for fn-lock (DEVS returns One unconditionally with no
+ * side effects). On these platforms fn-lock is controlled via a HID
+ * feature report sent directly to the N-Key keyboard. Return true if
+ * a hid-asus listener with fnlock support has registered, so that
+ * asus-wmi can manage the fn-lock state and expose the sysfs knob.
+ */
+ return asus_hid_has_fnlock_listener();
}
static void asus_wmi_fnlock_update(struct asus_wmi *asus)
{
int mode = asus->fnlock_locked;
+ u32 result;
- asus_wmi_set_devstate(ASUS_WMI_DEVID_FNLOCK, mode, NULL);
+ /* Platform has non-functional WMI DEVS for fn-lock — use HID directly */
+ if (asus->driver->quirks->fnlock_use_hid) {
+ asus_hid_set_fnlock(mode);
+ return;
+ }
+
+ asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FNLOCK, &result);
+
+ if ((result & ASUS_WMI_DSTS_PRESENCE_BIT) &&
+ !(result & ASUS_WMI_FNLOCK_BIOS_DISABLED)) {
+ asus_wmi_set_devstate(ASUS_WMI_DEVID_FNLOCK, mode, NULL);
+ return;
+ }
+
+ /* WMI path absent or non-functional — delegate to hid-asus */
+ asus_hid_set_fnlock(mode);
}
/* WMI events *****************************************************************/
@@ -4690,6 +4752,34 @@ static ssize_t cpufv_store(struct device *dev, struct device_attribute *attr,
static DEVICE_ATTR_WO(cpufv);
+static ssize_t fnlock_status_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct asus_wmi *asus = dev_get_drvdata(dev);
+
+ return sysfs_emit(buf, "%d\n", asus->fnlock_locked);
+}
+
+static ssize_t fnlock_status_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct asus_wmi *asus = dev_get_drvdata(dev);
+ bool enable;
+ int err;
+
+ err = kstrtobool(buf, &enable);
+ if (err)
+ return err;
+
+ asus->fnlock_locked = enable;
+ asus_wmi_fnlock_update(asus);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(fnlock_status);
+
static struct attribute *platform_attributes[] = {
&dev_attr_cpufv.attr,
&dev_attr_camera.attr,
@@ -4698,6 +4788,7 @@ static struct attribute *platform_attributes[] = {
&dev_attr_lid_resume.attr,
&dev_attr_als_enable.attr,
&dev_attr_fan_boost_mode.attr,
+ &dev_attr_fnlock_status.attr,
#if IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS)
&dev_attr_charge_mode.attr,
&dev_attr_egpu_enable.attr,
@@ -4741,6 +4832,8 @@ static umode_t asus_sysfs_is_visible(struct kobject *kobj,
devid = ASUS_WMI_DEVID_ALS_ENABLE;
else if (attr == &dev_attr_fan_boost_mode.attr)
ok = asus->fan_boost_mode_available;
+ else if (attr == &dev_attr_fnlock_status.attr)
+ ok = asus_wmi_has_fnlock_key(asus);
#if IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS)
if (attr == &dev_attr_charge_mode.attr)
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 5cd4392b964e..6c50b11860e8 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -52,6 +52,11 @@ struct quirk_entry {
*/
int no_display_toggle;
u32 xusb2pr;
+ /*
+ * Some platforms report WMI DEVID_FNLOCK as present but the DEVS call
+ * is a no-op. Force the HID feature report path via hid-asus instead.
+ */
+ bool fnlock_use_hid;
};
struct asus_wmi_driver {
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 554f41b827e1..569289417a51 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -173,10 +173,11 @@ enum asus_ally_mcu_hack {
ASUS_WMI_ALLY_MCU_HACK_DISABLED,
};
-/* Used to notify hid-asus when asus-wmi changes keyboard backlight */
+/* Used to notify hid-asus when asus-wmi changes keyboard backlight or fn-lock */
struct asus_hid_listener {
struct list_head list;
void (*brightness_set)(struct asus_hid_listener *listener, int brightness);
+ void (*fnlock_set)(struct asus_hid_listener *listener, bool enabled);
};
enum asus_hid_event {
@@ -196,6 +197,7 @@ int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1, u32 *retval);
int asus_hid_register_listener(struct asus_hid_listener *cdev);
void asus_hid_unregister_listener(struct asus_hid_listener *cdev);
int asus_hid_event(enum asus_hid_event event);
+void asus_hid_set_fnlock(bool enabled);
#else
static inline void set_ally_mcu_hack(enum asus_ally_mcu_hack status)
{
@@ -227,6 +229,9 @@ static inline int asus_hid_event(enum asus_hid_event event)
{
return -ENODEV;
}
+static inline void asus_hid_set_fnlock(bool enabled)
+{
+}
#endif
#endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
--
2.54.0
^ permalink raw reply related
* [PATCH] Input: wacom_w8001 - avoid double release of pen input device
From: Guangshuo Li @ 2026-04-30 7:13 UTC (permalink / raw)
To: Dmitry Torokhov, Guangshuo Li, Kees Cook, Peter Hutterer,
Benjamin Tissoires, linux-input, linux-kernel
When registering the touch input device fails after the pen input device
has already been registered, w8001_connect() jumps to fail4 and
unregisters w8001->pen_dev. It then falls through to fail1 where
input_dev_pen is passed to input_free_device().
Once input_register_device() has succeeded, the device must be released
with input_unregister_device(), and input_free_device() must not be used
on the same object afterwards. Since input_dev_pen still aliases
w8001->pen_dev, this can result in a use-after-free or kref underflow.
Clear the local and container aliases after unregistering the pen device
so that the common cleanup path does not try to free it again.
This issue was found by a static analysis tool I am developing.
Fixes: e0361b70175f0 ("Input: wacom_w8001 - split the touch and pen devices into two devices")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/input/touchscreen/wacom_w8001.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/wacom_w8001.c b/drivers/input/touchscreen/wacom_w8001.c
index 45930d731873..a3b283c59cdd 100644
--- a/drivers/input/touchscreen/wacom_w8001.c
+++ b/drivers/input/touchscreen/wacom_w8001.c
@@ -665,8 +665,11 @@ static int w8001_connect(struct serio *serio, struct serio_driver *drv)
return 0;
fail4:
- if (w8001->pen_dev)
+ if (w8001->pen_dev) {
input_unregister_device(w8001->pen_dev);
+ input_dev_pen = NULL;
+ w8001->pen_dev = NULL;
+ }
fail3:
serio_close(serio);
fail2:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/7] iio: accel: HID: Replace method accel_3d_adjust_channel_bit_mask()
From: Andy Shevchenko @ 2026-04-29 19:54 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Natália Salvino André, andy, bentiss, dlechner, jikos,
nuno.sa, srinivas.pandruvada, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260428191246.152c2972@jic23-huawei>
On Tue, Apr 28, 2026 at 07:12:46PM +0100, Jonathan Cameron wrote:
> On Mon, 27 Apr 2026 12:38:44 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Fri, Apr 24, 2026 at 08:08:47PM +0100, Jonathan Cameron wrote:
> > > 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:
...
> > > > > - 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.
> >
> > > Why the double tab? Maybe just go long on this one and align after the (
> >
> > I never know when you are strict about 80 limit :-)
> >
> I was meaning vs single tab really.
Ah, my point if the line is too long and maintainer is too strict about
the limit the indentation I would like to use is to occupy as much room as
possible. I.o.w. to indent right as much as possible to fit the limit.
> You are slowly wearing me down on the 80 limit by pointing out lots of
> cases where going beyond it really helps! ;)
Ha-ha :-)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/4] iio: introduce devm_ API for hid sensro setup and cleanup
From: Andy Shevchenko @ 2026-04-29 19:35 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260429175918.2541914-1-sanjayembedded@gmail.com>
On Wed, Apr 29, 2026 at 11:29:14PM +0530, Sanjay Chitroda wrote:
> Key highlights:
> - Prepare change as pre-requisite for devm conversion for HID IIO
> drivers by removing redundant argument
> - Add devm API to setup trigger and clenaup resource using
> devm_add_action_or_reset()
> - few sample driver update using devm conversion to auto release resource
> Based on further feedback and reviews, I would extend this series to convert
> all HID IIO driver to use devm_* API.
Not sure about this. But if people (and HID sensors maintainers in particular)
are fine with this, I have no objections. There are some nit-picks and one
serious problem to address, though.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 4/4] iio: humidity: drop hid_sensor_remove_trigger() using devm API
From: Andy Shevchenko @ 2026-04-29 19:33 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos, jic23, srinivas.pandruvada, dlechner, nuno.sa, andy,
sakari.ailus, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260429175918.2541914-5-sanjayembedded@gmail.com>
On Wed, Apr 29, 2026 at 11:29:18PM +0530, Sanjay Chitroda wrote:
> Use devm_hid_sensor_setup_trigger() to automatically release resource
> during fail, unbind or removal of driver using devres framework.
>
> This simplify the setup, remove goto, avoid manual resource cleanup in
> teardown path.
...
> - ret = hid_sensor_setup_trigger(indio_dev, name,
> - &humid_st->common_attributes);
> + ret = devm_hid_sensor_setup_trigger(&indio_dev->dev, indio_dev, name,
> + &humid_st->common_attributes);
I believe the first parameter is utterly wrong here.
Or other way around, same issue but in the previous patch.
> if (ret)
> return ret;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox