* Re: [PATCH] Input: serio - fix O(n^2) complexity in serio_unregister_driver()
From: Mohamad Raizudeen @ 2026-04-08 18:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: kees, linux-kernel, linux-input
In-Reply-To: <adaWU9rlMKcxLO1G@google.com>
On Wed, Apr 08, 2026 at 10:56:26AM -0700, Dmitry Torokhov wrote:
> On Wed, Apr 08, 2026 at 11:21:30PM +0530, Mohamad Raizudeen wrote:
> > Hi Dmitry,
>
> Please do not top-post.
>
> >
> > *We do not have such setups at the moment, but what about parent's parent's
> > parent?*
> > You are right. Even though we don't have such setups today, let me explain
> > why the patch works for arbitrary depth.
> >
> > If we have three ports linked like A->B->C (A is top, B is child of A, C is
> > child of B) and all use the same driver.
>
> What happens if B uses different driver from A?
>
> >
> > C sees its parent B is using the same driver, skip C
> > B sees its parent A is using the same driver, skip B
> > A has no parent using the same driver, collect A
> >
> > When we disconnect A, it automatically destroys B and C. So all ports are
> > cleaned up. The logic works for any number of levels.
> >
> > * Could you explain more about the use-after-free scenario?*
> > If we collected both A and B, disconnecting A would free B. Then when we
> > try to process B from the list, we would use memory that is already freed
> > that leads to crash. My patch avoids this by never collecting a port whose
> > parent is also using the same driver.
>
> But currently we restart scanning the list, so there won't be any stale
> entries. How would we end up with touching freed memory?
>
> Thanks.
>
> --
> Dmitry
Thank you for your careful review and for pointing out the mixed driver nestingscenario (A bound to driver X, B bound to driver Y, C bound to driver X). I completely missed that case.
You are right my
My patch would collect both A and C, then disconnecting A would detroy B and C, leading to a use-after-free when C is later processed from the temporary list. The original goto approach handles this correctly by restarting the scan.
I am sorry for sending a flawed patch. I will withdraw it.
I will try to deisign a better solution that works for all cases, includes mixed driver nesting, before submitting again.
Thank you again for your guidance.
Regards,
Mohamad Raizudeen.
^ permalink raw reply
* Re: [PATCH] Input: serio - fix O(n^2) complexity in serio_unregister_driver()
From: Dmitry Torokhov @ 2026-04-08 17:56 UTC (permalink / raw)
To: Mohamad Raizudeen; +Cc: kees, linux-input, linux-kernel
In-Reply-To: <CABkOv5cU8D8oo8scTOojvJ8hUeq4nxm6GGuA3GaBvebzdMBYpg@mail.gmail.com>
On Wed, Apr 08, 2026 at 11:21:30PM +0530, Mohamad Raizudeen wrote:
> Hi Dmitry,
Please do not top-post.
>
> *We do not have such setups at the moment, but what about parent's parent's
> parent?*
> You are right. Even though we don't have such setups today, let me explain
> why the patch works for arbitrary depth.
>
> If we have three ports linked like A->B->C (A is top, B is child of A, C is
> child of B) and all use the same driver.
What happens if B uses different driver from A?
>
> C sees its parent B is using the same driver, skip C
> B sees its parent A is using the same driver, skip B
> A has no parent using the same driver, collect A
>
> When we disconnect A, it automatically destroys B and C. So all ports are
> cleaned up. The logic works for any number of levels.
>
> * Could you explain more about the use-after-free scenario?*
> If we collected both A and B, disconnecting A would free B. Then when we
> try to process B from the list, we would use memory that is already freed
> that leads to crash. My patch avoids this by never collecting a port whose
> parent is also using the same driver.
But currently we restart scanning the list, so there won't be any stale
entries. How would we end up with touching freed memory?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v3 4/4] arm64: dts: rockchip: add analog audio to ROCK 4D
From: Nicolas Frattaroli @ 2026-04-08 17:49 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Nicolas Frattaroli, Cristian Ciocaltea
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
The RADXA ROCK 4D, like many other Rockchip-based boards, uses an ES8388
analog audio codec. On the production version of the board, the codec's
LOUT1 and ROUT1 pins are tied to the headphone jack, whereas pins LOUT2
and ROUT2 lead to a non-populated speaker amplifier that itself leads to
a non-populated speaker jack. The schematic is still haunted by the
ghosts of those symbols, but it clearly marks them as "NC".
The 3.5mm TRRS jack has its microphone ring (and ground ring) wired to
the codec's LINPUT1 and RINPUT1 pins for differential signalling.
Furthermore, it uses the SoCs ADC to detect whether the inserted cable
is of headphones (i.e., no microphone), or a headset (i.e., with
microphone). The way this is done is that the ADC input taps the output
of a 100K/100K resistor divider that divides the microphone ring pin
that's pulled up to 3.3V.
There is no ADC level difference between a completely empty jack and one
with a set of headphones (i.e., ones that don't have a microphone)
connected. Consequently headphone insertion detection isn't something
that can be done.
Add the necessary codec and audio card nodes. The non-populated parts,
i.e. LOUT2 and ROUT2, are not modeled at all, as they are not present on
the hardware.
Also, add an adc-keys node for the headset detection, which uses an
input type of EV_SW with the SW_MICROPHONE_INSERT keycode. Below the
220mV pressed voltage level of our SW_MICROPHONE_INSERT switch, we also
define a button that emits a KEY_RESERVED code, which is there to model
this part of the voltage range as not just being extra legroom for the
button above it, but actually a state that is encountered in the real
world, and should be recognised as a valid state for the ADC range to be
in so that no "closer" ADC button is chosen.
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 +++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
index 899a84b1fbf9..c848c706196e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/pwm/pwm.h>
@@ -37,6 +38,31 @@ hdmi_con_in: endpoint {
};
};
+ es8388_sound: es8388-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "On-board Analog ES8388";
+ simple-audio-card,widgets = "Microphone", "Headphone Mic",
+ "Headphone", "Headphone";
+ simple-audio-card,routing = "Headphone", "LOUT1",
+ "Headphone", "ROUT1",
+ "Left PGA Mux", "Differential Mux",
+ "Differential Mux", "LINPUT1",
+ "Differential Mux", "RINPUT1",
+ "LINPUT1", "Headphone Mic",
+ "RINPUT1", "Headphone Mic";
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
rfkill {
compatible = "rfkill-gpio";
pinctrl-names = "default";
@@ -65,6 +91,37 @@ user-led {
};
};
+ saradc_keys: adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 3>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <3000000>;
+ poll-interval = <100>;
+
+ /*
+ * During insertion and removal of a regular set of headphones,
+ * i.e. one without a microphone, the voltage level briefly
+ * dips below the 220mV of the headset connection switch.
+ * By having a button definition with a KEY_RESERVED signal
+ * between 0 to 220, we ensure no driver implementation thinks
+ * that the closest thing to 0V is 220mV so clearly there must
+ * be a headset connected.
+ */
+
+ button-headset-disconnected {
+ label = "Headset Microphone Disconnected";
+ linux,code = <KEY_RESERVED>;
+ press-threshold-microvolt = <0>;
+ };
+
+ button-headset-connected {
+ label = "Headset Microphone Connected";
+ linux,code = <SW_MICROPHONE_INSERT>;
+ linux,input-type = <EV_SW>;
+ press-threshold-microvolt = <220000>;
+ };
+ };
+
vcc_5v0_dcin: regulator-vcc-5v0-dcin {
compatible = "regulator-fixed";
regulator-always-on;
@@ -696,6 +753,25 @@ eeprom@50 {
};
};
+&i2c3 {
+ status = "okay";
+
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru CLK_SAI1_MCLKOUT_TO_IO>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcc_3v3_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clocks = <&cru CLK_SAI1_MCLKOUT_TO_IO>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sai1m0_mclk>;
+ };
+};
+
&mdio0 {
rgmii_phy0: ethernet-phy@1 {
compatible = "ethernet-phy-id001c.c916";
@@ -770,10 +846,24 @@ wifi_en_h: wifi-en-h {
};
};
+&sai1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sai1m0_lrck
+ &sai1m0_sclk
+ &sai1m0_sdi0
+ &sai1m0_sdo0>;
+ status = "okay";
+};
+
&sai6 {
status = "okay";
};
+&saradc {
+ vref-supply = <&vcca1v8_pldo2_s0>;
+ status = "okay";
+};
+
&sdmmc {
bus-width = <4>;
cap-mmc-highspeed;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/4] Input: adc-keys - Use dev_err_probe in probe function
From: Nicolas Frattaroli @ 2026-04-08 17:49 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Nicolas Frattaroli
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
Rework the probe function, and functions called by the probe function,
to use dev_err_probe for error logging.
While at it, also do some minor style cleanups, like not error logging
on -ENOMEM and using ! instead of == 0.
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/input/keyboard/adc-keys.c | 53 ++++++++++++++++-----------------------
1 file changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
index 62376f34f7d0..6f2ddcecea99 100644
--- a/drivers/input/keyboard/adc-keys.c
+++ b/drivers/input/keyboard/adc-keys.c
@@ -74,10 +74,8 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
int i;
st->num_keys = device_get_child_node_count(dev);
- if (st->num_keys == 0) {
- dev_err(dev, "keymap is missing\n");
- return -EINVAL;
- }
+ if (!st->num_keys)
+ return dev_err_probe(dev, -EINVAL, "keymap is missing\n");
map = devm_kmalloc_array(dev, st->num_keys, sizeof(*map), GFP_KERNEL);
if (!map)
@@ -86,17 +84,16 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
i = 0;
device_for_each_child_node_scoped(dev, child) {
if (fwnode_property_read_u32(child, "press-threshold-microvolt",
- &map[i].voltage)) {
- dev_err(dev, "Key with invalid or missing voltage\n");
- return -EINVAL;
- }
+ &map[i].voltage))
+ return dev_err_probe(dev, -EINVAL,
+ "Key with invalid or missing voltage\n");
+
map[i].voltage /= 1000;
if (fwnode_property_read_u32(child, "linux,code",
- &map[i].code)) {
- dev_err(dev, "Key with invalid or missing linux,code\n");
- return -EINVAL;
- }
+ &map[i].code))
+ return dev_err_probe(dev, -EINVAL,
+ "Key with invalid or missing linux,code\n");
if (fwnode_property_read_u32(child, "linux,input-type",
&map[i].type))
@@ -129,7 +126,8 @@ static int adc_keys_probe(struct platform_device *pdev)
st->channel = devm_iio_channel_get(dev, "buttons");
if (IS_ERR(st->channel))
- return PTR_ERR(st->channel);
+ return dev_err_probe(dev, PTR_ERR(st->channel),
+ "Could not get iio channel\n");
if (!st->channel->indio_dev)
return -ENXIO;
@@ -138,16 +136,13 @@ static int adc_keys_probe(struct platform_device *pdev)
if (error < 0)
return error;
- if (type != IIO_VOLTAGE) {
- dev_err(dev, "Incompatible channel type %d\n", type);
- return -EINVAL;
- }
+ if (type != IIO_VOLTAGE)
+ return dev_err_probe(dev, -EINVAL, "Incompatible channel type %d\n", type);
if (device_property_read_u32(dev, "keyup-threshold-microvolt",
- &st->keyup_voltage)) {
- dev_err(dev, "Invalid or missing keyup voltage\n");
- return -EINVAL;
- }
+ &st->keyup_voltage))
+ return dev_err_probe(dev, -EINVAL, "Invalid or missing keyup voltage\n");
+
st->keyup_voltage /= 1000;
error = adc_keys_load_keymap(dev, st);
@@ -155,10 +150,8 @@ static int adc_keys_probe(struct platform_device *pdev)
return error;
input = devm_input_allocate_device(dev);
- if (!input) {
- dev_err(dev, "failed to allocate input device\n");
+ if (!input)
return -ENOMEM;
- }
input_set_drvdata(input, st);
@@ -178,19 +171,15 @@ static int adc_keys_probe(struct platform_device *pdev)
error = input_setup_polling(input, adc_keys_poll);
- if (error) {
- dev_err(dev, "Unable to set up polling: %d\n", error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error, "Unable to set up polling\n");
if (!device_property_read_u32(dev, "poll-interval", &value))
input_set_poll_interval(input, value);
error = input_register_device(input);
- if (error) {
- dev_err(dev, "Unable to register input device: %d\n", error);
- return error;
- }
+ if (error)
+ return dev_err_probe(dev, error, "Unable to register input device\n");
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/4] Input: adc-keys - support EV_SW as well, not just EV_KEY.
From: Nicolas Frattaroli @ 2026-04-08 17:49 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Nicolas Frattaroli
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
Instead of doing something like what gpio-keys is doing, adc-keys
hardcodes that all keycodes must be of type EV_KEY.
This limits the usefulness of adc-keys, and overcomplicates the code
with manual bit-setting logic.
Instead, refactor the code to read the linux,input-type fwnode property,
and get rid of the custom bit setting logic, replacing it with
input_set_capability instead. input_report_key is replaced with
input_event, which allows us to explicitly pass the type.
Only EV_KEY and EV_SW is allowed at this stage.
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/input/keyboard/adc-keys.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
index f1753207429d..62376f34f7d0 100644
--- a/drivers/input/keyboard/adc-keys.c
+++ b/drivers/input/keyboard/adc-keys.c
@@ -18,13 +18,15 @@
struct adc_keys_button {
u32 voltage;
- u32 keycode;
+ u32 code;
+ u32 type;
};
struct adc_keys_state {
struct iio_channel *channel;
u32 num_keys;
u32 last_key;
+ u32 last_type;
u32 keyup_voltage;
const struct adc_keys_button *map;
};
@@ -34,7 +36,8 @@ static void adc_keys_poll(struct input_dev *input)
struct adc_keys_state *st = input_get_drvdata(input);
int i, value, ret;
u32 diff, closest = 0xffffffff;
- int keycode = 0;
+ u32 code = 0;
+ u32 type = EV_KEY;
ret = iio_read_channel_processed(st->channel, &value);
if (unlikely(ret < 0)) {
@@ -45,22 +48,24 @@ static void adc_keys_poll(struct input_dev *input)
diff = abs(st->map[i].voltage - value);
if (diff < closest) {
closest = diff;
- keycode = st->map[i].keycode;
+ code = st->map[i].code;
+ type = st->map[i].type;
}
}
}
if (abs(st->keyup_voltage - value) < closest)
- keycode = 0;
+ code = 0;
- if (st->last_key && st->last_key != keycode)
- input_report_key(input, st->last_key, 0);
+ if (st->last_key && st->last_key != code)
+ input_event(input, st->last_type, st->last_key, 0);
- if (keycode)
- input_report_key(input, keycode, 1);
+ if (code)
+ input_event(input, type, code, 1);
input_sync(input);
- st->last_key = keycode;
+ st->last_key = code;
+ st->last_type = type;
}
static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
@@ -88,11 +93,20 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
map[i].voltage /= 1000;
if (fwnode_property_read_u32(child, "linux,code",
- &map[i].keycode)) {
+ &map[i].code)) {
dev_err(dev, "Key with invalid or missing linux,code\n");
return -EINVAL;
}
+ if (fwnode_property_read_u32(child, "linux,input-type",
+ &map[i].type))
+ map[i].type = EV_KEY;
+
+ if (map[i].type != EV_KEY && map[i].type != EV_SW)
+ return dev_err_probe(dev, -EINVAL,
+ "Invalid linux,input-type: 0x%x\n",
+ map[i].type);
+
i++;
}
@@ -156,9 +170,8 @@ static int adc_keys_probe(struct platform_device *pdev)
input->id.product = 0x0001;
input->id.version = 0x0100;
- __set_bit(EV_KEY, input->evbit);
for (i = 0; i < st->num_keys; i++)
- __set_bit(st->map[i].keycode, input->keybit);
+ input_set_capability(input, st->map[i].type, st->map[i].code);
if (device_property_read_bool(dev, "autorepeat"))
__set_bit(EV_REP, input->evbit);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: input: adc-keys: allow all input properties
From: Nicolas Frattaroli @ 2026-04-08 17:49 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Nicolas Frattaroli, Krzysztof Kozlowski
In-Reply-To: <20260408-rock4d-audio-v3-0-49e43c3c2a68@collabora.com>
adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
property. This makes it impossible to model devices that have ADC inputs
that should generate switch events.
Replace "additionalProperties" with "unevaluatedProperties", so that any
of the properties in the referenced input.yaml schema can be used.
Consequently, throw out the explicit mention of "linux,code" and extend
the example to verify.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/devicetree/bindings/input/adc-keys.yaml | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/adc-keys.yaml b/Documentation/devicetree/bindings/input/adc-keys.yaml
index 7aa078dead37..f216bb874f26 100644
--- a/Documentation/devicetree/bindings/input/adc-keys.yaml
+++ b/Documentation/devicetree/bindings/input/adc-keys.yaml
@@ -33,15 +33,13 @@ patternProperties:
'^button-':
type: object
$ref: input.yaml#
- additionalProperties: false
+ unevaluatedProperties: false
description:
Each button (key) is represented as a sub-node.
properties:
label: true
- linux,code: true
-
press-threshold-microvolt:
description:
Voltage above or equal to which this key is considered pressed. No
@@ -65,7 +63,9 @@ examples:
- |
#include <dt-bindings/input/input.h>
// +--------------------------------+------------------------+
- // | 2.000.000 <= value | no key pressed |
+ // | 2.500.000 <= value | no key pressed |
+ // +--------------------------------+------------------------+
+ // | 2.000.000 <= value < 2.500.000 | Mic Insert Switch on |
// +--------------------------------+------------------------+
// | 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed |
// +--------------------------------+------------------------+
@@ -80,7 +80,14 @@ examples:
compatible = "adc-keys";
io-channels = <&lradc 0>;
io-channel-names = "buttons";
- keyup-threshold-microvolt = <2000000>;
+ keyup-threshold-microvolt = <2500000>;
+
+ button-headset-connected {
+ label = "Headset Microphone Connected";
+ linux,code = <SW_MICROPHONE_INSERT>;
+ linux,input-type = <EV_SW>;
+ press-threshold-microvolt = <2000000>;
+ };
button-up {
label = "Volume Up";
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/4] ROCK 4D audio enablement
From: Nicolas Frattaroli @ 2026-04-08 17:49 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner
Cc: kernel, linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, Nicolas Frattaroli, Krzysztof Kozlowski,
Cristian Ciocaltea
The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
no mic) and a headset (i.e., with mic). After some searching, it appears
that the closest we can get to modelling this is by sending a particular
switch input event.
So this series modifies the adc-keys bindings, extends the adc-keys
driver to allow sending other input types as well, and then adds the
analog audio nodes to ROCK 4D's device tree.
It should be noted that analog capture from the TRRS jack currently
results in completely digitally silent audio for me, i.e. no data other
than 0xFF. There's a few reasons why this could happen, chief among them
that my SAI driver is broken or that the ES8328 codec driver is once
again broken. The DAPM routes when graphed out look fine though. So the
DTS part is correct, and I can fix the broken capture in a separate
follow-up patch that doesn't have to include DT people.
Another possibility is that my phone headset, despite being 4 rings and
having a little pin hole at the back of the volume doodad, does not
actually have a microphone, but in that case I'd still expect some noise
in the PCM. Maybe it's just shy.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v3:
- bindings: use unevaluatedProperties instead of explicitly mentioning
linux,input-type.
- Link to v2: https://lore.kernel.org/r/20251215-rock4d-audio-v2-0-82a61de39b4c@collabora.com
Changes in v2:
- Drop HDMI audio patch, as it was already merged.
- adc-keys: rename "keycode" to "code".
- adc-keys: make the keycode (now "code") local a u32 instead of an int
- adc-keys: only allow EV_KEY and EV_SW for now. Rename patch
accordingly.
- adc-keys: Add another patch to rework probe function error logging.
- Link to v1: https://lore.kernel.org/r/20250630-rock4d-audio-v1-0-0b3c8e8fda9c@collabora.com
---
Nicolas Frattaroli (4):
dt-bindings: input: adc-keys: allow all input properties
Input: adc-keys - support EV_SW as well, not just EV_KEY.
Input: adc-keys - Use dev_err_probe in probe function
arm64: dts: rockchip: add analog audio to ROCK 4D
.../devicetree/bindings/input/adc-keys.yaml | 17 ++--
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 ++++++++++++++++++++++
drivers/input/keyboard/adc-keys.c | 88 ++++++++++-----------
3 files changed, 147 insertions(+), 48 deletions(-)
---
base-commit: 8de395f35e79d9168a78504fed495578ec7bac52
change-id: 20250627-rock4d-audio-cfc07f168a08
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply
* Re: [PATCH v2] xpad: Overhaul device data for wireless devices
From: Roman Gushchin @ 2026-04-08 17:45 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Antheas Kapenekakis, Sanjay Govind, Vicki Pfau, Nilton Perim Neto,
Mario Limonciello, Pierre-Loup A. Griffais, linux-input,
linux-kernel
In-Reply-To: <adaOmEQNXXPhxmmx@google.com>
> On Apr 8, 2026, at 10:24 AM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> On Wed, Apr 08, 2026 at 05:47:06PM +0200, Antheas Kapenekakis wrote:
>>> On Wed, 8 Apr 2026 at 07:04, Sanjay Govind <sanjay.govind9@gmail.com> wrote:
>>>
>>> On Wed, Apr 8, 2026 at 4:52 PM Dmitry Torokhov
>>> <dmitry.torokhov@gmail.com> wrote:
>>>> I think you'd have to spin up your own instance for that...
>>>
>>> makes sense
>>>
>>
>> Hi Sanjay,
>> I have a workflow for running an llm and getting reviews locally.
>> Perhaps I will post it to the mailing list soon. I can cc you. I have
>> been out for the Easter holidays
>>
>> Of course, you will need your own LLM and harness for that, Claude
>> code/Antigravity/Copilot/Opencode, etc. I know they aren't
>> particularly cheap.
>>
>> Dmitry, sashiko looks great, I left a star. I could also cc you. I
>> will also reference the prompts used in that as it claims some
>> subsystem specific ones. From a quick glance it seems to might suffer
>> from context bloat though. There are a lot of guideline files that
>> could have higher information density.
>
> I am just a happy user of sashiko, I'll leave it to Roman to comment on
> the potential bloat concerns.
All I can say is Sashiko is an open-source project and I’m happy to take
any pull requests (including alternative prompts) which are improving
the quality of reviews. I’m not attached to any particular approach to the
prompting and happy to change it assuming there is data showing that
some other approach is better.
Thanks!
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg via B4 Relay @ 2026-04-08 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
In-Reply-To: <20260408-synaptics-rmi4-dt-v1-0-2d32bacce673@ixit.cz>
From: David Heidelberg <david@ixit.cz>
We know the driver is reporting s3706b, introduce the compatible so we
can more easily introduce quirks for weird touchscreen replacements in
followup series.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
index 6b7378cf4d493..148164d456a5a 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
@@ -480,7 +480,7 @@ &i2c12 {
clock-frequency = <400000>;
synaptics-rmi4-i2c@20 {
- compatible = "syna,rmi4-i2c";
+ compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
reg = <0x20>;
#address-cells = <1>;
#size-cells = <0>;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: David Heidelberg via B4 Relay @ 2026-04-08 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
In-Reply-To: <20260408-synaptics-rmi4-dt-v1-0-2d32bacce673@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Mostly irrelevant for authentic Synaptics touchscreens, but very important
for applying workarounds to cheap TS knockoffs.
These knockoffs work well with the downstream driver, and since the user
has no way to distinguish them, later in this patch set, we introduce
workarounds to ensure they function as well as possible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index 8685ef4481f4a..fb4804ac3544d 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -18,9 +18,14 @@ description: |
properties:
compatible:
- enum:
- - syna,rmi4-i2c
- - syna,rmi4-spi
+ oneOf:
+ - enum:
+ - syna,rmi4-i2c
+ - syna,rmi4-spi
+ - items:
+ - enum:
+ - syna,rmi4-s3706b # OnePlus 6/6T
+ - const: syna,rmi4-i2c
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] Introduce OnePlus 6/6T touchscreen compatible
From: David Heidelberg via B4 Relay @ 2026-04-08 17:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
David Heidelberg, Krzysztof Kozlowski
Mostly related to the
https://codeberg.org/sdm845/linux/commits/branch/b4/synaptics-rmi4
series, but independent on other changes which I trying to upstream for
more than one year.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
David Heidelberg (2):
dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 11 ++++++++---
arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-synaptics-rmi4-dt-8aebf31790dc
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH v2] xpad: Overhaul device data for wireless devices
From: Dmitry Torokhov @ 2026-04-08 17:23 UTC (permalink / raw)
To: Antheas Kapenekakis, Roman Gushchin
Cc: Sanjay Govind, Vicki Pfau, Nilton Perim Neto, Mario Limonciello,
Pierre-Loup A. Griffais, linux-input, linux-kernel
In-Reply-To: <CAGwozwEoFWG-sQAbT8zxqEg8Q=+=xULj-a9y7yoEqu3ehZtSUw@mail.gmail.com>
On Wed, Apr 08, 2026 at 05:47:06PM +0200, Antheas Kapenekakis wrote:
> On Wed, 8 Apr 2026 at 07:04, Sanjay Govind <sanjay.govind9@gmail.com> wrote:
> >
> > On Wed, Apr 8, 2026 at 4:52 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > I think you'd have to spin up your own instance for that...
> >
> > makes sense
> >
>
> Hi Sanjay,
> I have a workflow for running an llm and getting reviews locally.
> Perhaps I will post it to the mailing list soon. I can cc you. I have
> been out for the Easter holidays
>
> Of course, you will need your own LLM and harness for that, Claude
> code/Antigravity/Copilot/Opencode, etc. I know they aren't
> particularly cheap.
>
> Dmitry, sashiko looks great, I left a star. I could also cc you. I
> will also reference the prompts used in that as it claims some
> subsystem specific ones. From a quick glance it seems to might suffer
> from context bloat though. There are a lot of guideline files that
> could have higher information density.
I am just a happy user of sashiko, I'll leave it to Roman to comment on
the potential bloat concerns.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Nicolas Frattaroli @ 2026-04-08 17:11 UTC (permalink / raw)
To: Rob Herring, Dmitry Torokhov
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Heiko Stuebner, kernel, linux-input,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <adaJOEZHHmvZM_cB@google.com>
On Wednesday, 8 April 2026 18:59:08 Central European Summer Time Dmitry Torokhov wrote:
> On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> > On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > > On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > > > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > > > property. This makes it impossible to model devices that have ADC inputs
> > > > > that should generate switch events.
> > > >
> > > > The solution is to use unevaluatedProps instead, which also allows
> > > > dropping other properties.
> > > >
> > > > Best regards,
> > > > Krzysztof
> > > >
> > > >
> > >
> > > Hi Krzysztof,
> > >
> > > to understand the motivation behind this suggestion correctly:
> > > are the "linux," vendor prefixed properties, especially with regards
> > > to key codes, generally a bit of a thorn in the side of DT bindings
> > > maintainers?
> >
> > Not really. Most have existed for decades. New ones get extra scrutiny
> > and often end up dropping the linux prefix.
> >
> > > I'd imagine so since they technically tie the DT to a specific OS
> > > kernel (though of course, others are free to translate those key
> > > codes). And the whole idea of configuring which code is emitted
> > > from something is basically abusing DT for configuring software
> > > rather than describing hardware.
> > >
> > > I'm mainly interested because this is a thought that has been in
> > > the back of my mind for a while now, and I'm curious if the DT
> > > binding maintainers happen to have arrived at the same impassé,
> > > where linux,input-type et al abuse the DT model for something we
> > > would tell any other vendor not to abuse it for, but no better
> > > solution exists right now to achieve the same thing.
> >
> > Not sure what the BSDs do here. It's never come up that I remember. Best
> > I can tell is they just make it a userspace problem. So every possible
> > keyboard needs a keymap file. Though I'm not sure how that would work
> > with GPIO keys as you don't really have a scan code.
>
> Is there an update for this binding or should I apply the current
> version? I am OK with the driver changes...
>
> Thanks.
>
>
I will send a new version that doesn't add the property but allows
unevaluatedProps instead. Thanks for reminding me.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* [PATCH] hid: wacom: add new usb id to device table
From: Roi L @ 2026-04-08 17:09 UTC (permalink / raw)
To: ping.cheng; +Cc: jason.gerecke, linux-input, Roi L
This adds the USB Device ID of Wacom CTL-4100 to the device ID
table.
Signed-off-by: Roi L <roeilev321_@outlook.com>
---
drivers/hid/wacom_wac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index da1f0ea85625..100f0ef03d1d 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -5116,6 +5116,7 @@ const struct hid_device_id wacom_ids[] = {
{ BT_DEVICE_WACOM(0x361) },
{ BT_DEVICE_WACOM(0x377) },
{ BT_DEVICE_WACOM(0x379) },
+ { USB_DEVICE_WACOM(0x374) },
{ USB_DEVICE_WACOM(0x37A) },
{ USB_DEVICE_WACOM(0x37B) },
{ BT_DEVICE_WACOM(0x393) },
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] Input: serio - fix O(n^2) complexity in serio_unregister_driver()
From: Dmitry Torokhov @ 2026-04-08 17:07 UTC (permalink / raw)
To: Mohamad Raizudeen; +Cc: kees, linux-input, linux-kernel
In-Reply-To: <20260408162849.4639-1-raizudeen.kerneldev@gmail.com>
Hi Mohamad,
On Wed, Apr 08, 2026 at 09:58:47PM +0530, Mohamad Raizudeen wrote:
> The current implementation restarts the scan from the beginning after
> each disconnection(goto start_over) because serio_disconnect_port() may
> delete the current list entry. This results in O(n^2) worst case
> behaviour.
The "big O" notation only makes sense when numbers are big. Here we are
dealing with 6 serio ports max (1 KBC, 4xMUX, 1 Synaptics pass-through)
unless you have a serial port expander and hooked up a few ports there.
But still, the number if very limited.
>
> Replace with a two-phase approach:
>
> 1.Collect only top-level ports bound to the driver(skip those whose parent is also bound to the same driver) into a
> temporary list.
We do not have such setups at the moment, but what about parent's
parent's parent?
>
> 2.Process each collected port once, moving it back to serio_list first to maintain invariants expected by serio_destroy_port().
>
> This eliminates the restart loop, reduces complexity from O(n^2) to O(n)
> and avoids use-after-free by never collecting child ports separately.
Could you explain more about the use-after-free scenario?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: input: adc-keys: allow linux,input-type property
From: Dmitry Torokhov @ 2026-04-08 16:59 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Frattaroli, Krzysztof Kozlowski, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Heiko Stuebner, kernel,
linux-input, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20251217133440.GA724723-robh@kernel.org>
On Wed, Dec 17, 2025 at 07:34:40AM -0600, Rob Herring wrote:
> On Wed, Dec 17, 2025 at 01:57:46PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 17 December 2025 09:31:15 Central European Standard Time Krzysztof Kozlowski wrote:
> > > On Mon, Dec 15, 2025 at 01:29:29PM +0100, Nicolas Frattaroli wrote:
> > > > adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> > > > property. This makes it impossible to model devices that have ADC inputs
> > > > that should generate switch events.
> > >
> > > The solution is to use unevaluatedProps instead, which also allows
> > > dropping other properties.
> > >
> > > Best regards,
> > > Krzysztof
> > >
> > >
> >
> > Hi Krzysztof,
> >
> > to understand the motivation behind this suggestion correctly:
> > are the "linux," vendor prefixed properties, especially with regards
> > to key codes, generally a bit of a thorn in the side of DT bindings
> > maintainers?
>
> Not really. Most have existed for decades. New ones get extra scrutiny
> and often end up dropping the linux prefix.
>
> > I'd imagine so since they technically tie the DT to a specific OS
> > kernel (though of course, others are free to translate those key
> > codes). And the whole idea of configuring which code is emitted
> > from something is basically abusing DT for configuring software
> > rather than describing hardware.
> >
> > I'm mainly interested because this is a thought that has been in
> > the back of my mind for a while now, and I'm curious if the DT
> > binding maintainers happen to have arrived at the same impassé,
> > where linux,input-type et al abuse the DT model for something we
> > would tell any other vendor not to abuse it for, but no better
> > solution exists right now to achieve the same thing.
>
> Not sure what the BSDs do here. It's never come up that I remember. Best
> I can tell is they just make it a userspace problem. So every possible
> keyboard needs a keymap file. Though I'm not sure how that would work
> with GPIO keys as you don't really have a scan code.
Is there an update for this binding or should I apply the current
version? I am OK with the driver changes...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()
From: Dmitry Torokhov @ 2026-04-08 16:53 UTC (permalink / raw)
To: pip-izony
Cc: Kyungtae Kim, Sanghoon Choi, Dan Carpenter, linux-input,
linux-kernel
In-Reply-To: <20251221211442.841549-2-eeodqql09@gmail.com>
Hi,
On Sun, Dec 21, 2025 at 04:14:42PM -0500, pip-izony wrote:
> From: Seungjin Bae <eeodqql09@gmail.com>
>
> The `ims_pcu_process_data()` processes incoming URB data byte by byte.
> However, it fails to check if the `read_pos` index exceeds
> IMS_PCU_BUF_SIZE.
>
> If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE,
> `read_pos` will increment indefinitely. Moreover, since `read_pos` is
> located immediately after `read_buf`, the attacker can overwrite
> `read_pos` itself to arbitrarily control the index.
>
> This manipulated `read_pos` is subsequently used in
> `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a
> heap buffer overflow.
>
> Specifically, an attacker can overwrite the `cmd_done.wait.head` located
> at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`.
> Consequently, when the driver calls `complete(&pcu->cmd_done)`, it
> triggers a control flow hijack by using the manipulated pointer.
>
> Fix this by adding a bounds check for `read_pos` before writing to
> `read_buf`. If the packet is too long, discard it, log a warning,
> and reset the parser state.
>
> Fixes: 628329d524743 ("Input: add IMS Passenger Control Unit driver")
> Co-developed-by: Sanghoon Choi <csh0052@gmail.com>
> Signed-off-by: Sanghoon Choi <csh0052@gmail.com>
> Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
> ---
> v1 -> v2: Add warning and reset the state of the parser for bad packet
> v2 -> v3: Add co-author information
>
> drivers/input/misc/ims-pcu.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
> index 4581f1c53644..c98ef71c841e 100644
> --- a/drivers/input/misc/ims-pcu.c
> +++ b/drivers/input/misc/ims-pcu.c
> @@ -450,6 +450,16 @@ static void ims_pcu_process_data(struct ims_pcu *pcu, struct urb *urb)
> continue;
>
> if (pcu->have_dle) {
> + if (pcu->read_pos >= IMS_PCU_BUF_SIZE) {
> + dev_warn(pcu->dev,
> + "Packet too long (%d bytes), discarding\n",
> + pcu->read_pos);
> + pcu->have_stx = false;
> + pcu->have_dle = false;
> + pcu->read_pos = 0;
Here and in the other place we also need to reset checksum, otherwise a
valid packet might get rejected.
I factored out the code resetting packet state and applied, thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - take event lock when submitting FF request "event"
From: Mikhail Gavrilov @ 2026-04-08 16:47 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <adXkf6MWzlB8LA_s@google.com>
On Wed, Apr 8, 2026 at 10:16 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> To avoid racing with FF playback events and corrupting device's event
> queue take event_lock spinlock when calling uinput_dev_event() when
> submitting a FF upload or erase "event".
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>
> Mikhail, could you please try this one?
>
> drivers/input/misc/uinput.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index e24caf6fc8e8..d32fa4b508fc 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -25,8 +25,10 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/fs.h>
> +#include <linux/lockdep.h>
> #include <linux/miscdevice.h>
> #include <linux/overflow.h>
> +#include <linux/spinlock.h>
> #include <linux/input/mt.h>
> #include "../input-compat.h"
>
> @@ -76,6 +78,8 @@ static int uinput_dev_event(struct input_dev *dev,
> struct uinput_device *udev = input_get_drvdata(dev);
> struct timespec64 ts;
>
> + lockdep_assert_held(&dev->event_lock);
> +
> ktime_get_ts64(&ts);
>
> udev->buff[udev->head] = (struct input_event) {
> @@ -147,6 +151,7 @@ static void uinput_request_release_slot(struct uinput_device *udev,
> static int uinput_request_send(struct uinput_device *udev,
> struct uinput_request *request)
> {
> + unsigned long flags;
> int retval = 0;
>
> spin_lock(&udev->state_lock);
> @@ -160,7 +165,9 @@ static int uinput_request_send(struct uinput_device *udev,
> * Tell our userspace application about this new request
> * by queueing an input event.
> */
> + spin_lock_irqsave(&udev->dev->event_lock, flags);
> uinput_dev_event(udev->dev, EV_UINPUT, request->code, request->id);
> + spin_unlock_irqrestore(&udev->dev->event_lock, flags);
>
> out:
> spin_unlock(&udev->state_lock);
> --
> 2.53.0.1213.gd9a14994de-goog
>
>
> --
> Dmitry
Applied on top of my v2 patch, built and tested with Flydigi Vader 5
controller under Wine (ELDEN RING, Resident Evil Requiem) -- no issues observed.
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
--
Best Regards,
Mike Gavrilov.
^ permalink raw reply
* [PATCH] Input: serio - fix O(n^2) complexity in serio_unregister_driver()
From: Mohamad Raizudeen @ 2026-04-08 16:28 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: Mohamad Raizudeen, kees, linux-input, linux-kernel
The current implementation restarts the scan from the beginning after
each disconnection(goto start_over) because serio_disconnect_port() may
delete the current list entry. This results in O(n^2) worst case
behaviour.
Replace with a two-phase approach:
1.Collect only top-level ports bound to the driver(skip those whose parent is also bound to the same driver) into a
temporary list.
2.Process each collected port once, moving it back to serio_list first to maintain invariants expected by serio_destroy_port().
This eliminates the restart loop, reduces complexity from O(n^2) to O(n)
and avoids use-after-free by never collecting child ports separately.
Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
---
drivers/input/serio/serio.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 54dd26249b02..46b8faf1a46c 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -821,22 +821,27 @@ EXPORT_SYMBOL(__serio_register_driver);
void serio_unregister_driver(struct serio_driver *drv)
{
- struct serio *serio;
+ struct serio *serio, *next;
+ LIST_HEAD(disconnect_list);
+
guard(mutex)(&serio_mutex);
drv->manual_bind = true; /* so serio_find_driver ignores it */
serio_remove_pending_events(drv);
-start_over:
- list_for_each_entry(serio, &serio_list, node) {
- if (serio->drv == drv) {
- serio_disconnect_port(serio);
- serio_find_driver(serio);
- /* we could've deleted some ports, restart */
- goto start_over;
+ /*Collect all ports bound to this driver first*/
+ list_for_each_entry_safe(serio, next, &serio_list, node) {
+ if (serio->drv == drv && !(serio->parent && serio->parent->drv == drv)) {
+ list_move_tail(&serio->node, &disconnect_list);
}
}
+
+ list_for_each_entry_safe(serio, next, &disconnect_list, node) {
+ list_move_tail(&serio->node, &serio_list);
+ serio_disconnect_port(serio);
+ serio_find_driver(serio);
+ }
driver_unregister(&drv->driver);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] HID: core: add short report quirk and use it for GPD Win (2f24:0137)
From: Zhouwang Huang @ 2026-04-08 16:07 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, denis.benato, linux-input, linux-kernel, honjow311
In-Reply-To: <adZ2PTzQ05iObcGt@beelink>
Hi Benjamin,
Thanks. Agreed, a core fix that checks the actual buffer size would be
much cleaner than a per-device quirk.
Happy to test when it's ready.
Thanks,
Zhouwang
^ permalink raw reply
* Re: [PATCH v2] xpad: Overhaul device data for wireless devices
From: Antheas Kapenekakis @ 2026-04-08 15:47 UTC (permalink / raw)
To: Sanjay Govind
Cc: Dmitry Torokhov, Vicki Pfau, Nilton Perim Neto, Mario Limonciello,
Pierre-Loup A. Griffais, linux-input, linux-kernel
In-Reply-To: <CALQgdA04mczQoJ4HyjSwgeXMHwLT+Rv0AEoArpwBohzL9oa1nw@mail.gmail.com>
On Wed, 8 Apr 2026 at 07:04, Sanjay Govind <sanjay.govind9@gmail.com> wrote:
>
> On Wed, Apr 8, 2026 at 4:52 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > I think you'd have to spin up your own instance for that...
>
> makes sense
>
Hi Sanjay,
I have a workflow for running an llm and getting reviews locally.
Perhaps I will post it to the mailing list soon. I can cc you. I have
been out for the Easter holidays
Of course, you will need your own LLM and harness for that, Claude
code/Antigravity/Copilot/Opencode, etc. I know they aren't
particularly cheap.
Dmitry, sashiko looks great, I left a star. I could also cc you. I
will also reference the prompts used in that as it claims some
subsystem specific ones. From a quick glance it seems to might suffer
from context bloat though. There are a lot of guideline files that
could have higher information density.
Antheas
^ permalink raw reply
* Re: [PATCH] HID: core: add short report quirk and use it for GPD Win (2f24:0137)
From: Benjamin Tissoires @ 2026-04-08 15:41 UTC (permalink / raw)
To: Zhouwang Huang; +Cc: Jiri Kosina, denis.benato, linux-kernel, linux-input
In-Reply-To: <20260407173212.86942-1-honjow311@gmail.com>
Hi,
Definitely not a big fan of that new quirk. The issue is that current
hid-core fix is too restrictive because it doesn't have enough
information, like the actual allocated buffer size.
On Apr 08 2026, Zhouwang Huang wrote:
> Commit 9e2a17d2e808 ("HID: gpd: fix report descriptor on GPD Win
> handheld (2f24:0137)") used report_fixup to shrink Report Count from
> 63 to 11 so that short reports from firmware <= 1.09 would not be
> rejected by hid_report_raw_event().
>
> However, firmware 1.10 fixed the report length and now sends the full
> 63 bytes. Because report_fixup already shrank the descriptor,
> usbhid allocates a 12-byte URB buffer — far too small for the 64-byte
> transfer — causing continuous -EOVERFLOW on every interrupt-in URB.
> The HID report descriptor and bcdDevice are identical across firmware
> versions, so report_fixup cannot conditionally apply.
OK, so if a firmware already fixed the bug, I'll drop 9e2a17d2e808 from
for-next and not include it in the final 7.0 PR I'll need to send. We
can tell people to upgrade to the latest firmware while I work on a
proper fix.
BTW, technically we could also not change the report descriptor if we
detect the correct firmware version. That would be easier to implement
than a global quirk. But hopefully we won't have to do anything and get
the proper hid-core fix soon.
Cheers,
Benjamin
>
> Replace the report_fixup driver with a new per-device quirk
> HID_QUIRK_ALLOW_SHORT_REPORTS. When set, hid_report_raw_event()
> zero-pads short reports instead of rejecting them — the same behaviour
> the core had before commit 0a3fe972a7cb ("HID: core: Mitigate
> potential OOB by removing bogus memset()"). The descriptor is left
> unmodified so the URB buffer matches the declared report size and works
> with any firmware version.
>
> Remove hid-gpd.c, its Kconfig entry and Makefile line; the device is
> now handled by hid-generic with the quirk applied from hid-quirks.c.
>
> Fixes: 9e2a17d2e808 ("HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)")
> Signed-off-by: Zhouwang Huang <honjow311@gmail.com>
> ---
> drivers/hid/Kconfig | 10 --------
> drivers/hid/Makefile | 1 -
> drivers/hid/hid-core.c | 11 +++++----
> drivers/hid/hid-gpd.c | 52 ----------------------------------------
> drivers/hid/hid-quirks.c | 2 ++
> include/linux/hid.h | 2 ++
> 6 files changed, 11 insertions(+), 67 deletions(-)
> delete mode 100644 drivers/hid/hid-gpd.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 2159d0fb7020..c1d9f7c6a5f2 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -419,16 +419,6 @@ 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"
> - 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 f69cd6015465..e01838239ae6 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -53,7 +53,6 @@ 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-core.c b/drivers/hid/hid-core.c
> index f5587b786f87..52e86f927a38 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2057,10 +2057,13 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
> rsize = max_buffer_size;
>
> if (csize < rsize) {
> - 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->quirks & HID_QUIRK_ALLOW_SHORT_REPORTS)) {
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
> + report->id, rsize, csize);
> + ret = -EINVAL;
> + goto out;
> + }
> + memset(cdata + csize, 0, rsize - csize);
> }
>
> if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
> diff --git a/drivers/hid/hid-gpd.c b/drivers/hid/hid-gpd.c
> deleted file mode 100644
> index 5b4d203e2499..000000000000
> --- a/drivers/hid/hid-gpd.c
> +++ /dev/null
> @@ -1,52 +0,0 @@
> -// 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-quirks.c b/drivers/hid/hid-quirks.c
> index f6be3ffee023..b9ae1442eba9 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -97,6 +97,8 @@ static const struct hid_device_id hid_quirks[] = {
> HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
> { HID_USB_DEVICE(USB_VENDOR_ID_GAMEVICE, USB_DEVICE_ID_GAMEVICE_KISHI),
> HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
> + { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137),
> + HID_QUIRK_ALLOW_SHORT_REPORTS },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING), HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 31324609af4d..212dd13bfcfa 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -381,6 +381,7 @@ struct hid_item {
> * | @HID_QUIRK_X_INVERT:
> * | @HID_QUIRK_Y_INVERT:
> * | @HID_QUIRK_IGNORE_MOUSE:
> + * | @HID_QUIRK_ALLOW_SHORT_REPORTS: accept shorter-than-expected reports, zero-pad
> * | @HID_QUIRK_SKIP_OUTPUT_REPORTS:
> * | @HID_QUIRK_SKIP_OUTPUT_REPORT_ID:
> * | @HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP:
> @@ -408,6 +409,7 @@ struct hid_item {
> #define HID_QUIRK_X_INVERT BIT(12)
> #define HID_QUIRK_Y_INVERT BIT(13)
> #define HID_QUIRK_IGNORE_MOUSE BIT(14)
> +#define HID_QUIRK_ALLOW_SHORT_REPORTS BIT(15)
> #define HID_QUIRK_SKIP_OUTPUT_REPORTS BIT(16)
> #define HID_QUIRK_SKIP_OUTPUT_REPORT_ID BIT(17)
> #define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP BIT(18)
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [RFC PATCH 3/5] Input: pc110pad - remove driver
From: Dmitry Torokhov @ 2026-04-08 14:49 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-input, linux-kernel, Vojtech Pavlik, Jiri Kosina,
Benjamin Tissoires, Maciej W. Rozycki
In-Reply-To: <20260407195138.GA251078@bhelgaas>
On Tue, Apr 07, 2026 at 02:51:38PM -0500, Bjorn Helgaas wrote:
> [+cc Maciej]
>
> On Thu, Aug 08, 2024 at 10:27:29AM -0700, Dmitry Torokhov wrote:
> > Palm Top PC 110 is a handheld personal computer with 80486SX CPU that
> > was released exclusively in Japan in September 1995.
> >
> > While the kernel still supports 486 CPU it is highly unlikely that
> > anyone is using this device with the latest kernel.
> >
> > Remove the driver.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> I applied this patch only to remove pc110pad to pci/enumeration for
> v7.1, since "x86/cpu: Remove M486/M486SX/ELAN support" has been queued
> for v7.1:
> https://lore.kernel.org/all/20251214084710.3606385-2-mingo@kernel.org/
>
> I put this in the PCI tree because pc110pad was the only user of
> no_pci_devices(), which we can now remove as well.
And I am going to apply the rest of the series. They are really simply a
historical curiosity now.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: qt1050 - inline i2c_check_functionality check
From: Dmitry Torokhov @ 2026-04-08 14:47 UTC (permalink / raw)
To: Thorsten Blum; +Cc: linux-input, linux-kernel
In-Reply-To: <20260408141926.1181389-3-thorsten.blum@linux.dev>
On Wed, Apr 08, 2026 at 04:19:25PM +0200, Thorsten Blum wrote:
> Inline the i2c_check_functionality() check, since the function returns a
> boolean status rather than an error code.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Applied both, thank you.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 1/2] Input: qt1050 - inline i2c_check_functionality check
From: Thorsten Blum @ 2026-04-08 14:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Thorsten Blum, linux-input, linux-kernel
Inline the i2c_check_functionality() check, since the function returns a
boolean status rather than an error code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/input/keyboard/qt1050.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/qt1050.c b/drivers/input/keyboard/qt1050.c
index bce8157d1871..f9f480c91032 100644
--- a/drivers/input/keyboard/qt1050.c
+++ b/drivers/input/keyboard/qt1050.c
@@ -435,8 +435,7 @@ static int qt1050_probe(struct i2c_client *client)
int err;
/* Check basic functionality */
- err = i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE);
- if (!err) {
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE)) {
dev_err(&client->dev, "%s adapter not supported\n",
dev_driver_string(&client->adapter->dev));
return -ENODEV;
^ 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