* [PATCH 3/3] Input: ads7846 - don't check penirq immediately for 7845
From: Luca Ellero @ 2023-01-26 10:52 UTC (permalink / raw)
To: dmitry.torokhov, daniel, m.felsch, andriy.shevchenko,
u.kleine-koenig, mkl, miquel.raynal, imre.deak, luca.ellero
Cc: linux-input, linux-kernel, Luca Ellero
In-Reply-To: <20230126105227.47648-1-l.ellero@asem.it>
To discard false readings, one should use "ti,penirq-recheck-delay-usecs".
Checking get_pendown_state() at the beginning, most of the time fails
causing malfunctioning.
Fixes: ffa458c1bd9b ("spi: ads7846 driver")
Signed-off-by: Luca Ellero <l.ellero@asem.it>
---
drivers/input/touchscreen/ads7846.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 15da1047a577..17f11bce8113 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -843,14 +843,8 @@ static void ads7846_report_state(struct ads7846 *ts)
if (x == MAX_12BIT)
x = 0;
- if (ts->model == 7843) {
+ if (ts->model == 7843 || ts->model == 7845) {
Rt = ts->pressure_max / 2;
- } else if (ts->model == 7845) {
- if (get_pendown_state(ts))
- Rt = ts->pressure_max / 2;
- else
- Rt = 0;
- dev_vdbg(&ts->spi->dev, "x/y: %d/%d, PD %d\n", x, y, Rt);
} else if (likely(x && z1)) {
/* compute touch pressure resistance using equation #2 */
Rt = z2;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] Input: ads7846 - always set last command to PWRDOWN
From: Luca Ellero @ 2023-01-26 10:52 UTC (permalink / raw)
To: dmitry.torokhov, daniel, m.felsch, andriy.shevchenko,
u.kleine-koenig, mkl, miquel.raynal, imre.deak, luca.ellero
Cc: linux-input, linux-kernel, Luca Ellero
In-Reply-To: <20230126105227.47648-1-l.ellero@asem.it>
Controllers that report pressure (e.g. ADS7846) use 5 commands and the
correct sequence is READ_X, READ_Y, READ_Z1, READ_Z2, PWRDOWN.
Controllers that don't report pressure (e.g. ADS7845/ADS7843) use only 3
commands and the correct sequence should be READ_X, READ_Y, PWRDOWN. But
the sequence sent was incorrect: READ_X, READ_Y, READ_Z1.
Fix this by setting the third (and last) command to PWRDOWN.
Fixes: ffa458c1bd9b ("spi: ads7846 driver")
Signed-off-by: Luca Ellero <l.ellero@asem.it>
---
drivers/input/touchscreen/ads7846.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index f11b444f2138..15da1047a577 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1066,6 +1066,9 @@ static int ads7846_setup_spi_msg(struct ads7846 *ts,
struct ads7846_buf_layout *l = &packet->l[cmd_idx];
unsigned int max_count;
+ if (cmd_idx == packet->cmds - 1)
+ cmd_idx = ADS7846_PWDOWN;
+
if (ads7846_cmd_need_settle(cmd_idx))
max_count = packet->count + packet->count_skip;
else
@@ -1102,7 +1105,12 @@ static int ads7846_setup_spi_msg(struct ads7846 *ts,
for (cmd_idx = 0; cmd_idx < packet->cmds; cmd_idx++) {
struct ads7846_buf_layout *l = &packet->l[cmd_idx];
- u8 cmd = ads7846_get_cmd(cmd_idx, vref);
+ u8 cmd;
+
+ if (cmd_idx == packet->cmds - 1)
+ cmd_idx = ADS7846_PWDOWN;
+
+ cmd = ads7846_get_cmd(cmd_idx, vref);
for (b = 0; b < l->count; b++)
packet->tx[l->offset + b].cmd = cmd;
--
2.25.1
^ permalink raw reply related
* [PATCH v5 0/3] Input: ads7846 - fix support for ADS7845
From: Luca Ellero @ 2023-01-26 10:52 UTC (permalink / raw)
To: dmitry.torokhov, daniel, m.felsch, andriy.shevchenko,
u.kleine-koenig, mkl, miquel.raynal, imre.deak, luca.ellero
Cc: linux-input, linux-kernel, Luca Ellero
ADS7845 support is buggy in this driver.
These patches fix various issues to get it work properly.
Changes for v2:
- add missing period in patch 0001 message
- elaborate comment in patch 0002
Changes for v3:
- send from the same email address of "Signed-off"
Changes for v4:
- fix tag
- fix comment in patch 0002
Changes for v5:
- add Fixes: tag
- fix comment in patch 0001
Luca Ellero (3):
Input: ads7846 - don't report pressure for ads7845
Input: ads7846 - always set last command to PWRDOWN
Input: ads7846 - don't check penirq immediately for 7845
drivers/input/touchscreen/ads7846.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/3] Input: ads7846 - don't report pressure for ads7845
From: Luca Ellero @ 2023-01-26 10:52 UTC (permalink / raw)
To: dmitry.torokhov, daniel, m.felsch, andriy.shevchenko,
u.kleine-koenig, mkl, miquel.raynal, imre.deak, luca.ellero
Cc: linux-input, linux-kernel, Luca Ellero
In-Reply-To: <20230126105227.47648-1-l.ellero@asem.it>
ADS7845 doesn't support pressure.
Avoid the following error reported by libinput-list-devices:
"ADS7845 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE".
Fixes: ffa458c1bd9b ("spi: ads7846 driver")
Signed-off-by: Luca Ellero <l.ellero@asem.it>
---
drivers/input/touchscreen/ads7846.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 4c3dd01902d0..f11b444f2138 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1316,8 +1316,9 @@ static int ads7846_probe(struct spi_device *spi)
pdata->y_min ? : 0,
pdata->y_max ? : MAX_12BIT,
0, 0);
- input_set_abs_params(input_dev, ABS_PRESSURE,
- pdata->pressure_min, pdata->pressure_max, 0, 0);
+ if (ts->model != 7845)
+ input_set_abs_params(input_dev, ABS_PRESSURE,
+ pdata->pressure_min, pdata->pressure_max, 0, 0);
/*
* Parse common framework properties. Must be done here to ensure the
--
2.25.1
^ permalink raw reply related
* [PATCH v2 3/5] HID: dualsense_remove: manually unregister leds
From: Pietro Borrello @ 2023-01-26 12:09 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Pietro Borrello, linux-leds, Cristiano Giuffrida, Bos, H.J.,
Jakob Koschel, linux-input, linux-kernel, Jiri Kosina,
Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires,
Hanno Zulla, Pavel Machek, Lee Jones, Roderick Colenbrander,
Sven Eckelmann
In-Reply-To: <CAEc3jaDRzvw4wqomWTZ4QiGT7ndm0u+LQuqDTOWB=B-6w=2yzg@mail.gmail.com>
Unregister the LED controllers before device removal, to prevent
unnecessary runs of dualsense_player_led_set_brightness().
Fixes: 8c0ab553b072 ("HID: playstation: expose DualSense player LEDs through LED class.")
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
---
Contrary to the other patches in this series, failing to unregister
the led controller does not results into a use-after-free thanks
to the output_worker_initialized variable and the spinlock checks.
Changes in v2:
- Unregister multicolor led controller
- Clarify UAF
- Link to v1: https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-3-9a5192dcef16@diag.uniroma1.it/
---
drivers/hid/hid-playstation.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 27c40894acab..f23186ca2d76 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -1503,11 +1503,17 @@ static void dualsense_remove(struct ps_device *ps_dev)
{
struct dualsense *ds = container_of(ps_dev, struct dualsense, base);
unsigned long flags;
+ int i;
spin_lock_irqsave(&ds->base.lock, flags);
ds->output_worker_initialized = false;
spin_unlock_irqrestore(&ds->base.lock, flags);
+ for (i = 0; i < ARRAY_SIZE(ds->player_leds); i++)
+ devm_led_classdev_unregister(&ps_dev->hdev->dev, &ds->player_leds[i]);
+
+ devm_led_classdev_multicolor_unregister(&ps_dev->hdev->dev, &ds->lightbar);
+
cancel_work_sync(&ds->output_worker);
}
--
2.25.1
^ permalink raw reply related
* [PATCH v2 4/5] HID: dualshock4_remove: manually unregister leds
From: Pietro Borrello @ 2023-01-26 12:11 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: Pietro Borrello, linux-leds, Cristiano Giuffrida, Bos, H.J.,
Jakob Koschel, linux-input, linux-kernel, Jiri Kosina,
Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires,
Hanno Zulla, Pavel Machek, Lee Jones, Roderick Colenbrander,
Sven Eckelmann
In-Reply-To: <CAEc3jaDRzvw4wqomWTZ4QiGT7ndm0u+LQuqDTOWB=B-6w=2yzg@mail.gmail.com>
Unregister the LED controllers before device removal, to prevent
unnecessary runs of dualshock4_led_set_brightness().
Fixes: 4521109a8f40 ("HID: playstation: support DualShock4 lightbar.")
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
---
Contrary to the other patches in this series, failing to unregister
the led controller does not results into a use-after-free thanks
to the output_worker_initialized variable and the spinlock checks.
Changes in v2:
- Clarify UAF
- Link to v1: https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-4-9a5192dcef16@diag.uniroma1.it/
---
drivers/hid/hid-playstation.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index f23186ca2d76..b41657842e26 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2434,11 +2434,15 @@ static void dualshock4_remove(struct ps_device *ps_dev)
{
struct dualshock4 *ds4 = container_of(ps_dev, struct dualshock4, base);
unsigned long flags;
+ int i;
spin_lock_irqsave(&ds4->base.lock, flags);
ds4->output_worker_initialized = false;
spin_unlock_irqrestore(&ds4->base.lock, flags);
+ for (i = 0; i < ARRAY_SIZE(ds4->lightbar_leds); i++)
+ devm_led_classdev_unregister(&ps_dev->hdev->dev, &ds4->lightbar_leds[i]);
+
cancel_work_sync(&ds4->output_worker);
if (ps_dev->hdev->product == USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v8 1/5] dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
From: Krzysztof Kozlowski @ 2023-01-26 12:32 UTC (permalink / raw)
To: Manuel Traut, linux-kernel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230126091825.220646-2-manuel.traut@mt.com>
On 26/01/2023 10:18, Manuel Traut wrote:
> Converts txt binding to new YAML format.
>
> Signed-off-by: Manuel Traut <manuel.traut@mt.com>
Thank you for your patch. There is something to discuss/improve.
> diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> new file mode 100644
> index 000000000000..351df83d5cbe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/input/pwm-beeper.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
Drop quotes from both. Apologies for not noticing it earlier.
> +
> +title: PWM beeper
> +
> +maintainers:
> + - Dmitry Torokhov <dmitry.torokhov@gmail.com>
> +
> +description: Registers a PWM device as beeper.
> +
> +properties:
> + compatible:
> + const: pwm-beeper
> +
> + pwms:
> + maxItems: 1
> +
> + amp-supply:
> + description: >
> + phandle to a regulator that acts as an amplifier for
> + the beeper
Drop "phandle to a"
> +
> + beeper-hz:
> + description: bell frequency in Hz
> +
> +required:
> + - compatible
> + - pwms
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + beeper_amp: amplifier {
> + compatible = "fixed-regulator";
> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> + };
Drop this device node, not related.
> +
> + beeper {
> + compatible = "pwm-beeper";
> + pwms = <&pwm0>;
> + amp-supply = <&beeper_amp>;
> + };
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 4/5] dt-bindings: input: pwm-beeper: add volume
From: Krzysztof Kozlowski @ 2023-01-26 12:36 UTC (permalink / raw)
To: Manuel Traut, linux-kernel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <20230126091825.220646-5-manuel.traut@mt.com>
On 26/01/2023 10:18, Manuel Traut wrote:
> Adds an array of supported volume levels and a default volume level.
>
> Signed-off-by: Manuel Traut <manuel.traut@mt.com>
This is the second patch. Bindings must be introduced before you start
using them.
> ---
> .../devicetree/bindings/input/pwm-beeper.yaml | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> index 351df83d5cbe..f1f9283ca855 100644
> --- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> @@ -26,6 +26,24 @@ properties:
> beeper-hz:
> description: bell frequency in Hz
>
> + volume-levels:
use -bp suffix:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml#L44
which will mean the unit is 1/100 of %, not 1/10. Then you can also drop
the $ref.
> + description: >
> + Array of PWM duty cycle values that correspond to
> + linear volume levels. These need to be in the range of
> + 0 to 500, while 0 means 0% duty cycle (mute) and 500
> + means 50% duty cycle (max volume).
> + Please note that the actual volume of most beepers is
> + highly non-linear, which means that low volume levels
> + are probably somewhere in the range of 1 to 30 (0.1-3%
> + duty cycle).
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> + default-volume-level:
I propose to use just the value, not the index, so the name should
finish with '-bp' and the $ref can be dropped.
> + description: >
> + The default volume level (index into the array defined
> + by the "volume-levels" property).
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> required:
> - compatible
> - pwms
> @@ -45,4 +63,6 @@ examples:
> compatible = "pwm-beeper";
> pwms = <&pwm0>;
> amp-supply = <&beeper_amp>;
> + volume-levels = <0 8 20 40 500>;
> + default-volume-level = <4>;
> };
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 0/3] Input: ads7846 - fix support for ADS7845
From: Andy Shevchenko @ 2023-01-26 13:06 UTC (permalink / raw)
To: Luca Ellero
Cc: dmitry.torokhov, daniel, m.felsch, u.kleine-koenig, mkl,
miquel.raynal, imre.deak, luca.ellero, linux-input, linux-kernel
In-Reply-To: <20230126105227.47648-1-l.ellero@asem.it>
On Thu, Jan 26, 2023 at 11:52:24AM +0100, Luca Ellero wrote:
> ADS7845 support is buggy in this driver.
> These patches fix various issues to get it work properly.
Entire series now looks good to me
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Thanks!
> Changes for v2:
> - add missing period in patch 0001 message
> - elaborate comment in patch 0002
>
> Changes for v3:
> - send from the same email address of "Signed-off"
>
> Changes for v4:
> - fix tag
> - fix comment in patch 0002
>
> Changes for v5:
> - add Fixes: tag
> - fix comment in patch 0001
>
> Luca Ellero (3):
> Input: ads7846 - don't report pressure for ads7845
> Input: ads7846 - always set last command to PWRDOWN
> Input: ads7846 - don't check penirq immediately for 7845
>
> drivers/input/touchscreen/ads7846.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 1/5] dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
From: Rob Herring @ 2023-01-26 13:21 UTC (permalink / raw)
To: Manuel Traut
Cc: Dmitry Torokhov, devicetree, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, Frieder Schrempf
In-Reply-To: <20230126091825.220646-2-manuel.traut@mt.com>
On Thu, 26 Jan 2023 10:18:21 +0100, Manuel Traut wrote:
> Converts txt binding to new YAML format.
>
> Signed-off-by: Manuel Traut <manuel.traut@mt.com>
> ---
> .../devicetree/bindings/input/pwm-beeper.txt | 24 ----------
> .../devicetree/bindings/input/pwm-beeper.yaml | 48 +++++++++++++++++++
> 2 files changed, 48 insertions(+), 24 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
> create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/input/pwm-beeper.example.dtb: /example-0/amplifier: failed to match any schema with compatible: ['fixed-regulator']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230126091825.220646-2-manuel.traut@mt.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2] drivers/mfd: simple-mfd-i2c: Add generic compatible
From: Lee Jones @ 2023-01-26 14:32 UTC (permalink / raw)
To: Rob Herring; +Cc: Jesse Taube, linux-kernel, linux-input, lee.jones
In-Reply-To: <CAL_JsqJQd4W5-8ej48hAebvyA6neH=2hTtzVU5HhFpQ2yKsQFw@mail.gmail.com>
On Fri, 20 Jan 2023, Rob Herring wrote:
> On Thu, Jan 19, 2023 at 2:54 PM Lee Jones <lee@kernel.org> wrote:
> >
> > On Thu, 19 Jan 2023, Rob Herring wrote:
> >
> > > On Fri, Dec 02, 2022 at 06:32:26AM -0500, Jesse Taube wrote:
> > > > Some devices may want to use this driver without having a specific
> > > > compatible string. Add a generic compatible string to allow this.
> > >
> > > What devices need this?
> > >
> > > Is that no specific compatible string at all or just in the kernel?
> > > Because the former definitely goes against DT requirements. The latter
> > > enables the former without a schema.
> > >
> > > >
> > > > Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
> > > > ---
> > > > drivers/mfd/simple-mfd-i2c.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c
> > > > index f4c8fc3ee463..0bda0dd9276e 100644
> > > > --- a/drivers/mfd/simple-mfd-i2c.c
> > > > +++ b/drivers/mfd/simple-mfd-i2c.c
> > > > @@ -73,6 +73,7 @@ static const struct simple_mfd_data silergy_sy7636a = {
> > > > };
> > > >
> > > > static const struct of_device_id simple_mfd_i2c_of_match[] = {
> > > > + { .compatible = "simple-mfd-i2c-generic" },
> > >
> > > Simple and generic? There is no such device. Anywhere.
> > >
> > > This is also not documented which is how I found it (make
> > > dt_compatible_check). But this should be reverted or dropped rather than
> > > documented IMO.
> >
> > I thought it would be better than having a huge list here.
>
> What indication is there that the list would be huge? We have 2 out of
> 137 MFD bindings. Usually if the MFD is simple, we'd make it a single
> node. It just needs to be clear what the conditions are for using it.
>
> > Devices should *also* be allocated a specific compatible string.
> >
> > $ git grep simple-mfd -- arch
>
> Why can't simple-mfd be used here?
Until this is clarified, agreed and documented, I'm dropping the patch.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v8 4/5] dt-bindings: input: pwm-beeper: add volume
From: Manuel Traut @ 2023-01-26 15:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <c519afe0-0a6f-e262-7a85-a3072a828e62@linaro.org>
> This is the second patch. Bindings must be introduced before you start
> using them.
OK, will be done in v9.
> > ---
> > .../devicetree/bindings/input/pwm-beeper.yaml | 20 +++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> > index 351df83d5cbe..f1f9283ca855 100644
> > --- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> > +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
> > @@ -26,6 +26,24 @@ properties:
> > beeper-hz:
> > description: bell frequency in Hz
> >
> > + volume-levels:
>
> use -bp suffix:
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml#L44
>
> which will mean the unit is 1/100 of %, not 1/10. Then you can also drop
> the $ref.
OK, this is also fine for me. Chaned the description and implementation
for v9.
> > + description: >
> > + Array of PWM duty cycle values that correspond to
> > + linear volume levels. These need to be in the range of
> > + 0 to 500, while 0 means 0% duty cycle (mute) and 500
> > + means 50% duty cycle (max volume).
> > + Please note that the actual volume of most beepers is
> > + highly non-linear, which means that low volume levels
> > + are probably somewhere in the range of 1 to 30 (0.1-3%
> > + duty cycle).
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > + default-volume-level:
>
> I propose to use just the value, not the index, so the name should
> finish with '-bp' and the $ref can be dropped.
I am not so happy with this suggestion. What shall be displayed in
sysfs as volume if a user specifies a value that is not defined in
the array.. So I tend to keep this as is.
Thanks for your feedback
Manuel
> > + description: >
> > + The default volume level (index into the array defined
> > + by the "volume-levels" property).
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > required:
> > - compatible
> > - pwms
> > @@ -45,4 +63,6 @@ examples:
> > compatible = "pwm-beeper";
> > pwms = <&pwm0>;
> > amp-supply = <&beeper_amp>;
> > + volume-levels = <0 8 20 40 500>;
> > + default-volume-level = <4>;
> > };
>
> Best regards,
> Krzysztof
>
--
Manuel Traut
^ permalink raw reply
* Re: [PATCH v8 4/5] dt-bindings: input: pwm-beeper: add volume
From: Krzysztof Kozlowski @ 2023-01-26 15:20 UTC (permalink / raw)
To: Manuel Traut
Cc: linux-kernel, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <Y9KYNSWwlJXPcw0L@mt.com>
On 26/01/2023 16:11, Manuel Traut wrote:
>> This is the second patch. Bindings must be introduced before you start
>> using them.
>
> OK, will be done in v9.
>
>>> ---
>>> .../devicetree/bindings/input/pwm-beeper.yaml | 20 +++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
>>> index 351df83d5cbe..f1f9283ca855 100644
>>> --- a/Documentation/devicetree/bindings/input/pwm-beeper.yaml
>>> +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml
>>> @@ -26,6 +26,24 @@ properties:
>>> beeper-hz:
>>> description: bell frequency in Hz
>>>
>>> + volume-levels:
>>
>> use -bp suffix:
>> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml#L44
>>
>> which will mean the unit is 1/100 of %, not 1/10. Then you can also drop
>> the $ref.
>
> OK, this is also fine for me. Chaned the description and implementation
> for v9.
>
>>> + description: >
>>> + Array of PWM duty cycle values that correspond to
>>> + linear volume levels. These need to be in the range of
>>> + 0 to 500, while 0 means 0% duty cycle (mute) and 500
>>> + means 50% duty cycle (max volume).
>>> + Please note that the actual volume of most beepers is
>>> + highly non-linear, which means that low volume levels
>>> + are probably somewhere in the range of 1 to 30 (0.1-3%
>>> + duty cycle).
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> + default-volume-level:
>>
>> I propose to use just the value, not the index, so the name should
>> finish with '-bp' and the $ref can be dropped.
>
> I am not so happy with this suggestion. What shall be displayed in
> sysfs as volume if a user specifies a value that is not defined in
> the array.. So I tend to keep this as is.
sysfs is not related to bindings. To rephrase your question: what shall
be shown in anywhere if the index is not correct? The same problem, the
same solution.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 4/5] dt-bindings: input: pwm-beeper: add volume
From: Manuel Traut @ 2023-01-26 16:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Frieder Schrempf, linux-input, devicetree
In-Reply-To: <b5aea934-4514-6b30-be95-f427d01f54bb@linaro.org>
> >>> + default-volume-level:
> >>
> >> I propose to use just the value, not the index, so the name should
> >> finish with '-bp' and the $ref can be dropped.
> >
> > I am not so happy with this suggestion. What shall be displayed in
> > sysfs as volume if a user specifies a value that is not defined in
> > the array.. So I tend to keep this as is.
>
> sysfs is not related to bindings. To rephrase your question: what shall
> be shown in anywhere if the index is not correct? The same problem, the
> same solution.
got it, thanks for the hint. I will implement it in v9.
Regards
Manuel
^ permalink raw reply
* Re: [PATCH resend 2/3] Input: silead - Add a settings module-parameter
From: Gregor Riepl @ 2023-01-26 17:53 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Bastien Nocera, Hans de Goede, Jeff LaBundy
In-Reply-To: <1b118a84-5758-0045-509f-322bac5b0375@redhat.com>
> Having this is actually useful, because users do need to check if
> they actually have a home-button:
>
> 1. Always setting this may lead to false-positive home button presses
> on some models (IIRC, this has been around for a long time)
>
> 2. The home button typical is a windows logo printed on the front of
> cheap windows tablets below the screen. Recently I was adding info
> for yet another such cheap tablet and I asked the user to test
> the home-button since the windows logo was clearly there visually.
> But on this specific model touching the windows logo does not do
> anything.
I vaguely remember that some users also reported Android-targeted
tablets where the surface covering the soft-touch buttons was simply an
extension of the whole touch surface, and not send any explicit key
press events.
But I may be mistaken, or it was a bug in an older driver version that
didn't support touch buttons well.
^ permalink raw reply
* [PATCH 10/35] Documentation: hid: correct spelling
From: Randy Dunlap @ 2023-01-27 6:39 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, linux-input, Jonathan Corbet, linux-doc
In-Reply-To: <20230127064005.1558-1-rdunlap@infradead.org>
Correct spelling problems for Documentation/hid/ as reported
by codespell.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: linux-input@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
---
Documentation/hid/hid-alps.rst | 2 +-
Documentation/hid/hid-bpf.rst | 2 +-
Documentation/hid/hiddev.rst | 2 +-
Documentation/hid/hidraw.rst | 2 +-
Documentation/hid/intel-ish-hid.rst | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff -- a/Documentation/hid/hid-alps.rst b/Documentation/hid/hid-alps.rst
--- a/Documentation/hid/hid-alps.rst
+++ b/Documentation/hid/hid-alps.rst
@@ -9,7 +9,7 @@ Currently ALPS HID driver supports U1 To
U1 device basic information.
========== ======
-Vender ID 0x044E
+Vendor ID 0x044E
Product ID 0x120B
Version ID 0x0121
========== ======
diff -- a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-bpf.rst
--- a/Documentation/hid/hid-bpf.rst
+++ b/Documentation/hid/hid-bpf.rst
@@ -307,7 +307,7 @@ sysfs path: ``/sys/bus/hid/devices/xxxx:
We can not rely on hidraw to bind a BPF program to a HID device. hidraw is an
artefact of the processing of the HID device, and is not stable. Some drivers
-even disable it, so that removes the tracing capabilies on those devices
+even disable it, so that removes the tracing capabilities on those devices
(where it is interesting to get the non-hidraw traces).
On the other hand, the ``hid_id`` is stable for the entire life of the HID device,
diff -- a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
--- a/Documentation/hid/hiddev.rst
+++ b/Documentation/hid/hiddev.rst
@@ -8,7 +8,7 @@ Introduction
In addition to the normal input type HID devices, USB also uses the
human interface device protocols for things that are not really human
interfaces, but have similar sorts of communication needs. The two big
-examples for this are power devices (especially uninterruptable power
+examples for this are power devices (especially uninterruptible power
supplies) and monitor control on higher end monitors.
To support these disparate requirements, the Linux USB system provides
diff -- a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst
--- a/Documentation/hid/hidraw.rst
+++ b/Documentation/hid/hidraw.rst
@@ -163,7 +163,7 @@ HIDIOCGOUTPUT(len):
Get an Output Report
This ioctl will request an output report from the device using the control
-endpoint. Typically, this is used to retrive the initial state of
+endpoint. Typically, this is used to retrieve the initial state of
an output report of a device, before an application updates it as necessary either
via a HIDIOCSOUTPUT request, or the regular device write() interface. The format
of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
diff -- a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -199,7 +199,7 @@ the sender that the memory region for th
DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message
(that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK.
Additionally to DMA address communication, this sequence checks capabilities:
-if thw host doesn't support DMA, then it won't send DMA allocation, so FW can't
+if the host doesn't support DMA, then it won't send DMA allocation, so FW can't
send DMA; if FW doesn't support DMA then it won't respond with
DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers.
Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER,
^ permalink raw reply
* [PATCH 12/35] Documentation: input: correct spelling
From: Randy Dunlap @ 2023-01-27 6:39 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Dmitry Torokhov, Henrik Rydberg, linux-input,
Jonathan Corbet, linux-doc
In-Reply-To: <20230127064005.1558-1-rdunlap@infradead.org>
Correct spelling problems for Documentation/input/ as reported
by codespell.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: linux-input@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
---
Documentation/input/devices/iforce-protocol.rst | 2 +-
Documentation/input/multi-touch-protocol.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -- a/Documentation/input/devices/iforce-protocol.rst b/Documentation/input/devices/iforce-protocol.rst
--- a/Documentation/input/devices/iforce-protocol.rst
+++ b/Documentation/input/devices/iforce-protocol.rst
@@ -49,7 +49,7 @@ OP DATA
== ====
The 2B, LEN and CS fields have disappeared, probably because USB handles
-frames and data corruption is handled or unsignificant.
+frames and data corruption is handled or insignificant.
First, I describe effects that are sent by the device to the computer
diff -- a/Documentation/input/multi-touch-protocol.rst b/Documentation/input/multi-touch-protocol.rst
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -383,7 +383,7 @@ Finger Tracking
---------------
The process of finger tracking, i.e., to assign a unique trackingID to each
-initiated contact on the surface, is a Euclidian Bipartite Matching
+initiated contact on the surface, is a Euclidean Bipartite Matching
problem. At each event synchronization, the set of actual contacts is
matched to the set of contacts from the previous synchronization. A full
implementation can be found in [#f3]_.
^ permalink raw reply
* [PATCH 00/35] Documentation: correct lots of spelling errors (series 1)
From: Randy Dunlap @ 2023-01-27 6:39 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jonathan Corbet, Catalin Marinas, Will Deacon,
Russell King, Jens Axboe, Andrii Nakryiko, Alexei Starovoitov,
Daniel Borkmann, Vladimir Oltean, Steffen Klassert, Daniel Jordan,
Akinobu Mita, Helge Deller, Rafael J. Wysocki, Jiri Kosina,
Benjamin Tissoires, Srinivas Pandruvada, Wolfram Sang,
Dmitry Torokhov, Henrik Rydberg, Karsten Keil, Pavel Machek,
Lee Jones, Josh Poimboeuf, Miroslav Benes, Petr Mladek,
Peter Zijlstra, Ingo Molnar, Jérôme Glisse,
Naoya Horiguchi, Miaohe Lin, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, Bjorn Helgaas, Lorenzo Pieralisi, Marc Zyngier,
Michael Ellerman, Len Brown, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Juri Lelli, Vincent Guittot, David Howells,
Jarkko Sakkinen, Paul Moore, James Morris, Serge E. Hallyn,
Jaroslav Kysela, Takashi Iwai, Mark Brown, Martin K. Petersen,
Daniel Bristot de Oliveira, Steven Rostedt, Greg Kroah-Hartman,
Masami Hiramatsu, Mathieu Poirier, Suzuki K Poulose,
Evgeniy Polyakov, Fenghua Yu, Reinette Chatre, Thomas Gleixner,
Borislav Petkov, Chris Zankel, Max Filippov, alsa-devel,
coresight, bpf, dri-devel, isdn4linux, keyrings, linux-acpi,
linux-block, linux-crypto, linux-doc, linux-fbdev, linux-i2c,
linux-input, linux-leds, linux-pci, linux-s390, linux-scsi,
linux-sgx, linux-spi, linux-trace-devel, linux-trace-kernel,
live-patching, linux-pm, linux-security-module, linux-usb, netdev,
target-devel, linux-mm, openrisc, linux-arm-kernel, linux-xtensa,
linuxppc-dev, x86
Correct many spelling errors in Documentation/ as reported by codespell.
Maintainers of specific kernel subsystems are only Cc-ed on their
respective patches, not the entire series. [if all goes well]
These patches are based on linux-next-20230125.
[PATCH 01/35] Documentation: arm64: correct spelling
[PATCH 02/35] Documentation: arm: correct spelling
[PATCH 03/35] Documentation: block: correct spelling
[PATCH 04/35] Documentation: bpf: correct spelling
[PATCH 05/35] Documentation: core-api: correct spelling
[PATCH 06/35] Documentation: fault-injection: correct spelling
[PATCH 07/35] Documentation: fb: correct spelling
[PATCH 08/35] Documentation: features: correct spelling
[PATCH 09/35] Documentation: firmware-guide/acpi: correct spelling
[PATCH 10/35] Documentation: hid: correct spelling
[PATCH 11/35] Documentation: i2c: correct spelling
[PATCH 12/35] Documentation: input: correct spelling
[PATCH 13/35] Documentation: isdn: correct spelling
[PATCH 14/35] Documentation: leds: correct spelling
[PATCH 15/35] Documentation: litmus-tests: correct spelling
[PATCH 16/35] Documentation: livepatch: correct spelling
[PATCH 17/35] Documentation: locking: correct spelling
[PATCH 18/35] Documentation: mm: correct spelling
[PATCH 19/35] Documentation: openrisc: correct spelling
[PATCH 20/35] Documentation: PCI: correct spelling
[PATCH 21/35] Documentation: powerpc: correct spelling
[PATCH 22/35] Documentation: power: correct spelling
[PATCH 23/35] Documentation: s390: correct spelling
[PATCH 24/35] Documentation: scheduler: correct spelling
[PATCH 25/35] Documentation: security: correct spelling
[PATCH 26/35] Documentation: sound: correct spelling
[PATCH 27/35] Documentation: spi: correct spelling
[PATCH 28/35] Documentation: target: correct spelling
[PATCH 29/35] Documentation: timers: correct spelling
[PATCH 30/35] Documentation: tools/rtla: correct spelling
[PATCH 31/35] Documentation: trace: correct spelling
[PATCH 32/35] Documentation: usb: correct spelling
[PATCH 33/35] Documentation: w1: correct spelling
[PATCH 34/35] Documentation: x86: correct spelling
[PATCH 35/35] Documentation: xtensa: correct spelling
Documentation/PCI/endpoint/pci-vntb-howto.rst | 2 -
Documentation/PCI/msi-howto.rst | 2 -
Documentation/arm/arm.rst | 2 -
Documentation/arm/ixp4xx.rst | 4 +-
Documentation/arm/keystone/knav-qmss.rst | 2 -
Documentation/arm/stm32/stm32-dma-mdma-chaining.rst | 6 +--
Documentation/arm/sunxi/clocks.rst | 2 -
Documentation/arm/swp_emulation.rst | 2 -
Documentation/arm/tcm.rst | 2 -
Documentation/arm/vlocks.rst | 2 -
Documentation/arm64/booting.rst | 2 -
Documentation/arm64/elf_hwcaps.rst | 2 -
Documentation/arm64/sve.rst | 4 +-
Documentation/block/data-integrity.rst | 2 -
Documentation/bpf/libbpf/libbpf_naming_convention.rst | 6 +--
Documentation/bpf/map_xskmap.rst | 2 -
Documentation/bpf/ringbuf.rst | 4 +-
Documentation/bpf/verifier.rst | 2 -
Documentation/core-api/packing.rst | 2 -
Documentation/core-api/padata.rst | 2 -
Documentation/fault-injection/fault-injection.rst | 2 -
Documentation/fb/sm712fb.rst | 2 -
Documentation/fb/sstfb.rst | 2 -
Documentation/features/core/thread-info-in-task/arch-support.txt | 2 -
Documentation/firmware-guide/acpi/acpi-lid.rst | 2 -
Documentation/firmware-guide/acpi/namespace.rst | 2 -
Documentation/hid/hid-alps.rst | 2 -
Documentation/hid/hid-bpf.rst | 2 -
Documentation/hid/hiddev.rst | 2 -
Documentation/hid/hidraw.rst | 2 -
Documentation/hid/intel-ish-hid.rst | 2 -
Documentation/i2c/gpio-fault-injection.rst | 2 -
Documentation/i2c/smbus-protocol.rst | 2 -
Documentation/input/devices/iforce-protocol.rst | 2 -
Documentation/input/multi-touch-protocol.rst | 2 -
Documentation/isdn/interface_capi.rst | 2 -
Documentation/isdn/m_isdn.rst | 2 -
Documentation/leds/leds-qcom-lpg.rst | 4 +-
Documentation/litmus-tests/README | 2 -
Documentation/livepatch/reliable-stacktrace.rst | 2 -
Documentation/locking/lockdep-design.rst | 4 +-
Documentation/locking/locktorture.rst | 2 -
Documentation/locking/locktypes.rst | 2 -
Documentation/locking/preempt-locking.rst | 2 -
Documentation/mm/hmm.rst | 4 +-
Documentation/mm/hwpoison.rst | 2 -
Documentation/openrisc/openrisc_port.rst | 4 +-
Documentation/power/suspend-and-interrupts.rst | 2 -
Documentation/powerpc/kasan.txt | 2 -
Documentation/powerpc/papr_hcalls.rst | 2 -
Documentation/powerpc/qe_firmware.rst | 4 +-
Documentation/powerpc/vas-api.rst | 4 +-
Documentation/s390/pci.rst | 4 +-
Documentation/s390/vfio-ccw.rst | 2 -
Documentation/scheduler/sched-bwc.rst | 2 -
Documentation/scheduler/sched-energy.rst | 4 +-
Documentation/security/digsig.rst | 4 +-
Documentation/security/keys/core.rst | 2 -
Documentation/security/secrets/coco.rst | 2 -
Documentation/sound/alsa-configuration.rst | 8 ++--
Documentation/sound/cards/audigy-mixer.rst | 2 -
Documentation/sound/cards/maya44.rst | 2 -
Documentation/sound/cards/sb-live-mixer.rst | 2 -
Documentation/sound/designs/jack-controls.rst | 2 -
Documentation/sound/designs/seq-oss.rst | 2 -
Documentation/sound/hd-audio/notes.rst | 2 -
Documentation/spi/pxa2xx.rst | 12 +++---
Documentation/spi/spi-lm70llp.rst | 2 -
Documentation/spi/spi-summary.rst | 2 -
Documentation/target/tcmu-design.rst | 2 -
Documentation/timers/hrtimers.rst | 2 -
Documentation/tools/rtla/rtla-timerlat-top.rst | 2 -
Documentation/trace/coresight/coresight-etm4x-reference.rst | 2 -
Documentation/trace/events.rst | 6 +--
Documentation/trace/fprobe.rst | 2 -
Documentation/trace/ftrace-uses.rst | 2 -
Documentation/trace/hwlat_detector.rst | 2 -
Documentation/trace/rv/runtime-verification.rst | 2 -
Documentation/trace/uprobetracer.rst | 2 -
Documentation/usb/chipidea.rst | 19 +++++-----
Documentation/usb/gadget-testing.rst | 2 -
Documentation/usb/mass-storage.rst | 2 -
Documentation/w1/w1-netlink.rst | 2 -
Documentation/x86/boot.rst | 2 -
Documentation/x86/buslock.rst | 2 -
Documentation/x86/mds.rst | 2 -
Documentation/x86/resctrl.rst | 2 -
Documentation/x86/sgx.rst | 2 -
Documentation/xtensa/atomctl.rst | 2 -
89 files changed, 124 insertions(+), 123 deletions(-)
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Vladimir Oltean <olteanv@gmail.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Helge Deller <deller@gmx.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Wolfram Sang <wsa@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Henrik Rydberg <rydberg@bitmath.org>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Lee Jones <lee@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Len Brown <len.brown@intel.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: alsa-devel@alsa-project.org
Cc: coresight@lists.linaro.org
Cc: bpf@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: isdn4linux@listserv.isdn4linux.de
Cc: keyrings@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-block@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-leds@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-sgx@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: linux-trace-devel@vger.kernel.org
Cc: linux-trace-kernel@vger.kernel.org
Cc: live-patching@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: target-devel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: openrisc@lists.librecores.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-xtensa@linux-xtensa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x86@kernel.org
^ permalink raw reply
* [PATCH] input: cyttsp5: Fix bitmask for touch buttons
From: Richard Kjerstadius @ 2023-01-27 10:29 UTC (permalink / raw)
To: linux-input
Cc: Richard Kjerstadius, linus.walleij, dmitry.torokhov, alistair,
linux-kernel
Prior to this patch, the bitmask ends up being 0x3, as opposed to 0x1
which likely was the intention. The erroneous bit results in the driver
reporting 2 different button activations in designs with 2 or more
buttons.
To detect which button has been pressed, cyttsp5_btn_attention() uses a
for loop to iterate through the input buffer, while shifting and
applying a bitmask to determine the state for each button.
Unfortunately, when the bitmask is 0x3 and there are multiple buttons,
this procedure falls apart.
Consider a design with 3 buttons. Pressing the third button will result
in a call to cyttsp5_btn_attention() with the input buffer containing
0x4 (binary 0100). In the first iteration of the for loop cur_btn_state
will be:
(0x4 >> 0 * 1) & 0x3 = 0x4 & 0x3 = 0x0
This is correct. However, in the next iteration this happens:
(0x4 >> 1 * 1) & 0x3 = 0x2 & 0x3 = 0x2
Which means that a key event for key 1 is generated, even though it's
not really active. In the third iteration, the loop detects the button
that was actually pressed:
(0x4 >> 2 * 1) & 0x3 = 0x1 & 0x3 = 0x1
This key event is the only one that should have been detected, but it is
accompanied by the preceding key. Ensuring the applied mask is 0x1
solves this problem.
Signed-off-by: Richard Kjerstadius <richard.kjerstadius@teledyne.com>
---
drivers/input/touchscreen/cyttsp5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
index 4a23d6231382..16caffa35dd9 100644
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -29,7 +29,7 @@
#define CY_MAX_INPUT 512
#define CYTTSP5_PREALLOCATED_CMD_BUFFER 32
#define CY_BITS_PER_BTN 1
-#define CY_NUM_BTN_EVENT_ID GENMASK(CY_BITS_PER_BTN, 0)
+#define CY_NUM_BTN_EVENT_ID GENMASK(CY_BITS_PER_BTN - 1, 0)
#define MAX_AREA 255
#define HID_OUTPUT_BL_SOP 0x1
--
2.39.0
^ permalink raw reply related
* [PATCH RESEND] Input: atmel_captouch - drop obsolete dependency on COMPILE_TEST
From: Jean Delvare @ 2023-01-27 11:28 UTC (permalink / raw)
To: linux-input, LKML
Cc: Daniel Hung-yu Wu, Dmitry Torokhov, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
As a nice side effect, dropping the alternative dependency on
COMPILE_TEST allows removing preprocessor directives, which will
speed up the build.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Daniel Hung-yu Wu <hywu@google.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/Kconfig | 2 +-
drivers/input/misc/atmel_captouch.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
--- linux-6.1.orig/drivers/input/misc/Kconfig
+++ linux-6.1/drivers/input/misc/Kconfig
@@ -107,7 +107,7 @@ config INPUT_ATC260X_ONKEY
config INPUT_ATMEL_CAPTOUCH
tristate "Atmel Capacitive Touch Button Driver"
- depends on OF || COMPILE_TEST
+ depends on OF
depends on I2C
help
Say Y here if an Atmel Capacitive Touch Button device which
--- linux-6.1.orig/drivers/input/misc/atmel_captouch.c
+++ linux-6.1/drivers/input/misc/atmel_captouch.c
@@ -249,7 +249,6 @@ static int atmel_captouch_probe(struct i
return 0;
}
-#ifdef CONFIG_OF
static const struct of_device_id atmel_captouch_of_id[] = {
{
.compatible = "atmel,captouch",
@@ -257,7 +256,6 @@ static const struct of_device_id atmel_c
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, atmel_captouch_of_id);
-#endif
static const struct i2c_device_id atmel_captouch_id[] = {
{ "atmel_captouch", 0 },
@@ -270,7 +268,7 @@ static struct i2c_driver atmel_captouch_
.id_table = atmel_captouch_id,
.driver = {
.name = "atmel_captouch",
- .of_match_table = of_match_ptr(atmel_captouch_of_id),
+ .of_match_table = atmel_captouch_of_id,
},
};
module_i2c_driver(atmel_captouch_driver);
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [git pull] Input updates for v6.1-rc5
From: Linux kernel regression tracking (Thorsten Leemhuis) @ 2023-01-27 12:49 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-kernel, linux-input, Jiri Slaby, Linus Torvalds,
Linux kernel regressions list
In-Reply-To: <824effa5-8b9a-c28a-82bb-9b0ab24623e1@kernel.org>
On 13.12.22 12:41, Jiri Slaby wrote:
> On 19. 11. 22, 2:26, Dmitry Torokhov wrote:
>> to receive updates for the input subsystem. You will get:
>>
>> - a fix for 8042 to stop leaking platform device on unload
>> - a fix for Goodix touchscreens on devices like Nanote UMPC-01 where we
>> need to reset controller to load config from firmware
>> - a workaround for Acer Switch to avoid interrupt storm from home and
>> power buttons
>> - a workaround for more ASUS ZenBook models to detect keyboard cnotroller
>> - a fix for iforce driver to properly handle communication errors
>> - touchpad on HP Laptop 15-da3001TU switched to RMI mode
>>
>> Changelog:
>> ---------
>>
>> Aman Dhoot (1):
>> Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to
>> RMI mode
>
> This appears to break keyboard on HP's 15-da1xxx which appears to have
> the same ID: SYN3286. This happens on 6.0.12.
Dmitry, Jiri's report afaics made you quickly apply a revert that since
round about mid December is in -next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id=3c44e2b6cde674797b76e76d3a903a63ce8a18bb
But it looks like it never made it to mainline (or am I missing
something here? it feels like I do... anyway, moving on.). Was that
intentional or did that simply fall through the cracks due to the
festive season?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke
> synaptics excerpt from dmesg:
> psmouse serio1: synaptics: Trying to set up SMBus access
> psmouse serio1: synaptics: SMbus companion is not ready yet
> ...
> psmouse serio1: synaptics: queried max coordinates: x [..5648], y [..4826]
> psmouse serio1: synaptics: queried min coordinates: x [1292..], y [1026..]
> psmouse serio1: synaptics: Trying to set up SMBus access
> rmi4_smbus 6-002c: registering SMbus-connected sensor
> rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics,
> product: TM3320-003, fw id: 2659795
> input: Synaptics TM3320-003 as
> /devices/pci0000:00/0000:00:1f.4/i2c-6/6-002c/rmi4-00/input/input21
>
>
>
>
> This was reported downstream as a regression between 6.0.10 and 6.0.12:
> https://bugzilla.suse.com/show_bug.cgi?id=1206358
>
> Full dmesgs available there too.
>
>
> 6.0.10 has this instead of the above:
> psmouse serio1: synaptics: queried max coordinates: x [..5648], y [..4826]
> psmouse serio1: synaptics: queried min coordinates: x [1292..], y [1026..]
> psmouse serio1: synaptics: Your touchpad (PNP: SYN3286 PNP0f13) says it
> can support a different bus. If i2c-hid and hid-rmi are not used, you
> might want to try setting psmouse.synaptics_intertouch to 1 and report
> this to linux-input@vger.kernel.org.
> psmouse serio1: synaptics: Touchpad model: 1, fw: 8.16, id: 0x1e2b1,
> caps: 0xf00323/0x840300/0x2e800/0x400000, board id: 3320, fw id: 2659795
>
>
>
> thanks,
^ permalink raw reply
* Re: [PATCH 10/35] Documentation: hid: correct spelling
From: srinivas pandruvada @ 2023-01-27 16:20 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, Jonathan Corbet,
linux-doc
In-Reply-To: <20230127064005.1558-11-rdunlap@infradead.org>
On Thu, 2023-01-26 at 22:39 -0800, Randy Dunlap wrote:
> Correct spelling problems for Documentation/hid/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: linux-input@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
For Documentation/hid/intel-ish-hid.rst
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> Documentation/hid/hid-alps.rst | 2 +-
> Documentation/hid/hid-bpf.rst | 2 +-
> Documentation/hid/hiddev.rst | 2 +-
> Documentation/hid/hidraw.rst | 2 +-
> Documentation/hid/intel-ish-hid.rst | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff -- a/Documentation/hid/hid-alps.rst b/Documentation/hid/hid-
> alps.rst
> --- a/Documentation/hid/hid-alps.rst
> +++ b/Documentation/hid/hid-alps.rst
> @@ -9,7 +9,7 @@ Currently ALPS HID driver supports U1 To
> U1 device basic information.
>
> ========== ======
> -Vender ID 0x044E
> +Vendor ID 0x044E
> Product ID 0x120B
> Version ID 0x0121
> ========== ======
> diff -- a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-
> bpf.rst
> --- a/Documentation/hid/hid-bpf.rst
> +++ b/Documentation/hid/hid-bpf.rst
> @@ -307,7 +307,7 @@ sysfs path: ``/sys/bus/hid/devices/xxxx:
>
> We can not rely on hidraw to bind a BPF program to a HID device.
> hidraw is an
> artefact of the processing of the HID device, and is not stable.
> Some drivers
> -even disable it, so that removes the tracing capabilies on those
> devices
> +even disable it, so that removes the tracing capabilities on those
> devices
> (where it is interesting to get the non-hidraw traces).
>
> On the other hand, the ``hid_id`` is stable for the entire life of
> the HID device,
> diff -- a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
> --- a/Documentation/hid/hiddev.rst
> +++ b/Documentation/hid/hiddev.rst
> @@ -8,7 +8,7 @@ Introduction
> In addition to the normal input type HID devices, USB also uses the
> human interface device protocols for things that are not really
> human
> interfaces, but have similar sorts of communication needs. The two
> big
> -examples for this are power devices (especially uninterruptable
> power
> +examples for this are power devices (especially uninterruptible
> power
> supplies) and monitor control on higher end monitors.
>
> To support these disparate requirements, the Linux USB system
> provides
> diff -- a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst
> --- a/Documentation/hid/hidraw.rst
> +++ b/Documentation/hid/hidraw.rst
> @@ -163,7 +163,7 @@ HIDIOCGOUTPUT(len):
> Get an Output Report
>
> This ioctl will request an output report from the device using the
> control
> -endpoint. Typically, this is used to retrive the initial state of
> +endpoint. Typically, this is used to retrieve the initial state of
> an output report of a device, before an application updates it as
> necessary either
> via a HIDIOCSOUTPUT request, or the regular device write()
> interface. The format
> of the buffer issued with this report is identical to that of
> HIDIOCGFEATURE.
> diff -- a/Documentation/hid/intel-ish-hid.rst
> b/Documentation/hid/intel-ish-hid.rst
> --- a/Documentation/hid/intel-ish-hid.rst
> +++ b/Documentation/hid/intel-ish-hid.rst
> @@ -199,7 +199,7 @@ the sender that the memory region for th
> DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus
> message
> (that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK.
> Additionally to DMA address communication, this sequence checks
> capabilities:
> -if thw host doesn't support DMA, then it won't send DMA allocation,
> so FW can't
> +if the host doesn't support DMA, then it won't send DMA allocation,
> so FW can't
> send DMA; if FW doesn't support DMA then it won't respond with
> DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers.
> Here ISH acts as busmaster DMA controller. Hence when host sends
> DMA_XFER,
^ permalink raw reply
* [PATCH] dt-bindings: input: touchscreen: st,stmfts: convert to dtschema
From: Krzysztof Kozlowski @ 2023-01-27 20:20 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Maxime Coquelin, Alexandre Torgue, linux-input, devicetree,
linux-stm32, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski
Convert the ST-Microelectronics FingerTip touchscreen controller
bindings to DT schema.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../bindings/input/touchscreen/st,stmfts.txt | 41 -----------
.../bindings/input/touchscreen/st,stmfts.yaml | 72 +++++++++++++++++++
2 files changed, 72 insertions(+), 41 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
deleted file mode 100644
index 0a5d0cb4a280..000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-* ST-Microelectronics FingerTip touchscreen controller
-
-The ST-Microelectronics FingerTip device provides a basic touchscreen
-functionality. Along with it the user can enable the touchkey which can work as
-a basic HOME and BACK key for phones.
-
-The driver supports also hovering as an absolute single touch event with x, y, z
-coordinates.
-
-Required properties:
-- compatible : must be "st,stmfts"
-- reg : I2C slave address, (e.g. 0x49)
-- interrupts : interrupt specification
-- avdd-supply : analogic power supply
-- vdd-supply : power supply
-- touchscreen-size-x : see touchscreen.txt
-- touchscreen-size-y : see touchscreen.txt
-
-Optional properties:
-- touch-key-connected : specifies whether the touchkey feature is connected
-- ledvdd-supply : power supply to the touch key leds
-
-Example:
-
-i2c@00000000 {
-
- /* ... */
-
- touchscreen@49 {
- compatible = "st,stmfts";
- reg = <0x49>;
- interrupt-parent = <&gpa1>;
- interrupts = <1 IRQ_TYPE_NONE>;
- touchscreen-size-x = <1599>;
- touchscreen-size-y = <2559>;
- touch-key-connected;
- avdd-supply = <&ldo30_reg>;
- vdd-supply = <&ldo31_reg>;
- ledvdd-supply = <&ldo33_reg>;
- };
-};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
new file mode 100644
index 000000000000..c593ae63d0ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/st,stmfts.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST-Microelectronics FingerTip touchscreen controller
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+ The ST-Microelectronics FingerTip device provides a basic touchscreen
+ functionality. Along with it the user can enable the touchkey which can work
+ as a basic HOME and BACK key for phones.
+
+allOf:
+ - $ref: touchscreen.yaml#
+
+properties:
+ compatible:
+ const: st,stmfts
+
+ reg:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analogic power supply
+
+ interrupts:
+ maxItems: 1
+
+ ledvdd-supply:
+ description: Power supply to the touch key leds
+
+ touch-key-connected:
+ type: boolean
+ description: The touchkey feature is connected
+
+ vdd-supply:
+ description: Power supply
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - interrupts
+ - vdd-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@49 {
+ compatible = "st,stmfts";
+ reg = <0x49>;
+ interrupt-parent = <&gpa1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ touchscreen-size-x = <1599>;
+ touchscreen-size-y = <2559>;
+ touch-key-connected;
+ avdd-supply = <&ldo30_reg>;
+ vdd-supply = <&ldo31_reg>;
+ ledvdd-supply = <&ldo33_reg>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH] HID: quirks: Add quirk for Logitech G923 Xbox steering wheel
From: Walt Holman @ 2023-01-27 22:03 UTC (permalink / raw)
To: linux-input, linux-kernel, Mattijs Korpershoek
Hello,
This patch adds support for the Logitech G923 Xbox edition steering
wheel.
-Walt
diff -uprN linux-master-source/drivers/hid/hid-ids.h linux-master-target/drivers/hid/hid-ids.h
--- linux-master-source/drivers/hid/hid-ids.h 2023-01-27 15:18:14.000000000 -0600
+++ linux-master-target/drivers/hid/hid-ids.h 2023-01-27 15:50:24.077639994 -0600
@@ -819,6 +819,7 @@
#define USB_DEVICE_ID_LOGITECH_G510_USB_AUDIO 0xc22e
#define USB_DEVICE_ID_LOGITECH_G29_WHEEL 0xc24f
#define USB_DEVICE_ID_LOGITECH_G920_WHEEL 0xc262
+#define USB_DEVICE_ID_LOGITECH_G923_XBOX_WHEEL 0xc26e
#define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283
#define USB_DEVICE_ID_LOGITECH_FORCE3D_PRO 0xc286
#define USB_DEVICE_ID_LOGITECH_FLIGHT_SYSTEM_G940 0xc287
diff -uprN linux-master-source/drivers/hid/hid-logitech-hidpp.c linux-master-target/drivers/hid/hid-logitech-hidpp.c
--- linux-master-source/drivers/hid/hid-logitech-hidpp.c 2023-01-27 15:18:14.000000000 -0600
+++ linux-master-target/drivers/hid/hid-logitech-hidpp.c 2023-01-27 15:50:24.077639994 -0600
@@ -4347,6 +4347,9 @@ static const struct hid_device_id hidpp_
{ /* Logitech G920 Wheel over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
+ { /* Logitech G923 Wheel (Xbox version) over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G923_XBOX_WHEEL),
+ .driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS },
{ /* Logitech G Pro Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC088) },
^ permalink raw reply
* Re: [PATCH] HID: quirks: Add quirk for Logitech G923 Xbox steering wheel
From: Walt Holman @ 2023-01-27 22:06 UTC (permalink / raw)
To: linux-input, linux-kernel, Mattijs Korpershoek
In-Reply-To: <823df262-aa1d-4340-666f-07b991fce64b@gmail.com>
On 1/27/23 16:03, Walt Holman wrote:
> Hello,
>
> This patch adds support for the Logitech G923 Xbox edition steering
> wheel.
>
> -Walt
>
> diff -uprN linux-master-source/drivers/hid/hid-ids.h linux-master-target/drivers/hid/hid-ids.h
> --- linux-master-source/drivers/hid/hid-ids.h 2023-01-27 15:18:14.000000000 -0600
> +++ linux-master-target/drivers/hid/hid-ids.h 2023-01-27 15:50:24.077639994 -0600
> @@ -819,6 +819,7 @@
> #define USB_DEVICE_ID_LOGITECH_G510_USB_AUDIO 0xc22e
> #define USB_DEVICE_ID_LOGITECH_G29_WHEEL 0xc24f
> #define USB_DEVICE_ID_LOGITECH_G920_WHEEL 0xc262
> +#define USB_DEVICE_ID_LOGITECH_G923_XBOX_WHEEL 0xc26e
> #define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283
> #define USB_DEVICE_ID_LOGITECH_FORCE3D_PRO 0xc286
> #define USB_DEVICE_ID_LOGITECH_FLIGHT_SYSTEM_G940 0xc287
> diff -uprN linux-master-source/drivers/hid/hid-logitech-hidpp.c linux-master-target/drivers/hid/hid-logitech-hidpp.c
> --- linux-master-source/drivers/hid/hid-logitech-hidpp.c 2023-01-27 15:18:14.000000000 -0600
> +++ linux-master-target/drivers/hid/hid-logitech-hidpp.c 2023-01-27 15:50:24.077639994 -0600
> @@ -4347,6 +4347,9 @@ static const struct hid_device_id hidpp_
> { /* Logitech G920 Wheel over USB */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G920_WHEEL),
> .driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
> + { /* Logitech G923 Wheel (Xbox version) over USB */
> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G923_XBOX_WHEEL),
> + .driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS },
> { /* Logitech G Pro Gaming Mouse over USB */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC088) },
>
Signed off by: Walt Holman (waltholman09@gmail.com)
^ 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;
as well as URLs for NNTP newsgroup(s).