* 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
* Re: (subset) [PATCH 0/4] HID: bpf fixes for 7.0/7.1
From: Benjamin Tissoires @ 2026-03-16 15:59 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan, Benjamin Tissoires
Cc: linux-input, linux-kselftest, linux-kernel, kernel test robot,
stable
In-Reply-To: <20260313-wip-bpf-fixes-v1-0-74b860315060@kernel.org>
On Fri, 13 Mar 2026 08:40:23 +0100, Benjamin Tissoires wrote:
> This is a series that targets a few HID-BPF issues I discovered or I've
> been reported:
> - first 2 patches should go to for-7.0/upstream-fixes:
> - 1/4 fixes a compilation issue when HID is not enabled
> - 2/4 is a nasty bug which allows a HID-BPF to crash the running
> kernel, so not critical (you need special permissions to load the
> HID-BPF program), but not great as you don't expect tinkering with
> HID-BPF would crash
> - last 2 patches are more 7.1 material: basically the LEDs on the
> keyboards are bypassing HID-BPF, and then that made me realize that
> the fallback calls in case of an unnumbered report is not correct (and
> likely unnoticed because I don't think I've seen unnumbered reports on
> anything else than USB devices)
>
> [...]
Applied, thanks!
[1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported
commit: 5d4c6c132ea9a967d48890dd03e6a786c060e968
[2/4] HID: bpf: prevent buffer overflow in hid_hw_request
commit: 2b658c1c442ec1cd9eec5ead98d68662c40fe645
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: (subset) [RFC v3 1/2] HID: core: Mitigate potential OOB by removing bogus memset()
From: Benjamin Tissoires @ 2026-03-16 15:59 UTC (permalink / raw)
To: Jiri Kosina, linux-input, linux-kernel, Lee Jones
In-Reply-To: <20260309145942.1496072-1-lee@kernel.org>
On Mon, 09 Mar 2026 14:59:29 +0000, Lee Jones wrote:
> The memset() in hid_report_raw_event() has the good intention of
> clearing out bogus data by zeroing the area from the end of the incoming
> data string to the assumed end of the buffer. However, as we have
> previously seen, doing so can easily result in OOB reads and writes in
> the subsequent thread of execution.
>
> The current suggestion from one of the HID maintainers is to remove the
> memset() and simply return if the incoming event buffer size is not
> large enough to fill the associated report.
>
> [...]
Applied, thanks!
[1/2] HID: core: Mitigate potential OOB by removing bogus memset()
commit: 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/1] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure
From: Benjamin Tissoires @ 2026-03-16 15:30 UTC (permalink / raw)
To: Lee Jones
Cc: Günther Noack, Filipe Laíns, Bastien Nocera,
Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260316151144.GB554736@google.com>
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.
Cheers,
Benjamin
>
> --
> Lee Jones [李琼斯]
>
^ permalink raw reply
* Re: [RFC v3 2/2] HID: core: Check to ensure report responses match the request
From: Benjamin Tissoires @ 2026-03-16 15:28 UTC (permalink / raw)
To: Lee Jones; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260309145942.1496072-2-lee@kernel.org>
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.
Cheers,
Benjamin
>
> drivers/hid/hid-core.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index da9231ca42bc..da4078554331 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2490,8 +2490,17 @@ int __hid_hw_raw_request(struct hid_device *hdev,
> if (ret)
> return ret;
>
> - return hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
> - rtype, reqtype);
> + ret = hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
> + rtype, reqtype);
> + if (ret)
> + return ret;
> +
> + if (reportnum != buf[0]) {
> + hid_err(hdev, "Returned feature report did not match the request\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> }
>
> /**
> --
> 2.53.0.473.g4a7958ca14-goog
>
>
^ permalink raw reply
* Re: [RFC v3 1/2] HID: core: Mitigate potential OOB by removing bogus memset()
From: Benjamin Tissoires @ 2026-03-16 15:26 UTC (permalink / raw)
To: Lee Jones; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <20260309145942.1496072-1-lee@kernel.org>
On Mar 09 2026, Lee Jones wrote:
> The memset() in hid_report_raw_event() has the good intention of
> clearing out bogus data by zeroing the area from the end of the incoming
> data string to the assumed end of the buffer. However, as we have
> previously seen, doing so can easily result in OOB reads and writes in
> the subsequent thread of execution.
>
> The current suggestion from one of the HID maintainers is to remove the
> memset() and simply return if the incoming event buffer size is not
> large enough to fill the associated report.
>
> Suggested-by Benjamin Tissoires <bentiss@kernel.org>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v2 -> v3: Instead of removing the check entirely, show a warning and return early
>
> RFC query: Is it better to return SUCCESS or -EINVAL?
I'd say -EINVAL is better.
Also, one brain fart I had today was that this works in 99% of the cases
because the transport layer allocates a big enough buffer.
So that means that if this function, and hid_input_report() both have
the allocated size as parameter, we could make a smarter decision and
do the memset when we have enough space.
This would require an API change, and probably to keep things under
control adding a new API with the buffer_allocated_size that would be
used by uhid, usbhid, i2c-hid, and others when we can.
But let's go with the current state of the patch, and say sorry if we
break some devices later on. (patch is currently in my queue, no need to
resend it).
Cheers,
Benjamin
>
> drivers/hid/hid-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index a5b3a8ca2fcb..da9231ca42bc 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2057,9 +2057,9 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
> rsize = max_buffer_size;
>
> if (csize < rsize) {
> - dbg_hid("report %d is too short, (%d < %d)\n", report->id,
> - csize, rsize);
> - memset(cdata + csize, 0, rsize - csize);
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
> + report->id, rsize, csize);
> + goto out;
> }
>
> if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
> --
> 2.53.0.473.g4a7958ca14-goog
>
>
^ permalink raw reply
* Re: [RFC v3 1/2] HID: core: Mitigate potential OOB by removing bogus memset()
From: Lee Jones @ 2026-03-16 15:14 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260309145942.1496072-1-lee@kernel.org>
On Mon, 09 Mar 2026, Lee Jones wrote:
> The memset() in hid_report_raw_event() has the good intention of
> clearing out bogus data by zeroing the area from the end of the incoming
> data string to the assumed end of the buffer. However, as we have
> previously seen, doing so can easily result in OOB reads and writes in
> the subsequent thread of execution.
>
> The current suggestion from one of the HID maintainers is to remove the
> memset() and simply return if the incoming event buffer size is not
> large enough to fill the associated report.
>
> Suggested-by Benjamin Tissoires <bentiss@kernel.org>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v2 -> v3: Instead of removing the check entirely, show a warning and return early
>
> RFC query: Is it better to return SUCCESS or -EINVAL?
>
> drivers/hid/hid-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index a5b3a8ca2fcb..da9231ca42bc 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2057,9 +2057,9 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
> rsize = max_buffer_size;
>
> if (csize < rsize) {
> - dbg_hid("report %d is too short, (%d < %d)\n", report->id,
> - csize, rsize);
> - memset(cdata + csize, 0, rsize - csize);
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
> + report->id, rsize, csize);
> + goto out;
> }
>
> if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
Same here. Are these still in your queue or would you like me to [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-16 15:11 UTC (permalink / raw)
To: Günther Noack
Cc: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <aaareetB3Hhd6xgI@google.com>
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?
I'm happy to submit a [RESEND] if that's required to get this back into view.
--
Lee Jones [李琼斯]
^ 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