* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
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, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-03-31 8:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mediatek, Fabien Parent, Val Packett, 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, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260331-flawless-bronze-lorikeet-59a6ff@quoll>
> > - required:
> > - - compatible
>
> Not really, this affects existing ABI and might make the child schema
> being applied. Basically regulators node can be anything now.
>
> This is definitely not a binding we want. The syntax for parent schema
> when listing only compatibles is requiring this compatible. You cannot
> have here whatever empty node.
Hi, it felt quite strange to me too, but that's what I thought you
meant with your previous suggestion [1].
To keep the required attribute I would be happy to reintroduce the
compatible here, in the regulator schema and the pmic dtsi.
Before I do that and resubmit, could you please help me understand
what you meant before?
Thank you!
[1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Lee Jones @ 2026-03-31 7:58 UTC (permalink / raw)
To: Günther Noack
Cc: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260331074052.194064-1-gnoack@google.com>
On Tue, 31 Mar 2026, Günther Noack wrote:
> Without this bounds check, this might otherwise overwrite index -1.
>
> Triggering this condition requires action both from the USB device and from
> userspace, which reduces the scenarios in which it can be exploited.
>
> Cc: Lee Jones <lee@kernel.org>
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index d1dea7297712..5f63f1d2303a 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
> }
> break;
> case HIDPP_FF_DESTROY_EFFECT:
> - if (wd->effect_id >= 0)
> - /* regular effect destroyed */
> - data->effect_ids[wd->params[0]-1] = -1;
> - else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
> - /* autocenter spring destroyed */
> - data->slot_autocenter = 0;
> + slot = wd->params[0];
> + if (slot > 0 && slot <= data->num_effects) {
> + if (wd->effect_id >= 0)
> + /* regular effect destroyed */
> + data->effect_ids[slot-1] = -1;
> + else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
> + /* autocenter spring destroyed */
> + data->slot_autocenter = 0;
> + }
LGTM.
Reviewed-by: Lee Jones <lee@kernel.org>
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Günther Noack @ 2026-03-31 7:40 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires
Cc: Günther Noack, Lee Jones, linux-input, linux-kernel
Without this bounds check, this might otherwise overwrite index -1.
Triggering this condition requires action both from the USB device and from
userspace, which reduces the scenarios in which it can be exploited.
Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Günther Noack <gnoack@google.com>
---
drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712..5f63f1d2303a 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
}
break;
case HIDPP_FF_DESTROY_EFFECT:
- if (wd->effect_id >= 0)
- /* regular effect destroyed */
- data->effect_ids[wd->params[0]-1] = -1;
- else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
- /* autocenter spring destroyed */
- data->slot_autocenter = 0;
+ slot = wd->params[0];
+ if (slot > 0 && slot <= data->num_effects) {
+ if (wd->effect_id >= 0)
+ /* regular effect destroyed */
+ data->effect_ids[slot-1] = -1;
+ else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
+ /* autocenter spring destroyed */
+ data->slot_autocenter = 0;
+ }
break;
case HIDPP_FF_SET_GLOBAL_GAINS:
data->gain = (wd->params[0] << 8) + wd->params[1];
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, 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, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> 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 | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 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..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# 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
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + 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.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, 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, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)
From: Thorsten Leemhuis @ 2026-03-31 6:25 UTC (permalink / raw)
To: honjow, Jiri Kosina, Benjamin Tissoires
Cc: denis.benato, linux-kernel, linux-input,
Linux kernel regressions list
In-Reply-To: <20260324013847.68024-1-honjow311@gmail.com>
On 3/24/26 02:38, honjow wrote:
> The OEM USB HID interface found on GPD Win handhelds (VID 2f24, registered
> to ShenZhen HuiJiaZhi / GameSir, PID 0137) declares 63-byte Input and
> Feature reports for Report ID 1, but the firmware only transfers 11 data
> bytes per interrupt.
>
> Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), the HID core rejects undersized reports instead of zero-
> padding them. This breaks the device entirely on kernels >= v7.0-rc5.
>
> Fix it by patching the report descriptor in report_fixup(), reducing
> Report Count from 63 to 11 for both Input and Feature.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221271
> Signed-off-by: honjow <honjow311@gmail.com>
> ---
> drivers/hid/Kconfig | 10 +++++++++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-gpd.c | 52 +++++++++++++++++++++++++++++++++++++++++++
> drivers/hid/hid-ids.h | 3 +++
> 4 files changed, 66 insertions(+)
> create mode 100644 drivers/hid/hid-gpd.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 10c12d8e65579..20c60f5aca4c5 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -419,6 +419,16 @@ config HID_GLORIOUS
> Support for Glorious PC Gaming Race mice such as
> the Glorious Model O, O- and D.
>
> +config HID_GPD
> + tristate "GPD Win handheld OEM HID support"
Hmmm, why does this need to be a config option? Can't this be enabled
unconditionally? I ask in general, as it's just another point where
things can go wrong. But I mainly ask because it's a regression fix –
and from my understanding wrt to what Linus wants we don't expect users
to turn some .config on to keep their hardware running (unless it can't
be avoided at all costs).
Ciao, Thorsten
> + depends on USB_HID
> + help
> + Report descriptor fix for the OEM USB HID interface (GameSir
> + 2f24:0137) found on GPD Win handhelds. The firmware declares 63-byte
> + reports but only sends 11 bytes, which the HID core rejects.
> +
> + Say Y or M here if you use a GPD Win handheld with this interface.
> +
> config HID_HOLTEK
> tristate "Holtek HID devices"
> depends on USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 07dfdb6a49c59..03ef72ec4499f 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
> obj-$(CONFIG_HID_EVISION) += hid-evision.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_FT260) += hid-ft260.o
> +obj-$(CONFIG_HID_GPD) += hid-gpd.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
> obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
> diff --git a/drivers/hid/hid-gpd.c b/drivers/hid/hid-gpd.c
> new file mode 100644
> index 0000000000000..5b4d203e24995
> --- /dev/null
> +++ b/drivers/hid/hid-gpd.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * HID report descriptor fixup for GPD Win handhelds.
> + *
> + * The OEM HID interface (VID 2f24 / GameSir, PID 0137) declares Report ID 1
> + * with Report Count 63 (8-bit fields) for both Input and Feature, but the
> + * firmware only sends 11 bytes of payload after the report ID.
> + */
> +
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +
> +#include "hid-ids.h"
> +
> +#define RDESC_LEN 38
> +#define RPT_COUNT_INPUT_OFF 21
> +#define RPT_COUNT_FEATURE_OFF 34
> +
> +static const __u8 *gpd_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> + unsigned int *rsize)
> +{
> + if (*rsize != RDESC_LEN)
> + return rdesc;
> +
> + if (rdesc[RPT_COUNT_INPUT_OFF - 1] == 0x95 &&
> + rdesc[RPT_COUNT_INPUT_OFF] == 0x3f &&
> + rdesc[RPT_COUNT_FEATURE_OFF - 1] == 0x95 &&
> + rdesc[RPT_COUNT_FEATURE_OFF] == 0x3f) {
> + hid_info(hdev, "fixing report counts (63 -> 11 bytes)\n");
> + rdesc[RPT_COUNT_INPUT_OFF] = 11;
> + rdesc[RPT_COUNT_FEATURE_OFF] = 11;
> + }
> +
> + return rdesc;
> +}
> +
> +static const struct hid_device_id gpd_devices[] = {
> + { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137) },
> + { }
> +};
> +MODULE_DEVICE_TABLE(hid, gpd_devices);
> +
> +static struct hid_driver gpd_driver = {
> + .name = "gpd",
> + .id_table = gpd_devices,
> + .report_fixup = gpd_report_fixup,
> +};
> +
> +module_hid_driver(gpd_driver);
> +
> +MODULE_DESCRIPTION("HID report descriptor fix for GPD Win handheld (GameSir 2f24:0137)");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 933b7943bdb50..d0a6c19baa660 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -533,6 +533,9 @@
> #define USB_VENDOR_ID_FRUCTEL 0x25B6
> #define USB_DEVICE_ID_GAMETEL_MT_MODE 0x0002
>
> +#define USB_VENDOR_ID_GAMESIR 0x2f24
> +#define USB_DEVICE_ID_GAMESIR_0137 0x0137
> +
> #define USB_VENDOR_ID_GAMEVICE 0x27F8
> #define USB_DEVICE_ID_GAMEVICE_GV186 0x0BBE
> #define USB_DEVICE_ID_GAMEVICE_KISHI 0x0BBF
^ permalink raw reply
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Dmitry Torokhov @ 2026-03-30 23:55 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> Use the common USB helpers for looking up bulk and interrupt endpoints
> instead of open coding.
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND] Input: atkbd - skip cleanup when used as a wakeup source
From: Dmitry Torokhov @ 2026-03-30 21:56 UTC (permalink / raw)
To: hbarnor; +Cc: linux-input, linux-kernel
In-Reply-To: <20260330-wakeup-v1-1-d269624fa519@chromium.org>
Hi Henry,
On Mon, Mar 30, 2026 at 12:01:50PM -0700, Henry Barnor via B4 Relay wrote:
> From: Henry Barnor <hbarnor@chromium.org>
>
> In systems using suspend-to-idle, the serio core calls atkbd_cleanup()
> during the suspend transition. Currently, this function unconditionally
> calls atkbd_disable(), setting atkbd->enabled to false.
>
> This creates a race condition during wakeup: when a key is pressed to
> wake the system, atkbd_receive_byte() is triggered. It correctly signals
> a wakeup event to the PM core, but then checks atkbd->enabled. Because
> the driver was disabled during suspend, the scancode is discarded.
> The system wakes up, but the initial keystroke is lost.
>
> This is particularly problematic for platforms like Android that rely on
> the input event itself to complete the wakeup transition and turn on the
> screen. On these systems, the device wakes up but remains in a dim state
> because the initial interaction was lost.
This is really for the Android system layer to solve.
>
> This patch modifies atkbd_cleanup() to skip disabling and resetting
> the keyboard if the device is configured as a wakeup source. This
> preserves atkbd->enabled = true through the sleep duration, ensuring
> the wake-up scancode is reported to the input subsystem.
>
> Note that this also affects the shutdown path. However, if a device is
> configured for wakeup, skipping the reset to "default" state is
> consistent with the goal of allowing the hardware to trigger a
> system-state transition. Modern BIOS/UEFI implementations perform their
> own keyboard initialization, so skipping the legacy reset on reboot
> for these devices poses minimal risk.
We unfortunately need to support devices much older than that, so we can
not be sure that this change is safe. Historically there we a lot of
instances where systems were unhappy if we attempted to enter shutdown
or suspend paths with devices in state other than freshly reset.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH RESEND] Input: atkbd - skip cleanup when used as a wakeup source
From: Henry Barnor via B4 Relay @ 2026-03-30 19:01 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Henry Barnor
From: Henry Barnor <hbarnor@chromium.org>
In systems using suspend-to-idle, the serio core calls atkbd_cleanup()
during the suspend transition. Currently, this function unconditionally
calls atkbd_disable(), setting atkbd->enabled to false.
This creates a race condition during wakeup: when a key is pressed to
wake the system, atkbd_receive_byte() is triggered. It correctly signals
a wakeup event to the PM core, but then checks atkbd->enabled. Because
the driver was disabled during suspend, the scancode is discarded.
The system wakes up, but the initial keystroke is lost.
This is particularly problematic for platforms like Android that rely on
the input event itself to complete the wakeup transition and turn on the
screen. On these systems, the device wakes up but remains in a dim state
because the initial interaction was lost.
This patch modifies atkbd_cleanup() to skip disabling and resetting
the keyboard if the device is configured as a wakeup source. This
preserves atkbd->enabled = true through the sleep duration, ensuring
the wake-up scancode is reported to the input subsystem.
Note that this also affects the shutdown path. However, if a device is
configured for wakeup, skipping the reset to "default" state is
consistent with the goal of allowing the hardware to trigger a
system-state transition. Modern BIOS/UEFI implementations perform their
own keyboard initialization, so skipping the legacy reset on reboot
for these devices poses minimal risk.
Signed-off-by: Henry Barnor <hbarnor@chromium.org>
---
drivers/input/keyboard/atkbd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 4560d3964eee..1fba1932412e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -958,6 +958,9 @@ static void atkbd_cleanup(struct serio *serio)
{
struct atkbd *atkbd = atkbd_from_serio(serio);
+ if (device_may_wakeup(&serio->dev))
+ return;
+
atkbd_disable(atkbd);
ps2_command(&atkbd->ps2dev, NULL, ATKBD_CMD_RESET_DEF);
}
---
base-commit: 6d4b67a2a76a4ff2393fe88119ae4332821b82b4
change-id: 20260310-wakeup-ec57a88a0162
Best regards,
--
Henry Barnor <hbarnor@chromium.org>
^ permalink raw reply related
* Re: [PATCH] HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)
From: Jiri Kosina @ 2026-03-30 14:21 UTC (permalink / raw)
To: honjow; +Cc: Benjamin Tissoires, denis.benato, linux-kernel, linux-input
In-Reply-To: <20260324013847.68024-1-honjow311@gmail.com>
On Tue, 24 Mar 2026, honjow wrote:
> The OEM USB HID interface found on GPD Win handhelds (VID 2f24, registered
> to ShenZhen HuiJiaZhi / GameSir, PID 0137) declares 63-byte Input and
> Feature reports for Report ID 1, but the firmware only transfers 11 data
> bytes per interrupt.
>
> Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), the HID core rejects undersized reports instead of zero-
> padding them. This breaks the device entirely on kernels >= v7.0-rc5.
>
> Fix it by patching the report descriptor in report_fixup(), reducing
> Report Count from 63 to 11 for both Input and Feature.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221271
> Signed-off-by: honjow <honjow311@gmail.com>
I have added Fixes: tag and applied to hid.git#for-7.0/upstream-fixes,
thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset()
From: Jiri Kosina @ 2026-03-30 13:32 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, patches, stable, Lee Jones, Benjamin Tissoires,
linux-input, linux-kernel, honjow
In-Reply-To: <695caa61-20f9-4932-9ff9-431be7615c43@leemhuis.info>
On Mon, 30 Mar 2026, Thorsten Leemhuis wrote:
> > From: Lee Jones <lee@kernel.org>
> >
> > [ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]
>
> TWIMC, honjow (now CCed) reported a regression (GPD Win5 handhelds
> stopped working) caused by this change – and provided a patch (which
> misses a Fixes tag) to resolve it:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=221271
> https://lore.kernel.org/all/20260324013847.68024-1-honjow311@gmail.com/
Thanks for pointing out the missing Fixes: tag, I'll add it manually when
applying.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v2] HID: mcp2221: validate report size in raw_event handler
From: Sebastian Josue Alba Vives @ 2026-03-30 13:29 UTC (permalink / raw)
To: jikos, bentiss
Cc: linux-input, linux-kernel, stable, Sebastian Josue Alba Vives
mcp2221_raw_event() accesses the data buffer at offsets up to 55
without validating the size parameter. Since __hid_input_report()
invokes the driver's raw_event callback before
hid_report_raw_event() performs its own report-size validation, a
device sending a truncated HID report can cause out-of-bounds heap
reads in the kernel.
The most critical access is the memcpy from data[50] into
mcp->adc_values (6 bytes) when CONFIG_IIO is reachable. Other
unchecked accesses include data[20] and a memcpy at data[22].
Additionally, a memcpy with device-controlled length (data[3],
up to 60 bytes) from data[4] does not verify that size is large
enough to cover the copy.
MCP2221 devices use 64-byte HID reports. Add a check at the top of
the handler to reject any report shorter than expected, and log a
warning to aid debugging.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-mcp2221.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index ef3b5c77c..770c305d8 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -850,6 +850,11 @@ static int mcp2221_raw_event(struct hid_device *hdev,
{
u8 *buf;
struct mcp2221 *mcp = hid_get_drvdata(hdev);
+ /* MCP2221 always sends 64-byte reports */
+ if (size < 64) {
+ hid_warn(hdev, "report too short: %d < 64\n", size);
+ return 0;
+ }
switch (data[0]) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2] HID: ft260: validate report size and payload length in raw_event
From: Sebastian Josue Alba Vives @ 2026-03-30 13:28 UTC (permalink / raw)
To: jikos, bentiss
Cc: linux-input, linux-kernel, stable, Sebastian Josue Alba Vives
ft260_raw_event() casts the raw data buffer to a
ft260_i2c_input_report struct and accesses its fields without
validating the size parameter. Since __hid_input_report() invokes
the driver's raw_event callback before hid_report_raw_event()
performs its own report-size validation, a device sending a
truncated HID report can cause out-of-bounds heap reads.
Additionally, even with a full-sized report, a corrupted
xfer->length field can cause memcpy to read beyond the report
buffer. The existing check only validates against the destination
buffer size, not the source data available in the report.
Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,
and verify that xfer->length does not exceed the actual data
available in the report. Log warnings to aid debugging.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-ft260.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index 333341e80..68008a423 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
struct ft260_device *dev = hid_get_drvdata(hdev);
struct ft260_i2c_input_report *xfer = (void *)data;
+ if (size < FT260_REPORT_MAX_LENGTH) {
+ hid_warn(hdev, "short report: %d\n", size);
+ return 0;
+ }
+
+ if (xfer->length > size - offsetof(struct ft260_i2c_input_report, data)) {
+ hid_warn(hdev, "payload %d exceeds report size %d\n",
+ xfer->length, size);
+ return 0;
+ }
+
if (xfer->report >= FT260_I2C_REPORT_MIN &&
xfer->report <= FT260_I2C_REPORT_MAX) {
ft260_dbg("i2c resp: rep %#02x len %d\n", xfer->report,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset()
From: Thorsten Leemhuis @ 2026-03-30 13:26 UTC (permalink / raw)
To: Sasha Levin, patches, stable
Cc: Lee Jones, Benjamin Tissoires, jikos, linux-input, linux-kernel,
honjow
In-Reply-To: <20260324111931.3257972-18-sashal@kernel.org>
On 3/24/26 12:19, Sasha Levin wrote:
> From: Lee Jones <lee@kernel.org>
>
> [ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]
TWIMC, honjow (now CCed) reported a regression (GPD Win5 handhelds
stopped working) caused by this change – and provided a patch (which
misses a Fixes tag) to resolve it:
https://bugzilla.kernel.org/show_bug.cgi?id=221271
https://lore.kernel.org/all/20260324013847.68024-1-honjow311@gmail.com/
Ciao, Thorsten
> 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>
> [bentiss: changed the return value]
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> LLM Generated explanations, may be completely bogus:
>
> Now I have all the information needed to complete the analysis. Let me
> compile the full assessment.
>
> ---
>
> ## PHASE 1: COMMIT MESSAGE FORENSICS
>
> **Step 1.1: Subject Line**
> - Subsystem: `HID: core:`
> - Action verb: "Mitigate" (fix-oriented)
> - Summary: Removes a memset() that causes OOB reads/writes when incoming
> HID event data is shorter than expected report size.
> - Record: [HID core] [Mitigate/fix] [Remove memset that causes OOB
> memory corruption]
>
> **Step 1.2: Tags**
> - `Suggested-by: Benjamin Tissoires <bentiss@kernel.org>` — HID co-
> maintainer suggested the approach
> - `Signed-off-by: Lee Jones <lee@kernel.org>` — author
> - `[bentiss: changed the return value]` — maintainer modified the return
> value
> - `Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>` — applied by
> HID maintainer
> - No Fixes: tag (expected for candidates)
> - No Cc: stable (expected)
> - No Reported-by tag
> - Record: Suggested and accepted by the HID co-maintainer. Strong
> endorsement.
>
> **Step 1.3: Commit Body**
> - Bug: The `memset()` in `hid_report_raw_event()` zeros from `cdata +
> csize` to `cdata + rsize` when `csize < rsize`. However, the actual
> buffer may not be `rsize` bytes — it could be smaller, causing OOB
> writes.
> - "as we have previously seen" — acknowledges a history of OOB issues
> from this code.
> - The fix: reject short reports entirely with -EINVAL instead of zero-
> padding.
> - Record: OOB writes from memset writing past actual buffer boundary.
> Longstanding known issue class.
>
> **Step 1.4: Hidden Bug Fix Detection**
> - Not hidden — explicitly describes an OOB vulnerability fix. The word
> "mitigate" and "OOB" make it clear.
>
> ## PHASE 2: DIFF ANALYSIS
>
> **Step 2.1: Inventory**
> - Files: `drivers/hid/hid-core.c` (+4/-3 lines)
> - Function: `hid_report_raw_event()`
> - Scope: Single-file, single-function surgical fix
> - Record: [1 file, net +1 line] [hid_report_raw_event()] [Single-file
> surgical fix]
>
> **Step 2.2: Code Flow Change**
> - BEFORE: When `csize < rsize`, the code logs a debug message and calls
> `memset(cdata + csize, 0, rsize - csize)` to zero-pad the buffer, then
> continues processing.
> - AFTER: When `csize < rsize`, the code logs a rate-limited warning and
> returns `-EINVAL` via `goto out`, rejecting the short report entirely.
> - Record: [Short report path: zero-pad and continue → reject and return
> -EINVAL]
>
> **Step 2.3: Bug Mechanism**
> - Category: **Buffer overflow / OOB write** (memory safety)
> - Mechanism: `memset(cdata + csize, 0, rsize - csize)` writes zeros from
> the end of the actual received data to position `rsize`. But the
> underlying buffer (allocated by the transport layer) may only be
> `csize` bytes, meaning the memset writes past the buffer boundary.
> - Additionally, subsequent code (like `hid_process_report`) reads up to
> `rsize` bytes from the buffer, causing OOB reads.
> - Record: [OOB write from memset] [Buffer may be smaller than rsize,
> memset writes past end]
>
> **Step 2.4: Fix Quality**
> - Obviously correct: rejecting a too-short report is safer than
> attempting to zero-pad a buffer of unknown size.
> - Minimal: 4 lines changed, net +1 line.
> - Regression risk: Some devices that send short reports and relied on
> zero-padding will now have those reports rejected. Tissoires
> acknowledged this ("let's go with it and say sorry if we break some
> devices later on"), meaning the maintainer accepted this tradeoff.
> - Record: [High quality, minimal fix] [Low regression risk, maintainer-
> accepted tradeoff]
>
> ## PHASE 3: GIT HISTORY INVESTIGATION
>
> **Step 3.1: Blame**
> - The buggy memset line traces to `85cdaf524b7dda` ("HID: make a bus
> from hid code") from 2008-05-16.
> - This code has been present since Linux 2.6.26 — it exists in ALL
> active stable trees.
> - Record: [Buggy code from 2008, present in all stable trees]
>
> **Step 3.2: Fixes Tag**
> - No Fixes: tag present. However, the memset dates to 85cdaf524b7dda
> (2008).
>
> **Step 3.3: File History — Related Changes**
> - 966922f26c7fb (2011): Fixed crash from rsize being too large
> (536870912) causing memset crash
> - 5ebdffd250988 (2020): Fixed off-by-one in rsize calculation causing
> OOB memset
> - b1a37ed00d790 (2023): Added `max_buffer_size` attribute to cap rsize
> - ec61b41918587 (2022): Fixed shift-out-of-bounds in the processing
> after the memset
> - Record: **Long history of OOB/crash bugs from this exact memset**.
> This is the definitive fix.
>
> **Step 3.4: Author**
> - Lee Jones is a prolific kernel contributor and has previously worked
> on HID buffer size hardening (b1a37ed00d790).
> - Fix was suggested by and applied by Benjamin Tissoires, HID co-
> maintainer.
> - Record: [Experienced author, maintainer-endorsed fix]
>
> **Step 3.5: Dependencies**
> - The fix uses `hid_warn_ratelimited`, introduced in commit
> 1d64624243af8, which only entered v6.18.
> - For stable trees < 6.18, this would need trivial adaptation (use
> `hid_warn` or `dev_warn_ratelimited` instead).
> - The companion patch `e716edafedad4` (hid-multitouch report ID check)
> is independent — it adds a defense at the caller level, not a
> prerequisite.
> - Record: [Minor dependency on hid_warn_ratelimited macro for older
> trees, trivially resolvable]
>
> ## PHASE 4: MAILING LIST RESEARCH
>
>>From the lore.kernel.org investigation:
> - **v1 (2026-02-27)**: Initial version simply removed the memset
> entirely.
> - **Tissoires review (2026-03-02)**: Pushed back — removing memset alone
> isn't enough because `hid_process_report()` would still read OOB.
> Suggested rejecting short reports entirely.
> - **v3 (2026-03-09)**: Revised per Tissoires's feedback — now returns
> early with warning.
> - **Tissoires final review (2026-03-16)**: Endorsed, changed return to
> -EINVAL, noted "works in 99% of cases" since transport layers allocate
> big enough buffers.
> - Applied 2026-03-16, merged to Linus 2026-03-17.
> - No explicit stable nomination, but no objections to backporting
> either.
> - Record: [Thorough review by HID maintainer, iterated to correct
> approach, accepted]
>
> ## PHASE 5: CODE SEMANTIC ANALYSIS
>
> **Step 5.1: Functions Modified**
> - `hid_report_raw_event()` — the core HID report processing function.
>
> **Step 5.2: Callers**
> - `__hid_input_report()` in hid-core.c (line 2144) — **THE main HID
> input path** for all HID devices
> - `wacom_sys.c` — 3 call sites (Wacom tablet driver)
> - `hid-gfrm.c` — Google Fiber Remote
> - `hid-logitech-hidpp.c` — Logitech HID++
> - `hid-primax.c` — Primax keyboards
> - `hid-multitouch.c` — multitouch devices
> - `hid-vivaldi-common.c` — Vivaldi keyboard
> - Record: [Called from core HID input path and multiple drivers — very
> high impact surface]
>
> **Step 5.3-5.4: Call Chain**
> - USB HID: `hid_irq_in()` → `hid_input_report()` →
> `__hid_input_report()` → `hid_report_raw_event()`
> - This is reachable from any USB HID device event — keyboards, mice,
> touchscreens, gamepads, etc.
> - Also reachable from I2C-HID, BT-HID, and other transports.
> - Record: [Reachable from any HID device input — universal impact]
>
> ## PHASE 6: STABLE TREE ANALYSIS
>
> **Step 6.1: Buggy Code in Stable?**
> - The memset dates to 2008. Present in every stable tree.
> - Record: [ALL active stable trees contain the buggy code]
>
> **Step 6.2: Backport Complications**
> - `hid_warn_ratelimited` only in v6.18+. For older stable trees, trivial
> substitution needed (e.g., `hid_warn`).
> - The rest of the code context (csize, rsize, max_buffer_size, goto out)
> is identical in recent stable trees (verified: max_buffer_size was
> added in b1a37ed00d790 from 2023, present in 6.6+).
> - Record: [Minor adaptation needed for < 6.18, clean apply otherwise]
>
> **Step 6.3: Related Fixes in Stable**
> - Previous mitigations (max_buffer_size capping, off-by-one fix) are in
> stable but didn't eliminate the fundamental OOB risk.
> - Record: [No equivalent fix already in stable — this is the definitive
> solution]
>
> ## PHASE 7: SUBSYSTEM CONTEXT
>
> **Step 7.1: Subsystem Criticality**
> - HID core — every keyboard, mouse, touchscreen, gamepad, etc. goes
> through this code.
> - Criticality: **IMPORTANT** (affects virtually all desktop/laptop
> systems and many embedded devices)
>
> **Step 7.2: Subsystem Activity**
> - Very active — multiple fixes per release cycle.
>
> ## PHASE 8: IMPACT AND RISK ASSESSMENT
>
> **Step 8.1: Affected Users**
> - Every system with HID devices (USB, Bluetooth, I2C) — essentially
> universal for desktops/laptops.
>
> **Step 8.2: Trigger Conditions**
> - A HID device sends a report shorter than the expected report size.
> - Can be triggered by: malicious USB devices, faulty/buggy HID devices,
> or specific device configurations.
> - Potentially exploitable via USB (e.g., BadUSB attacks).
> - Record: [Trigger: short HID report] [Moderate likelihood for
> accidental, high for deliberate]
>
> **Step 8.3: Failure Mode**
> - **OOB write**: memset writes past buffer boundary → memory corruption,
> potential code execution
> - **OOB read**: subsequent `hid_process_report()` reads past buffer →
> info leak or crash
> - Severity: **CRITICAL** (OOB writes = security vulnerability, potential
> crash/corruption)
>
> **Step 8.4: Risk-Benefit**
> - Benefit: **VERY HIGH** — prevents OOB writes in a core, universally-
> used kernel path. Addresses a class of bugs that has caused multiple
> CVEs/crashes historically.
> - Risk: **VERY LOW** — 4-line change, simple logic (reject vs. pad),
> maintainer acknowledged 99% of cases won't be affected, accepted the
> tradeoff.
> - Ratio: Strongly favors backporting.
>
> ## PHASE 9: FINAL SYNTHESIS
>
> **Step 9.1: Evidence Summary**
>
> FOR backporting:
> - Fixes OOB writes and reads (security-critical memory safety bug)
> - In HID core — affects all HID users (universal impact)
> - Very small change: 4 lines, single function, single file
> - Bug exists since 2008 — present in ALL stable trees
> - Long history of crashes/CVEs from this exact memset (966922f, 5ebdffd,
> ec61b41)
> - Reviewed and applied by HID co-maintainer (Tissoires)
> - Suggested by the maintainer himself
> - Fix is the definitive solution after years of band-aid fixes
>
> AGAINST backporting:
> - Uses `hid_warn_ratelimited` not available before v6.18 (trivially
> adaptable)
> - Tissoires noted potential for breaking devices relying on zero-padding
> (accepted risk)
> - No explicit stable nomination (expected for candidates)
>
> **Step 9.2: Stable Rules Checklist**
> 1. Obviously correct and tested? **YES** — reviewed by maintainer,
> iterated through 3 versions
> 2. Fixes a real bug? **YES** — OOB write/read in HID core
> 3. Important issue? **YES** — security vulnerability (OOB write),
> potential crash/corruption
> 4. Small and contained? **YES** — 4 lines, single function
> 5. No new features or APIs? **YES** — behavior change only (reject
> instead of pad)
> 6. Can apply to stable? **YES** — with trivial adaptation for
> hid_warn_ratelimited
>
> **Step 9.3: Exception Categories**
> - Not an exception category — this is a standard critical bug fix.
>
> **Step 9.4: Decision**
> This is a clear YES. A 4-line fix to a critical OOB write vulnerability
> in the core HID input path, present since 2008, with a long history of
> related crashes, endorsed by the HID co-maintainer.
>
> ## Verification
>
> - [Phase 1] Parsed tags: Suggested-by Tissoires, SOB by Lee Jones and
> Tissoires (maintainer applied)
> - [Phase 2] Diff analysis: +4/-3 lines in hid_report_raw_event(),
> replaces memset+dbg_hid with warn+return -EINVAL
> - [Phase 3] git blame: buggy memset from commit 85cdaf524b7dda (2008,
> v2.6.26), present in all stable trees
> - [Phase 3] git log: found 3 prior fixes to same memset area (966922f,
> 5ebdffd, b1a37ed) — confirms recurring issue
> - [Phase 3] Author: Lee Jones authored the max_buffer_size hardening
> (b1a37ed), experienced with this code
> - [Phase 4] lore.kernel.org: v1 reviewed by Tissoires who requested
> stronger approach; v3 accepted with -EINVAL return; maintainer noted
> "works in 99% of cases"
> - [Phase 5] Callers: hid_report_raw_event() called from
> __hid_input_report() (core path) and 6+ drivers
> - [Phase 6] hid_warn_ratelimited introduced in v6.18 (1d64624243af8) —
> verified not in v6.12/6.14/6.15/6.16/6.17; needs trivial adaptation
> for older trees
> - [Phase 6] Companion patch e716edafedad4 is independent (hid-
> multitouch.c report ID check), not a prerequisite
> - [Phase 8] Failure mode: OOB writes via memset → memory corruption,
> severity CRITICAL
> - UNVERIFIED: Exact behavior with specific HID devices that send
> intentionally short reports (Tissoires accepted the risk)
>
> **YES**
>
> drivers/hid/hid-core.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index a5b3a8ca2fcbc..f5587b786f875 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2057,9 +2057,10 @@ 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);
> + ret = -EINVAL;
> + goto out;
> }
>
> if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
^ permalink raw reply
* Re: [PATCH] hid: usbhid: fix deadlock in hid_post_reset()
From: Oliver Neukum @ 2026-03-30 11:43 UTC (permalink / raw)
To: Jiri Kosina; +Cc: bentiss, linux-input, linux-usb
In-Reply-To: <8q66o2o4-7844-6p76-9964-7pr205p190pr@xreary.bet>
On 27.03.26 11:34, Jiri Kosina wrote:
> Did you find this just by code inspection, or was this reported with a
> real device?
Pure inspection. We are looking at USB error handling
in general right now.
Regards
Oliver
^ permalink raw reply
* [PATCH 2/4] Input: appletouch - refactor endpoint lookup
From: Johan Hovold @ 2026-03-30 9:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
Use the common USB helpers for looking up interrupt-in endpoints (and
determining endpoint numbers) instead of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/input/mouse/appletouch.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index 87d8f5afdfd9..eebeb57515e1 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -829,29 +829,20 @@ static int atp_probe(struct usb_interface *iface,
struct atp *dev;
struct input_dev *input_dev;
struct usb_device *udev = interface_to_usbdev(iface);
- struct usb_host_interface *iface_desc;
- struct usb_endpoint_descriptor *endpoint;
- int int_in_endpointAddr = 0;
- int i, error = -ENOMEM;
+ struct usb_endpoint_descriptor *ep;
+ int error;
const struct atp_info *info = (const struct atp_info *)id->driver_info;
/* set up the endpoint information */
/* use only the first interrupt-in endpoint */
- iface_desc = iface->cur_altsetting;
- for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
- endpoint = &iface_desc->endpoint[i].desc;
- if (!int_in_endpointAddr && usb_endpoint_is_int_in(endpoint)) {
- /* we found an interrupt in endpoint */
- int_in_endpointAddr = endpoint->bEndpointAddress;
- break;
- }
- }
- if (!int_in_endpointAddr) {
+ error = usb_find_int_in_endpoint(iface->cur_altsetting, &ep);
+ if (error) {
dev_err(&iface->dev, "Could not find int-in endpoint\n");
return -EIO;
}
/* allocate memory for our device state and initialize it */
+ error = -ENOMEM;
dev = kzalloc_obj(*dev);
input_dev = input_allocate_device();
if (!dev || !input_dev) {
@@ -875,7 +866,7 @@ static int atp_probe(struct usb_interface *iface,
goto err_free_urb;
usb_fill_int_urb(dev->urb, udev,
- usb_rcvintpipe(udev, int_in_endpointAddr),
+ usb_rcvintpipe(udev, usb_endpoint_num(ep)),
dev->data, dev->info->datalen,
dev->info->callback, dev, 1);
--
2.52.0
^ permalink raw reply related
* [PATCH 1/4] Input: keyspan-remote - refactor endpoint lookup
From: Johan Hovold @ 2026-03-30 9:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
Use the common USB helper for looking up interrupt-in endpoints instead
of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/input/misc/keyspan_remote.c | 22 ++--------------------
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/input/misc/keyspan_remote.c b/drivers/input/misc/keyspan_remote.c
index 152633bd2266..70cd6586459e 100644
--- a/drivers/input/misc/keyspan_remote.c
+++ b/drivers/input/misc/keyspan_remote.c
@@ -420,24 +420,6 @@ static void keyspan_close(struct input_dev *dev)
usb_kill_urb(remote->irq_urb);
}
-static struct usb_endpoint_descriptor *keyspan_get_in_endpoint(struct usb_host_interface *iface)
-{
-
- struct usb_endpoint_descriptor *endpoint;
- int i;
-
- for (i = 0; i < iface->desc.bNumEndpoints; ++i) {
- endpoint = &iface->endpoint[i].desc;
-
- if (usb_endpoint_is_int_in(endpoint)) {
- /* we found our interrupt in endpoint */
- return endpoint;
- }
- }
-
- return NULL;
-}
-
/*
* Routine that sets up the driver to handle a specific USB device detected on the bus.
*/
@@ -449,8 +431,8 @@ static int keyspan_probe(struct usb_interface *interface, const struct usb_devic
struct input_dev *input_dev;
int i, error;
- endpoint = keyspan_get_in_endpoint(interface->cur_altsetting);
- if (!endpoint)
+ error = usb_find_int_in_endpoint(interface->cur_altsetting, &endpoint);
+ if (error)
return -ENODEV;
remote = kzalloc_obj(*remote);
--
2.52.0
^ permalink raw reply related
* [PATCH 4/4] Input: usbtouchscreen - refactor endpoint lookup
From: Johan Hovold @ 2026-03-30 9:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
Use the common USB helpers for looking up bulk and interrupt endpoints
(and determining endpoint numbers) instead of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/input/touchscreen/usbtouchscreen.c | 38 +++++++---------------
1 file changed, 12 insertions(+), 26 deletions(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 657555c8796c..edc809d0f773 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -969,24 +969,21 @@ static int nexio_init(struct usbtouch_usb *usbtouch)
{
struct usb_device *dev = interface_to_usbdev(usbtouch->interface);
struct usb_host_interface *interface = usbtouch->interface->cur_altsetting;
+ struct usb_endpoint_descriptor *ep_in, *ep_out;
struct nexio_priv *priv = usbtouch->priv;
- int ret = -ENOMEM;
int actual_len, i;
char *firmware_ver = NULL, *device_name = NULL;
- int input_ep = 0, output_ep = 0;
+ int input_ep, output_ep;
+ int ret;
/* find first input and output endpoint */
- for (i = 0; i < interface->desc.bNumEndpoints; i++) {
- if (!input_ep &&
- usb_endpoint_dir_in(&interface->endpoint[i].desc))
- input_ep = interface->endpoint[i].desc.bEndpointAddress;
- if (!output_ep &&
- usb_endpoint_dir_out(&interface->endpoint[i].desc))
- output_ep = interface->endpoint[i].desc.bEndpointAddress;
- }
- if (!input_ep || !output_ep)
+ ret = usb_find_common_endpoints(interface, &ep_in, &ep_out, NULL, NULL);
+ if (ret)
return -ENXIO;
+ input_ep = usb_endpoint_num(ep_in);
+ output_ep = usb_endpoint_num(ep_out);
+
u8 *buf __free(kfree) = kmalloc(NEXIO_BUFSIZE, GFP_NOIO);
if (!buf)
return -ENOMEM;
@@ -1427,18 +1424,6 @@ static void usbtouch_free_buffers(struct usb_device *udev,
kfree(usbtouch->buffer);
}
-static struct usb_endpoint_descriptor *
-usbtouch_get_input_endpoint(struct usb_host_interface *interface)
-{
- int i;
-
- for (i = 0; i < interface->desc.bNumEndpoints; i++)
- if (usb_endpoint_dir_in(&interface->endpoint[i].desc))
- return &interface->endpoint[i].desc;
-
- return NULL;
-}
-
static int usbtouch_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1447,17 +1432,18 @@ static int usbtouch_probe(struct usb_interface *intf,
struct usb_endpoint_descriptor *endpoint;
struct usb_device *udev = interface_to_usbdev(intf);
const struct usbtouch_device_info *type;
- int err = -ENOMEM;
+ int err;
/* some devices are ignored */
type = (const struct usbtouch_device_info *)id->driver_info;
if (!type)
return -ENODEV;
- endpoint = usbtouch_get_input_endpoint(intf->cur_altsetting);
- if (!endpoint)
+ err = usb_find_int_in_endpoint(intf->cur_altsetting, &endpoint);
+ if (err)
return -ENXIO;
+ err = -ENOMEM;
usbtouch = kzalloc_obj(*usbtouch);
input_dev = input_allocate_device();
if (!usbtouch || !input_dev)
--
2.52.0
^ permalink raw reply related
* [PATCH 0/4] Input: refactor USB endpoint lookups
From: Johan Hovold @ 2026-03-30 9:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
Use the common USB helpers for looking up bulk and interrupt endpoints
instead of open coding.
Johan
Johan Hovold (4):
Input: keyspan-remote - refactor endpoint lookup
Input: appletouch - refactor endpoint lookup
Input: synaptics_usb - refactor endpoint lookup
Input: usbtouchscreen - refactor endpoint lookup
drivers/input/misc/keyspan_remote.c | 22 ++-----------
drivers/input/mouse/appletouch.c | 21 ++++--------
drivers/input/mouse/synaptics_usb.c | 23 ++-----------
drivers/input/touchscreen/usbtouchscreen.c | 38 +++++++---------------
4 files changed, 22 insertions(+), 82 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH 3/4] Input: synaptics_usb - refactor endpoint lookup
From: Johan Hovold @ 2026-03-30 9:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Johan Hovold
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
Use the common USB helper for looking up interrupt-in endpoints instead
of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/input/mouse/synaptics_usb.c | 23 ++---------------------
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/input/mouse/synaptics_usb.c b/drivers/input/mouse/synaptics_usb.c
index 5a86f6f387d8..880a0c79148c 100644
--- a/drivers/input/mouse/synaptics_usb.c
+++ b/drivers/input/mouse/synaptics_usb.c
@@ -220,25 +220,6 @@ static void synusb_irq(struct urb *urb)
__func__, error);
}
-static struct usb_endpoint_descriptor *
-synusb_get_in_endpoint(struct usb_host_interface *iface)
-{
-
- struct usb_endpoint_descriptor *endpoint;
- int i;
-
- for (i = 0; i < iface->desc.bNumEndpoints; ++i) {
- endpoint = &iface->endpoint[i].desc;
-
- if (usb_endpoint_is_int_in(endpoint)) {
- /* we found our interrupt in endpoint */
- return endpoint;
- }
- }
-
- return NULL;
-}
-
static int synusb_open(struct input_dev *dev)
{
struct synusb *synusb = input_get_drvdata(dev);
@@ -307,8 +288,8 @@ static int synusb_probe(struct usb_interface *intf,
return error;
}
- ep = synusb_get_in_endpoint(intf->cur_altsetting);
- if (!ep)
+ error = usb_find_int_in_endpoint(intf->cur_altsetting, &ep);
+ if (error)
return -ENODEV;
synusb = kzalloc_obj(*synusb);
--
2.52.0
^ permalink raw reply related
* [PATCH] HID: usbhid: refactor endpoint lookup
From: Johan Hovold @ 2026-03-30 9:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-usb, linux-input, linux-kernel, Johan Hovold
Use the common USB helper for looking up interrupt-in endpoints instead
of open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/hid/usbhid/hid-core.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ddd5d77fb5a5..2447bc7cb7a1 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1363,19 +1363,17 @@ static int usbhid_probe(struct usb_interface *intf, const struct usb_device_id *
{
struct usb_host_interface *interface = intf->cur_altsetting;
struct usb_device *dev = interface_to_usbdev(intf);
+ struct usb_endpoint_descriptor *ep;
struct usbhid_device *usbhid;
struct hid_device *hid;
- unsigned int n, has_in = 0;
size_t len;
int ret;
dbg_hid("HID probe called for ifnum %d\n",
intf->altsetting->desc.bInterfaceNumber);
- for (n = 0; n < interface->desc.bNumEndpoints; n++)
- if (usb_endpoint_is_int_in(&interface->endpoint[n].desc))
- has_in++;
- if (!has_in) {
+ ret = usb_find_int_in_endpoint(interface, &ep);
+ if (ret) {
hid_err(intf, "couldn't find an input interrupt endpoint\n");
return -ENODEV;
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: Chen-Yu Tsai @ 2026-03-30 9:35 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, 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, Louis-Alexis Eyraud, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2J355NZH=7iQ9sTDBhAmtjP7xTpXe21_3Z9J_R5YvdXAQ@mail.gmail.com>
On Mon, Mar 30, 2026 at 3:39 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> Il giorno gio 19 mar 2026 alle ore 06:04 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
>
> > If this PMIC is anything like the MT6358, then it has 0.01V fine
> > tuning for most if not all the LDOs. It is sometimes needed as
> > a rail may have a 0.04V boost that would otherwise be invisible
> > to the system. And then if you have something like 3.04V set in
> > the DT constraints, you end up with something the regulator driver
> > doesn't support, but the hardware does.
> >
> > Please see how it's done in the MT6358 driver. I spent a lot of
> > time on that driver to make it actually support the full range
> > of voltages, and describing the supplies.
> >
>
> I had a good look at the datasheet (MT6392 PMIC Datasheet v1.0 08 Dec.
> 2016) and unfortunately I did not see any fine tuning option in there.
> I'm sure this data sheet is not perfect as it's missing some regulator
> registers that are clearly used in the Android sources, but there's no
> mention of fine tuning in that code either. I guess it does not have
> that capability.
Well, thanks for looking. FWIW on the MT6358 / MT6366, the main voltage
control and the fine tuning are mostly in the same register. The fine
tuning is described as "calibrates output voltage" from +00mV to +100mV.
I looked into this because the LDO table shows some of the default voltages
with 0.01V precision, but the main voltage controls only have 0.1V precision.
ChenYu
> I will shortly submit v4 that hopefully addresses the rest of the comments.
>
> Thanks for your help!
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2] MIPS/input: Move RB532 button to GPIO descriptors
From: Bartosz Golaszewski @ 2026-03-30 9:12 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-mips, linux-input, linux-gpio, linux-mtd,
Thomas Bogendoerfer, Dmitry Torokhov, Bartosz Golaszewski,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
In-Reply-To: <20260328-mips-input-rb532-button-v1-1-98e201621501@kernel.org>
On Sat, 28 Mar 2026 16:55:47 +0100, Linus Walleij <linusw@kernel.org> said:
> Convert the Mikrotik RouterBoard RB532 to use GPIO descriptors
> by defining a software node for the GPIO chip, then register
> the button platform device with full info passing the GPIO
> as a device property.
>
> This can be used as a base to move more of the RB532 devices
> over to passing GPIOs using device properties.
>
> Use the GPIO_ACTIVE_LOW flag and drop the inversion in the
> rb532_button_pressed() function.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> arch/mips/rb532/devices.c | 47 +++++++++++++++++++++++++++++++++------
> drivers/input/misc/rb532_button.c | 35 ++++++++++++++++++++++++-----
> 2 files changed, 69 insertions(+), 13 deletions(-)
>
> diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
> index 4f027efbf27b..3f56d9feb73a 100644
> --- a/arch/mips/rb532/devices.c
> +++ b/arch/mips/rb532/devices.c
> @@ -16,8 +16,10 @@
> #include <linux/mtd/mtd.h>
> #include <linux/gpio.h>
> #include <linux/gpio/machine.h>
> +#include <linux/gpio/property.h>
> #include <linux/gpio_keys.h>
> #include <linux/input.h>
> +#include <linux/property.h>
> #include <linux/serial_8250.h>
>
> #include <asm/bootinfo.h>
> @@ -38,6 +40,10 @@ extern unsigned int idt_cpu_freq;
>
> static struct mpmc_device dev3;
>
> +static const struct software_node rb532_gpio0_node = {
> + .name = "gpio0",
> +};
> +
Hi Linus!
I'm seeing patches from you lately using the pattern of "dangling software"
nodes that's documented under Documentation/driver-api/gpio/board.rst as the
recommended approach but which I have been trying to come up with a better
alternetive for and eventually phase out. I will post a series providing a way
to automatically assign software nodes as secondary firmware nodes for devices
and this series will also remove the offending bits from the docs.
As you're dealing with a board file here: could you assign the firmware node
you get after registering this software node to the target GPIO controller
under arch/mips/rb532/gpio.c so that the firmware node lookup can work by
matching the address rather than falling back to the label string matching?
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v4 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Luca Leonardo Scorcia @ 2026-03-30 8:29 UTC (permalink / raw)
To: linux-mediatek
Cc: 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, Julien Massot, Louis-Alexis Eyraud, Gary Bisson,
Fabien Parent, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-1-l.scorcia@gmail.com>
From: Val Packett <val@packett.cool>
Add the dts to be included by all boards using the MT6392 PMIC.
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
arch/arm64/boot/dts/mediatek/mt6392.dtsi | 73 ++++++++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
new file mode 100644
index 000000000000..750ee9b2856f
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Copyright (c) 2024 Val Packett <val@packett.cool>
+ */
+
+#include <dt-bindings/input/input.h>
+
+&pwrap {
+ pmic: pmic {
+ compatible = "mediatek,mt6392", "mediatek,mt6323";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ keys {
+ compatible = "mediatek,mt6392-keys";
+
+ key-power {
+ linux,keycodes = <KEY_POWER>;
+ wakeup-source;
+ };
+
+ key-home {
+ linux,keycodes = <KEY_HOME>;
+ wakeup-source;
+ };
+ };
+
+ pio6392: pinctrl {
+ compatible = "mediatek,mt6392-pinctrl";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ rtc {
+ compatible = "mediatek,mt6392-rtc",
+ "mediatek,mt6323-rtc";
+ };
+
+ mt6392regulators: regulators {
+ /* Fixed supply defined in the data sheet */
+ avddldo-supply = <&mt6392_vsys_reg>;
+
+ mt6392_vcore_reg: vcore { };
+ mt6392_vproc_reg: vproc { };
+ mt6392_vsys_reg: vsys { };
+ mt6392_vaud28_reg: vaud28 { };
+ mt6392_vxo22_reg: vxo22 { };
+ mt6392_vaud22_reg: vaud22 { };
+ mt6392_vadc18_reg: vadc18 { };
+ mt6392_vcama_reg: vcama { };
+ mt6392_vcn35_reg: vcn35 { };
+ mt6392_vio28_reg: vio28 { };
+ mt6392_vusb_reg: vusb { };
+ mt6392_vmc_reg: vmc { };
+ mt6392_vmch_reg: vmch { };
+ mt6392_vemc3v3_reg: vemc3v3 { };
+ mt6392_vcamaf_reg: vcamaf { };
+ mt6392_vgp1_reg: vgp1 { };
+ mt6392_vgp2_reg: vgp2 { };
+ mt6392_vefuse_reg: vefuse { };
+ mt6392_vm25_reg: vm25 { };
+ mt6392_vdig18_reg: vdig18 { };
+ mt6392_vm_reg: vm { };
+ mt6392_vio18_reg: vio18 { };
+ mt6392_vcn18_reg: vcn18 { };
+ mt6392_vcamd_reg: vcamd { };
+ mt6392_vcamio_reg: vcamio { };
+ mt6392_vrtc_reg: vrtc { };
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox