* Re: [PATCH] dt-bindings: Remove the redundant 'type: boolean'
From: Krzysztof Kozlowski @ 2026-04-23 9:20 UTC (permalink / raw)
To: phucduc.bui, robh, krzk+dt, conor+dt
Cc: nick, dmitry.torokhov, nicolas.ferre, alexandre.belloni,
claudiu.beznea, lee, heiko, gregkh, linusw, zyw, zhangqing,
gene_chen, linux-input, devicetree, linux-arm-kernel, linux-usb
In-Reply-To: <20260417021858.6582-1-phucduc.bui@gmail.com>
On 17/04/2026 04:18, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> The 'wakeup-source' property already has its type defined in the core
> schema. Remove the redundant 'type: boolean' from the binding file to
> clean up the binding files.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 3 +--
> Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml | 3 +--
Why did you change one file and ignore the rest?
Why did you not mention previous feedback I gave you on your patches
(some time ago), that there are TWO TYPES defined for wakeup-source.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] HID: usbhid: sanitize hid->uniq against non-printable bytes
From: Greg KH @ 2026-04-23 9:29 UTC (permalink / raw)
To: Eric Naim
Cc: Taylor Hewetson, Jiri Kosina, Benjamin Tissoires, linux-usb,
linux-input, linux-kernel
In-Reply-To: <81ef5ca0-b070-4afc-bda7-3e5a49677115@cachyos.org>
On Thu, Apr 23, 2026 at 05:55:00AM +0000, Eric Naim wrote:
> On 4/18/26 3:14 PM, Greg KH wrote:
> > On Sat, Apr 18, 2026 at 02:58:23PM +1200, Taylor Hewetson wrote:
> >> Some USB HID devices (observed on ASUS ROG Azoth via its 2.4GHz
> >> dongle, USB ID 0b05:1a85) report an iSerialNumber string whose
> >> USB string descriptor declares a longer length than the actual
> >> serial, leaving uninitialized firmware memory - including control
> >> characters such as 0x18 - appended to the returned string.
> >>
> >> These non-printable bytes propagate into hid->uniq, which in turn
> >> populates /sys/class/input/inputN/uniq. Downstream userspace
> >> components (systemd sd-device property_is_valid(), and by extension
> >> mutter input enumeration on GNOME Wayland sessions) reject devices
> >> with control characters in their uniq, rendering otherwise-
> >> functional input devices unusable in graphical sessions despite
> >> the kernel input layer correctly translating keypresses.
> >>
> >> Truncate hid->uniq at the first byte outside the printable ASCII
> >> range (0x20..0x7e) after the serial is read.
> >
> > Why aren't we doing this in the USB core instead of forcing all users of
> > this to do it instead?
>
> Should it be up to the kernel to do this as well? Currently this is only a
> problem with systemd because they added this check, and it looks like they
> have something in mind to fix it as well [1].
>
> [1] https://github.com/systemd/systemd/issues/41339#issuecomment-4266429563
It's either up to the kernel, or every single userspace program that
reads the strings from a device. Might as well do it in one place,
right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] HID: usbhid: sanitize hid->uniq against non-printable bytes
From: Eric Naim @ 2026-04-23 9:36 UTC (permalink / raw)
To: Greg KH
Cc: Taylor Hewetson, Jiri Kosina, Benjamin Tissoires, linux-usb,
linux-input, linux-kernel
In-Reply-To: <2026042330-underarm-reusable-effa@gregkh>
On 4/23/26 5:29 PM, Greg KH wrote:
> On Thu, Apr 23, 2026 at 05:55:00AM +0000, Eric Naim wrote:
>> On 4/18/26 3:14 PM, Greg KH wrote:
>>> On Sat, Apr 18, 2026 at 02:58:23PM +1200, Taylor Hewetson wrote:
>>>> Some USB HID devices (observed on ASUS ROG Azoth via its 2.4GHz
>>>> dongle, USB ID 0b05:1a85) report an iSerialNumber string whose
>>>> USB string descriptor declares a longer length than the actual
>>>> serial, leaving uninitialized firmware memory - including control
>>>> characters such as 0x18 - appended to the returned string.
>>>>
>>>> These non-printable bytes propagate into hid->uniq, which in turn
>>>> populates /sys/class/input/inputN/uniq. Downstream userspace
>>>> components (systemd sd-device property_is_valid(), and by extension
>>>> mutter input enumeration on GNOME Wayland sessions) reject devices
>>>> with control characters in their uniq, rendering otherwise-
>>>> functional input devices unusable in graphical sessions despite
>>>> the kernel input layer correctly translating keypresses.
>>>>
>>>> Truncate hid->uniq at the first byte outside the printable ASCII
>>>> range (0x20..0x7e) after the serial is read.
>>>
>>> Why aren't we doing this in the USB core instead of forcing all users of
>>> this to do it instead?
>>
>> Should it be up to the kernel to do this as well? Currently this is only a
>> problem with systemd because they added this check, and it looks like they
>> have something in mind to fix it as well [1].
>>
>> [1] https://github.com/systemd/systemd/issues/41339#issuecomment-4266429563
>
> It's either up to the kernel, or every single userspace program that
> reads the strings from a device. Might as well do it in one place,
> right?
That is a very good point. Thanks for the insight!
>
> thanks,
>
> greg k-h
--
Regards,
Eric
^ permalink raw reply
* Re: [PATCH] HID: usbhid: sanitize hid->uniq against non-printable bytes
From: Oliver Neukum @ 2026-04-23 9:49 UTC (permalink / raw)
To: Greg KH, Eric Naim
Cc: Taylor Hewetson, Jiri Kosina, Benjamin Tissoires, linux-usb,
linux-input, linux-kernel
In-Reply-To: <2026042330-underarm-reusable-effa@gregkh>
On 23.04.26 11:29, Greg KH wrote:
> On Thu, Apr 23, 2026 at 05:55:00AM +0000, Eric Naim wrote:
>> On 4/18/26 3:14 PM, Greg KH wrote:
>> [1] https://github.com/systemd/systemd/issues/41339#issuecomment-4266429563
>
> It's either up to the kernel, or every single userspace program that
> reads the strings from a device. Might as well do it in one place,
> right?
No, because that puts the assumption that user space is not interested
in what the device actually returns and uses these strings just
for printing.
Eg. you can no longer use this in a udev rule.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] HID: usbhid: sanitize hid->uniq against non-printable bytes
From: Alan Stern @ 2026-04-23 14:03 UTC (permalink / raw)
To: Oliver Neukum
Cc: Greg KH, Eric Naim, Taylor Hewetson, Jiri Kosina,
Benjamin Tissoires, linux-usb, linux-input, linux-kernel
In-Reply-To: <7312e4df-9eab-4678-bd40-ae7187a53827@suse.com>
On Thu, Apr 23, 2026 at 11:49:02AM +0200, Oliver Neukum wrote:
>
>
> On 23.04.26 11:29, Greg KH wrote:
> > On Thu, Apr 23, 2026 at 05:55:00AM +0000, Eric Naim wrote:
> > > On 4/18/26 3:14 PM, Greg KH wrote:
>
> > > [1] https://github.com/systemd/systemd/issues/41339#issuecomment-4266429563
> >
> > It's either up to the kernel, or every single userspace program that
> > reads the strings from a device. Might as well do it in one place,
> > right?
>
> No, because that puts the assumption that user space is not interested
> in what the device actually returns and uses these strings just
> for printing.
> Eg. you can no longer use this in a udev rule.
Also, the USB spec doesn't say anything about what characters are or
aren't allowed in a string descriptor. Anything, even a control
character, is valid. The kernel should not rule them and certainly
shouldn't truncate a string descriptor.
Alan Stern
^ permalink raw reply
* Re: [PATCH] HID: intel-thc-hid: Intel-quickspi: Fix some error codes
From: Mark Pearson @ 2026-04-23 14:51 UTC (permalink / raw)
To: Dan Carpenter, Even Xu
Cc: Xinpeng Sun, Jiri Kosina, Benjamin Tissoires, Srinivas Pandruvada,
linux-input, linux-kernel, kernel-janitors
In-Reply-To: <aenFyk36rTnrD9s3@stanley.mountain>
Hi Dan,
On Thu, Apr 23, 2026, at 3:10 AM, Dan Carpenter wrote:
> If we have a partial read that is supposed to be treated as failure but
> in this code we forgot to set the error code. Return -EINVAL.
>
> Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI
> protocol implementation")
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> index 16f780bc879b..cb19057f1191 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> @@ -94,7 +94,7 @@ static int quickspi_get_device_descriptor(struct
> quickspi_device *qsdev)
> dev_err_once(qsdev->dev, "Read DEVICE_DESCRIPTOR failed, ret =
> %d\n", ret);
> dev_err_once(qsdev->dev, "DEVICE_DESCRIPTOR expected len = %u,
> actual read = %u\n",
> input_len, read_len);
> - return ret;
> + return ret ?: -EINVAL;
> }
>
> input_rep_type = ((struct input_report_body_header
> *)read_buf)->input_report_type;
> @@ -318,7 +318,7 @@ int reset_tic(struct quickspi_device *qsdev)
> dev_err_once(qsdev->dev, "Read RESET_RESPONSE body failed, ret =
> %d\n", ret);
> dev_err_once(qsdev->dev, "RESET_RESPONSE body expected len = %u,
> actual = %u\n",
> read_len, actual_read_len);
> - return ret;
> + return ret ?: -EINVAL;
> }
>
> input_rep_type = FIELD_GET(HIDSPI_IN_REP_BDY_HDR_REP_TYPE, reset_response);
> --
> 2.53.0
I think this would be throwing away other possible different return values from thc_tic_pio_read?
You'd be losing the -EINTR,-EBUSY, -ETIMEDOUT conditions that might be useful to the upper layers.
Should that block be split into two separate error conditions?
Mark
^ permalink raw reply
* Re: [PATCH] HID: intel-thc-hid: Intel-quickspi: Fix some error codes
From: Dan Carpenter @ 2026-04-23 15:12 UTC (permalink / raw)
To: Mark Pearson
Cc: Even Xu, Xinpeng Sun, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, linux-input, linux-kernel, kernel-janitors
In-Reply-To: <7e6c43e6-7896-4504-bc13-5f12025596b1@app.fastmail.com>
On Thu, Apr 23, 2026 at 10:51:10AM -0400, Mark Pearson wrote:
> Hi Dan,
>
> On Thu, Apr 23, 2026, at 3:10 AM, Dan Carpenter wrote:
> > dev_err_once(qsdev->dev, "RESET_RESPONSE body expected len = %u,
> > actual = %u\n",
> > read_len, actual_read_len);
> > - return ret;
> > + return ret ?: -EINVAL;
> > }
> >
> > input_rep_type = FIELD_GET(HIDSPI_IN_REP_BDY_HDR_REP_TYPE, reset_response);
> > --
> > 2.53.0
>
> I think this would be throwing away other possible different return values from thc_tic_pio_read?
> You'd be losing the -EINTR,-EBUSY, -ETIMEDOUT conditions that might be useful to the upper layers.
>
> Should that block be split into two separate error conditions?
It doesn't throw away any error codes. Writing "return ret ?: -EINVAL;"
is a short hand for "return ret ? ret : -EINVAL;".
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] HID: intel-thc-hid: Intel-quickspi: Fix some error codes
From: Mark Pearson @ 2026-04-23 15:32 UTC (permalink / raw)
To: Dan Carpenter
Cc: Even Xu, Xinpeng Sun, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, linux-input, linux-kernel, kernel-janitors
In-Reply-To: <aeo25zL_XIoFZ7uK@stanley.mountain>
On Thu, Apr 23, 2026, at 11:12 AM, Dan Carpenter wrote:
> On Thu, Apr 23, 2026 at 10:51:10AM -0400, Mark Pearson wrote:
>> Hi Dan,
>>
>> On Thu, Apr 23, 2026, at 3:10 AM, Dan Carpenter wrote:
>> > dev_err_once(qsdev->dev, "RESET_RESPONSE body expected len = %u,
>> > actual = %u\n",
>> > read_len, actual_read_len);
>> > - return ret;
>> > + return ret ?: -EINVAL;
>> > }
>> >
>> > input_rep_type = FIELD_GET(HIDSPI_IN_REP_BDY_HDR_REP_TYPE, reset_response);
>> > --
>> > 2.53.0
>>
>> I think this would be throwing away other possible different return values from thc_tic_pio_read?
>> You'd be losing the -EINTR,-EBUSY, -ETIMEDOUT conditions that might be useful to the upper layers.
>>
>> Should that block be split into two separate error conditions?
>
> It doesn't throw away any error codes. Writing "return ret ?: -EINVAL;"
> is a short hand for "return ret ? ret : -EINVAL;".
>
Yeah, you're right - read it to fast. Sorry!
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
^ permalink raw reply
* Re: [git pull] Input updates for v7.1-rc0
From: pr-tracker-bot @ 2026-04-23 16:18 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <aejjiyVgBhKsw2-4@google.com>
The pull request you sent on Wed, 22 Apr 2026 08:05:35 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v7.1-rc0
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/429e6c7f90d12a8551b3eaa9faca7cfaefd99b1d
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] Input: ims-pcu - bound frame parser write index against read_buf size
From: Dmitry Torokhov @ 2026-04-23 17:24 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <2026042322-swooned-bauble-40eb@gregkh>
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.
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.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: elan_i2c - Add ic type 0x19
From: Dmitry.torokhov@gmail.com @ 2026-04-23 18:02 UTC (permalink / raw)
To: Jingle Wu 吳金國
Cc: Linux-kernel@vger.kernel.org, Linux-input@vger.kernel.org
In-Reply-To: <KL1PR01MB511699853D1B66D137C06806DC2C2@KL1PR01MB5116.apcprd01.prod.exchangelabs.com>
On Tue, Apr 21, 2026 at 07:00:10AM +0000, Jingle Wu 吳金國 wrote:
> The 0x19 is valid 3000 serial ic type too.
>
> Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>
> ---
> drivers/input/mouse/elan_i2c_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
> index fee1796da3d0..7475803c6ce4 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -162,6 +162,9 @@ static int elan_get_fwinfo(u16 ic_type, u8 iap_version, u16 *validpage_count,
> case 0x15:
> *validpage_count = 1024;
> break;
> + case 0x19:
> + *validpage_count = 2032;
> + break;
> default:
> /* unknown ic type clear value */
> *validpage_count = 0;
Applied both, thank you.
--
Dmitry
^ permalink raw reply
* RE: [PATCH] HID: intel-thc-hid: Intel-quickspi: Fix some error codes
From: Xu, Even @ 2026-04-24 0:53 UTC (permalink / raw)
To: Dan Carpenter
Cc: Sun, Xinpeng, Jiri Kosina, Benjamin Tissoires, Mark Pearson,
Srinivas Pandruvada, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <aenFyk36rTnrD9s3@stanley.mountain>
> -----Original Message-----
> From: Dan Carpenter <error27@gmail.com>
> Sent: Thursday, April 23, 2026 3:10 PM
> To: Xu, Even <even.xu@intel.com>
> Cc: Sun, Xinpeng <xinpeng.sun@intel.com>; Jiri Kosina <jikos@kernel.org>;
> Benjamin Tissoires <bentiss@kernel.org>; Mark Pearson <mpearson-
> lenovo@squebb.ca>; Srinivas Pandruvada
> <srinivas.pandruvada@linux.intel.com>; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [PATCH] HID: intel-thc-hid: Intel-quickspi: Fix some error codes
>
> If we have a partial read that is supposed to be treated as failure but in this code
> we forgot to set the error code. Return -EINVAL.
>
> Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol
> implementation")
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> index 16f780bc879b..cb19057f1191 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> @@ -94,7 +94,7 @@ static int quickspi_get_device_descriptor(struct
> quickspi_device *qsdev)
> dev_err_once(qsdev->dev, "Read DEVICE_DESCRIPTOR failed,
> ret = %d\n", ret);
> dev_err_once(qsdev->dev, "DEVICE_DESCRIPTOR expected len
> = %u, actual read = %u\n",
> input_len, read_len);
> - return ret;
> + return ret ?: -EINVAL;
> }
Good capture! If ret > 0, but read length != expected length, the error also needs to be thrown.
Thanks for the patch!
Reviewed-by: Even Xu <even.xu@intel.com>
>
> input_rep_type = ((struct input_report_body_header *)read_buf)-
> >input_report_type; @@ -318,7 +318,7 @@ int reset_tic(struct quickspi_device
> *qsdev)
> dev_err_once(qsdev->dev, "Read RESET_RESPONSE body failed,
> ret = %d\n", ret);
> dev_err_once(qsdev->dev, "RESET_RESPONSE body expected
> len = %u, actual = %u\n",
> read_len, actual_read_len);
> - return ret;
> + return ret ?: -EINVAL;
> }
>
> input_rep_type = FIELD_GET(HIDSPI_IN_REP_BDY_HDR_REP_TYPE,
> reset_response);
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH v2 4/4] HID: wacom: use __free(kfree) to clean up temporary buffers
From: kernel test robot @ 2026-04-24 1:08 UTC (permalink / raw)
To: Benjamin Tissoires, Jiri Kosina, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Lee Jones
Cc: oe-kbuild-all, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, Benjamin Tissoires
In-Reply-To: <20260416-wip-fix-core-v2-4-be92570e5627@kernel.org>
Hi Benjamin,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 7df6572f1cb381d6b89ceed58e3b076c233c2cd0]
url: https://github.com/intel-lab-lkp/linux/commits/Benjamin-Tissoires/HID-pass-the-buffer-size-to-hid_report_raw_event/20260422-150759
base: 7df6572f1cb381d6b89ceed58e3b076c233c2cd0
patch link: https://lore.kernel.org/r/20260416-wip-fix-core-v2-4-be92570e5627%40kernel.org
patch subject: [PATCH v2 4/4] HID: wacom: use __free(kfree) to clean up temporary buffers
config: i386-randconfig-2006-20250804 (https://download.01.org/0day-ci/archive/20260424/202604240311.WgVgLjLa-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260424/202604240311.WgVgLjLa-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604240311.WgVgLjLa-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/linux/input.h:19,
from drivers/hid/hid-core.c:25:
drivers/hid/hid-core.c: In function 'hid_report_raw_event':
>> drivers/hid/hid-core.c:2053:43: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:156:61: note: in expansion of macro 'dev_fmt'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
include/linux/dev_printk.h:215:17: note: in expansion of macro 'dev_warn'
215 | dev_level(dev, fmt, ##__VA_ARGS__); \
| ^~~~~~~~~
include/linux/dev_printk.h:227:9: note: in expansion of macro 'dev_level_ratelimited'
227 | dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~
include/linux/hid.h:1340:9: note: in expansion of macro 'dev_warn_ratelimited'
1340 | dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2053:17: note: in expansion of macro 'hid_warn_ratelimited'
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2053:91: note: format string is defined here
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~^
| |
| long int
| %d
drivers/hid/hid-core.c:2075:43: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:156:61: note: in expansion of macro 'dev_fmt'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
include/linux/dev_printk.h:215:17: note: in expansion of macro 'dev_warn'
215 | dev_level(dev, fmt, ##__VA_ARGS__); \
| ^~~~~~~~~
include/linux/dev_printk.h:227:9: note: in expansion of macro 'dev_level_ratelimited'
227 | dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~
include/linux/hid.h:1340:9: note: in expansion of macro 'dev_warn_ratelimited'
1340 | dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2075:17: note: in expansion of macro 'hid_warn_ratelimited'
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ^~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-core.c:2075:92: note: format string is defined here
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~^
| |
| long int
| %d
vim +2053 drivers/hid/hid-core.c
2035
2036 int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
2037 size_t bufsize, u32 size, int interrupt)
2038 {
2039 struct hid_report_enum *report_enum = hid->report_enum + type;
2040 struct hid_report *report;
2041 struct hid_driver *hdrv;
2042 int max_buffer_size = HID_MAX_BUFFER_SIZE;
2043 u32 rsize, csize = size;
2044 size_t bsize = bufsize;
2045 u8 *cdata = data;
2046 int ret = 0;
2047
2048 report = hid_get_report(report_enum, data);
2049 if (!report)
2050 return 0;
2051
2052 if (unlikely(bsize < csize)) {
> 2053 hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
2054 report->id, csize, bsize);
2055 return -EINVAL;
2056 }
2057
2058 if (report_enum->numbered) {
2059 cdata++;
2060 csize--;
2061 bsize--;
2062 }
2063
2064 rsize = hid_compute_report_size(report);
2065
2066 if (hid->ll_driver->max_buffer_size)
2067 max_buffer_size = hid->ll_driver->max_buffer_size;
2068
2069 if (report_enum->numbered && rsize >= max_buffer_size)
2070 rsize = max_buffer_size - 1;
2071 else if (rsize > max_buffer_size)
2072 rsize = max_buffer_size;
2073
2074 if (bsize < rsize) {
2075 hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
2076 report->id, rsize, bsize);
2077 return -EINVAL;
2078 }
2079
2080 if (csize < rsize) {
2081 dbg_hid("report %d is too short, (%d < %d)\n", report->id,
2082 csize, rsize);
2083 memset(cdata + csize, 0, rsize - csize);
2084 }
2085
2086 if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
2087 hid->hiddev_report_event(hid, report);
2088 if (hid->claimed & HID_CLAIMED_HIDRAW) {
2089 ret = hidraw_report_event(hid, data, size);
2090 if (ret)
2091 return ret;
2092 }
2093
2094 if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
2095 hid_process_report(hid, report, cdata, interrupt);
2096 hdrv = hid->driver;
2097 if (hdrv && hdrv->report)
2098 hdrv->report(hid, report);
2099 }
2100
2101 if (hid->claimed & HID_CLAIMED_INPUT)
2102 hidinput_report_event(hid, report);
2103
2104 return ret;
2105 }
2106 EXPORT_SYMBOL_GPL(hid_report_raw_event);
2107
2108
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] Input: ims-pcu - bound frame parser write index against read_buf size
From: Greg Kroah-Hartman @ 2026-04-24 4:16 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <aepUPTvakExa3OZS@google.com>
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 :(
> 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.
thanks,
greg k-h
^ permalink raw reply
* Re: regarding runtime PM in pegasus_notetaker
From: Martin Kepplinger @ 2026-04-24 4:27 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-input@vger.kernel.org, USB list
In-Reply-To: <59b2c482-06b4-48e6-addc-ba585b580006@suse.com>
Am Mittwoch, dem 25.03.2026 um 15:00 +0100 schrieb Oliver Neukum:
> Hi,
>
> the driver takes a PM reference in open(), yet it marks
> the device busy in pegasus_irq(). These approaches contradict
> each other. There is no point in marking a device as busy
> while its PM count is elevated. It will not be runtime suspended
> anyway.
>
> Did you mean for the device to be subjected to runtime PM
> while in use? If so, could you test the attached patch?
>
> Regards
> Oliver
hi Oliver,
sorry I haven't replied in a month. I saw your patch and have the
device. I plan to look at it and get back to you eventuelly but haven't
done so yet.
thank you,
martin
^ permalink raw reply
* [PATCH v1 0/2] input: misc: add support for Imagis ISA1200 haptic motor driver
From: Svyatoslav Ryhel @ 2026-04-24 7:13 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel
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.
Linus Walleij (1):
Input: isa1200 - new driver for Imagis ISA1200
Svyatoslav Ryhel (1):
dt-bindings: input: Document Imagis ISA1200 haptic motor driver
.../bindings/input/imagis,isa1200.yaml | 145 ++++++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/isa1200.c | 459 ++++++++++++++++++
include/dt-bindings/input/isa1200.h | 16 +
5 files changed, 632 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/imagis,isa1200.yaml
create mode 100644 drivers/input/misc/isa1200.c
create mode 100644 include/dt-bindings/input/isa1200.h
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Svyatoslav Ryhel @ 2026-04-24 7:13 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20260424071305.89503-1-clamor95@gmail.com>
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
diff --git a/Documentation/devicetree/bindings/input/imagis,isa1200.yaml b/Documentation/devicetree/bindings/input/imagis,isa1200.yaml
new file mode 100644
index 000000000000..51767fd8189d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/imagis,isa1200.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/imagis,isa1200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagis ISA1200 haptic motor driver
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+ - Linus Walleij <linusw@kernel.org>
+
+description:
+ The ISA1200 is a high-performance enhanced haptic motor driver designed
+ for mobile hand-held devices. It supports various voltages for both ERM
+ (Eccentric Rotating Mass) and LRA (Linear Resonant Actuator) type
+ actuators. Thanks to an embedded LDO, battery power can be used directly
+ in handheld applications.
+
+properties:
+ compatible:
+ const: imagis,isa1200
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ description:
+ One or two GPIOs flagged as active high linked to HEN and LEN pins
+ maxItems: 2
+
+ clocks:
+ maxItems: 1
+
+ pwms:
+ maxItems: 1
+
+ vdd-supply:
+ description:
+ Regulator for 2.4V - 5.5V power supply
+
+ vddp-supply:
+ description:
+ Regulator for 2.4V - 3.6V IO power supply
+
+ imagis,clk-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Divider for the external input clock/PWM
+ 0 - 128
+ 1 - 256
+ 2 - 512
+ 3 - 1024
+ enum: [0, 1, 2, 3]
+ default: 0
+
+ imagis,pll-div:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Divider for the internal PLL clock
+ minimum: 1
+ maximum: 15
+ default: 1
+
+ imagis,mode:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the motor type isa1200 drives
+ 0 - LRA (Linear Resonant Actuator)
+ 1 - ERM (Eccentric Rotating Mass)
+ enum: [0, 1]
+ default: 0
+
+ imagis,period-ns:
+ description:
+ Period of the internal PWM channel in nanoseconds.
+ minimum: 128
+ maximum: 254
+
+ imagis,duty-cycle-ns:
+ description:
+ Duty cycle of the external/internal PWM channel in nanoseconds,
+ defaults to 50% of the channel's period
+
+ ldo:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ description:
+ Embedded LDO regulator with voltage range 2.3V - 3.8V
+ unevaluatedProperties: false
+
+ required:
+ - regulator-min-microvolt
+ - regulator-max-microvolt
+
+required:
+ - compatible
+ - reg
+ - ldo
+
+anyOf:
+ - required:
+ - clocks
+ - imagis,period-ns
+ - required:
+ - pwms
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/input/isa1200.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ haptic-engine@49 {
+ compatible = "imagis,isa1200";
+ reg = <0x49>;
+
+ clocks = <&isa1200_refclk>;
+
+ enable-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>,
+ <&gpio 23 GPIO_ACTIVE_HIGH>;
+
+ vdd-supply = <&vdd_3v3_vbat>;
+ vddp-supply = <&vdd_2v8_vvib>;
+
+ imagis,clk-div = <ISA1200_CKLDIV_256>;
+ imagis,pll-div = <2>;
+
+ imagis,mode = <ISA1200_LRA_MODE>;
+
+ imagis,period-ns = <134>;
+ imagis,duty-cycle-ns = <100>;
+
+ ldo {
+ regulator-name = "vdd_vib";
+ regulator-min-microvolt = <2300000>;
+ regulator-max-microvolt = <2300000>;
+ };
+ };
+ };
diff --git a/include/dt-bindings/input/isa1200.h b/include/dt-bindings/input/isa1200.h
new file mode 100644
index 000000000000..cbae47ccf99b
--- /dev/null
+++ b/include/dt-bindings/input/isa1200.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
+
+#ifndef _DT_BINDINGS_ISA1200_H
+#define _DT_BINDINGS_ISA1200_H
+
+/* Linked actuator type */
+#define ISA1200_LRA_MODE 0
+#define ISA1200_ERM_MODE 1
+
+/* External clock divider */
+#define ISA1200_CKLDIV_128 0
+#define ISA1200_CKLDIV_256 1
+#define ISA1200_CKLDIV_512 2
+#define ISA1200_CKLDIV_1024 3
+
+#endif
--
2.51.0
^ permalink raw reply related
* [PATCH v1 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-04-24 7:13 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20260424071305.89503-1-clamor95@gmail.com>
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>
---
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/isa1200.c | 459 +++++++++++++++++++++++++++++++++++
3 files changed, 471 insertions(+)
create mode 100644 drivers/input/misc/isa1200.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 94a753fcb64f..5e5d46f44b91 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -852,6 +852,17 @@ config INPUT_IQS7222
To compile this driver as a module, choose M here: the
module will be called iqs7222.
+config INPUT_ISA1200_HAPTIC
+ tristate "Imagis ISA1200 haptic feedback unit"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the Imagis ISA1200 haptic
+ feedback unit.
+
+ To compile this driver as a module, choose M here: the
+ module will be called isa1200.
+
config INPUT_CMA3000
tristate "VTI CMA3000 Tri-axis accelerometer"
help
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415fc4e2918b..d62bf2e9d85f 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_INPUT_IMS_PCU) += ims-pcu.o
obj-$(CONFIG_INPUT_IQS269A) += iqs269a.o
obj-$(CONFIG_INPUT_IQS626A) += iqs626a.o
obj-$(CONFIG_INPUT_IQS7222) += iqs7222.o
+obj-$(CONFIG_INPUT_ISA1200_HAPTIC) += isa1200.o
obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
diff --git a/drivers/input/misc/isa1200.c b/drivers/input/misc/isa1200.c
new file mode 100644
index 000000000000..965883e29c37
--- /dev/null
+++ b/drivers/input/misc/isa1200.c
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/bitmap.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/units.h>
+
+#include <dt-bindings/input/isa1200.h>
+
+/*
+ * System control (LDO regulator)
+ *
+ * LDO voltage to register mapping is linear, but it is split in two parts:
+ * 2.3V - 3.0V map to 0x08 - 0x0f; 3.1V - 3.8V map to 0x00 - 0x7
+ */
+
+#define ISA1200_SCTRL 0x00
+#define ISA1200_LDO_VOLTAGE_BASE 0x08
+#define ISA1200_LDO_VOLTAGE_STEP 100000
+#define ISA1200_LDO_VOLTAGE_2V3 23
+#define ISA1200_LDO_VOLTAGE_3V1 31
+
+/*
+ * The output frequency is calculated with this formula:
+ *
+ * base clock frequency
+ * fout = -----------------------------------------
+ * (128 - PWM_FREQ) * 2 * PLLDIV * PWM_PERIOD
+ *
+ * The base clock frequency is the clock frequency provided on the
+ * clock input to the chip, divided by the value in HCTRL0
+ *
+ * PWM_FREQ is configured in register HCTRL4, it is common to set this
+ * to 0 to get only two variables to calculate.
+ *
+ * PLLDIV is configured in register HCTRL3 (bits 7..4, so 0..15)
+ * PWM_PERIOD is configured in register HCTRL6
+ * Further the duty cycle can be configured in HCTRL5
+ */
+
+/*
+ * HCTRL0 configures clock or PWM input and selects the divider for
+ * the clock input.
+ */
+#define ISA1200_HCTRL0 0x30
+#define ISA1200_HCTRL0_HAP_ENABLE BIT(7)
+#define ISA1200_HCTRL0_PWM_GEN_MODE BIT(4)
+#define ISA1200_HCTRL0_PWM_INPUT_MODE BIT(3)
+#define ISA1200_HCTRL0_TO_CLKDIV(n) (128 << (n))
+
+/*
+ * HCTRL1 configures the motor type and clock sourse
+ */
+#define ISA1200_HCTRL1 0x31
+#define ISA1200_HCTRL1_EXT_CLOCK BIT(7)
+#define ISA1200_HCTRL1_DAC_INVERT BIT(6)
+#define ISA1200_HCTRL1_MODE(n) ((n) << 5)
+
+/* HCTRL2 controls software reset of the chip */
+#define ISA1200_HCTRL2 0x32
+#define ISA1200_HCTRL2_SW_RESET BIT(0)
+
+/*
+ * HCTRL3 controls the PLL divisor
+ *
+ * Bits [0,1] are always set to 1 (we don't know what they are
+ * used for) and bit 4 and upward control the PLL divisor.
+ */
+#define ISA1200_HCTRL3 0x33
+#define ISA1200_HCTRL3_DEFAULT 0x03
+#define ISA1200_HCTRL3_PLLDIV(n) (((n) & 0xf) << 4)
+
+/* HCTRL4 controls the PWM frequency of external channel */
+#define ISA1200_HCTRL4 0x34
+
+/* HCTRL5 controls the PWM high duty cycle of internal channel */
+#define ISA1200_HCTRL5 0x35
+
+/* HCTRL6 controls the PWM period of internal channel */
+#define ISA1200_HCTRL6 0x36
+
+#define ISA1200_EN_PINS_MAX 2
+
+struct isa1200_config {
+ u32 ldo_voltage;
+ u32 mode;
+ u32 clkdiv;
+ u32 plldiv;
+ u32 freq;
+ u32 period;
+ u32 duty;
+};
+
+struct isa1200 {
+ struct input_dev *input;
+ struct regmap *map;
+
+ struct clk *clk;
+ struct pwm_device *pwm;
+ struct gpio_descs *enable_gpios;
+
+ struct work_struct play_work;
+ struct isa1200_config config;
+
+ int level;
+};
+
+static const struct regmap_config isa1200_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x3d,
+};
+
+static void isa1200_start(struct isa1200 *isa)
+{
+ struct isa1200_config *config = &isa->config;
+ struct pwm_state state;
+ u8 hctrl0, hctrl1;
+ DECLARE_BITMAP(values, ISA1200_EN_PINS_MAX);
+
+ clk_prepare_enable(isa->clk);
+
+ bitmap_fill(values, ISA1200_EN_PINS_MAX);
+ gpiod_multi_set_value_cansleep(isa->enable_gpios, values);
+
+ usleep_range(200, 300);
+
+ regmap_write(isa->map, ISA1200_SCTRL, config->ldo_voltage);
+
+ if (isa->clk) {
+ hctrl0 = ISA1200_HCTRL0_PWM_GEN_MODE;
+ hctrl1 = ISA1200_HCTRL1_EXT_CLOCK;
+ }
+
+ if (isa->pwm) {
+ hctrl0 = ISA1200_HCTRL0_PWM_INPUT_MODE;
+ hctrl1 = 0;
+ }
+
+ hctrl0 |= config->clkdiv;
+ hctrl1 |= ISA1200_HCTRL1_DAC_INVERT;
+ hctrl1 |= ISA1200_HCTRL1_MODE(config->mode);
+
+ regmap_write(isa->map, ISA1200_HCTRL0, hctrl0);
+ regmap_write(isa->map, ISA1200_HCTRL1, hctrl1);
+
+ /* Make sure to de-assert software reset */
+ regmap_write(isa->map, ISA1200_HCTRL2, 0x00);
+
+ /* PLL divisor */
+ regmap_write(isa->map, ISA1200_HCTRL3,
+ ISA1200_HCTRL3_PLLDIV(config->plldiv) |
+ ISA1200_HCTRL3_DEFAULT);
+
+ /* Frequency */
+ regmap_write(isa->map, ISA1200_HCTRL4, config->freq);
+ /* Duty cycle */
+ regmap_write(isa->map, ISA1200_HCTRL5, config->period >> 1);
+ /* Period */
+ regmap_write(isa->map, ISA1200_HCTRL6, config->period);
+
+ hctrl0 |= ISA1200_HCTRL0_HAP_ENABLE;
+ regmap_write(isa->map, ISA1200_HCTRL0, hctrl0);
+
+ if (isa->clk)
+ regmap_write(isa->map, ISA1200_HCTRL5, config->duty);
+
+ if (isa->pwm) {
+ pwm_get_state(isa->pwm, &state);
+ state.duty_cycle = config->duty;
+ state.enabled = true;
+ pwm_apply_might_sleep(isa->pwm, &state);
+ }
+}
+
+static void isa1200_stop(struct isa1200 *isa)
+{
+ struct pwm_state state;
+ DECLARE_BITMAP(values, ISA1200_EN_PINS_MAX);
+
+ if (isa->pwm) {
+ pwm_get_state(isa->pwm, &state);
+ state.duty_cycle = 0;
+ state.enabled = false;
+ pwm_apply_might_sleep(isa->pwm, &state);
+ }
+
+ regmap_write(isa->map, ISA1200_HCTRL0, 0x00);
+
+ bitmap_zero(values, ISA1200_EN_PINS_MAX);
+ gpiod_multi_set_value_cansleep(isa->enable_gpios, values);
+
+ clk_disable_unprepare(isa->clk);
+}
+
+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);
+}
+
+static int isa1200_vibrator_play_effect(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct isa1200 *isa = input_get_drvdata(input);
+ int level;
+
+ /*
+ * TODO: we currently only support rumble.
+ * The ISA1200 can control two motors and some devices
+ * also have two motors mounted.
+ */
+ level = effect->u.rumble.strong_magnitude;
+ if (!level)
+ level = effect->u.rumble.weak_magnitude;
+
+ dev_dbg(&input->dev, "FF effect type %d level %d\n",
+ effect->type, level);
+
+ if (isa->level != level) {
+ isa->level = level;
+ schedule_work(&isa->play_work);
+ }
+
+ return 0;
+}
+
+static void isa1200_vibrator_close(struct input_dev *input)
+{
+ struct isa1200 *isa = input_get_drvdata(input);
+
+ cancel_work_sync(&isa->play_work);
+
+ if (isa->level)
+ isa1200_stop(isa);
+
+ isa->level = 0;
+}
+
+static int isa1200_of_probe(struct i2c_client *client)
+{
+ static const char * const isa1200_supplies[] = { "vdd", "vddp" };
+ struct isa1200 *isa = i2c_get_clientdata(client);
+ struct isa1200_config *config = &isa->config;
+ struct device *dev = &client->dev;
+ struct fwnode_handle *ldo_node;
+ int ret;
+
+ isa->clk = devm_clk_get_optional(dev, NULL);
+ if (IS_ERR(isa->clk))
+ return dev_err_probe(dev, PTR_ERR(isa->clk),
+ "failed to get clock\n");
+
+ isa->pwm = devm_pwm_get(dev, NULL);
+ if (IS_ERR(isa->pwm))
+ isa->pwm = NULL;
+
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(isa1200_supplies),
+ isa1200_supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to set up supplies\n");
+
+ isa->enable_gpios = devm_gpiod_get_array_optional(dev, "enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(isa->enable_gpios))
+ return dev_err_probe(dev, PTR_ERR(isa->enable_gpios),
+ "failed to get enable gpios\n");
+
+ ldo_node = device_get_named_child_node(dev, "ldo");
+ if (!ldo_node)
+ return dev_err_probe(dev, -ENODEV,
+ "failed to get embedded LDO node\n");
+
+ config->ldo_voltage = 2300000;
+ ret = fwnode_property_read_u32(ldo_node, "regulator-min-microvolt",
+ &config->ldo_voltage);
+ fwnode_handle_put(ldo_node);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to get ldo voltage\n");
+
+ /* Device supports only 2.3V - 3.8V range */
+ if (config->ldo_voltage < 2300000 || config->ldo_voltage > 38000000)
+ return dev_err_probe(dev, -EINVAL,
+ "voltage is out of 2.3V - 3.8V range\n");
+
+ config->ldo_voltage /= ISA1200_LDO_VOLTAGE_STEP;
+ if (config->ldo_voltage < ISA1200_LDO_VOLTAGE_3V1)
+ config->ldo_voltage = config->ldo_voltage -
+ ISA1200_LDO_VOLTAGE_2V3 +
+ ISA1200_LDO_VOLTAGE_BASE;
+ else
+ config->ldo_voltage -= ISA1200_LDO_VOLTAGE_3V1;
+
+ config->mode = ISA1200_LRA_MODE;
+ device_property_read_u32(dev, "imagis,mode", &config->mode);
+
+ config->clkdiv = ISA1200_CKLDIV_128;
+ device_property_read_u32(dev, "imagis,clk-div", &config->clkdiv);
+
+ config->plldiv = 1;
+ device_property_read_u32(dev, "imagis,pll-div", &config->plldiv);
+
+ config->period = 0;
+ config->freq = 0;
+ config->duty = 0;
+
+ 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->duty = config->period >> 1;
+ }
+
+ if (isa->pwm) {
+ struct pwm_state state;
+
+ pwm_init_state(isa->pwm, &state);
+
+ config->freq = div64_u64(NANO, state.period *
+ ISA1200_HCTRL0_TO_CLKDIV(config->clkdiv));
+ config->duty = state.period >> 1;
+
+ ret = pwm_apply_might_sleep(isa->pwm, &state);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to apply initial PWM state\n");
+ }
+
+ device_property_read_u32(dev, "imagis,duty-cycle-ns", &config->duty);
+
+ return 0;
+}
+
+static int isa1200_probe(struct i2c_client *client)
+{
+ struct isa1200 *isa;
+ struct device *dev = &client->dev;
+ DECLARE_BITMAP(values, ISA1200_EN_PINS_MAX);
+ u32 val;
+ int ret;
+
+ isa = devm_kzalloc(dev, sizeof(*isa), GFP_KERNEL);
+ if (!isa)
+ return -ENOMEM;
+
+ isa->input = devm_input_allocate_device(dev);
+ if (!isa->input)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, isa);
+
+ ret = isa1200_of_probe(client);
+ if (ret)
+ return ret;
+
+ isa->map = devm_regmap_init_i2c(client, &isa1200_regmap_config);
+ if (IS_ERR(isa->map))
+ return dev_err_probe(dev, PTR_ERR(isa->map),
+ "failed to initialize register map\n");
+
+ clk_prepare_enable(isa->clk);
+
+ bitmap_fill(values, ISA1200_EN_PINS_MAX);
+ gpiod_multi_set_value_cansleep(isa->enable_gpios, values);
+
+ usleep_range(200, 300);
+
+ /* Read a register so we know that regmap and I2C transport works */
+ ret = regmap_read(isa->map, ISA1200_SCTRL, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to read SCTRL\n");
+
+ INIT_WORK(&isa->play_work, isa1200_play_work);
+
+ isa->input->name = "isa1200-haptic";
+ isa->input->id.bustype = BUS_HOST;
+ isa->input->dev.parent = dev;
+ isa->input->close = isa1200_vibrator_close;
+
+ input_set_drvdata(isa->input, isa);
+
+ /* TODO: this hardware can likely support more than rumble */
+ input_set_capability(isa->input, EV_FF, FF_RUMBLE);
+
+ ret = input_ff_create_memless(isa->input, NULL,
+ isa1200_vibrator_play_effect);
+ if (ret)
+ return dev_err_probe(dev, ret, "couldn't create FF dev\n");
+
+ ret = input_register_device(isa->input);
+ if (ret)
+ return dev_err_probe(dev, ret, "couldn't register input dev\n");
+
+ return ret;
+}
+
+static int isa1200_suspend(struct device *dev)
+{
+ struct isa1200 *isa = dev_get_drvdata(dev);
+
+ if (isa->level)
+ isa1200_stop(isa);
+
+ return 0;
+}
+
+static int isa1200_resume(struct device *dev)
+{
+ struct isa1200 *isa = dev_get_drvdata(dev);
+
+ if (isa->level)
+ isa1200_start(isa);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(isa1200_pm_ops, isa1200_suspend, isa1200_resume);
+
+static const struct of_device_id isa1200_of_match[] = {
+ { .compatible = "imagis,isa1200" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, isa1200_of_match);
+
+static struct i2c_driver isa1200_i2c_driver = {
+ .driver = {
+ .name = "isa1200",
+ .of_match_table = isa1200_of_match,
+ .pm = pm_sleep_ptr(&isa1200_pm_ops),
+ },
+ .probe = isa1200_probe,
+};
+module_i2c_driver(isa1200_i2c_driver);
+
+MODULE_AUTHOR("Linus Walleij <linusw@kernel.org>");
+MODULE_AUTHOR("Svyatoslav Ryhel <clamor95@gmail.com>");
+MODULE_DESCRIPTION("Imagis ISA1200 haptic feedback unit");
+MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Linus Walleij @ 2026-04-24 7:48 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260424071305.89503-2-clamor95@gmail.com>
On Fri, Apr 24, 2026 at 9:13 AM Svyatoslav Ryhel <clamor95@gmail.com> 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>
DT binding maintainers: notice that this version is essentially a reply to
requested changes from Rob in 2022:
https://lore.kernel.org/linux-input/YjuaK09nOztYOmyn@robh.at.kernel.org/
I.e. moving from "all info derived from the compatible" to "use more
properties".
Yours,
Linus Walleij
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 8f9d6cd6d3916add4c47a9dd1622e4fc057f877b
From: kernel test robot @ 2026-04-24 8:28 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 8f9d6cd6d3916add4c47a9dd1622e4fc057f877b Input: elan_i2c - increase device reset wait timeout after update FW
elapsed time: 829m
configs tested: 53
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
loongarch allnoconfig clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sparc allnoconfig gcc-15.2.0
sparc64 allmodconfig clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Rob Herring (Arm) @ 2026-04-24 8:30 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-kernel, linux-input, Dmitry Torokhov, devicetree,
Conor Dooley, Krzysztof Kozlowski, Linus Walleij
In-Reply-To: <20260424071305.89503-2-clamor95@gmail.com>
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.
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Svyatoslav Ryhel @ 2026-04-24 8:57 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: linux-kernel, linux-input, Dmitry Torokhov, devicetree,
Conor Dooley, Krzysztof Kozlowski, Linus Walleij
In-Reply-To: <177701943440.2848156.923810545023102522.robh@kernel.org>
пт, 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
^ permalink raw reply
* [PATCH] HID: bpf: Sync KF_SLEEPABLE flags in hid_bpf_syscall_kfuncs set
From: Zhao Mengmeng @ 2026-04-24 10:22 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, bpf, Zhao Mengmeng
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.
Link: https://lore.kernel.org/sched-ext/177693500312.275653.17323765149266875001.b4-reply@b4/
Signed-off-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index 50c7b45c59e3..62db80ead86e 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -585,11 +585,11 @@ static const struct btf_kfunc_id_set hid_bpf_kfunc_set = {
/* for syscall HID-BPF */
BTF_KFUNCS_START(hid_bpf_syscall_kfunc_ids)
-BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL)
-BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE)
-BTF_ID_FLAGS(func, hid_bpf_hw_request)
-BTF_ID_FLAGS(func, hid_bpf_hw_output_report)
-BTF_ID_FLAGS(func, hid_bpf_input_report)
+BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE | KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_hw_request, KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_hw_output_report, KF_SLEEPABLE)
+BTF_ID_FLAGS(func, hid_bpf_input_report, KF_SLEEPABLE)
BTF_KFUNCS_END(hid_bpf_syscall_kfunc_ids)
static const struct btf_kfunc_id_set hid_bpf_syscall_kfunc_set = {
---
base-commit: a67bb21a5fc478443d6db490c7049e9aeeb92bd4
change-id: 20260424-btf-define-622697aaece1
Best regards,
--
Zhao Mengmeng <zhaomengmeng@kylinos.cn>
^ permalink raw reply related
* Re: [PATCH v1 1/2] dt-bindings: input: Document Imagis ISA1200 haptic motor driver
From: Rob Herring @ 2026-04-24 11:55 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-kernel, linux-input, Dmitry Torokhov, devicetree,
Conor Dooley, Krzysztof Kozlowski, Linus Walleij
In-Reply-To: <CAPVz0n3Wxk=9YpmU0nXsOQdtxBhoTBv8283+OHhUr-TKxkAb5A@mail.gmail.com>
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'.
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.
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