* [PATCH 1/1] HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write
From: Lee Jones @ 2026-03-17 16:24 UTC (permalink / raw)
To: lee, Filipe Laíns, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
logi_dj_recv_send_report() assumes that all incoming REPORT_ID_DJ_SHORT
reports are 14 Bytes (DJREPORT_SHORT_LENGTH - 1) long. It uses that
assumption to load the associated field's 'value' array with 14 Bytes of
data. However, if a malicious user only sends say 1 Byte of data,
'report_count' will be 1 and only 1 Byte of memory will be allocated to
the 'value' Byte array. When we come to populate 'value[1-13]' we will
experience an OOB write.
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-logitech-dj.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 44b716697510..885b986c7a12 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1282,6 +1282,12 @@ static int logi_dj_recv_send_report(struct dj_receiver_dev *djrcv_dev,
return -ENODEV;
}
+ if (report->maxfield < 1 || report->field[0]->report_count != DJREPORT_SHORT_LENGTH - 1) {
+ hid_err(hdev, "Expected size of dj report is %d, but got %d",
+ DJREPORT_SHORT_LENGTH - 1, report->field[0]->report_count);
+ return -EINVAL;
+ }
+
for (i = 0; i < DJREPORT_SHORT_LENGTH - 1; i++)
report->field[0]->value[i] = data[i];
--
2.53.0.851.ga537e3e6e9-goog
^ permalink raw reply related
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Mathieu Desnoyers @ 2026-03-17 16:02 UTC (permalink / raw)
To: Steven Rostedt, Vineeth Remanan Pillai
Cc: Andrii Nakryiko, Peter Zijlstra, Dmitry Ilvokhin,
Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260317120049.6a60fa88@gandalf.local.home>
On 2026-03-17 12:00, Steven Rostedt wrote:
> On Fri, 13 Mar 2026 10:02:32 -0400
> Vineeth Remanan Pillai <vineeth@bitbyteword.org> wrote:
>
>>>
>>> Perhaps: call_trace_foo() ?
>>>
>> call_trace_foo has one collision with the tracepoint
>> sched_update_nr_running and a function
>> call_trace_sched_update_nr_running. I had considered this and later
>> moved to trace_invoke_foo() because of the collision. But I can rename
>> call_trace_sched_update_nr_running to something else if call_trace_foo
>> is the general consensus.
>
> OK, then lets go with: trace_call__foo()
>
> The double underscore should prevent any name collisions.
>
> Does anyone have an objections?
I'm OK with it.
Thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Steven Rostedt @ 2026-03-17 16:00 UTC (permalink / raw)
To: Vineeth Remanan Pillai
Cc: Andrii Nakryiko, Mathieu Desnoyers, Peter Zijlstra,
Dmitry Ilvokhin, Masami Hiramatsu, Ingo Molnar, Jens Axboe,
io-uring, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, Aaron Conole,
Eelco Chaudron, Ilya Maximets, netdev, bpf, linux-sctp,
tipc-discussion, dev, Oded Gabbay, Koby Elbaz, dri-devel,
Rafael J. Wysocki, Viresh Kumar, Gautham R. Shenoy, Huang Rui,
Mario Limonciello, Len Brown, Srinivas Pandruvada, linux-pm,
MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Christian König,
Sumit Semwal, linaro-mm-sig, Eddie James, Andrew Jeffery,
Joel Stanley, linux-fsi, David Airlie, Simona Vetter,
Alex Deucher, Danilo Krummrich, Matthew Brost, Philipp Stanner,
Harry Wentland, Leo Li, amd-gfx, Jiri Kosina, Benjamin Tissoires,
linux-input, Wolfram Sang, linux-i2c, Mark Brown,
Michael Hennerich, Nuno Sá, linux-spi, James E.J. Bottomley,
Martin K. Petersen, linux-scsi, Chris Mason, David Sterba,
linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <CAO7JXPgHYZ9zF1HFahb2447X85YRZCQQBHB6ihOwKSDtiZi8kQ@mail.gmail.com>
On Fri, 13 Mar 2026 10:02:32 -0400
Vineeth Remanan Pillai <vineeth@bitbyteword.org> wrote:
> >
> > Perhaps: call_trace_foo() ?
> >
> call_trace_foo has one collision with the tracepoint
> sched_update_nr_running and a function
> call_trace_sched_update_nr_running. I had considered this and later
> moved to trace_invoke_foo() because of the collision. But I can rename
> call_trace_sched_update_nr_running to something else if call_trace_foo
> is the general consensus.
OK, then lets go with: trace_call__foo()
The double underscore should prevent any name collisions.
Does anyone have an objections?
-- Steve
^ permalink raw reply
* Re: [RFC v3 2/2] HID: core: Check to ensure report responses match the request
From: Benjamin Tissoires @ 2026-03-17 14:52 UTC (permalink / raw)
To: Lee Jones; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260317092056.GE554736@google.com>
On Mar 17 2026, Lee Jones wrote:
> On Mon, 16 Mar 2026, Benjamin Tissoires wrote:
>
> > On Mar 09 2026, Lee Jones wrote:
> > > It is possible for a malicious (or clumsy) device to respond to a
> > > specific report's feature request using a completely different report
> > > ID. This can cause confusion in the HID core resulting in nasty
> > > side-effects such as OOB writes.
> > >
> > > Add a check to ensure that the report ID in the response, matches the
> > > one that was requested.
> > >
> > > Signed-off-by: Lee Jones <lee@kernel.org>
> > > ---
> > > v2 -> v3: Cover more bases by moving the check up a layer from MT to HID Core
> > >
> > > RFC query: Is this always okay?
> > > Should the report number always match the request?
> > > Are there legitimate times where the two would differ?
> >
> > Technically, there is no reasons for a HID_SET_REPORT request to change
> > the incoming buffer. So that test might break it.
> >
> > I prefered fixing the calling sites (hid-multitouch and others), because
> > here we are making decisions on the device behaviour which is not ours
> > to make. More specifically, such a test will prevent us to fix a bogus
> > device by plainly rejecting the call after the facts.
>
> Okay, so this one is a NACK? No changes, do not resend?
>
Yes, NACK on this one. I've merged the hid-multitouch one which wasn't
using the API correctly, please send a followup for the other similar
cases.
Cheers,
Benjamin
^ permalink raw reply
* Re: (subset) [PATCH 2/2] HID: multitouch: Check to ensure report responses match the request
From: Benjamin Tissoires @ 2026-03-17 14:03 UTC (permalink / raw)
To: Jiri Kosina, linux-input, linux-kernel, Lee Jones
In-Reply-To: <20260227163031.1166560-2-lee@kernel.org>
On Fri, 27 Feb 2026 16:30:25 +0000, Lee Jones wrote:
> It is possible for a malicious (or clumsy) device to respond to a
> specific report's feature request using a completely different report
> ID. This can cause confusion in the HID core resulting in nasty
> side-effects such as OOB writes.
>
> Add a check to ensure that the report ID in the response, matches the
> one that was requested. If it doesn't, omit reporting the raw event and
> return early.
>
> [...]
Applied, thanks!
[2/2] HID: multitouch: Check to ensure report responses match the request
commit: e716edafedad4952fe3a4a273d2e039a84e8681a
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
From: Conor Dooley @ 2026-03-17 12:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: phucduc.bui, robh, conor+dt, devicetree, dmitry.torokhov, krzk+dt,
linux-input, linux-kernel, marex, mingo, tglx
In-Reply-To: <fef8779a-a5e6-45f0-82dd-0cd8a892c0ea@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
On Mon, Mar 16, 2026 at 06:10:23PM +0100, Krzysztof Kozlowski wrote:
> On 16/03/2026 12:13, Conor Dooley wrote:
> > On Mon, Mar 16, 2026 at 10:46:06AM +0700, phucduc.bui@gmail.com wrote:
> >> From: bui duc phuc <phucduc.bui@gmail.com>
> >>
> >> Document the "wakeup-source" property for the ti,tsc2005 touchscreen
> >> controllers to allow the device to wake the system from suspend.
> >>
> >> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> >> ---
> >> .../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
> >> index 7187c390b2f5..c0aae044d7d4 100644
> >> --- a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
> >> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
> >> @@ -55,6 +55,9 @@ properties:
> >> touchscreen-size-x: true
> >> touchscreen-size-y: true
> >>
> >> + wakeup-source:
> >> + type: boolean
> >
> > wakeup-source: true
>
> I am not so sure.
>
> The property is multi-type, so we want to choose one - bool, IMO,
> because device cannot wakeup the specific system idle states. Or am I
> misinterpreting the phandles behind wakeup-source and every device can
> be differently routed in such system?
I checked before my original comment, and there there's a bout a 2:1
ratio of defined v true. I suppose my comment can be ignored, I am just
used to this always being true.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC v3 2/2] HID: core: Check to ensure report responses match the request
From: Lee Jones @ 2026-03-17 9:20 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <abghH9Cf5FvUpfE0@beelink>
On Mon, 16 Mar 2026, Benjamin Tissoires wrote:
> On Mar 09 2026, Lee Jones wrote:
> > It is possible for a malicious (or clumsy) device to respond to a
> > specific report's feature request using a completely different report
> > ID. This can cause confusion in the HID core resulting in nasty
> > side-effects such as OOB writes.
> >
> > Add a check to ensure that the report ID in the response, matches the
> > one that was requested.
> >
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > v2 -> v3: Cover more bases by moving the check up a layer from MT to HID Core
> >
> > RFC query: Is this always okay?
> > Should the report number always match the request?
> > Are there legitimate times where the two would differ?
>
> Technically, there is no reasons for a HID_SET_REPORT request to change
> the incoming buffer. So that test might break it.
>
> I prefered fixing the calling sites (hid-multitouch and others), because
> here we are making decisions on the device behaviour which is not ours
> to make. More specifically, such a test will prevent us to fix a bogus
> device by plainly rejecting the call after the facts.
Okay, so this one is a NACK? No changes, do not resend?
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 1/1] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure
From: Lee Jones @ 2026-03-17 9:17 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Günther Noack, Filipe Laíns, Bastien Nocera,
Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <abgh0US3fO98w18G@beelink>
On Mon, 16 Mar 2026, Benjamin Tissoires wrote:
> On Mar 16 2026, Lee Jones wrote:
> > On Tue, 03 Mar 2026, Günther Noack wrote:
> >
> > > On Fri, Feb 27, 2026 at 10:09:38AM +0000, Lee Jones wrote:
> > > > Presently, if the force feedback initialisation fails when probing the
> > > > Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
> > > > will be returned and propagated before the userspace infrastructure
> > > > (sysfs and /dev/input) has been torn down. If userspace ignores the
> > > > errors and continues to use its references to these dangling entities, a
> > > > UAF will promptly follow.
> > > >
> > > > We have 2 options; continue to return the error, but ensure that all of
> > > > the infrastructure is torn down accordingly or continue to treat this
> > > > condition as a warning by emitting the message but returning success.
> > > > It is thought that the original author's intention was to emit the
> > > > warning but keep the device functional, less the force feedback feature,
> > > > so let's go with that.
> > > >
> > > > Signed-off-by: Lee Jones <lee@kernel.org>
> > > > ---
> > > > drivers/hid/hid-logitech-hidpp.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> > > > index e871f1729d4b..eee9ab6a2fc4 100644
> > > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > > @@ -4487,10 +4487,12 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > > if (!ret)
> > > > ret = hidpp_ff_init(hidpp, &data);
> > > >
> > > > - if (ret)
> > > > + if (ret) {
> > > > hid_warn(hidpp->hid_dev,
> > > > "Unable to initialize force feedback support, errno %d\n",
> > > > ret);
> > > > + ret = 0;
> > > > + }
> > > > }
> > > >
> > > > /*
> > > > --
> > > > 2.53.0.473.g4a7958ca14-goog
> > > >
> > >
> > > Reviewed-by: Günther Noack <gnoack@google.com>
> >
> > What are the subsystem preferences in terms of pokes or [RESENDS], please?
>
> Just send a gently ping like this on the thread, this will make it pop
> up in our mailboxes :)
>
> >
> > I'm happy to submit a [RESEND] if that's required to get this back into view.
>
> Nah, no need to send a [RESEND] when the patch is just a couple of weeks
> old.
Understood, thank you.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 1/2] iio: add IIO_DECLARE_QUATERNION() macro
From: Francesco Lavra @ 2026-03-17 8:03 UTC (permalink / raw)
To: David Lechner
Cc: linux-iio, linux-kernel, Jonathan Cameron, linux-input,
Jonathan Cameron, Nuno Sá, Andy Shevchenko, Jiri Kosina,
Srinivas Pandruvada
In-Reply-To: <b050ce49-9880-4d87-8e52-09705e7166bc@baylibre.com>
On Mon, 2026-03-16 at 14:56 -0500, David Lechner wrote:
...
> > As for the alignment, according to your patch at [1], when the repeat
> > number is not a power of two, it is (will be) rounded up to the next
> > power
> > of two (and this is consistent with what the lsm6dsx driver expects),
> > so
> > the alignment will be 8 bytes.
>
> I think you are referring to the 8-byte alignment for the timestamp?
>
> Patch [1] should make a difference when the timestamp is not enabled
> in a buffered read though.
>
> When the timestamp is enabled, the buffer is going to be 16 bytes per
> sample no matter what because of the 8-byte alignment of the timestamp.
>
> But if the timestamp is not enabled, then for 16-bit storagebits and
> repeat of 3, before the patch, the buffer would only be 6 bytes per
> sample, but after the patch would be 8 bytes per sample. This doesn't
> make a difference in the driver itself, but does make a difference to
> userspace that is reading the buffer.
I was referring to alignment in general, regardless of the timestamp being
enabled. From my understanding, the computed storage size is also used for
alignment. Anyway, yes, after [1] the storage size for the quaternion scan
element will be 8 bytes, with the last 2 bytes of each sample zeroed out.
>
> > [1]
> > https://lore.kernel.org/linux-iio/20260307-iio-fix-timestamp-alignment-v2-4-d1d48fbadbbf@baylibre.com/
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: Convert TS-4800 to DT schema
From: Krzysztof Kozlowski @ 2026-03-17 7:50 UTC (permalink / raw)
To: Eduard Bostina
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Mark Brown,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260316181038.9771-1-egbostina@gmail.com>
On Mon, Mar 16, 2026 at 08:10:37PM +0200, Eduard Bostina wrote:
> Convert the TS-4800 touchscreen bindings to DT schema.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] Hid: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs
From: Even Xu @ 2026-03-17 5:56 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
In-Reply-To: <20260317055629.3877299-1-even.xu@intel.com>
Add Nova Lake THC QuickSPI device IDs to support list.
Signed-off-by: Even Xu <even.xu@intel.com>
---
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 6 ++++++
drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
index ad6bd59963b2..b6a69995692c 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -37,6 +37,10 @@ struct quickspi_driver_data arl = {
.max_packet_size_value = MAX_PACKET_SIZE_VALUE_MTL,
};
+struct quickspi_driver_data nvl = {
+ .max_packet_size_value = MAX_PACKET_SIZE_VALUE_LNL,
+};
+
/* THC QuickSPI ACPI method to get device properties */
/* HIDSPI Method: {6e2ac436-0fcf-41af-a265-b32a220dcfab} */
static guid_t hidspi_guid =
@@ -982,6 +986,8 @@ static const struct pci_device_id quickspi_pci_tbl[] = {
{PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_SPI_PORT2, &ptl), },
{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT1, &arl), },
{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT2, &arl), },
+ {PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT1, &nvl), },
+ {PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT2, &nvl), },
{}
};
MODULE_DEVICE_TABLE(pci, quickspi_pci_tbl);
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
index c30e1a42eb09..bf5e18f5a5f4 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
@@ -23,6 +23,8 @@
#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_SPI_PORT2 0x4D4B
#define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT1 0x7749
#define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT2 0x774B
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT1 0xD349
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT2 0xD34B
/* HIDSPI special ACPI parameters DSM methods */
#define ACPI_QUICKSPI_REVISION_NUM 2
--
2.40.1
^ permalink raw reply related
* [PATCH 1/2] Hid: Intel-thc-hid: Intel-quicki2c: Add NVL Device IDs
From: Even Xu @ 2026-03-17 5:56 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
In-Reply-To: <20260317055629.3877299-1-even.xu@intel.com>
Add Nova Lake THC QuickI2C device IDs to support list.
Signed-off-by: Even Xu <even.xu@intel.com>
---
drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 7 +++++++
drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h | 4 ++++
2 files changed, 11 insertions(+)
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
index f178017352ba..46d3e9a01999 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c
@@ -26,6 +26,11 @@ static struct quicki2c_ddata ptl_ddata = {
.max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
};
+static struct quicki2c_ddata nvl_ddata = {
+ .max_detect_size = MAX_RX_DETECT_SIZE_NVL,
+ .max_interrupt_delay = MAX_RX_INTERRUPT_DELAY,
+};
+
/* THC QuickI2C ACPI method to get device properties */
/* HIDI2C device method */
static guid_t i2c_hid_guid =
@@ -1032,6 +1037,8 @@ static const struct pci_device_id quicki2c_pci_tbl[] = {
{ PCI_DEVICE_DATA(INTEL, THC_PTL_U_DEVICE_ID_I2C_PORT2, &ptl_ddata) },
{ PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_I2C_PORT1, &ptl_ddata) },
{ PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_I2C_PORT2, &ptl_ddata) },
+ { PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_I2C_PORT1, &nvl_ddata) },
+ { PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_I2C_PORT2, &nvl_ddata) },
{ }
};
MODULE_DEVICE_TABLE(pci, quicki2c_pci_tbl);
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
index 33a1e3db1cb2..61dbdece59a1 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h
@@ -15,6 +15,8 @@
#define PCI_DEVICE_ID_INTEL_THC_PTL_U_DEVICE_ID_I2C_PORT2 0xE44A
#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_I2C_PORT1 0x4D48
#define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_I2C_PORT2 0x4D4A
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_I2C_PORT1 0xD348
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_I2C_PORT2 0xD34A
/* Packet size value, the unit is 16 bytes */
#define MAX_PACKET_SIZE_VALUE_LNL 256
@@ -40,6 +42,8 @@
/* PTL Max packet size detection capability is 255 Bytes */
#define MAX_RX_DETECT_SIZE_PTL 255
+/* NVL Max packet size detection capability is 64K Bytes */
+#define MAX_RX_DETECT_SIZE_NVL 65535
/* Max interrupt delay capability is 2.56ms */
#define MAX_RX_INTERRUPT_DELAY 256
--
2.40.1
^ permalink raw reply related
* [PATCH 0/2] Add THC Nova Lake device IDs
From: Even Xu @ 2026-03-17 5:56 UTC (permalink / raw)
To: bentiss, jikos; +Cc: srinivas.pandruvada, linux-input, linux-kernel, Even Xu
Add THC Device IDs for Nova Lake platform.
Even Xu (2):
Hid: Intel-thc-hid: Intel-quicki2c: Add NVL Device IDs
Hid: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs
drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c | 7 +++++++
drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-dev.h | 4 ++++
drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 6 ++++++
drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h | 2 ++
4 files changed, 19 insertions(+)
--
2.40.1
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: input: add adi,max16150.yaml
From: Sosa, Marc Paolo @ 2026-03-17 3:14 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Dmitry Torokhov, linux-input@vger.kernel.org, Conor Dooley,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Krzysztof Kozlowski
In-Reply-To: <177184949524.3256996.10057873509160996630.robh@kernel.org>
> -----Original Message-----
> From: Rob Herring (Arm) <robh@kernel.org>
> Sent: Monday, February 23, 2026 8:25 PM
> To: Sosa, Marc Paolo <MarcPaolo.Sosa@analog.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; linux-
> input@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Krzysztof Kozlowski
> <krzk+dt@kernel.org>
> Subject: Re: [PATCH 1/2] dt-bindings: input: add adi,max16150.yaml
>
> [External]
>
>
> On Mon, 23 Feb 2026 19:03:39 +0800, Marc Paolo Sosa wrote:
> > Add documentation for device tree bindings for MAX16150/MAX16169
> >
> > Signed-off-by: Marc Paolo Sosa <marcpaolo.sosa@analog.com>
> > ---
> > .../devicetree/bindings/input/adi,max16150.yaml | 57
> ++++++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
>
> 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/adi,max16150.example.dtb
> : power-button (adi,max16150a): 'interrupt-gpios' does not match any of the
> regexes: '^pinctrl-[0-9]+$'
> from schema $id:
> https://urldefense.com/v3/__http://devicetree.org/schemas/input/adi,max16
> 150.yaml__;!!A3Ni8CS0y2Y!-TPsir0eSI17GHXi7gGeaK1XizFHf0bf6SbAJdX07Ztz-
> nAbFzqUqkvcxua95NPqfd9F9hYLmClYnD4Q$
>
> doc reference errors (make refcheckdocs):
>
> See
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/devicetree
> /patch/20260223-max16150-v1-1-
> 38e2a4f0d0f1@analog.com__;!!A3Ni8CS0y2Y!-
> TPsir0eSI17GHXi7gGeaK1XizFHf0bf6SbAJdX07Ztz-
> nAbFzqUqkvcxua95NPqfd9F9hYLmMWFLC-A$
>
> 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.
Alright, will check this out before sending another patch.
Thanks,
Pao
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: input: add adi,max16150.yaml
From: Sosa, Marc Paolo @ 2026-03-17 3:13 UTC (permalink / raw)
To: Rob Herring
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260223165034.GA3975976-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Tuesday, February 24, 2026 12:51 AM
> To: Sosa, Marc Paolo <MarcPaolo.Sosa@analog.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> input@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] dt-bindings: input: add adi,max16150.yaml
>
> [External]
>
> On Mon, Feb 23, 2026 at 07:03:39PM +0800, Marc Paolo Sosa wrote:
> > Add documentation for device tree bindings for MAX16150/MAX16169
> >
> > Signed-off-by: Marc Paolo Sosa <marcpaolo.sosa@analog.com>
> > ---
> > .../devicetree/bindings/input/adi,max16150.yaml | 57
> ++++++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/adi,max16150.yaml
> > b/Documentation/devicetree/bindings/input/adi,max16150.yaml
> > new file mode 100644
> > index 000000000000..327811e1ebd4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/adi,max16150.yaml
> > @@ -0,0 +1,57 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://urldefense.com/v3/__http://devicetree.org/schemas/input/adi,m
> >
> +ax16150.yaml*__;Iw!!A3Ni8CS0y2Y!7MP9aN8nPEM3L2rIf_pWYnGRpvrMnRa
> dsVK3J
> > +dATD43g-6ZDMtcTwePpZWP1Ji7DaZoV6c0Iy5nMrfJM$
> > +$schema:
> > +https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.y
> >
> +aml*__;Iw!!A3Ni8CS0y2Y!7MP9aN8nPEM3L2rIf_pWYnGRpvrMnRadsVK3JdA
> TD43g-6
> > +ZDMtcTwePpZWP1Ji7DaZoV6c0IywbOF-bm$
> > +
> > +title: Analog Devices MAX16150/MAX16169 nanoPower Pushbutton On/Off
> > +Controller
> > +
> > +maintainers:
> > + - Marc Paolo Sosa <marcpaolo.sosa@analog.com>
> > +
> > +description:
> > + The MAX16150/MAX16169 is a low-power pushbutton on/off controller
> > +with a
> > + switch debouncer and built-in latch. It accepts a noisy input from
> > +a
> > + mechanical switch and produces a clean latched output, as well as a
> > +one-shot
> > + interrupt output.
> > +
> > +properties:
> > + compatible:
> > + description:
> > + Specifies the supported device variants. The MAX16150 and MAX16169
> are supported.
>
> Drop description.
>
> > + enum:
> > + - adi,max16150a
> > + - adi,max16150b
> > + - adi,max16169a
> > + - adi,max16169b
>
> What's the diff between a and b? If nothing s/w needs to know about, then
> maybe you don't need to distinguish.
>
> > +
> > + interrupt-gpio:
> > + maxItems: 1
>
> Use 'interrupts' property.
>
> > +
> > + clr-gpios:
> > + description:
> > + Clear Input. Pulling CLR low deasserts the latched OUT signal. If OUT is
> > + already deasserted when CLR is pulled low, the state of OUT is
> unchanged.
> > + maxItems: 1
> > +
> > + linux,code:
> > + default: KEY_POWER
> > +
> > +required:
> > + - compatible
> > + - interrupt-gpios
> > + - clr-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/input/linux-event-codes.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + power-button {
> > + compatible = "adi,max16150a";
> > + interrupt-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
> > + clr-gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
> > + linux,code = <KEY_POWER>;
> > + };
> >
> > --
> > 2.34.1
> >
This is noted, I'll test this out and will apply it on my next patch.
Regards,
Pao
^ permalink raw reply
* RE: [PATCH 2/2] input: misc: add driver for max16150
From: Sosa, Marc Paolo @ 2026-03-17 3:12 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <aZ4nA33Lc73L1D2y@google.com>
> -----Original Message-----
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Sent: Wednesday, February 25, 2026 6:42 AM
> To: Sosa, Marc Paolo <MarcPaolo.Sosa@analog.com>
> Cc: Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> input@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] input: misc: add driver for max16150
>
> [External]
>
> Hi Marc,
>
> On Mon, Feb 23, 2026 at 07:03:40PM +0800, Marc Paolo Sosa via B4 Relay
> wrote:
> > From: Marc Paolo Sosa <marcpaolo.sosa@analog.com>
> >
> > MAX16150/MAX16169 nanoPower Pushbutton On/Off Controller
> >
> > Signed-off-by: Marc Paolo Sosa <marcpaolo.sosa@analog.com>
> > ---
> > drivers/input/misc/Kconfig | 9 +++
> > drivers/input/misc/Makefile | 1 +
> > drivers/input/misc/max16150.c | 161
> > ++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 171 insertions(+)
> >
> > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> > index 94a753fcb64f..a31d3d2a7fd6 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -178,6 +178,15 @@ config INPUT_E3X0_BUTTON
> > To compile this driver as a module, choose M here: the
> > module will be called e3x0_button.
> >
> > +config INPUT_MAX16150_PWRBUTTON
> > + tristate "MAX16150/MAX16169 Pushbutton driver"
> > + help
> > + Say Y here if you want to enable power key reporting via
> > + MAX16150/MAX16169 nanoPower Pushbutton On/Off Controller.
> > +
> > + To compile this driver as a module, choose M here. The module will
> > + be called max16150.
> > +
> > config INPUT_PCSPKR
> > tristate "PC Speaker support"
> > depends on PCSPKR_PLATFORM
> > diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> > index 415fc4e2918b..c2c1c45f2df6 100644
> > --- a/drivers/input/misc/Makefile
> > +++ b/drivers/input/misc/Makefile
> > @@ -52,6 +52,7 @@ obj-$(CONFIG_INPUT_IQS7222) += iqs7222.o
> > obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
> > obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
> > obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
> > +obj-$(CONFIG_INPUT_MAX16150_PWRBUTTON) += max16150.o
> > obj-$(CONFIG_INPUT_MAX7360_ROTARY) += max7360-rotary.o
> > obj-$(CONFIG_INPUT_MAX77650_ONKEY) += max77650-onkey.o
> > obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
> > diff --git a/drivers/input/misc/max16150.c
> > b/drivers/input/misc/max16150.c new file mode 100644 index
> > 000000000000..ae353b926afc
> > --- /dev/null
> > +++ b/drivers/input/misc/max16150.c
> > @@ -0,0 +1,161 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Analog Devices MAX16150/MAX16169 Pushbutton Driver
> > + *
> > + * Copyright 2025 Analog Devices Inc.
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/init.h>
> > +#include <linux/input.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +
> > +#define MAX16150_LONG_INTERRUPT 120000000
> > +
> > +struct max16150_chip_info {
> > + bool has_clr_gpio;
> > +};
> > +
> > +struct max16150_device {
> > + struct input_dev *input;
> > + struct gpio_desc *gpiod;
> > + struct gpio_desc *clr_gpiod;
> > + const struct max16150_chip_info *chip_info;
> > + u64 low, high, duration;
>
> I do not think you need to store "high" and "duration", just "press"
> time. I also do not think you need nanosecond resilution, jiffies will do.
>
> > + unsigned int keycode;
> > +};
> > +
> > +static irqreturn_t max16150_irq_handler(int irq, void *_max16150) {
> > + struct max16150_device *max16150 = _max16150;
> > + int value;
> > +
> > + value = gpiod_get_value(max16150->gpiod);
> > +
> > + if (!value) {
> > + max16150->low = ktime_get_ns();
> > + return IRQ_HANDLED;
> > + }
> > +
> > + max16150->high = ktime_get_ns();
> > + if (max16150->low) {
> > + max16150->duration = max16150->high - max16150->low;
> > +
> > + if (max16150->duration > MAX16150_LONG_INTERRUPT) {
>
> time_after() is probably what you need here.
>
> > + gpiod_set_value(max16150->clr_gpiod, 1);
> > + input_report_key(max16150->input, max16150-
> >keycode, 1);
> > + input_sync(max16150->input);
>
> Why is press not reported right away?
>
> > + input_report_key(max16150->input, max16150-
> >keycode, 0);
> > + input_sync(max16150->input);
> > + }
> > +
> > + max16150->low = 0;
> > + }
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static const struct max16150_chip_info max16150_variant_a = {
> > + .has_clr_gpio = true,
> > +};
> > +
> > +static const struct max16150_chip_info max16150_variant_b = {
> > + .has_clr_gpio = false,
> > +};
> > +
> > +static int max16150_probe(struct platform_device *pdev) {
> > + const struct max16150_chip_info *chip_info;
> > + struct max16150_device *max16150;
> > + struct device *dev = &pdev->dev;
> > + int err, irq, ret;
>
> Why do you need both err and ret?
>
> > + u32 keycode;
> > +
> > + chip_info = device_get_match_data(dev);
> > + if (!chip_info)
> > + return -EINVAL;
> > +
> > + max16150 = devm_kzalloc(dev, sizeof(*max16150), GFP_KERNEL);
> > + if (!max16150)
> > + return -ENOMEM;
> > +
> > + max16150->chip_info = chip_info;
> > +
> > + max16150->input = devm_input_allocate_device(dev);
> > + if (!max16150->input)
> > + return -ENOMEM;
> > +
> > + max16150->input->name = "MAX16150 Pushbutton";
> > + max16150->input->phys = "max16150/input0";
> > + max16150->input->id.bustype = BUS_HOST;
> > +
> > + keycode = KEY_POWER;
> > + ret = device_property_read_u32(dev, "linux,code", &keycode);
>
> err = ...
>
> > + if (ret)
> > + return dev_err_probe(dev, ret, "Failed to get keycode\n");
> > +
> > + max16150->keycode = keycode;
> > +
> > + input_set_capability(max16150->input, EV_KEY, max16150->keycode);
> > +
> > + max16150->gpiod = devm_gpiod_get(dev, "interrupt", GPIOD_IN);
> > + if (IS_ERR(max16150->gpiod))
> > + return dev_err_probe(dev, PTR_ERR(max16150->gpiod),
> > + "Failed to get interrupt GPIO\n");
> > +
> > + if (chip_info->has_clr_gpio) {
> > + max16150->clr_gpiod = devm_gpiod_get(dev, "clr",
> GPIOD_OUT_HIGH);
> > + if (IS_ERR(max16150->clr_gpiod))
> > + return dev_err_probe(dev, PTR_ERR(max16150-
> >clr_gpiod),
> > + "Failed to get clr GPIO\n");
> > +
> > + if (!max16150->clr_gpiod)
>
>
> How would we end up here? You are using devm_gpiod_get() which will never
> return NULL GPIO descriptor.
>
> > + return dev_err_probe(dev, -ENODEV,
> > + "clr GPIO is mandatory\n");
> > +
> > + if (max16150->clr_gpiod) {
> > + fsleep(1000);
> > + gpiod_set_value(max16150->clr_gpiod, 0);
> > + }
> > + }
> > +
> > + irq = gpiod_to_irq(max16150->gpiod);
> > + if (irq < 0)
> > + return dev_err_probe(dev, irq,
> > + "MAX16150: Failed to map GPIO to IRQ");
>
> As Rob said in DT binding review use interrupts property and separate IRQ and
> GPIO handling.
>
> > +
> > + err = devm_request_irq(dev, irq, max16150_irq_handler,
> > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> > + "max16150_irq", max16150);
> > + if (err)
> > + return err;
> > +
> > + return input_register_device(max16150->input);
>
> err = input_register_device(...);
> if (err)
> return err;
>
> return 0;
>
> > +}
> > +
> > +static const struct of_device_id max16150_of_match[] = {
> > + { .compatible = "adi,max16150a", .data = &max16150_variant_a },
> > + { .compatible = "adi,max16150b", .data = &max16150_variant_b },
> > + { .compatible = "adi,max16169a", .data = &max16150_variant_a },
> > + { .compatible = "adi,max16169b", .data = &max16150_variant_b },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, max16150_of_match);
> > +
> > +static struct platform_driver max16150_driver = {
> > + .probe = max16150_probe,
> > + .driver = {
> > + .name = "max16150",
> > + .of_match_table = max16150_of_match,
> > + },
> > +};
> > +module_platform_driver(max16150_driver);
> > +
> > +MODULE_AUTHOR("Marc Paolo Sosa <marcpaolo.sosa@analog.com>");
> > +MODULE_DESCRIPTION("MAX16150/MAX16169 Pushbutton Driver");
> > +MODULE_LICENSE("GPL");
>
Thank you for the initial review, I'll test the ff suggestions above and apply it to V2, for summary,
1. Switch from nanoseconds to jiffies with single press_time variable and
time_after() for comparison
2. Remove redundant err/ret variables and use consistent naming
3. Remove impossible NULL checks after devm_gpiod_get() since it never returns NULL
4. Fix device_property_read_u32() error handling since linux,code is optional with
default
5. Use explicit error checking pattern instead of implicit return
6. The MAX16150's OUT pin serves dual purposes (interrupt + GPIO state reading) -
should I use separate 'interrupts' and 'out-gpios' properties for the same physical pin, or is there a
preferred approach for this hardware design?
7. The duration measurement is needed since the device ignores short presses, but I could
report press immediately and validate on release instead
I'll send v2 with these improvements once I clarify the preferred IRQ/GPIO handling approach.
Best regards,
Pao
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: input: add adi,max16150.yaml
From: Sosa, Marc Paolo @ 2026-03-17 1:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <c2985ac9-1917-4044-a896-8e701a3046af@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Tuesday, February 24, 2026 1:02 AM
> To: Sosa, Marc Paolo <MarcPaolo.Sosa@analog.com>; Dmitry Torokhov
> <dmitry.torokhov@gmail.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>
> Cc: linux-input@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] dt-bindings: input: add adi,max16150.yaml
>
> [External]
>
> On 23/02/2026 12:03, Marc Paolo Sosa via B4 Relay wrote:
> > +
> > +properties:
> > + compatible:
> > + description:
> > + Specifies the supported device variants. The MAX16150 and MAX16169
> are supported.
> > + enum:
> > + - adi,max16150a
> > + - adi,max16150b
> > + - adi,max16169a
> > + - adi,max16169b
>
> Your driver code says 16150 and 16169 are compatible, to express it with
> fallback (oneOf). See example-schema.
>
This is noted; I will apply this on my next patch.
Thanks,
Pao
^ permalink raw reply
* Re: [External] : [PATCH] Input: sentelic: fix comment typo
From: Joseph Salisbury @ 2026-03-16 23:48 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260316181200.146681-1-joseph.salisbury@oracle.com>
On 3/16/26 2:12 PM, Joseph Salisbury wrote:
> The file contains a spelling error in a source comment (formating).
>
> Typos in comments reduce readability and make text searches less reliable
> for developers and maintainers.
>
> Replace 'formating' with 'formatting' in the affected comment. This is a
> comment-only cleanup and does not change behavior.
>
> Fixes: fc69f4a6af49 ("Input: add new driver for Sentelic Finger Sensing Pad")
> Cc: stable@vger.kernel.org
> Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
> ---
> drivers/input/mouse/sentelic.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/sentelic.h b/drivers/input/mouse/sentelic.h
> index 02cac0e7ad63..9ba3631e3d0f 100644
> --- a/drivers/input/mouse/sentelic.h
> +++ b/drivers/input/mouse/sentelic.h
> @@ -60,7 +60,7 @@
> #define FSP_REG_SN1 (0x41)
> #define FSP_REG_SN2 (0x42)
>
> -/* Finger-sensing Pad packet formating related definitions */
> +/* Finger-sensing Pad packet formatting related definitions */
>
> /* absolute packet type */
> #define FSP_PKT_TYPE_NORMAL (0x00)
I inadvertently added Fixes: and Cc: stable tags. If possible, please
remove them as they are not appropriate for fixes to misspellings in
code comments. If it's not possible to remove them, I can send a v2.
^ permalink raw reply
* Re: [PATCH 46/61] vfio: Prefer IS_ERR_OR_NULL over manual NULL check
From: Alex Williamson @ 2026-03-16 22:10 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, alex
In-Reply-To: <20260310-b4-is_err_or_null-v1-46-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:49:12 +0100
Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Alex Williamson <alex@shazbot.org>
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/vfio/vfio_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 742477546b15d4dbaf9ebcfb2e67627db71521e0..d71922dfde5885967398deddec3e9e04b05adfec 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -923,7 +923,7 @@ vfio_ioctl_device_feature_mig_device_state(struct vfio_device *device,
>
> /* Handle the VFIO_DEVICE_FEATURE_SET */
> filp = device->mig_ops->migration_set_state(device, mig.device_state);
> - if (IS_ERR(filp) || !filp)
> + if (IS_ERR_OR_NULL(filp))
> goto out_copy;
>
> return vfio_ioct_mig_return_fd(filp, arg, &mig);
>
As others have expressed in general, this doesn't seem to be cleaner
and tends to mask that we consider IS_ERR() and NULL as separate cases
in the goto. This code looks like it could use some refactoring, and
likely that refactoring should handle the IS_ERR() and NULL cases
separately, but conflating them here is not an improvement. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2 1/2] iio: add IIO_DECLARE_QUATERNION() macro
From: David Lechner @ 2026-03-16 19:56 UTC (permalink / raw)
To: Francesco Lavra
Cc: linux-iio, linux-kernel, Jonathan Cameron, linux-input,
Jonathan Cameron, Nuno Sá, Andy Shevchenko, Jiri Kosina,
Srinivas Pandruvada
In-Reply-To: <0b9ac137f52c2c279e07b2d1d8f7379ca9631cef.camel@baylibre.com>
On 3/16/26 2:03 PM, Francesco Lavra wrote:
> On Sat, 2026-03-07 at 18:35 -0600, David Lechner wrote:
>> On 2/28/26 2:02 PM, David Lechner wrote:
>>> Add a new IIO_DECLARE_QUATERNION() macro that is used to declare the
>>> field in an IIO buffer struct that contains a quaternion vector.
>>>
>>> Quaternions are currently the only IIO data type that uses the .repeat
>>> feature of struct iio_scan_type. This has an implicit rule that the
>>> element in the buffer must be aligned to the entire size of the
>>> repeated
>>> element. This macro will make that requirement explicit. Since this is
>>> the only user, we just call the macro IIO_DECLARE_QUATERNION() instead
>>> of something more generic.
>
> ...
>
>
>> Hi Francesco,
>>
>> I should have cc'ed you on this one. We'll want to add another macro
>> like this for IIO_DECLARE_QUATERNION_AXIS(), I imagine. (This has been
>> applied to the fixes-togreg branch since it is a dependency to a fix.)
>>
>> What to do on that for the alignment though is an open question since
>> we've never had a repeat of 3 before. The question is if it is OK to
>> have an alignment that isn't a power of two bytes. For your case, since
>> the data is 3 x 16-bit, it would be 3 * 2 = 6 bytes.
>
> Hi David. Differently from the hid-sensor driver (where the `scan` field in
> struct dev_rot_state is used exclusively for quaternion data), the lsm6dsx
> driver uses a data structure (see the `iio_buff` variable in
> st_lsm6dsx_buffer.c:st_lsm6dsx_read_tagged_fifo()) that is shared between
> all the different data types that can be read from the hardware FIFO
> (accel, gyro, quaternion, external sensor data), so changing this structure
> to a quaternion-specific type is not ideal. So I think for the time being
> there wouldn't be any users of an IIO_DECLARE_QUATERNION_AXIS() macro.
Makes sense.
>
> As for the alignment, according to your patch at [1], when the repeat
> number is not a power of two, it is (will be) rounded up to the next power
> of two (and this is consistent with what the lsm6dsx driver expects), so
> the alignment will be 8 bytes.
I think you are referring to the 8-byte alignment for the timestamp?
Patch [1] should make a difference when the timestamp is not enabled
in a buffered read though.
When the timestamp is enabled, the buffer is going to be 16 bytes per
sample no matter what because of the 8-byte alignment of the timestamp.
But if the timestamp is not enabled, then for 16-bit storagebits and
repeat of 3, before the patch, the buffer would only be 6 bytes per
sample, but after the patch would be 8 bytes per sample. This doesn't
make a difference in the driver itself, but does make a difference to
userspace that is reading the buffer.
>
> [1]
> https://lore.kernel.org/linux-iio/20260307-iio-fix-timestamp-alignment-v2-4-d1d48fbadbbf@baylibre.com/
^ permalink raw reply
* Re: [PATCH v2 1/2] iio: add IIO_DECLARE_QUATERNION() macro
From: Francesco Lavra @ 2026-03-16 19:03 UTC (permalink / raw)
To: David Lechner
Cc: linux-iio, linux-kernel, Jonathan Cameron, linux-input,
Jonathan Cameron, Nuno Sá, Andy Shevchenko, Jiri Kosina,
Srinivas Pandruvada
In-Reply-To: <7f000ea5-1a41-4da8-aad5-04aa875fa4bc@baylibre.com>
On Sat, 2026-03-07 at 18:35 -0600, David Lechner wrote:
> On 2/28/26 2:02 PM, David Lechner wrote:
> > Add a new IIO_DECLARE_QUATERNION() macro that is used to declare the
> > field in an IIO buffer struct that contains a quaternion vector.
> >
> > Quaternions are currently the only IIO data type that uses the .repeat
> > feature of struct iio_scan_type. This has an implicit rule that the
> > element in the buffer must be aligned to the entire size of the
> > repeated
> > element. This macro will make that requirement explicit. Since this is
> > the only user, we just call the macro IIO_DECLARE_QUATERNION() instead
> > of something more generic.
...
> Hi Francesco,
>
> I should have cc'ed you on this one. We'll want to add another macro
> like this for IIO_DECLARE_QUATERNION_AXIS(), I imagine. (This has been
> applied to the fixes-togreg branch since it is a dependency to a fix.)
>
> What to do on that for the alignment though is an open question since
> we've never had a repeat of 3 before. The question is if it is OK to
> have an alignment that isn't a power of two bytes. For your case, since
> the data is 3 x 16-bit, it would be 3 * 2 = 6 bytes.
Hi David. Differently from the hid-sensor driver (where the `scan` field in
struct dev_rot_state is used exclusively for quaternion data), the lsm6dsx
driver uses a data structure (see the `iio_buff` variable in
st_lsm6dsx_buffer.c:st_lsm6dsx_read_tagged_fifo()) that is shared between
all the different data types that can be read from the hardware FIFO
(accel, gyro, quaternion, external sensor data), so changing this structure
to a quaternion-specific type is not ideal. So I think for the time being
there wouldn't be any users of an IIO_DECLARE_QUATERNION_AXIS() macro.
As for the alignment, according to your patch at [1], when the repeat
number is not a power of two, it is (will be) rounded up to the next power
of two (and this is consistent with what the lsm6dsx driver expects), so
the alignment will be 8 bytes.
[1]
https://lore.kernel.org/linux-iio/20260307-iio-fix-timestamp-alignment-v2-4-d1d48fbadbbf@baylibre.com/
^ permalink raw reply
* [PATCH] dt-bindings: input: touchscreen: Convert TS-4800 to DT schema
From: Eduard Bostina @ 2026-03-16 18:10 UTC (permalink / raw)
To: daniel.baluta, simona.toaca, egbostina, d-gole, m-chawdhry,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mark Brown, linux-input, devicetree, linux-kernel
Convert the TS-4800 touchscreen bindings to DT schema.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
Note:
* This patch is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../touchscreen/technologic,ts4800-ts.yaml | 42 +++++++++++++++++++
.../bindings/input/touchscreen/ts4800-ts.txt | 11 -----
2 files changed, 42 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/technologic,ts4800-ts.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/technologic,ts4800-ts.yaml b/Documentation/devicetree/bindings/input/touchscreen/technologic,ts4800-ts.yaml
new file mode 100644
index 000000000..c033774b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/technologic,ts4800-ts.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/technologic,ts4800-ts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TS-4800 Touchscreen
+
+maintainers:
+ - Eduard Bostina <egbostina@gmail.com>
+
+properties:
+ compatible:
+ const: technologic,ts4800-ts
+
+ reg:
+ maxItems: 1
+
+ syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: Phandle to the FPGA's syscon
+ - description: Offset to the touchscreen register
+ - description: Offset to the touchscreen enable bit
+ description: Phandle / integers array that points to the syscon node which
+ describes the FPGA's syscon registers.
+
+required:
+ - compatible
+ - reg
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ touchscreen@1000 {
+ compatible = "technologic,ts4800-ts";
+ reg = <0x1000 0x100>;
+ syscon = <&fpga_syscon 0x20 3>;
+ };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt
deleted file mode 100644
index 4c1c092c2..000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-* TS-4800 Touchscreen bindings
-
-Required properties:
-- compatible: must be "technologic,ts4800-ts"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- syscon: phandle / integers array that points to the syscon node which
- describes the FPGA's syscon registers.
- - phandle to FPGA's syscon
- - offset to the touchscreen register
- - offset to the touchscreen enable bit
--
2.43.0
^ permalink raw reply related
* [PATCH] Input: sentelic: fix comment typo
From: Joseph Salisbury @ 2026-03-16 18:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
The file contains a spelling error in a source comment (formating).
Typos in comments reduce readability and make text searches less reliable
for developers and maintainers.
Replace 'formating' with 'formatting' in the affected comment. This is a
comment-only cleanup and does not change behavior.
Fixes: fc69f4a6af49 ("Input: add new driver for Sentelic Finger Sensing Pad")
Cc: stable@vger.kernel.org
Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
---
drivers/input/mouse/sentelic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/sentelic.h b/drivers/input/mouse/sentelic.h
index 02cac0e7ad63..9ba3631e3d0f 100644
--- a/drivers/input/mouse/sentelic.h
+++ b/drivers/input/mouse/sentelic.h
@@ -60,7 +60,7 @@
#define FSP_REG_SN1 (0x41)
#define FSP_REG_SN2 (0x42)
-/* Finger-sensing Pad packet formating related definitions */
+/* Finger-sensing Pad packet formatting related definitions */
/* absolute packet type */
#define FSP_PKT_TYPE_NORMAL (0x00)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
From: Krzysztof Kozlowski @ 2026-03-16 17:10 UTC (permalink / raw)
To: Conor Dooley, phucduc.bui
Cc: robh, conor+dt, devicetree, dmitry.torokhov, krzk+dt, linux-input,
linux-kernel, marex, mingo, tglx
In-Reply-To: <20260316-refusal-disband-54161c7b96e0@spud>
On 16/03/2026 12:13, Conor Dooley wrote:
> On Mon, Mar 16, 2026 at 10:46:06AM +0700, phucduc.bui@gmail.com wrote:
>> From: bui duc phuc <phucduc.bui@gmail.com>
>>
>> Document the "wakeup-source" property for the ti,tsc2005 touchscreen
>> controllers to allow the device to wake the system from suspend.
>>
>> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
>> ---
>> .../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
>> index 7187c390b2f5..c0aae044d7d4 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
>> @@ -55,6 +55,9 @@ properties:
>> touchscreen-size-x: true
>> touchscreen-size-y: true
>>
>> + wakeup-source:
>> + type: boolean
>
> wakeup-source: true
I am not so sure.
The property is multi-type, so we want to choose one - bool, IMO,
because device cannot wakeup the specific system idle states. Or am I
misinterpreting the phandles behind wakeup-source and every device can
be differently routed in such system?
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH 1/1] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure
From: Benjamin Tissoires @ 2026-03-16 15:59 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera, Jiri Kosina, linux-input,
linux-kernel, Lee Jones
In-Reply-To: <20260227100939.961011-1-lee@kernel.org>
On Fri, 27 Feb 2026 10:09:38 +0000, Lee Jones wrote:
> Presently, if the force feedback initialisation fails when probing the
> Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
> will be returned and propagated before the userspace infrastructure
> (sysfs and /dev/input) has been torn down. If userspace ignores the
> errors and continues to use its references to these dangling entities, a
> UAF will promptly follow.
>
> [...]
Applied, thanks!
[1/1] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure
commit: f7a4c78bfeb320299c1b641500fe7761eadbd101
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ 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