* Re: [PATCH] input: cyttsp5: Fix bitmask for touch buttons
From: Alistair @ 2023-02-01 8:00 UTC (permalink / raw)
To: Richard Kjerstadius, linux-input
Cc: Richard Kjerstadius, Linus Walleij, Dmitry Torokhov,
Linux Kernel Mailing List
In-Reply-To: <20230127102903.3317089-1-richard.kjerstadius@teledyne.com>
On Fri, 27 Jan 2023, at 8:29 PM, Richard Kjerstadius wrote:
> 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>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Alistair
> ---
> 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
* [PATCH v2] HID: Ignore battery for ELAN touchscreen 29DF on HP
From: Luka Guzenko @ 2023-02-01 1:14 UTC (permalink / raw)
To: benjamin.tissoires; +Cc: linux-input, linux-kernel, Luka Guzenko
The touchscreen reports a battery status of 0% and jumps to 1% when a
stylus is used. The device ID was added and the battery ignore quirk was
enabled for it.
Signed-off-by: Luka Guzenko <l.guzenko@web.de>
---
V1 -> V2: linux-hardware.org suggests that this touchscreen is present in all
devices of the Spectre x360 13-aw0xxx family. Renamed Device_ID
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 82713ef3aaa6..78f4846e5711 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -414,6 +414,7 @@
#define I2C_DEVICE_ID_HP_ENVY_X360_15T_DR100 0x29CF
#define I2C_DEVICE_ID_HP_ENVY_X360_EU0009NV 0x2CF9
#define I2C_DEVICE_ID_HP_SPECTRE_X360_15 0x2817
+#define I2C_DEVICE_ID_HP_SPECTRE_X360_13_AW0XXX 0x29DF
#define USB_DEVICE_ID_ASUS_UX550VE_TOUCHSCREEN 0x2544
#define USB_DEVICE_ID_ASUS_UX550_TOUCHSCREEN 0x2706
#define I2C_DEVICE_ID_SURFACE_GO_TOUCHSCREEN 0x261A
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 9b59e436df0a..27f17fafce58 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -384,6 +384,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_SPECTRE_X360_15),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_SPECTRE_X360_13_AW0XXX),
+ HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_SURFACE_GO_TOUCHSCREEN),
HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_SURFACE_GO2_TOUCHSCREEN),
--
2.39.1
^ permalink raw reply related
* [PATCH v7] HID: multitouch: Add quirks for flipped axes
From: Allen Ballway @ 2023-01-31 19:46 UTC (permalink / raw)
To: ballway
Cc: benjamin.tissoires, dmitry.torokhov, dtor, jikos, linux-input,
linux-kernel, rydberg, lukas.bulwahn
In-Reply-To: <20230110202550.651091-1-ballway@chromium.org>
Certain touchscreen devices, such as the ELAN9034, are oriented
incorrectly and report touches on opposite points on the X and Y axes.
For example, a 100x200 screen touched at (10,20) would report (90, 180)
and vice versa.
This is fixed by adding device quirks to transform the touch points
into the correct spaces, from X -> MAX(X) - X, and Y -> MAX(Y) - Y.
Signed-off-by: Allen Ballway <ballway@chromium.org>
---
V6 -> V7: Fix typo in config name.
V5 -> V6: Add another IS_ENABLED check for CONFIG_I2C_DMI_CORE because
the module may not be there at all.
V4 -> V5: Add IS_ENABLED check for CONFIG_DMI to prevent linker error.
V3 -> V4: Move quirk logic to i2c_hid_get_dmi_quirks and remove
duplicate quirks from hid-multitouch.
V2 -> V3: Use existing HID_QUIRK_*_INVERT and match the quirk in
hid-quirk, passing down to hid-multitouch through the hid device.
V1 -> V2: Address review comments, change to use DMI match. Confirmed
MT_TOOL_X/Y require transformation and update orientation based on
flipped axes.
drivers/hid/hid-multitouch.c | 39 ++++++++++++++++++---
drivers/hid/hid-quirks.c | 6 ++++
drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 43 ++++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid.h | 3 ++
4 files changed, 87 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 91a4d3fc30e08..622fe6928104c 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -71,6 +71,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_SEPARATE_APP_REPORT BIT(19)
#define MT_QUIRK_FORCE_MULTI_INPUT BIT(20)
#define MT_QUIRK_DISABLE_WAKEUP BIT(21)
+#define MT_QUIRK_ORIENTATION_INVERT BIT(22)
#define MT_INPUTMODE_TOUCHSCREEN 0x02
#define MT_INPUTMODE_TOUCHPAD 0x03
@@ -1009,6 +1010,7 @@ static int mt_process_slot(struct mt_device *td, struct input_dev *input,
struct mt_usages *slot)
{
struct input_mt *mt = input->mt;
+ struct hid_device *hdev = td->hdev;
__s32 quirks = app->quirks;
bool valid = true;
bool confidence_state = true;
@@ -1086,6 +1088,10 @@ static int mt_process_slot(struct mt_device *td, struct input_dev *input,
int orientation = wide;
int max_azimuth;
int azimuth;
+ int x;
+ int y;
+ int cx;
+ int cy;
if (slot->a != DEFAULT_ZERO) {
/*
@@ -1104,6 +1110,9 @@ static int mt_process_slot(struct mt_device *td, struct input_dev *input,
if (azimuth > max_azimuth * 2)
azimuth -= max_azimuth * 4;
orientation = -azimuth;
+ if (quirks & MT_QUIRK_ORIENTATION_INVERT)
+ orientation = -orientation;
+
}
if (quirks & MT_QUIRK_TOUCH_SIZE_SCALING) {
@@ -1115,10 +1124,23 @@ static int mt_process_slot(struct mt_device *td, struct input_dev *input,
minor = minor >> 1;
}
- input_event(input, EV_ABS, ABS_MT_POSITION_X, *slot->x);
- input_event(input, EV_ABS, ABS_MT_POSITION_Y, *slot->y);
- input_event(input, EV_ABS, ABS_MT_TOOL_X, *slot->cx);
- input_event(input, EV_ABS, ABS_MT_TOOL_Y, *slot->cy);
+ x = hdev->quirks & HID_QUIRK_X_INVERT ?
+ input_abs_get_max(input, ABS_MT_POSITION_X) - *slot->x :
+ *slot->x;
+ y = hdev->quirks & HID_QUIRK_Y_INVERT ?
+ input_abs_get_max(input, ABS_MT_POSITION_Y) - *slot->y :
+ *slot->y;
+ cx = hdev->quirks & HID_QUIRK_X_INVERT ?
+ input_abs_get_max(input, ABS_MT_POSITION_X) - *slot->cx :
+ *slot->cx;
+ cy = hdev->quirks & HID_QUIRK_Y_INVERT ?
+ input_abs_get_max(input, ABS_MT_POSITION_Y) - *slot->cy :
+ *slot->cy;
+
+ input_event(input, EV_ABS, ABS_MT_POSITION_X, x);
+ input_event(input, EV_ABS, ABS_MT_POSITION_Y, y);
+ input_event(input, EV_ABS, ABS_MT_TOOL_X, cx);
+ input_event(input, EV_ABS, ABS_MT_TOOL_Y, cy);
input_event(input, EV_ABS, ABS_MT_DISTANCE, !*slot->tip_state);
input_event(input, EV_ABS, ABS_MT_ORIENTATION, orientation);
input_event(input, EV_ABS, ABS_MT_PRESSURE, *slot->p);
@@ -1735,6 +1757,15 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (id->vendor == HID_ANY_ID && id->product == HID_ANY_ID)
td->serial_maybe = true;
+
+ /* Orientation is inverted if the X or Y axes are
+ * flipped, but normalized if both are inverted.
+ */
+ if (hdev->quirks & (HID_QUIRK_X_INVERT | HID_QUIRK_Y_INVERT) &&
+ !((hdev->quirks & HID_QUIRK_X_INVERT)
+ && (hdev->quirks & HID_QUIRK_Y_INVERT)))
+ td->mtclass.quirks = MT_QUIRK_ORIENTATION_INVERT;
+
/* This allows the driver to correctly support devices
* that emit events over several HID messages.
*/
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 0e9702c7f7d6c..78452faf3c9b4 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -19,6 +19,7 @@
#include <linux/input/elan-i2c-ids.h>
#include "hid-ids.h"
+#include "i2c-hid/i2c-hid.h"
/*
* Alphabetically sorted by vendor then product.
@@ -1298,6 +1299,11 @@ unsigned long hid_lookup_quirk(const struct hid_device *hdev)
quirks = hid_gets_squirk(hdev);
mutex_unlock(&dquirks_lock);
+ /* Get quirks specific to I2C devices */
+ if (IS_ENABLED(CONFIG_I2C_HID_CORE) && IS_ENABLED(CONFIG_DMI) &&
+ hdev->bus == BUS_I2C)
+ quirks |= i2c_hid_get_dmi_quirks(hdev->vendor, hdev->product);
+
return quirks;
}
EXPORT_SYMBOL_GPL(hid_lookup_quirk);
diff --git a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
index 8e0f67455c098..554a7dc285365 100644
--- a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
+++ b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
@@ -10,8 +10,10 @@
#include <linux/types.h>
#include <linux/dmi.h>
#include <linux/mod_devicetable.h>
+#include <linux/hid.h>
#include "i2c-hid.h"
+#include "../hid-ids.h"
struct i2c_hid_desc_override {
@@ -416,6 +418,28 @@ static const struct dmi_system_id i2c_hid_dmi_desc_override_table[] = {
{ } /* Terminate list */
};
+static const struct hid_device_id i2c_hid_elan_flipped_quirks = {
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_ELAN, 0x2dcd),
+ HID_QUIRK_X_INVERT | HID_QUIRK_Y_INVERT
+};
+
+/*
+ * This list contains devices which have specific issues based on the system
+ * they're on and not just the device itself. The driver_data will have a
+ * specific hid device to match against.
+ */
+static const struct dmi_system_id i2c_hid_dmi_quirk_table[] = {
+ {
+ .ident = "DynaBook K50/FR",
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dynabook Inc."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "dynabook K50/FR"),
+ },
+ .driver_data = (void *)&i2c_hid_elan_flipped_quirks,
+ },
+ { } /* Terminate list */
+};
+
struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name)
{
@@ -450,3 +474,22 @@ char *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
*size = override->hid_report_desc_size;
return override->hid_report_desc;
}
+
+u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product)
+{
+ u32 quirks = 0;
+ const struct dmi_system_id *system_id =
+ dmi_first_match(i2c_hid_dmi_quirk_table);
+
+ if (system_id) {
+ const struct hid_device_id *device_id =
+ (struct hid_device_id *)(system_id->driver_data);
+
+ if (device_id && device_id->vendor == vendor &&
+ device_id->product == product)
+ quirks = device_id->driver_data;
+ }
+
+ return quirks;
+}
+EXPORT_SYMBOL_GPL(i2c_hid_get_dmi_quirks);
diff --git a/drivers/hid/i2c-hid/i2c-hid.h b/drivers/hid/i2c-hid/i2c-hid.h
index 96c75510ad3f1..2c7b66d5caa0f 100644
--- a/drivers/hid/i2c-hid/i2c-hid.h
+++ b/drivers/hid/i2c-hid/i2c-hid.h
@@ -9,6 +9,7 @@
struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name);
char *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
unsigned int *size);
+u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product);
#else
static inline struct i2c_hid_desc
*i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name)
@@ -16,6 +17,8 @@ static inline struct i2c_hid_desc
static inline char *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
unsigned int *size)
{ return NULL; }
+static inline u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product)
+{ return 0; }
#endif
/**
--
2.39.0.rc1.256.g54fd8350bd-goog
^ permalink raw reply related
* Re: [PATCH v2 0/5] HID: manually unregister leds on device removal to prevent UAFs
From: Lee Jones @ 2023-01-31 17:19 UTC (permalink / raw)
To: Pietro Borrello
Cc: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Roderick Colenbrander, Sven Eckelmann, linux-leds,
Cristiano Giuffrida, Bos, H.J., Jakob Koschel, linux-input,
linux-kernel, Jiri Kosina, Roderick Colenbrander
In-Reply-To: <20230125-hid-unregister-leds-v2-0-689cc62fc878@diag.uniroma1.it>
> To: Jiri Kosina <jikos@kernel.org>
> To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> To: Hanno Zulla <kontakt@hanno.de>
> To: Pavel Machek <pavel@ucw.cz>
> To: Lee Jones <lee@kernel.org>
Not entirely sure why I'm receiving these?
> To: Roderick Colenbrander <roderick.colenbrander@sony.com>
> To: Sven Eckelmann <sven@narfation.org>
> Cc: linux-leds@vger.kernel.org
> Cc: Cristiano Giuffrida <c.giuffrida@vu.nl>
> Cc: "Bos, H.J." <h.j.bos@vu.nl>
> Cc: Jakob Koschel <jkl820.git@gmail.com>
> Cc: linux-input@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: Roderick Colenbrander <roderick@gaikai.com>
> Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
>
> ---
> Changes in v2:
> - dualshock4: Clarify UAF
> - dualsense: Clarify UAF
> - dualsense: Unregister multicolor led controller
> - Link to v1: https://lore.kernel.org/r/20230125-hid-unregister-leds-v1-0-9a5192dcef16@diag.uniroma1.it
>
> ---
> Pietro Borrello (5):
> HID: bigben_remove: manually unregister leds
> HID: asus_remove: manually unregister led
> HID: dualsense_remove: manually unregister leds
> HID: dualshock4_remove: manually unregister leds
> HID: sony_remove: manually unregister leds
>
> drivers/hid/hid-asus.c | 1 +
> drivers/hid/hid-bigbenff.c | 5 +++++
> drivers/hid/hid-playstation.c | 10 ++++++++++
> drivers/hid/hid-sony.c | 8 ++++++++
> 4 files changed, 24 insertions(+)
> ---
> base-commit: 2241ab53cbb5cdb08a6b2d4688feb13971058f65
> change-id: 20230125-hid-unregister-leds-4cbf67099e1d
>
> Best regards,
> --
> Pietro Borrello <borrello@diag.uniroma1.it>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 4/4] CP2112 Devicetree Support
From: Krzysztof Kozlowski @ 2023-01-31 16:45 UTC (permalink / raw)
To: Daniel Kaehn
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
devicetree, linux-input, ethan.twardy
In-Reply-To: <CAP+ZCCe6J8y=qLMWafXPur1V_0=oQdw2QWqeAZ-C3TroMB4HhA@mail.gmail.com>
On 31/01/2023 02:06, Daniel Kaehn wrote:
> On Sun, Jan 29, 2023 at 5:06 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 28/01/2023 21:26, Danny Kaehn wrote:
>>> +#if defined(CONFIG_OF_GPIO)
>>
>> Don't use #if, but IS_ENABLED(). I think it should work here.
>
> I think I will still need to use an #if / some sort of preprocessor directive,
> since of_node is only a member of the gpio_chip struct if that is enabled
> (and thus causes a compile error if done outside of the preprocessor)...
> Unless I'm misinterpreting your comment?
If of_node in gpio_chip is indeed hidden by #ifdef, then the code is ok.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH 00/35] Documentation: correct lots of spelling errors (series 1)
From: Catalin Marinas @ 2023-01-31 16:28 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Will Deacon, Jonathan Corbet, 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
In-Reply-To: <20230127064005.1558-1-rdunlap@infradead.org>
On Thu, 26 Jan 2023 22:39:30 -0800, Randy Dunlap wrote:
> 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.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[01/35] Documentation: arm64: correct spelling
https://git.kernel.org/arm64/c/a70f00e7f1a3
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 5/8] Docs/input/index: Add missing SPDX License Identifier
From: Mauro Carvalho Chehab @ 2023-01-31 14:57 UTC (permalink / raw)
To: SeongJae Park
Cc: Jonathan Corbet, Dmitry Torokhov, linux-input, linux-doc,
linux-kernel
In-Reply-To: <20230122213650.187710-6-sj@kernel.org>
Em Sun, 22 Jan 2023 21:36:47 +0000
SeongJae Park <sj@kernel.org> escreveu:
> Add missing SPDX License Identifier for input documentation index file.
>
> Signed-off-by: SeongJae Park <sj@kernel.org>
Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org>
> ---
> Documentation/input/index.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/input/index.rst b/Documentation/input/index.rst
> index 35581cd18e91..d60bf9cfe005 100644
> --- a/Documentation/input/index.rst
> +++ b/Documentation/input/index.rst
> @@ -1,3 +1,5 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> ===================
> Input Documentation
> ===================
Thanks,
Mauro
^ permalink raw reply
* Re: Dependency on non-existing config I2C_DMI_CORE in commit a2f416bf062a ("HID: multitouch: Add quirks for flipped axes")
From: Allen Ballway @ 2023-01-31 14:43 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: linux-input, Jiri Kosina, Jiri Kosina, Benjamin Tissoires,
Henrik Rydberg, Linux Kernel Mailing List
In-Reply-To: <CAKXUXMycsUQ3aWbAHa6fnSwmQpTt9PhagY14_k2sKGC+vGiqGg@mail.gmail.com>
Hi Lukas,
Thanks for catching this, that's definitely a mistake in my code.
That was supposed to be CONFIG_I2C_HID_CORE.
Should I send a follow-up patch for this, or another revision for the patch?
It looks like it hasn't been pulled into the mainline branch yet and I'm not
familiar with updating it while in a maintainer branch.
Thanks,
Allen
On Mon, Jan 30, 2023 at 3:44 AM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>
> Dear Allen,
>
> with commit a2f416bf062a ("HID: multitouch: Add quirks for flipped
> axes"), you add code that is dependent on the CONFIG_I2C_DMI_CORE.
> However, this config symbol has not been defined anywhere in the
> kernel repository. Is this a mistake in your code and you intended to
> refer to another config symbol? Is there another patch to come that
> adds this config symbol? Or is this a config symbol that only exists
> in some out-of-tree repository?
>
> Something might be odd here, because this code is effectively dead now
> with being dependent on a non-existing config symbol.
>
> Best regards,
>
> Lukas
^ permalink raw reply
* [PATCH v2 5/5] HID: sony_remove: manually unregister leds
From: Pietro Borrello @ 2023-01-31 13:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Lee Jones, Roderick Colenbrander, Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander,
Pietro Borrello
In-Reply-To: <20230125-hid-unregister-leds-v2-0-689cc62fc878@diag.uniroma1.it>
Unregister the LED controller before device removal, as
sony_led_set_brightness() may schedule sc->state_worker
after the structure has been freed, causing a use-after-free.
Fixes: 0a286ef27852 ("HID: sony: Add LED support for Sixaxis/Dualshock3 USB")
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: Sven Eckelmann <sven@narfation.org>
---
drivers/hid/hid-sony.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 13125997ab5e..146677c8319c 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -3083,6 +3083,7 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
static void sony_remove(struct hid_device *hdev)
{
struct sony_sc *sc = hid_get_drvdata(hdev);
+ int n;
if (sc->quirks & (GHL_GUITAR_PS3WIIU | GHL_GUITAR_PS4)) {
del_timer_sync(&sc->ghl_poke_timer);
@@ -3100,6 +3101,13 @@ static void sony_remove(struct hid_device *hdev)
if (sc->hw_version_created)
device_remove_file(&sc->hdev->dev, &dev_attr_hardware_version);
+ if (sc->quirks & SONY_LED_SUPPORT) {
+ for (n = 0; n < sc->led_count; n++) {
+ if (sc->leds[n])
+ devm_led_classdev_unregister(&hdev->dev, sc->leds[n]);
+ }
+ }
+
sony_cancel_work_sync(sc);
sony_remove_dev_list(sc);
--
2.25.1
^ permalink raw reply related
* [PATCH v2 4/5] HID: dualshock4_remove: manually unregister leds
From: Pietro Borrello @ 2023-01-31 13:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Lee Jones, Roderick Colenbrander, Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander,
Pietro Borrello
In-Reply-To: <20230125-hid-unregister-leds-v2-0-689cc62fc878@diag.uniroma1.it>
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
* [PATCH v2 3/5] HID: dualsense_remove: manually unregister leds
From: Pietro Borrello @ 2023-01-31 13:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Lee Jones, Roderick Colenbrander, Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander,
Pietro Borrello
In-Reply-To: <20230125-hid-unregister-leds-v2-0-689cc62fc878@diag.uniroma1.it>
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 2/5] HID: asus_remove: manually unregister led
From: Pietro Borrello @ 2023-01-31 13:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Lee Jones, Roderick Colenbrander, Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander,
Pietro Borrello
In-Reply-To: <20230125-hid-unregister-leds-v2-0-689cc62fc878@diag.uniroma1.it>
Unregister the LED controller before device removal, as
asus_kbd_backlight_set() may schedule led->work after the structure
has been freed, causing a use-after-free.
Fixes: af22a610bc38 ("HID: asus: support backlight on USB keyboards")
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
---
drivers/hid/hid-asus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index f99752b998f3..0f274c8d1bef 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1122,6 +1122,7 @@ static void asus_remove(struct hid_device *hdev)
if (drvdata->kbd_backlight) {
drvdata->kbd_backlight->removed = true;
+ devm_led_classdev_unregister(&hdev->dev, &drvdata->kbd_backlight->cdev);
cancel_work_sync(&drvdata->kbd_backlight->work);
}
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/5] HID: bigben_remove: manually unregister leds
From: Pietro Borrello @ 2023-01-31 13:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Lee Jones, Roderick Colenbrander, Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander,
Pietro Borrello
In-Reply-To: <20230125-hid-unregister-leds-v2-0-689cc62fc878@diag.uniroma1.it>
Unregister the LED controllers before device removal, as
bigben_set_led() may schedule bigben->worker after the structure has
been freed, causing a use-after-free.
Fixes: 4eb1b01de5b9 ("HID: hid-bigbenff: fix race condition for scheduled work during removal")
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
---
drivers/hid/hid-bigbenff.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-bigbenff.c b/drivers/hid/hid-bigbenff.c
index e8b16665860d..d3201b755595 100644
--- a/drivers/hid/hid-bigbenff.c
+++ b/drivers/hid/hid-bigbenff.c
@@ -306,9 +306,14 @@ static enum led_brightness bigben_get_led(struct led_classdev *led)
static void bigben_remove(struct hid_device *hid)
{
+ int n;
struct bigben_device *bigben = hid_get_drvdata(hid);
bigben->removed = true;
+ for (n = 0; n < NUM_LEDS; n++) {
+ if (bigben->leds[n])
+ devm_led_classdev_unregister(&hid->dev, bigben->leds[n]);
+ }
cancel_work_sync(&bigben->worker);
hid_hw_stop(hid);
}
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/5] HID: manually unregister leds on device removal to prevent UAFs
From: Pietro Borrello @ 2023-01-31 13:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Hanno Zulla, Pavel Machek,
Lee Jones, Roderick Colenbrander, Sven Eckelmann
Cc: linux-leds, Cristiano Giuffrida, Bos, H.J., Jakob Koschel,
linux-input, linux-kernel, Jiri Kosina, Roderick Colenbrander,
Pietro Borrello
I noticed a recurring pattern is present in multiple hid devices in the
Linux tree, where the LED controller of a device schedules a work_struct
to interact with the hardware.
The work_struct is embedded in the device structure and thus, is freed
at device removal.
The issue is that a LED worker may be scheduled by a timer concurrently
with device removal, causing the work_struct to be accessed after having
been freed.
I was able to trigger the issue in hid-bigbenff.c and hid-asus.c
where the work_structs may be scheduled by the LED controller
while the device is disconnecting, triggering use-after-frees.
I can attach the reproducer, but it's very simple USB configuration,
using the /dev/raw-gadget interface with some more USB interactions
to manage LEDs configuration and pass checks in asus_kbd_init()
and asus_kbd_get_functions() in case of hid-asus.c.
I triggered the issue by connecting a device and immediately
disconnecting it, so that the remove function runs before the LED one
which remains pending.
More drivers have the same pattern (hid-lg-g15.c, hid-playstation.c,
hid-sony.c) but I wasn't able to properly pass the right descriptors
to trigger the led configurations needed to trigger the workers.
Some other drivers manually unregister at removal (hid-corsair.c,
hid-gt683r.c, hid-lenovo.c) since they do not use the managed
interface, which is safe, to my understanding.
Also, a similar pattern is present with callbacks which schedule
a worker originating from input_ff_create_memless() (e.g.,
in hid-bigbenff.c) but in these cases, I wasn't able to trigger
the race condition with the event handling to schedule the worker
during device removal. However, I have no experience with the USB
protocol and I'm not able to say that they cannot be triggered.
I am currently wondering if this is due to some emulation of the
/dev/raw-gadget interface or if it's effectively an issue with how each
device manages resource removal.
But I wonder why syzkaller didn't find any crash while fuzzing the
interface with upstream-usb.config, as they seem pretty
straightforward to trigger.
Configuring the kernel with CONFIG_DEBUG_OBJECTS, it emits
a warning in debug_check_no_obj_freed, which makes it clear that
device removal is freeing resources in use.
KASAN detects them as use-after-free.
I am attaching multiple patches for all the drivers I suspect the bug
is present.
The proposed patches unregister the LED controllers before removing the
device itself.
I attach the (partial for brevity) ODEBUG dumps:
```hid-bigbenff.c
[ 37.803135][ T1170] usb 1-1: USB disconnect, device number 2
[ 37.827979][ T1170] ODEBUG: free active (active state 0) object
type: work_struct hint: bigben_worker+0x0/0x860
[ 37.829634][ T1170] WARNING: CPU: 0 PID: 1170 at
lib/debugobjects.c:505 debug_check_no_obj_freed+0x43a/0x630
[ 37.830904][ T1170] Modules linked in:
[ 37.831413][ T1170] CPU: 0 PID: 1170 Comm: kworker/0:3 Not tainted
6.1.0-rc4-dirty #43
[ 37.832465][ T1170] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 37.833751][ T1170] Workqueue: usb_hub_wq hub_event
[ 37.834409][ T1170] RIP: 0010:debug_check_no_obj_freed+0x43a/0x630
[ 37.835218][ T1170] Code: 48 89 ef e8 28 82 58 ff 49 8b 14 24 4c 8b
45 00 48 c7 c7 40 5f 09 87 48 c7 c6 60 5b 09 87 89 d9 4d 89 f9 31 c0
e8 46 25 ef fe <0f> 0b 4c 8b 64 24 20 48 ba 00 00 00 00 00 fc ff df ff
05 4f 7c 17
[ 37.837667][ T1170] RSP: 0018:ffffc900006fee60 EFLAGS: 00010246
[ 37.838503][ T1170] RAX: 0d2d19ffcded3d00 RBX: 0000000000000000
RCX: ffff888117fc9b00
[ 37.839519][ T1170] RDX: 0000000000000000 RSI: 0000000000000000
RDI: 0000000000000000
[ 37.840570][ T1170] RBP: ffffffff86e88380 R08: ffffffff8130793b
R09: fffff520000dfd85
[ 37.841618][ T1170] R10: fffff520000dfd85 R11: 0000000000000000
R12: ffffffff87095fb8
[ 37.842649][ T1170] R13: ffff888117770ad8 R14: ffff888117770acc
R15: ffffffff852b7420
[ 37.843728][ T1170] FS: 0000000000000000(0000)
GS:ffff8881f6600000(0000) knlGS:0000000000000000
[ 37.844877][ T1170] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.845749][ T1170] CR2: 00007f992eaab380 CR3: 000000011834b000
CR4: 00000000001006f0
[ 37.846794][ T1170] Call Trace:
[ 37.847245][ T1170] <TASK>
[ 37.847643][ T1170] slab_free_freelist_hook+0x89/0x160
[ 37.848409][ T1170] ? devres_release_all+0x262/0x350
[ 37.849156][ T1170] __kmem_cache_free+0x71/0x110
[ 37.849829][ T1170] devres_release_all+0x262/0x350
[ 37.850478][ T1170] ? devres_release+0x90/0x90
[ 37.851118][ T1170] device_release_driver_internal+0x5e5/0x8a0
[ 37.851944][ T1170] bus_remove_device+0x2ea/0x400
[ 37.852611][ T1170] device_del+0x64f/0xb40
[ 37.853212][ T1170] ? kill_device+0x150/0x150
[ 37.853831][ T1170] ? print_irqtrace_events+0x1f0/0x1f0
[ 37.854564][ T1170] hid_destroy_device+0x66/0x100
[ 37.855226][ T1170] usbhid_disconnect+0x9a/0xc0
[ 37.855887][ T1170] usb_unbind_interface+0x1e1/0x890
```
``` hid-asus.c
[ 77.409878][ T1169] usb 1-1: USB disconnect, device number 2
[ 77.423606][ T1169] ODEBUG: free active (active state 0) object
type: work_struct hint: asus_kbd_backlight_work+0x0/0x2c0
[ 77.425222][ T1169] WARNING: CPU: 0 PID: 1169 at
lib/debugobjects.c:505 debug_check_no_obj_freed+0x43a/0x630
[ 77.426599][ T1169] Modules linked in:
[ 77.427322][ T1169] CPU: 0 PID: 1169 Comm: kworker/0:3 Not tainted
6.1.0-rc4-dirty #43
[ 77.428404][ T1169] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 77.429644][ T1169] Workqueue: usb_hub_wq hub_event
[ 77.430296][ T1169] RIP: 0010:debug_check_no_obj_freed+0x43a/0x630
[ 77.431142][ T1169] Code: 48 89 ef e8 28 82 58 ff 49 8b 14 24 4c 8b
45 00 48 c7 c7 40 5f 09 87 48 c7 c6 60 5b 09 87 89 d9 4d 89 f9 31 c0
e8 46 25 ef fe <0f> 0b 4c 8b 64 24 20 48 ba 00 00 00 00 00 fc ff df ff
05 4f 7c 17
[ 77.433691][ T1169] RSP: 0018:ffffc9000069ee60 EFLAGS: 00010246
[ 77.434470][ T1169] RAX: b85d2b40c12d7600 RBX: 0000000000000000
RCX: ffff888117a78000
[ 77.435507][ T1169] RDX: 0000000000000000 RSI: 0000000080000000
RDI: 0000000000000000
[ 77.436521][ T1169] RBP: ffffffff86e88380 R08: ffffffff8130793b
R09: ffffed103ecc4ed6
[ 77.437582][ T1169] R10: ffffed103ecc4ed6 R11: 0000000000000000
R12: ffffffff87095fb8
[ 77.438593][ T1169] R13: ffff88810e348fe0 R14: ffff88810e348fd4
R15: ffffffff852b5780
[ 77.439667][ T1169] FS: 0000000000000000(0000)
GS:ffff8881f6600000(0000) knlGS:0000000000000000
[ 77.440842][ T1169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 77.441688][ T1169] CR2: 00007ffc05495ff0 CR3: 000000010cdf0000
CR4: 00000000001006f0
[ 77.442720][ T1169] Call Trace:
[ 77.443167][ T1169] <TASK>
[ 77.443555][ T1169] slab_free_freelist_hook+0x89/0x160
[ 77.444302][ T1169] ? devres_release_all+0x262/0x350
[ 77.444990][ T1169] __kmem_cache_free+0x71/0x110
[ 77.445638][ T1169] devres_release_all+0x262/0x350
[ 77.446309][ T1169] ? devres_release+0x90/0x90
[ 77.446978][ T1169] device_release_driver_internal+0x5e5/0x8a0
[ 77.447748][ T1169] bus_remove_device+0x2ea/0x400
[ 77.448421][ T1169] device_del+0x64f/0xb40
[ 77.448976][ T1169] ? kill_device+0x150/0x150
[ 77.449577][ T1169] ? print_irqtrace_events+0x1f0/0x1f0
[ 77.450307][ T1169] hid_destroy_device+0x66/0x100
[ 77.450938][ T1169] usbhid_disconnect+0x9a/0xc0
```
To: Jiri Kosina <jikos@kernel.org>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Hanno Zulla <kontakt@hanno.de>
To: Pavel Machek <pavel@ucw.cz>
To: Lee Jones <lee@kernel.org>
To: Roderick Colenbrander <roderick.colenbrander@sony.com>
To: Sven Eckelmann <sven@narfation.org>
Cc: linux-leds@vger.kernel.org
Cc: Cristiano Giuffrida <c.giuffrida@vu.nl>
Cc: "Bos, H.J." <h.j.bos@vu.nl>
Cc: Jakob Koschel <jkl820.git@gmail.com>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Roderick Colenbrander <roderick@gaikai.com>
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
---
Changes in v2:
- dualshock4: Clarify UAF
- dualsense: Clarify UAF
- dualsense: Unregister multicolor led controller
- Link to v1: https://lore.kernel.org/r/20230125-hid-unregister-leds-v1-0-9a5192dcef16@diag.uniroma1.it
---
Pietro Borrello (5):
HID: bigben_remove: manually unregister leds
HID: asus_remove: manually unregister led
HID: dualsense_remove: manually unregister leds
HID: dualshock4_remove: manually unregister leds
HID: sony_remove: manually unregister leds
drivers/hid/hid-asus.c | 1 +
drivers/hid/hid-bigbenff.c | 5 +++++
drivers/hid/hid-playstation.c | 10 ++++++++++
drivers/hid/hid-sony.c | 8 ++++++++
4 files changed, 24 insertions(+)
---
base-commit: 2241ab53cbb5cdb08a6b2d4688feb13971058f65
change-id: 20230125-hid-unregister-leds-4cbf67099e1d
Best regards,
--
Pietro Borrello <borrello@diag.uniroma1.it>
^ permalink raw reply
* [PATCH v2] HID: add KEY_CAMERA_FOCUS event in HID
From: Qi Feng @ 2023-01-31 11:46 UTC (permalink / raw)
To: jikos; +Cc: benjamin.tissoires, rydberg, linux-input, linux-kernel, fengqi
From: fengqi <fengqi@xiaomi.com>
Our HID device need KEY_CAMERA_FOCUS event to control camera, but this
event is non-existent in current HID driver.we add this event in hid-input.c
We committed this v2 version following your previous suggestion
Signed-off-by: fengqi <fengqi@xiaomi.com>
---
drivers/hid/hid-input.c | 7 +++++++
include/linux/hid.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 9b59e436df0a..05fa3e191574 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1221,6 +1221,13 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
return;
}
goto unknown;
+ case HID_UP_CAMERA:
+ switch (usage->hid & HID_USAGE){
+ case 0x020: map_key_clear(KEY_CAMERA_FOCUS); break;
+ case 0x021: map_key_clear(KEY_CAMERA); break;
+ default: goto ignore;
+ }
+ break;
case HID_UP_HPVENDOR: /* Reported on a Dutch layout HP5308 */
set_bit(EV_REP, input->evbit);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 8677ae38599e..e3daf2c7739c 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -155,6 +155,7 @@ struct hid_item {
#define HID_UP_DIGITIZER 0x000d0000
#define HID_UP_PID 0x000f0000
#define HID_UP_BATTERY 0x00850000
+#define HID_UP_CAMERA 0x00900000
#define HID_UP_HPVENDOR 0xff7f0000
#define HID_UP_HPVENDOR2 0xff010000
#define HID_UP_MSVENDOR 0xff000000
--
2.39.0
^ permalink raw reply related
* Re: [PATCH 9/9] staging: greybus: hid: Constify lowlevel HID driver
From: Greg Kroah-Hartman @ 2023-01-31 10:15 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Basavaraj Natikar, Jiri Kosina, Benjamin Tissoires,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Filipe Laíns, Srinivas Pandruvada, Maximilian Luz,
Corentin Chary, Hans de Goede, Mark Gross, Viresh Kumar,
Johan Hovold, Alex Elder, linux-input, linux-kernel, linux-hyperv,
platform-driver-x86, acpi4asus-user, greybus-dev, linux-staging
In-Reply-To: <20230130-hid-const-ll-driver-v1-9-3fc282b3b1d0@weissschuh.net>
On Mon, Jan 30, 2023 at 03:59:45AM +0000, Thomas Weißschuh wrote:
> Since commit 52d225346904 ("HID: Make lowlevel driver structs const")
> the lowlevel HID drivers are only exposed as const.
>
> Take advantage of this to constify the underlying structure, too.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: mfd: Add nxp bbnsm
From: Lee Jones @ 2023-01-31 9:15 UTC (permalink / raw)
To: Jacky Bai
Cc: robh+dt, krzysztof.kozlowski+dt, shawnguo, s.hauer,
dmitry.torokhov, a.zummo, alexandre.belloni, devicetree,
linux-arm-kernel, linux-input, linux-rtc, kernel, linux-imx,
festevam
In-Reply-To: <20230129070823.1945489-2-ping.bai@nxp.com>
On Sun, 29 Jan 2023, Jacky Bai wrote:
> Add binding for NXP BBNSM(Battery-Backed Non-Secure Module).
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> ---
> - v2 changes:
> - remove the redundant 'bindings' string
> - add ref to rtc.yaml
> - add start-year property
> - rename 'regmap' to 'nxp,bbnsm-regmap' and add description & type define
> - add header files including in the example and correct the indentation
>
> -v3 changes:
> - remove the 'nxp,bbnsm-regmap' property, get the regmap directly from the
> parent node in rtc/pwrkey driver
>
> - v4 changes:
> - update the compatible string to include the soc id as Rob suggested
> ---
> .../devicetree/bindings/mfd/nxp,bbnsm.yaml | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml
Applied, thanks
--
Lee Jones [李琼斯]
^ permalink raw reply
* Słowa kluczowe do wypozycjonowania
From: Adam Charachuta @ 2023-01-31 8:35 UTC (permalink / raw)
To: linux-input
Dzień dobry,
zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów.
Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci.
Możemy porozmawiać w najbliższym czasie?
Pozdrawiam
Adam Charachuta
^ permalink raw reply
* Re: [PATCH 4/4] CP2112 Devicetree Support
From: Daniel Kaehn @ 2023-01-31 1:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
devicetree, linux-input, ethan.twardy
In-Reply-To: <b3712d74-2276-b7ba-4145-4d9a6d5f3a34@linaro.org>
On Sun, Jan 29, 2023 at 5:06 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 28/01/2023 21:26, Danny Kaehn wrote:
> > +#if defined(CONFIG_OF_GPIO)
>
> Don't use #if, but IS_ENABLED(). I think it should work here.
I think I will still need to use an #if / some sort of preprocessor directive,
since of_node is only a member of the gpio_chip struct if that is enabled
(and thus causes a compile error if done outside of the preprocessor)...
Unless I'm misinterpreting your comment?
>
> > + dev->gc.of_node = of_get_child_by_name(hdev->dev.of_node, "gpio");
>
> You leak it now on error paths.
Ah, good point. Will fix!
Thanks,
Danny Kaehn
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: hid: Add CP2112 HID USB to SMBus Bridge
From: Daniel Kaehn @ 2023-01-31 0:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
devicetree, linux-input, ethan.twardy
In-Reply-To: <e4f11bda-32c1-fa9d-39d7-402e55ff1d22@linaro.org>
Thanks for all of the comments. All feedback is ACK'd and will be
added in v2 -- what follows is just commentary on some comments.
On Sun, Jan 29, 2023 at 5:33 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 29/01/2023 12:05, Krzysztof Kozlowski wrote:
> > On 28/01/2023 21:26, Danny Kaehn wrote:
> >> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> >>
> > Thank you for your patch. There is something to discuss/improve.
> >
> >> The binding allows describing the chip's gpio and i2c controller in DT
> >> using the subnodes named "gpio" and "i2c", respectively. This is
> >> intended to be used in configurations where the CP2112 is permanently
> >> connected in hardware.
> >>
> >> Signed-off-by: Danny Kaehn <kaehndan@gmail.com>
> >> ---
> >> .../bindings/hid/silabs,cp2112.yaml | 82 +++++++++++++++++++
> >
> > There is no "hid" directory, so I think such devices where going to
> > different place, didn't they?
Good point, I didn't notice other hid-related bindings went into
input/ -- will change
> >
> >> + While USB devices typically aren't described in DeviceTree, doing so with the
> >> + CP2112 allows use of its i2c and gpio controllers with other DT nodes when
> >> + the chip is expected to be found on a USB port.
> >
> > Drop these three and replace with description of the hardware.
Understood. I noticed that a similar usb-based binding included
a similar description (net/marvell,mvusb.yaml) but I understand why
we would not want this in new bindings.
> >
> >> + i2c:
> >> + $ref: /schemas/i2c/i2c-controller.yaml#
> >
> > This is not specific enough. What controller is there?
>
> OK, assuming this is tightly wired (with cp2112 I2C controller), then
> the compatible could be skipped as it is inferred from parent one. Yet
> still you need description and unevaluatedProperties.
>
Great point, will update -- I didn't quite understand that child nodes of the
root could have properties/unevaluatedProperties/etc.. but I see now that
that is well-documented (just not often done in existing bindings)!
> >
> > Missing unevaluatedProperties: false, anyway.
> >
> >> + gpio:
> >> + $ref: /schemas/gpio/gpio.yaml#
> >
> > Same comments.
>
> Description, unevaluatedProperties and constraints on properties (line
> names, reserved ranges, ranges).
>
Will add.
Thanks,
Danny Kaehn
^ permalink raw reply
* Re: [PATCH v9 1/4] dt-bindings: input: pwm-beeper: Convert txt bindings to yaml
From: Rob Herring @ 2023-01-30 23:00 UTC (permalink / raw)
To: Manuel Traut
Cc: devicetree, Dmitry Torokhov, Frieder Schrempf, Rob Herring,
linux-kernel, linux-input, Krzysztof Kozlowski
In-Reply-To: <20230130135650.1407156-2-manuel.traut@mt.com>
On Mon, 30 Jan 2023 14:56:47 +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 | 39 +++++++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
> create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: mfd: Add nxp bbnsm
From: Rob Herring @ 2023-01-30 22:09 UTC (permalink / raw)
To: Jacky Bai
Cc: shawnguo, a.zummo, lee, alexandre.belloni, linux-input, linux-rtc,
festevam, dmitry.torokhov, linux-arm-kernel, devicetree,
linux-imx, s.hauer, krzysztof.kozlowski+dt, kernel, robh+dt
In-Reply-To: <20230129070823.1945489-2-ping.bai@nxp.com>
On Sun, 29 Jan 2023 15:08:20 +0800, Jacky Bai wrote:
> Add binding for NXP BBNSM(Battery-Backed Non-Secure Module).
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> ---
> - v2 changes:
> - remove the redundant 'bindings' string
> - add ref to rtc.yaml
> - add start-year property
> - rename 'regmap' to 'nxp,bbnsm-regmap' and add description & type define
> - add header files including in the example and correct the indentation
>
> -v3 changes:
> - remove the 'nxp,bbnsm-regmap' property, get the regmap directly from the
> parent node in rtc/pwrkey driver
>
> - v4 changes:
> - update the compatible string to include the soc id as Rob suggested
> ---
> .../devicetree/bindings/mfd/nxp,bbnsm.yaml | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/nxp,bbnsm.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] HID: core: Fix deadloop in hid_apply_multiplier.
From: Xin Zhao @ 2023-01-30 21:29 UTC (permalink / raw)
To: jikos, benjamin.tissoires, linux-input, linux-kernel; +Cc: Xin Zhao
The initial value of hid->collection[].parent_idx if 0. When
Report descriptor doesn't contain "HID Collection", the value
remains as 0.
In the meanwhile, when the Report descriptor fullfill
all following conditions, it will trigger hid_apply_multiplier
function call.
1. Usage page is Generic Desktop Ctrls (0x01)
2. Usage is RESOLUTION_MULTIPLIER (0x48)
3. Contain any FEATURE items
The while loop in hid_apply_multiplier will search the top-most
collection by searching parent_idx == -1. Because all parent_idx
is 0. The loop will run forever.
There is a Report Descriptor triggerring the deadloop
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x48, // Usage (0x48)
0x95, 0x01, // Report Count (1)
0x75, 0x08, // Report Size (8)
0xB1, 0x01, // Feature
Signed-off-by: Xin Zhao <xnzhao@google.com>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 3e1803592bd4..5c72aef3d3dd 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1202,6 +1202,7 @@ int hid_open_report(struct hid_device *device)
__u8 *end;
__u8 *next;
int ret;
+ int i;
static int (*dispatch_type[])(struct hid_parser *parser,
struct hid_item *item) = {
hid_parser_main,
@@ -1252,6 +1253,8 @@ int hid_open_report(struct hid_device *device)
goto err;
}
device->collection_size = HID_DEFAULT_NUM_COLLECTIONS;
+ for (i = 0; i < HID_DEFAULT_NUM_COLLECTIONS; i++)
+ device->collection[i].parent_idx = -1;
ret = -EINVAL;
while ((next = fetch_item(start, end, &item)) != NULL) {
--
2.39.1.456.gfc5497dd1b-goog
^ permalink raw reply related
* Re: [PATCH v2 2/2] dt-bindings: input: iqs626a: Redefine trackpad property types
From: Rob Herring @ 2023-01-30 21:23 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: linux-input, dmitry.torokhov, robh+dt, devicetree
In-Reply-To: <Y9RQcddToBr1rrnJ@nixie71>
On Fri, 27 Jan 2023 16:30:09 -0600, Jeff LaBundy wrote:
> Following a recent refactor of the driver to properly drop unused
> device nodes, the driver expects trackpad channel touch thresholds
> and ATI base values to be specified under single trackpad channel
> child nodes.
>
> This enhancement moves both properties to scalar values as opposed
> to arrays, making their types consistent across bindings.
>
> Fixes: a8f1f0dc865c ("dt-bindings: input: Add bindings for Azoteq IQS626A")
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
> ---
> Changes in v2:
> - Added to series
>
> .../devicetree/bindings/input/iqs626a.yaml | 94 +++++++++++++------
> 1 file changed, 67 insertions(+), 27 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: st,stmfts: convert to dtschema
From: Rob Herring @ 2023-01-30 21:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel,
Maxime Coquelin, Alexandre Torgue, Krzysztof Kozlowski,
linux-stm32, linux-input, Dmitry Torokhov
In-Reply-To: <20230127202040.196411-1-krzysztof.kozlowski@linaro.org>
On Fri, 27 Jan 2023 21:20:40 +0100, Krzysztof Kozlowski wrote:
> 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
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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