* [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Luca Leonardo Scorcia @ 2026-04-20 21:30 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Louis-Alexis Eyraud,
Gary Bisson, Val Packett, Julien Massot, Fabien Parent,
Akari Tsuyukusa, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-1-l.scorcia@gmail.com>
Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
the already supported MT6397.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../pinctrl/mediatek,mt65xx-pinctrl.yaml | 1 +
.../pinctrl/mediatek,mt6392-pinfunc.h | 39 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
index aa71398cf522..1468c6f87cfa 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
@@ -17,6 +17,7 @@ properties:
enum:
- mediatek,mt2701-pinctrl
- mediatek,mt2712-pinctrl
+ - mediatek,mt6392-pinctrl
- mediatek,mt6397-pinctrl
- mediatek,mt7623-pinctrl
- mediatek,mt8127-pinctrl
diff --git a/include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h b/include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
new file mode 100644
index 000000000000..c65278c8103d
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+#ifndef __DTS_MT6392_PINFUNC_H
+#define __DTS_MT6392_PINFUNC_H
+
+#include <dt-bindings/pinctrl/mt65xx.h>
+
+#define MT6392_PIN_0_INT__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT6392_PIN_0_INT__FUNC_INT (MTK_PIN_NO(0) | 1)
+#define MT6392_PIN_0_INT__FUNC_TEST_CK2 (MTK_PIN_NO(0) | 5)
+#define MT6392_PIN_0_INT__FUNC_TEST_IN1 (MTK_PIN_NO(0) | 6)
+#define MT6392_PIN_0_INT__FUNC_TEST_OUT1 (MTK_PIN_NO(0) | 7)
+
+#define MT6392_PIN_1_SRCLKEN__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT6392_PIN_1_SRCLKEN__FUNC_SRCLKEN (MTK_PIN_NO(1) | 1)
+#define MT6392_PIN_1_SRCLKEN__FUNC_TEST_CK0 (MTK_PIN_NO(1) | 5)
+#define MT6392_PIN_1_SRCLKEN__FUNC_TEST_IN2 (MTK_PIN_NO(1) | 6)
+#define MT6392_PIN_1_SRCLKEN__FUNC_TEST_OUT2 (MTK_PIN_NO(1) | 7)
+
+#define MT6392_PIN_2_RTC_32K1V8__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT6392_PIN_2_RTC_32K1V8__FUNC_RTC_32K1V8 (MTK_PIN_NO(2) | 1)
+#define MT6392_PIN_2_RTC_32K1V8__FUNC_TEST_CK1 (MTK_PIN_NO(2) | 5)
+#define MT6392_PIN_2_RTC_32K1V8__FUNC_TEST_IN3 (MTK_PIN_NO(2) | 6)
+#define MT6392_PIN_2_RTC_32K1V8__FUNC_TEST_OUT3 (MTK_PIN_NO(2) | 7)
+
+#define MT6392_PIN_3_SPI_CLK__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT6392_PIN_3_SPI_CLK__FUNC_SPI_CLK (MTK_PIN_NO(3) | 1)
+
+#define MT6392_PIN_4_SPI_CSN__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT6392_PIN_4_SPI_CSN__FUNC_SPI_CSN (MTK_PIN_NO(4) | 1)
+
+#define MT6392_PIN_5_SPI_MOSI__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT6392_PIN_5_SPI_MOSI__FUNC_SPI_MOSI (MTK_PIN_NO(5) | 1)
+
+#define MT6392_PIN_6_SPI_MISO__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT6392_PIN_6_SPI_MISO__FUNC_SPI_MISO (MTK_PIN_NO(6) | 1)
+#define MT6392_PIN_6_SPI_MISO__FUNC_TEST_IN4 (MTK_PIN_NO(6) | 6)
+#define MT6392_PIN_6_SPI_MISO__FUNC_TEST_OUT4 (MTK_PIN_NO(6) | 7)
+
+#endif /* __DTS_MT6392_PINFUNC_H */
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-04-20 21:30 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Val Packett, Julien Massot,
Gary Bisson, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260420213529.1645560-1-l.scorcia@gmail.com>
Add bindings for the regulators found in the MediaTek MT6392 PMIC,
usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../regulator/mediatek,mt6392-regulator.yaml | 76 +++++++++++++++++++
.../regulator/mediatek,mt6392-regulator.h | 24 ++++++
2 files changed, 100 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
new file mode 100644
index 000000000000..f62bd94bd42c
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6392 regulator
+
+maintainers:
+ - Luca Leonardo Scorcia <l.scorcia@gmail.com>
+
+description:
+ MT6392 is a power management system chip containing three buck converters and
+ 23 LDOs. All voltage regulators provided by the PMIC are described as
+ sub-nodes of this node.
+
+properties:
+ vproc-supply:
+ description: Supply for buck regulator vproc
+ vcore-supply:
+ description: Supply for buck regulator vcore
+ vsys-supply:
+ description: Supply for buck regulator vsys
+ avddldo-supply:
+ description: |
+ Supply for AVDD LDOs (vm, vio18, vcn18, vcamd, vcamio). According to the data sheet
+ this is an internal supply derived from vsys.
+ ldo1-supply:
+ description: Supply for LDOs group 1 (vaud28, vxo22, vaud22, vadc18, vcama, vrtc)
+ ldo2-supply:
+ description: Supply for LDOs group 2 (vcn35, vio28, vmc, vmch, vefuse, vdig18)
+ ldo3-supply:
+ description: Supply for LDOs group 3 (vusb, vemc3v3, vcamaf, vgp1, vgp2, vm25)
+
+patternProperties:
+ "^v(core|proc|sys)$":
+ description: Buck regulators
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes:
+ description: |
+ BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
+ values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
+ items:
+ enum: [0, 1]
+ unevaluatedProperties: false
+
+ "^v(adc18|camio|cn18|io18|xo22|m25|aud28|io28|rtc|usb)$":
+ description: LDOs with fixed output and mode setting
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes:
+ description: |
+ LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
+ values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
+ items:
+ enum: [0, 1]
+ unevaluatedProperties: false
+
+ "^v(cama|dig18)$":
+ description: LDOs with fixed output without mode setting
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ "^v(aud22|camaf|camd|cn35|efuse|emc3v3|gp1|gp2|m|mc|mch)$":
+ description: LDOs with adjustable output
+ type: object
+ $ref: regulator.yaml#
+ properties:
+ regulator-allowed-modes: false
+ unevaluatedProperties: false
+
+additionalProperties: false
diff --git a/include/dt-bindings/regulator/mediatek,mt6392-regulator.h b/include/dt-bindings/regulator/mediatek,mt6392-regulator.h
new file mode 100644
index 000000000000..8bd1a13faad8
--- /dev/null
+++ b/include/dt-bindings/regulator/mediatek,mt6392-regulator.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_REGULATOR_MEDIATEK_MT6392_H_
+#define _DT_BINDINGS_REGULATOR_MEDIATEK_MT6392_H_
+
+/*
+ * Buck mode constants which may be used in devicetree properties (eg.
+ * regulator-initial-mode, regulator-allowed-modes).
+ * See the manufacturer's datasheet for more information on these modes.
+ */
+
+#define MT6392_BUCK_MODE_AUTO 0
+#define MT6392_BUCK_MODE_FORCE_PWM 1
+
+/*
+ * LDO mode constants which may be used in devicetree properties (eg.
+ * regulator-initial-mode, regulator-allowed-modes).
+ * See the manufacturer's datasheet for more information on these modes.
+ */
+
+#define MT6392_LDO_MODE_NORMAL 0
+#define MT6392_LDO_MODE_LP 1
+
+#endif
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/9] dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
From: Luca Leonardo Scorcia @ 2026-04-20 21:30 UTC (permalink / raw)
To: linux-mediatek
Cc: Fabien Parent, Val Packett, Luca Leonardo Scorcia,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Gary Bisson, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-1-l.scorcia@gmail.com>
From: Fabien Parent <parent.f@gmail.com>
Add the binding documentation of mtk-pmic-keys for the MT6392 PMIC.
Signed-off-by: Fabien Parent <parent.f@gmail.com>
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
index b95435bd6a9b..2d3c4161a7f8 100644
--- a/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
+++ b/Documentation/devicetree/bindings/input/mediatek,pmic-keys.yaml
@@ -30,6 +30,7 @@ properties:
- mediatek,mt6357-keys
- mediatek,mt6358-keys
- mediatek,mt6359-keys
+ - mediatek,mt6392-keys
- mediatek,mt6397-keys
power-off-time-sec: true
--
2.43.0
^ permalink raw reply related
* [PATCH v5 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-04-20 21:30 UTC (permalink / raw)
To: linux-mediatek
Cc: Fabien Parent, Val Packett, Luca Leonardo Scorcia,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Julien Massot, Louis-Alexis Eyraud,
Akari Tsuyukusa, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-1-l.scorcia@gmail.com>
From: Fabien Parent <parent.f@gmail.com>
Add the currently supported bindings for the MT6392 PMIC. Its MFD driver
does not use the compatible property to bind the regulator driver, so
don't mark it as required.
Signed-off-by: Fabien Parent <parent.f@gmail.com>
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../bindings/mfd/mediatek,mt6397.yaml | 27 ++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..2866e95e338b 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -40,6 +40,10 @@ properties:
- mediatek,mt6358
- mediatek,mt6359
- mediatek,mt6397
+ - items:
+ - enum:
+ - mediatek,mt6392
+ - const: mediatek,mt6323
- items:
- enum:
- mediatek,mt6366
@@ -68,6 +72,10 @@ properties:
- mediatek,mt6331-rtc
- mediatek,mt6358-rtc
- mediatek,mt6397-rtc
+ - items:
+ - enum:
+ - mediatek,mt6392-rtc
+ - const: mediatek,mt6323-rtc
- items:
- enum:
- mediatek,mt6366-rtc
@@ -99,9 +107,6 @@ properties:
- mediatek,mt6366-regulator
- const: mediatek,mt6358-regulator
- required:
- - compatible
-
adc:
type: object
$ref: /schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
@@ -231,6 +236,22 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt6392
+ then:
+ properties:
+ regulators:
+ $ref: /schemas/regulator/mediatek,mt6392-regulator.yaml
+ else:
+ properties:
+ regulators:
+ required:
+ - compatible
+
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
--
2.43.0
^ permalink raw reply related
* [PATCH v5 0/9] Add support for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-04-20 21:29 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Julien Massot, Val Packett, Gary Bisson,
Louis-Alexis Eyraud, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
The MediaTek MT6392 PMIC is usually found on devices powered by
the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
This series is mostly based around patches submitted a couple
years ago by Fabien Parent and not merged and from Val Packett's
submission from Jan 2025 that included extra cleanups, fixes, and a
new dtsi file similar to ones that exist for other PMICs. Some
comments weren't addressed and the series was ultimately not merged.
This series only enables four functions: regulators, keys, pinctrl
and RTC.
I added a handful of device tree improvements to fix some dtbs_check
errors, added support for the pinctrl device and addressed the comments
from last year's reviews.
The series has been tested on Xiaomi Mi Smart Clock X04G.
Changes in v5:
- Double checked regulator driver with data sheet and Android sources.
The data sheet I have misses a lot of register descriptions, but
Android sources have been helpful to fill the gaps
- Reintroduced the required attribute for the regulator compatible
in the bindings
- Fixed the missing reference to the MT6392 schema
- Fixed casts/unused vars reported by kernel test robot
- Removed Reviewed-by tags from the regulator patches as they have been
modified in this version
Changes in v4 [4]:
- Dropped usage of the regulator compatible
- Fixed commit messages text to properly reference the target subsystem
- Added supply rails to the regulator
- Reworked the regulator schema and PMIC dtsi. Now all supplies are
documented and the schema no longer includes voltage information
- Removed redundant ldo- / buck- prefixes
- Renamed the pinfunc header to mediatek,mt6392-pinfunc.h
- Modified the MFD driver to use a simple identifier in the of_match
data properties
Changes in v3 [3]:
- Added pinctrl device
- Changed mt6397-rtc fallback to mt6323-rtc
- Added schema for regulators
- Fixed checkpatch issues
Changes in v2 [2]:
- Replaced explicit compatibles with fallbacks
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/cover.1771865014.git.l.scorcia@gmail.com/
[2] https://lore.kernel.org/linux-mediatek/20260306120521.163654-1-l.scorcia@gmail.com/
[3] https://lore.kernel.org/linux-mediatek/20260317184507.523060-1-l.scorcia@gmail.com/
[4] https://lore.kernel.org/linux-mediatek/20260330083429.359819-1-l.scorcia@gmail.com/
Fabien Parent (4):
dt-bindings: mfd: mt6397: Add MT6392 PMIC
dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
mfd: mt6397: Add support for MT6392 PMIC
regulator: Add MediaTek MT6392 regulator
Luca Leonardo Scorcia (3):
regulator: dt-bindings: Add MediaTek MT6392 PMIC
dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
pinctrl: mediatek: mt6397: Add MediaTek MT6392
Val Packett (2):
input: keyboard: mtk-pmic-keys: Add MT6392 support
arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
.../bindings/input/mediatek,pmic-keys.yaml | 1 +
.../bindings/mfd/mediatek,mt6397.yaml | 27 +-
.../pinctrl/mediatek,mt65xx-pinctrl.yaml | 1 +
.../regulator/mediatek,mt6392-regulator.yaml | 76 ++
arch/arm64/boot/dts/mediatek/mt6392.dtsi | 73 ++
drivers/input/keyboard/mtk-pmic-keys.c | 17 +
drivers/mfd/mt6397-core.c | 118 ++-
drivers/mfd/mt6397-irq.c | 8 +
drivers/pinctrl/mediatek/pinctrl-mt6397.c | 37 +-
drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h | 64 ++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6392-regulator.c | 740 ++++++++++++++++++
.../pinctrl/mediatek,mt6392-pinfunc.h | 39 +
.../regulator/mediatek,mt6392-regulator.h | 24 +
include/linux/mfd/mt6392/core.h | 42 +
include/linux/mfd/mt6392/registers.h | 487 ++++++++++++
include/linux/mfd/mt6397/core.h | 1 +
include/linux/regulator/mt6392-regulator.h | 42 +
19 files changed, 1776 insertions(+), 31 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
create mode 100644 drivers/regulator/mt6392-regulator.c
create mode 100644 include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
create mode 100644 include/linux/mfd/mt6392/core.h
create mode 100644 include/linux/mfd/mt6392/registers.h
create mode 100644 include/linux/regulator/mt6392-regulator.h
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: ads7846 - fix up the pendown GPIO setup on Nokia 770
From: Aaro Koskinen @ 2026-04-20 19:43 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Oleksij Rempel, Janusz Krzysztofik, Tony Lindgren, Linus Walleij,
linux-input, linux-kernel, linux-omap
In-Reply-To: <aeVs2VUqPL1v0Vka@google.com>
Hi,
On Sun, Apr 19, 2026 at 05:06:53PM -0700, Dmitry Torokhov wrote:
> > - d = gpiod_get(NULL, "ads7846_irq", GPIOD_IN);
> > - if (IS_ERR(d))
> > - pr_err("Unable to get ADS7846 IRQ GPIO descriptor\n");
> > - else
> > - nokia770_spi_board_info[1].irq = gpiod_to_irq(d);
>
> No, I think what we need here is a simple gpiod_put(). The mapping is
> not going to change unless someone tries to unload gpiochip, but then
> the device is not going to work anyway.
OK, I will do that in v3. I tried unbind/re-bind the gpiochip before
loading the touchscreen module and yes, it seems to fail in consistent
manner without suprises (e.g. no crash, just probe failing).
A.
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: ads7846 - restore half-duplex support
From: Aaro Koskinen @ 2026-04-20 19:32 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Oleksij Rempel, Janusz Krzysztofik, Tony Lindgren, Linus Walleij,
linux-input, linux-kernel, linux-omap
In-Reply-To: <aeVu2-zlzl-fn1dN@google.com>
Hi,
On Sun, Apr 19, 2026 at 05:13:56PM -0700, Dmitry Torokhov wrote:
> > +static void ads7846_halfd_read_state(struct ads7846 *ts)
> > +{
> > + struct ads7846_packet *packet = ts->packet;
> > + int msg_idx = 0;
> > +
> > + packet->ignore = false;
> > +
> > + while (msg_idx < ts->msg_count) {
> > + int error;
> > +
> > + ads7846_wait_for_hsync(ts);
> > +
> > + error = spi_sync(ts->spi, &ts->msg[msg_idx]);
> > + if (error) {
> > + dev_err_ratelimited(&ts->spi->dev, "spi_sync --> %d\n",
> > + error);
> > + packet->ignore = true;
> > + return;
>
> Sashiko recommends trying to power down ADC on errors, what do you
> think?
If we want to re-work error handling, then I guess it should be done the
same way for both full and half-duplex modes, and belongs to a separate
change set. This code has been in use quite a while, maybe 20 years,
and I haven't seen those errors in real use anyway, and AFAIK there
hasn't been any bug/problem reports by others either.
Maybe it wasn't so clearly stated in the commit message, but the patch
just restores the old code verbatim that was working fine for half-duplex
mode.
(Thanks for introducing Sashiko, I wasn't aware.)
A.
^ permalink raw reply
* [PATCH] Input: ims-pcu - bound frame parser write index against read_buf size
From: Greg Kroah-Hartman @ 2026-04-20 19:05 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
ims_pcu_process_data() implements a STX/DLE/ETX byte-stuffing parser
that accumulates frame payload into pcu->read_buf[] using the running
index pcu->read_pos. read_buf is IMS_PCU_BUF_SIZE (128) bytes and
read_pos is u8 but of course, we don't check the index before actually
writing the data :(
Fix this up by properly rejecting the frame at the first attempt to
write past read_buf and resync on the next STX, mirroring how the parser
handles short and bad-checksum frames on ETX.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/misc/ims-pcu.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index f69de9762c4e..87c66483b493 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -451,6 +451,8 @@ static void ims_pcu_process_data(struct ims_pcu *pcu, struct urb *urb)
if (pcu->have_dle) {
pcu->have_dle = false;
+ if (pcu->read_pos >= IMS_PCU_BUF_SIZE)
+ goto frame_overflow;
pcu->read_buf[pcu->read_pos++] = data;
pcu->check_sum += data;
continue;
@@ -491,10 +493,19 @@ static void ims_pcu_process_data(struct ims_pcu *pcu, struct urb *urb)
break;
default:
+ if (pcu->read_pos >= IMS_PCU_BUF_SIZE)
+ goto frame_overflow;
pcu->read_buf[pcu->read_pos++] = data;
pcu->check_sum += data;
break;
}
+ continue;
+
+frame_overflow:
+ dev_warn(pcu->dev, "Frame longer than %d bytes, discarding\n", IMS_PCU_BUF_SIZE);
+ pcu->have_stx = false;
+ pcu->have_dle = false;
+ pcu->read_pos = 0;
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] Input: synaptics-rmi4 - validate register descriptor structure against its declared size
From: Greg Kroah-Hartman @ 2026-04-20 18:59 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
rmi_read_register_desc() trusts three independent device-supplied
quantities to be correct:
- struct_size, taken from the presence-register header (up to 65535
via buf[1]|buf[2]<<8 when buf[0]==0),
- num_registers, the popcount of the presence bitmap (up to 255),
- the per-register entries inside struct_buf, each a variable-length
{reg_size, subpacket-continuation-bytes...} record.
But nothing checks that num_registers entries actually fit in
struct_size bytes, and nothing bounds the subpacket continuation chain,
which can cause two different types of overruns if left unchecked.
Fix this all up by properly checking the values every time and aborting
if anything is out of range.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/rmi4/rmi_driver.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index ccd9338a44db..9143f11e42a3 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -643,16 +643,24 @@ int rmi_read_register_desc(struct rmi_device *d, u16 addr,
reg = find_first_bit(rdesc->presense_map, RMI_REG_DESC_PRESENSE_BITS);
for (i = 0; i < rdesc->num_registers; i++) {
struct rmi_register_desc_item *item = &rdesc->registers[i];
- int reg_size = struct_buf[offset];
+ int reg_size;
+
+ if (offset >= rdesc->struct_size)
+ goto malformed;
+ reg_size = struct_buf[offset];
++offset;
if (reg_size == 0) {
+ if (offset + 2 > rdesc->struct_size)
+ goto malformed;
reg_size = struct_buf[offset] |
(struct_buf[offset + 1] << 8);
offset += 2;
}
if (reg_size == 0) {
+ if (offset + 4 > rdesc->struct_size)
+ goto malformed;
reg_size = struct_buf[offset] |
(struct_buf[offset + 1] << 8) |
(struct_buf[offset + 2] << 16) |
@@ -666,6 +674,9 @@ int rmi_read_register_desc(struct rmi_device *d, u16 addr,
map_offset = 0;
do {
+ if (offset >= rdesc->struct_size ||
+ map_offset >= RMI_REG_DESC_SUBPACKET_BITS)
+ goto malformed;
for (b = 0; b < 7; b++) {
if (struct_buf[offset] & (0x1 << b))
bitmap_set(item->subpacket_map,
@@ -688,6 +699,12 @@ int rmi_read_register_desc(struct rmi_device *d, u16 addr,
free_struct_buff:
kfree(struct_buf);
return ret;
+
+malformed:
+ dev_err(&d->dev,
+ "register descriptor structure does not match its declared size\n");
+ ret = -EIO;
+ goto free_struct_buff;
}
const struct rmi_register_desc_item *rmi_get_register_desc_item(
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] Input: synaptics-rmi4 - use u32 for reg_size to avoid sign extension into item->reg_size
From: Greg Kroah-Hartman @ 2026-04-20 18:59 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
In-Reply-To: <2026042044-amuser-tantrum-73af@gregkh>
rmi_read_register_desc() builds the 4-byte register size from device
bytes:
reg_size = struct_buf[offset] |
(struct_buf[offset + 1] << 8) |
(struct_buf[offset + 2] << 16) |
(struct_buf[offset + 3] << 24);
struct_buf is u8 *, so each byte is promoted to int before the shift. A
device that supplies a top byte with bit 7 set (e.g. 00 00 00 00 00 00
80 in struct_buf to reach the 4-byte path with offset+3 = 0x80) makes
(0x80 << 24) overflow into the int sign bit, and the OR result is
negative. reg_size is then assigned to item->reg_size, which is
unsigned long, so the negative int sign-extends to a value near
ULONG_MAX.
After this, bad things happen when numbers start wrapping and buffers
are allocatged based on those numbers, and then accessed based on those
buffers assuming to be a sane size (bigger or smaller).
Fix this all up by just properly making reg_size be a u32.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: b43d2c1e9353 ("Input: synaptics-rmi4 - add support for F12")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/rmi4/rmi_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 9143f11e42a3..801096c7235e 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -643,7 +643,7 @@ int rmi_read_register_desc(struct rmi_device *d, u16 addr,
reg = find_first_bit(rdesc->presense_map, RMI_REG_DESC_PRESENSE_BITS);
for (i = 0; i < rdesc->num_registers; i++) {
struct rmi_register_desc_item *item = &rdesc->registers[i];
- int reg_size;
+ u32 reg_size;
if (offset >= rdesc->struct_size)
goto malformed;
--
2.53.0
^ permalink raw reply related
* [PATCH] HID: hid-lenovo-go-s: restore OS_TYPE after resume from s2idle
From: Matthew Schwartz @ 2026-04-20 18:15 UTC (permalink / raw)
To: derekjohn.clark, jikos, bentiss
Cc: mpearson-lenovo, linux-input, linux-kernel, Matthew Schwartz
The controller MCU does not persist OS_TYPE across power cycles. During
s2idle resume, the USB device may be power-cycled, causing the OS_TYPE
setting to revert to the default Windows value.
Add a reset_resume callback so that this is correctly restored after
resume.
Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
---
drivers/hid/hid-lenovo-go-s.c | 44 +++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/hid/hid-lenovo-go-s.c b/drivers/hid/hid-lenovo-go-s.c
index 01c7bdd4fbe0..ff1782a75191 100644
--- a/drivers/hid/hid-lenovo-go-s.c
+++ b/drivers/hid/hid-lenovo-go-s.c
@@ -1369,6 +1369,14 @@ static void cfg_setup(struct work_struct *work)
"Failed to retrieve IMU Manufacturer: %i\n", ret);
return;
}
+
+ ret = mcu_property_out(drvdata.hdev, GET_GAMEPAD_CFG, FEATURE_OS_MODE,
+ NULL, 0);
+ if (ret) {
+ dev_err(&drvdata.hdev->dev,
+ "Failed to retrieve OS Mode: %i\n", ret);
+ return;
+ }
}
static int hid_gos_cfg_probe(struct hid_device *hdev,
@@ -1427,6 +1435,27 @@ static void hid_gos_cfg_remove(struct hid_device *hdev)
hid_set_drvdata(hdev, NULL);
}
+static int hid_gos_cfg_reset_resume(struct hid_device *hdev)
+{
+ u8 os_mode = drvdata.os_mode;
+ int ret;
+
+ ret = mcu_property_out(drvdata.hdev, SET_GAMEPAD_CFG,
+ FEATURE_OS_MODE, &os_mode, 1);
+ if (ret < 0)
+ return ret;
+
+ ret = mcu_property_out(drvdata.hdev, GET_GAMEPAD_CFG,
+ FEATURE_OS_MODE, NULL, 0);
+ if (ret < 0)
+ return ret;
+
+ if (drvdata.os_mode != os_mode)
+ return -ENODEV;
+
+ return 0;
+}
+
static int hid_gos_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
@@ -1481,6 +1510,20 @@ static void hid_gos_remove(struct hid_device *hdev)
}
}
+static int hid_gos_reset_resume(struct hid_device *hdev)
+{
+ int ep = get_endpoint_address(hdev);
+
+ switch (ep) {
+ case GO_S_CFG_INTF_IN:
+ return hid_gos_cfg_reset_resume(hdev);
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static const struct hid_device_id hid_gos_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_QHE,
USB_DEVICE_ID_LENOVO_LEGION_GO_S_XINPUT) },
@@ -1496,6 +1539,7 @@ static struct hid_driver hid_lenovo_go_s = {
.probe = hid_gos_probe,
.remove = hid_gos_remove,
.raw_event = hid_gos_raw_event,
+ .reset_resume = hid_gos_reset_resume,
};
module_hid_driver(hid_lenovo_go_s);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-04-20 17:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <aeZe7XoDbOMqMG_c@google.com>
On Mon, 20 Apr 2026 10:16:02 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Mon, Apr 20, 2026 at 11:01:59AM -0400, Hugo Villeneuve wrote:
> > I tested it on the real hardware and all is good.
>
> Thank you for testing the changes.
>
> >
> > So I imagine that it can still go into 7.1 since it is a new driver
> > and not a modification of an existing one?
>
> Yes, since this is a new driver I will include it in 7.1 pull request.
>
> Thanks.
Great, thank you.
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Dmitry Torokhov @ 2026-04-20 17:16 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420110159.29ccb815eb584bca18a407ac@hugovil.com>
On Mon, Apr 20, 2026 at 11:01:59AM -0400, Hugo Villeneuve wrote:
> I tested it on the real hardware and all is good.
Thank you for testing the changes.
>
> So I imagine that it can still go into 7.1 since it is a new driver
> and not a modification of an existing one?
Yes, since this is a new driver I will include it in 7.1 pull request.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] iio: magnetometer: hid-sensor-magn-3d: prefer 'unsigned int'
From: Andy Shevchenko @ 2026-04-20 16:50 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Joshua Crofts, jikos, jic23, dlechner, nuno.sa, andy, linux-input,
linux-iio, linux-kernel
In-Reply-To: <4e84f9cc258676ed038e1f932137f10f34064aca.camel@linux.intel.com>
On Mon, Apr 20, 2026 at 08:46:57AM -0700, srinivas pandruvada wrote:
> On Sun, 2026-04-19 at 20:05 +0200, Joshua Crofts wrote:
> > Use 'u32' instead of bare 'unsigned' to resolve checkpatch.pl
> > warnings
> > and correct type use as defined in the hid_sensor_hub_callbacks
> > struct.
> >
> > No functional change.
> >
> > Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
The Subject needs to be adjusted as well.
> > ---
> > v2:
> > - changed 'unsigned int' to 'u32' per struct definition
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size
From: Greg Kroah-Hartman @ 2026-04-20 16:00 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
nexio_read_data() pulls data_len and x_len from a packed __be16 header
in the device's interrupt packet and then walks packet->data[0..x_len)
and packet->data[x_len..data_len) comparing each byte against a
threshold.
Both fields are 16-bit on the wire (max 65535). The existing
adjustments shave at most 0x100 / 0x80 off, so the loop bound can still
reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size
(1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the
packed header — so packet->data[] has 1017 valid bytes. read_data()
callbacks are not given urb->actual_length, and nothing else bounds the
walk.
A device that lies about its length can get a ~64 KiB out-of-bounds read
past the coherent DMA allocation. The first index whose byte exceeds
NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the
reported touch coordinates, so adjacent kernel memory contents leak to
userspace as ABS_X / ABS_Y events. Far enough out, the read can also
hit an unmapped page and fault.
Fix this all by clamping data_len to the buffer's data[] capacity and
x_len to data_len.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 5197424cdccc ("Input: usbtouchscreen - add NEXIO (or iNexio) support")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/usbtouchscreen.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 657555c8796c..866d4a7fbe42 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -1070,6 +1070,11 @@ static int nexio_read_data(struct usbtouch_usb *usbtouch, unsigned char *pkt)
if (x_len > 0xff)
x_len -= 0x80;
+ if (data_len > usbtouch->data_size - sizeof(*packet))
+ data_len = usbtouch->data_size - sizeof(*packet);
+ if (x_len > data_len)
+ x_len = data_len;
+
/* send ACK */
ret = usb_submit_urb(priv->ack, GFP_ATOMIC);
if (ret)
--
2.53.0
^ permalink raw reply related
* [PATCH] Input: xpad - reject short Xbox One packets before len-relative share-button index
From: Greg Kroah-Hartman @ 2026-04-20 15:53 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Greg Kroah-Hartman, Dmitry Torokhov, stable
xpadone_process_packet() receives len directly from urb->actual_length
and uses it to index the share-button byte at data[len - 18] or
data[len - 26]. Since both len and data[0] are under the device's
control, a broken controller can send a GIP_CMD_INPUT packet with
actual_length < 18 (e.g. 5 bytes) and reach this code path, causing
accesses beyond the actual array.
Since len is u32, 5 - 26 wraps to 0xFFFFFFEB, and data[0xFFFFFFEB] can
dereference about 4 GiB past the 64-byte usb_alloc_coherent() idata
buffer. On a KASAN system this is an immediate splat otherwise the read
will either fault on an unmapped page (DoS) or pull a bit from arbitrary
kernel memory and report it as KEY_RECORD.
Fix this all up by properly bounds checking the value provided by the
device.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 4ef46367073b ("Input: xpad - fix Share button on Xbox One controllers")
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/joystick/xpad.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index d6fc3d6006bb..7d99fe0ecf91 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1110,10 +1110,13 @@ static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char
input_report_key(dev, BTN_START, data[4] & BIT(2));
input_report_key(dev, BTN_SELECT, data[4] & BIT(3));
if (xpad->mapping & MAP_SHARE_BUTTON) {
- if (xpad->mapping & MAP_SHARE_OFFSET)
- input_report_key(dev, KEY_RECORD, data[len - 26] & BIT(0));
- else
- input_report_key(dev, KEY_RECORD, data[len - 18] & BIT(0));
+ if (xpad->mapping & MAP_SHARE_OFFSET) {
+ if (len >= 26)
+ input_report_key(dev, KEY_RECORD, data[len - 26] & BIT(0));
+ } else {
+ if (len >= 18)
+ input_report_key(dev, KEY_RECORD, data[len - 18] & BIT(0));
+ }
}
/* buttons A,B,X,Y */
--
2.53.0
^ permalink raw reply related
* [PATCH 6.12 098/162] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:42 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153927.006696811@linuxfoundation.org>
6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.12 097/162] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:42 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153927.006696811@linuxfoundation.org>
6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.
Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* [PATCH 6.18 127/198] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153935.605963767@linuxfoundation.org>
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.18 126/198] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153935.605963767@linuxfoundation.org>
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.
Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* [PATCH 6.19 145/220] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153934.013228280@linuxfoundation.org>
6.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
* [PATCH 6.19 144/220] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, Masaki Ota, linux-input, Jiri Kosina
In-Reply-To: <20260420153934.013228280@linuxfoundation.org>
6.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.
Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.
Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.
Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Masaki Ota <masaki.ota@jp.alps.com>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-alps.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -437,6 +437,9 @@ static int alps_raw_event(struct hid_dev
int ret = 0;
struct alps_dev *hdata = hid_get_drvdata(hdev);
+ if (!(hdev->claimed & HID_CLAIMED_INPUT) || !hdata->input)
+ return 0;
+
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
ret = t4_raw_event(hdata, data, size);
^ permalink raw reply
* Re: [PATCH v2] iio: orientation: hid-sensor-rotation: use ext_scan_type
From: srinivas pandruvada @ 2026-04-20 15:45 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Lixu Zhang
Cc: Jiri Kosina, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260412152643.68c8f065@jic23-huawei>
+Lixu
On Sun, 2026-04-12 at 15:26 +0100, Jonathan Cameron wrote:
> On Sun, 01 Mar 2026 17:46:48 -0600
> David Lechner <dlechner@baylibre.com> wrote:
>
> > Make use of ext_scan_type to handle the dynamic realbits size of
> > the
> > quaternion data. This lets us implement it using static data rather
> > than
> > having to duplicate the channel info for each driver instance.
> >
> > Signed-off-by: David Lechner <dlechner@baylibre.com>
> > ---
> I'm going to apply this now, but would welcome any additional
> feedback
> from Srinivas or others.
>
> Note, given this is next cycle material now I'll only push the tree
> out
> as testing until I can rebase on rc1.
>
In real world I think report size is always 16 copying from spec.
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Thanks,
Srinivas
> Thanks,
>
> Jonathan
>
> > This is something I noticed we could do while looking at an
> > unrelated
> > bug. I've tested this using the same script from [1] and confirmed
> > that
> > that the scan type didn't change. Before and after are both:
> >
> > $ cat in_rot_quaternion_type
> > le:s16/32X4>>0
> >
> > [1]:
> > https://lore.kernel.org/linux-iio/20260301-iio-fix-timestamp-alignment-v1-1-1a54980bfb90@baylibre.com/
> > ---
> > Changes in v2:
> > - Dropped DEV_ROT_SCAN_TYPE_8BIT.
> > - Tested using /dev/uhid.
> > - Link to v1:
> > https://lore.kernel.org/r/20260214-iio-hid-sensor-rotation-cleanup-v1-1-3aec9a533c0f@baylibre.com
> > ---
> > drivers/iio/orientation/hid-sensor-rotation.c | 71
> > ++++++++++++++++-----------
> > 1 file changed, 43 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/iio/orientation/hid-sensor-rotation.c
> > b/drivers/iio/orientation/hid-sensor-rotation.c
> > index e759f91a710a..3cfd0b323514 100644
> > --- a/drivers/iio/orientation/hid-sensor-rotation.c
> > +++ b/drivers/iio/orientation/hid-sensor-rotation.c
> > @@ -34,6 +34,27 @@ static const u32
> > rotation_sensitivity_addresses[] = {
> > HID_USAGE_SENSOR_ORIENT_QUATERNION,
> > };
> >
> > +enum {
> > + DEV_ROT_SCAN_TYPE_16BIT,
> > + DEV_ROT_SCAN_TYPE_32BIT,
> > +};
> > +
> > +static const struct iio_scan_type dev_rot_scan_types[] = {
> > + [DEV_ROT_SCAN_TYPE_16BIT] = {
> > + .sign = 's',
> > + .realbits = 16,
> > + /* Storage bits has to stay 32 to not break
> > userspace. */
> > + .storagebits = 32,
> > + .repeat = 4,
> > + },
> > + [DEV_ROT_SCAN_TYPE_32BIT] = {
> > + .sign = 's',
> > + .realbits = 32,
> > + .storagebits = 32,
> > + .repeat = 4,
> > + },
> > +};
> > +
> > /* Channel definitions */
> > static const struct iio_chan_spec dev_rot_channels[] = {
> > {
> > @@ -45,23 +66,14 @@ static const struct iio_chan_spec
> > dev_rot_channels[] = {
> > BIT(IIO_CHAN_INFO_OFFSET)
> > |
> > BIT(IIO_CHAN_INFO_SCALE) |
> > BIT(IIO_CHAN_INFO_HYSTERES
> > IS),
> > - .scan_index = 0
> > + .scan_index = 0,
> > + .has_ext_scan_type = 1,
> > + .ext_scan_type = dev_rot_scan_types,
> > + .num_ext_scan_type =
> > ARRAY_SIZE(dev_rot_scan_types),
> > },
> > IIO_CHAN_SOFT_TIMESTAMP(1)
> > };
> >
> > -/* Adjust channel real bits based on report descriptor */
> > -static void dev_rot_adjust_channel_bit_mask(struct iio_chan_spec
> > *chan,
> > - int size)
> > -{
> > - chan->scan_type.sign = 's';
> > - /* Real storage bits will change based on the report desc.
> > */
> > - chan->scan_type.realbits = size * 8;
> > - /* Maximum size of a sample to capture is u32 */
> > - chan->scan_type.storagebits = sizeof(u32) * 8;
> > - chan->scan_type.repeat = 4;
> > -}
> > -
> > /* Channel read_raw handler */
> > static int dev_rot_read_raw(struct iio_dev *indio_dev,
> > struct iio_chan_spec const *chan,
> > @@ -136,9 +148,25 @@ static int dev_rot_write_raw(struct iio_dev
> > *indio_dev,
> > return ret;
> > }
> >
> > +static int dev_rot_get_current_scan_type(const struct iio_dev
> > *indio_dev,
> > + const struct
> > iio_chan_spec *chan)
> > +{
> > + struct dev_rot_state *rot_state = iio_priv(indio_dev);
> > +
> > + switch (rot_state->quaternion.size / 4) {
> > + case sizeof(s16):
> > + return DEV_ROT_SCAN_TYPE_16BIT;
> > + case sizeof(s32):
> > + return DEV_ROT_SCAN_TYPE_32BIT;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > static const struct iio_info dev_rot_info = {
> > .read_raw_multi = &dev_rot_read_raw,
> > .write_raw = &dev_rot_write_raw,
> > + .get_current_scan_type = &dev_rot_get_current_scan_type,
> > };
> >
> > /* Callback handler to send event after all samples are received
> > and captured */
> > @@ -196,7 +224,6 @@ static int dev_rot_capture_sample(struct
> > hid_sensor_hub_device *hsdev,
> > /* Parse report which is specific to an usage id*/
> > static int dev_rot_parse_report(struct platform_device *pdev,
> > struct hid_sensor_hub_device
> > *hsdev,
> > - struct iio_chan_spec *channels,
> > unsigned usage_id,
> > struct dev_rot_state *st)
> > {
> > @@ -210,9 +237,6 @@ static int dev_rot_parse_report(struct
> > platform_device *pdev,
> > if (ret)
> > return ret;
> >
> > - dev_rot_adjust_channel_bit_mask(&channels[0],
> > - st->quaternion.size / 4);
> > -
> > dev_dbg(&pdev->dev, "dev_rot %x:%x\n", st-
> > >quaternion.index,
> > st->quaternion.report_id);
> >
> > @@ -271,22 +295,13 @@ static int hid_dev_rot_probe(struct
> > platform_device *pdev)
> > return ret;
> > }
> >
> > - indio_dev->channels = devm_kmemdup(&pdev->dev,
> > dev_rot_channels,
> > -
> > sizeof(dev_rot_channels),
> > - GFP_KERNEL);
> > - if (!indio_dev->channels) {
> > - dev_err(&pdev->dev, "failed to duplicate
> > channels\n");
> > - return -ENOMEM;
> > - }
> > -
> > - ret = dev_rot_parse_report(pdev, hsdev,
> > - (struct iio_chan_spec
> > *)indio_dev->channels,
> > - hsdev->usage, rot_state);
> > + ret = dev_rot_parse_report(pdev, hsdev, hsdev->usage,
> > rot_state);
> > if (ret) {
> > dev_err(&pdev->dev, "failed to setup
> > attributes\n");
> > return ret;
> > }
> >
> > + indio_dev->channels = dev_rot_channels;
> > indio_dev->num_channels = ARRAY_SIZE(dev_rot_channels);
> > indio_dev->info = &dev_rot_info;
> > indio_dev->name = name;
> >
> > ---
> > base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> > change-id: 20260214-iio-hid-sensor-rotation-cleanup-84e8410926ef
> >
> > Best regards,
^ permalink raw reply
* Re: [PATCH v2] iio: magnetometer: hid-sensor-magn-3d: prefer 'unsigned int'
From: srinivas pandruvada @ 2026-04-20 15:46 UTC (permalink / raw)
To: Joshua Crofts, jikos, jic23
Cc: dlechner, nuno.sa, andy, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260419180523.37396-1-joshua.crofts1@gmail.com>
On Sun, 2026-04-19 at 20:05 +0200, Joshua Crofts wrote:
> Use 'u32' instead of bare 'unsigned' to resolve checkpatch.pl
> warnings
> and correct type use as defined in the hid_sensor_hub_callbacks
> struct.
>
> No functional change.
>
> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v2:
> - changed 'unsigned int' to 'u32' per struct definition
>
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index c673f9323e..b01dd53eb1 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> @@ -280,7 +280,7 @@ static const struct iio_info magn_3d_info = {
>
> /* Callback handler to send event after all samples are received and
> captured */
> static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(priv);
> @@ -302,7 +302,7 @@ static int magn_3d_proc_event(struct
> hid_sensor_hub_device *hsdev,
>
> /* Capture samples in local storage */
> static int magn_3d_capture_sample(struct hid_sensor_hub_device
> *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
> {
> @@ -350,7 +350,7 @@ static int magn_3d_parse_report(struct
> platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> struct iio_chan_spec **channels,
> int *chan_count,
> - unsigned usage_id,
> + u32 usage_id,
> struct magn_3d_state *st)
> {
> int i;
^ permalink raw reply
* [PATCH 7.0 07/76] HID: core: clamp report_size in s32ton() to avoid undefined shift
From: Greg Kroah-Hartman @ 2026-04-20 15:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, stable, Jiri Kosina,
Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20260420153910.810034134@linuxfoundation.org>
7.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
Cc: stable <stable@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -71,6 +71,9 @@ static u32 s32ton(__s32 value, unsigned
if (!value || !n)
return 0;
+ if (n > 32)
+ n = 32;
+
a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
^ permalink raw reply
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