* 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
* 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
* [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
* [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 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
* 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 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
* [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 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 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 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
* 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
* 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 18:36 UTC (permalink / raw)
To: Mohamad Raizudeen; +Cc: kees, linux-kernel, linux-input
In-Reply-To: <adacRNjPg2ChJjAn@raizudeen>
On Wed, Apr 08, 2026 at 11:49:48PM +0530, Mohamad Raizudeen wrote:
> 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.
Appreciate you looking at the code but I do not think that particular
area needs addressing.
If you would like to improve the subsystem I would recommend you look
into making serio rely on the asynchronous driver probing, removing
custom handling of async port registration. This would allow
serio_register_port() to return errors and clean up bunch of things.
This will complicate attempt to synchronously switch serio protocols,
but I am willing to let go of that feature as I do not think anyone is
actually using this.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: core: add short report quirk and use it for GPD Win (2f24:0137)
From: Jiri Kosina @ 2026-04-08 19:30 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Zhouwang Huang, denis.benato, linux-kernel, linux-input
In-Reply-To: <adZ2PTzQ05iObcGt@beelink>
On Wed, 8 Apr 2026, Benjamin Tissoires wrote:
> 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.
Now dropped.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 8/8] bpf: Add fix for Trust Philips SPK6327 (145f:024b) modifier keys
From: Jiri Kosina @ 2026-04-08 19:48 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input, linux-kernel, muhammed Rishal
In-Reply-To: <ac_nblOZD_DwTYKb@beelink>
On Fri, 3 Apr 2026, Benjamin Tissoires wrote:
> Of course, you hit send and you realize the commit message is missing
> the 'HID:' marker. Sorry Jiri.
>
> Also, this commit should probably be tagged with:
> From: muhammed Rishal <muhammedrishal7777777@gmail.com>
I have fixed that manually and queued the series now in
hid.git#for-7.1/hid-bpf. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] HID: multitouch: Add support for Dell Pro Rugged 12 Tablet RA02260
From: Jiri Kosina @ 2026-04-08 20:32 UTC (permalink / raw)
To: hmtheboy154; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260403092848.10223-1-buingoc67@gmail.com>
On Fri, 3 Apr 2026, buingoc67@gmail.com wrote:
> From: hmtheboy154 <buingoc67@gmail.com>
>
> This patch series adds multitouch and stylus support for the eGalax
> I2C touchscreen found in the Dell Pro Rugged 12 Tablet RA02260.
>
> hmtheboy154 (2):
Thanks a lot for the patches.
I know that the kernel documentation is now a little bit more liberal
about not having to use real names, but "well established identities"
being fine, but stil ... would you mind submitting this under some more
comprehensible authorship? (anonymous submissions are still not allowed,
BTW).
hmtheboy154 / buingoc67 doesn't really sound too well established identity
to me, unfortunately :)
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add battery status support for Rock Band 4 PS5 guitars
From: Jiri Kosina @ 2026-04-08 20:35 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260307094824.50332-2-rosalie@mailbox.org>
On Sat, 7 Mar 2026, Rosalie Wanders wrote:
> This commit adds battery status support for Rock Band 4 PS5 guitars.
>
> The data is reported in the same way as the dualsense in hid-playstation
> except it's located at byte 30.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Applied to hid.git#for-7.1/sony, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: sony: update module description
From: Jiri Kosina @ 2026-04-08 20:37 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260402155915.17745-2-rosalie@mailbox.org>
On Thu, 2 Apr 2026, Rosalie Wanders wrote:
> This commit updates the hid-sony module description to make it correct
> with the recent hid-sony changes alongside making it more consistent.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Applied to hid.git#for-7.1/sony.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Jiri Kosina @ 2026-04-08 20:41 UTC (permalink / raw)
To: Rosalie Wanders
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <20260407194636.9671-2-rosalie@mailbox.org>
On Tue, 7 Apr 2026, Rosalie Wanders wrote:
> This patch adds support for the following instruments:
>
> * Rock Band 1/2/3 Wii/PS3 instruments
> * Rock Band 3 PS3 Pro instruments
> * DJ Hero Turntable
>
> Wii and PS3 instruments are the same besides the vendor and product ID.
>
> This patch also fixes the mappings for the existing Guitar Hero
> instruments.
>
> Co-developed-by: Sanjay Govind <sanjay.govind9@gmail.com>
> Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com>
> Co-developed-by: Brenton Simpson <appsforartists@google.com>
> Signed-off-by: Brenton Simpson <appsforartists@google.com>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
> ---
> changes:
> v2: correct squier device name and remove non-existent squier usb device
Rosalie,
as v1 is already sitting in hid.git#for-7.1/sony for some time, could you
please send this as a followup fix instead?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: quirks: update hid-sony supported devices
From: Jiri Kosina @ 2026-04-08 20:43 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260407195327.10698-3-rosalie@mailbox.org>
On Tue, 7 Apr 2026, Rosalie Wanders wrote:
> hid-sony has been updated with new device support, update the
> hid_have_special_driver list accordingly.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Now in hid.git#for-7.1/sony, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] HID: sony: fix incorrect Squier name and remove non-existent device
From: Rosalie Wanders @ 2026-04-08 21:51 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Rosalie Wanders, Sanjay Govind, linux-input, linux-kernel
This patch fixes the Squier device name and removes a non-existent
device from hid-sony.
Co-developed-by: Sanjay Govind <sanjay.govind9@gmail.com>
Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com>
Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
---
drivers/hid/hid-ids.h | 6 ++----
drivers/hid/hid-sony.c | 8 ++------
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0d78904ee802..f3946932dd95 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -671,9 +671,8 @@
#define USB_DEVICE_ID_HARMONIX_WII_RB2_DRUMS 0x3110
#define USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_DRUMS_MODE 0x3138
#define USB_DEVICE_ID_HARMONIX_WII_RB3_MUSTANG_GUITAR 0x3430
-#define USB_DEVICE_ID_HARMONIX_WII_RB3_SQUIRE_GUITAR 0x3530
#define USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_MUSTANG_MODE 0x3438
-#define USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_SQUIRE_MODE 0x3538
+#define USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_SQUIER_MODE 0x3538
#define USB_DEVICE_ID_HARMONIX_WII_RB3_KEYBOARD 0x3330
#define USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_KEYBOARD_MODE 0x3338
@@ -1331,9 +1330,8 @@
#define USB_DEVICE_ID_SONY_PS3_RB_DRUMS 0x0210
#define USB_DEVICE_ID_SONY_PS3_RB3_MPA_DRUMS_MODE 0x0218
#define USB_DEVICE_ID_SONY_PS3_RB3_MUSTANG_GUITAR 0x2430
-#define USB_DEVICE_ID_SONY_PS3_RB3_SQUIRE_GUITAR 0x2530
#define USB_DEVICE_ID_SONY_PS3_RB3_MPA_MUSTANG_MODE 0x2438
-#define USB_DEVICE_ID_SONY_PS3_RB3_MPA_SQUIRE_MODE 0x2538
+#define USB_DEVICE_ID_SONY_PS3_RB3_MPA_SQUIER_MODE 0x2538
#define USB_DEVICE_ID_SONY_PS3_RB3_KEYBOARD 0x2330
#define USB_DEVICE_ID_SONY_PS3_RB3_MPA_KEYBOARD_MODE 0x2338
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index f72201b30ac6..74a160ec4d08 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -2571,11 +2571,9 @@ static const struct hid_device_id sony_devices[] = {
.driver_data = INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MUSTANG_GUITAR),
.driver_data = INSTRUMENT },
- { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_SQUIRE_GUITAR),
- .driver_data = INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_MUSTANG_MODE),
.driver_data = INSTRUMENT },
- { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_SQUIRE_MODE),
+ { HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_MPA_SQUIER_MODE),
.driver_data = INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_HARMONIX, USB_DEVICE_ID_HARMONIX_WII_RB3_KEYBOARD),
.driver_data = INSTRUMENT },
@@ -2591,11 +2589,9 @@ static const struct hid_device_id sony_devices[] = {
/* Rock Band 3 PS3 Pro instruments */
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MUSTANG_GUITAR),
.driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_SQUIRE_GUITAR),
- .driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_MUSTANG_MODE),
.driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
- { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_SQUIRE_MODE),
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_MPA_SQUIER_MODE),
.driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, USB_DEVICE_ID_SONY_PS3_RB3_KEYBOARD),
.driver_data = INSTRUMENT | RB3_PS3_PRO_INSTRUMENT },
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Rosalie @ 2026-04-08 22:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <37nrpop7-rn05-pqo6-3951-171nr8nq441o@xreary.bet>
Hello,
I've sent 'HID: sony: fix incorrect Squier name and remove non-existent
device', though I will mention you didn't apply 'HID: quirks: update
hid-sony supported devices' cleanly because it duplicated the vendor and
device ID defines in hid-ids.h for the Wii instruments so it will not
compile, I'd advise you apply the patches in the following order to
prevent issues:
1) v1 of 'HID: sony: add support for more instruments'
2) 'HID: sony: fix incorrect Squier name and remove non-existent device'
3) v2 of 'HID: quirks: update hid-sony supported devices' but without
changing hid-ids.h
4) v2 of 'HID: sony: fix style issues' (if you want this patch to be
included that is)
alternatively you could also do:
1) v2 of 'HID: sony: add support for more instruments'
2) v2 of 'HID: quirks: update hid-sony supported devices'
3) v2 of 'HID: sony: fix style issues'
I hope this doesn't cause too much hassle,
Rosalie
On 4/8/26 22:41, Jiri Kosina wrote:
> On Tue, 7 Apr 2026, Rosalie Wanders wrote:
>
>> This patch adds support for the following instruments:
>>
>> * Rock Band 1/2/3 Wii/PS3 instruments
>> * Rock Band 3 PS3 Pro instruments
>> * DJ Hero Turntable
>>
>> Wii and PS3 instruments are the same besides the vendor and product ID.
>>
>> This patch also fixes the mappings for the existing Guitar Hero
>> instruments.
>>
>> Co-developed-by: Sanjay Govind <sanjay.govind9@gmail.com>
>> Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com>
>> Co-developed-by: Brenton Simpson <appsforartists@google.com>
>> Signed-off-by: Brenton Simpson <appsforartists@google.com>
>> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
>> ---
>> changes:
>> v2: correct squier device name and remove non-existent squier usb device
>
> Rosalie,
>
> as v1 is already sitting in hid.git#for-7.1/sony for some time, could you
> please send this as a followup fix instead?
>
> Thanks,
>
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Jiri Kosina @ 2026-04-08 22:08 UTC (permalink / raw)
To: Rosalie
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <6893d7ea-f585-45fa-aa53-cd7a10fec34a@mailbox.org>
On Thu, 9 Apr 2026, Rosalie wrote:
> Hello,
>
> I've sent 'HID: sony: fix incorrect Squier name and remove non-existent
> device', though I will mention you didn't apply 'HID: quirks: update hid-sony
> supported devices' cleanly because it duplicated the vendor and device ID
> defines in hid-ids.h for the Wii instruments so it will not compile, I'd
> advise you apply the patches in the following order to prevent issues:
>
> 1) v1 of 'HID: sony: add support for more instruments'
> 2) 'HID: sony: fix incorrect Squier name and remove non-existent device'
> 3) v2 of 'HID: quirks: update hid-sony supported devices' but without changing
> hid-ids.h
> 4) v2 of 'HID: sony: fix style issues' (if you want this patch to be included
> that is)
>
> alternatively you could also do:
>
> 1) v2 of 'HID: sony: add support for more instruments'
> 2) v2 of 'HID: quirks: update hid-sony supported devices'
> 3) v2 of 'HID: sony: fix style issues'
>
> I hope this doesn't cause too much hassle,
Thanks, I will look into it. But going forward, you really should either
send this as series, or clearly mark the dependencies. Sending it as a
followup fix in the same thread also works.
Or, even better, send a pull request against a git branch if the
interdependencies are tricky.
Imagine you're getting higher tens of patches a day (including e.g. quite
often v1->v5 within a timeframe of a few hours), and you are somehow
magically expected to untangle all this.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Rosalie @ 2026-04-08 22:12 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <o488s484-r1os-6736-o800-7on55687757s@xreary.bet>
Hello,
Yes I do apologize, and I'll be mindful of either doing a series, mark
dependencies clearly or do a pull request.
I didn't expect to be sending this many patches at all in the first
place, but one minor annoyance of the code bothers me one day and then
another day someone else mentions that e.g a device name is incorrect,
so that kinda led to this chaos.
Apologies and I'll try preventing it in the future, and thanks for the
advice,
Rosalie
On 4/9/26 00:08, Jiri Kosina wrote:
> On Thu, 9 Apr 2026, Rosalie wrote:
>
>> Hello,
>>
>> I've sent 'HID: sony: fix incorrect Squier name and remove non-existent
>> device', though I will mention you didn't apply 'HID: quirks: update hid-sony
>> supported devices' cleanly because it duplicated the vendor and device ID
>> defines in hid-ids.h for the Wii instruments so it will not compile, I'd
>> advise you apply the patches in the following order to prevent issues:
>>
>> 1) v1 of 'HID: sony: add support for more instruments'
>> 2) 'HID: sony: fix incorrect Squier name and remove non-existent device'
>> 3) v2 of 'HID: quirks: update hid-sony supported devices' but without changing
>> hid-ids.h
>> 4) v2 of 'HID: sony: fix style issues' (if you want this patch to be included
>> that is)
>>
>> alternatively you could also do:
>>
>> 1) v2 of 'HID: sony: add support for more instruments'
>> 2) v2 of 'HID: quirks: update hid-sony supported devices'
>> 3) v2 of 'HID: sony: fix style issues'
>>
>> I hope this doesn't cause too much hassle,
>
> Thanks, I will look into it. But going forward, you really should either
> send this as series, or clearly mark the dependencies. Sending it as a
> followup fix in the same thread also works.
>
> Or, even better, send a pull request against a git branch if the
> interdependencies are tricky.
>
> Imagine you're getting higher tens of patches a day (including e.g. quite
> often v1->v5 within a timeframe of a few hours), and you are somehow
> magically expected to untangle all this.
>
> Thanks,
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox