* [PATCH AUTOSEL 6.2 03/20] HID: apple: Set the tilde quirk flag on the Geyser 4 and later
From: Sasha Levin @ 2023-05-07 0:32 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alex Henrie, Jiri Kosina, Sasha Levin, jikos, benjamin.tissoires,
linux-input
In-Reply-To: <20230507003237.4074305-1-sashal@kernel.org>
From: Alex Henrie <alexhenrie24@gmail.com>
[ Upstream commit c3388ddc74a863466c7c3fa24d3a9cea9c9bca53 ]
I recently tested several old MacBooks and as far as I can tell, all
MacBooks that have an ISO keyboard have the tilde key quirk:
Product Model Year System CPU Shape Labels Country Quirky
============================================================================
05ac:021b A1181 2006 MacBook2,1 T5600 ISO British 13 Yes
05ac:021b A1181 2007 MacBook2,1 T7200 ISO Québécois 13 Yes
05ac:0229 A1181 2007 MacBook4,1 T8300 ANSI Usonian 33 No
05ac:022a A1181 2007 MacBook4,1 T8100 ISO English 13 Yes
05ac:022a A1181 2007 MacBook5,2 P7350 ISO Québécois 13 Yes
05ac:0237 A1278 2008 MacBook5,1 P7350 ISO Dutch 13 Yes
05ac:0237 A1278 2009 MacBook5,5 P7550 ISO British 13 Yes
The model number and year are from the laptop case. Since Apple printed
the same model and year on many different laptops, the system name (as
reported in the SMBIOS tables) and CPU form a more precise identifier.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-apple.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 1ccab8aa326cd..5c145775482bc 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -882,7 +882,8 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
+ APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
@@ -901,7 +902,8 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
+ APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
@@ -942,31 +944,31 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING3_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING3_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING3_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ANSI),
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.2 17/20] HID: wacom: generic: Set battery quirk only when we see battery data
From: Sasha Levin @ 2023-05-07 0:32 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jason Gerecke, Jason Gerecke, Mario Limonciello, Jiri Kosina,
Sasha Levin, ping.cheng, jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230507003237.4074305-1-sashal@kernel.org>
From: Jason Gerecke <killertofu@gmail.com>
[ Upstream commit bea407a427baa019758f29f4d31b26f008bb8cc6 ]
Some devices will include battery status usages in the HID descriptor
but we won't see that battery data for one reason or another. For example,
AES sensors won't send battery data unless an AES pen is in proximity.
If a user does not have an AES pen but instead only interacts with the
AES touchscreen with their fingers then there is no need for us to create
a battery object. Similarly, if a family of peripherals shares the same
HID descriptor between wired-only and wireless-capable SKUs, users of the
former may never see a battery event and will not want a power_supply
object created.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217062
Link: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2354
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/wacom_wac.c | 33 +++++++++++----------------------
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9312d611db8e5..7fa3b6ccdb53b 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1929,18 +1929,7 @@ static void wacom_map_usage(struct input_dev *input, struct hid_usage *usage,
static void wacom_wac_battery_usage_mapping(struct hid_device *hdev,
struct hid_field *field, struct hid_usage *usage)
{
- struct wacom *wacom = hid_get_drvdata(hdev);
- struct wacom_wac *wacom_wac = &wacom->wacom_wac;
- struct wacom_features *features = &wacom_wac->features;
- unsigned equivalent_usage = wacom_equivalent_usage(usage->hid);
-
- switch (equivalent_usage) {
- case HID_DG_BATTERYSTRENGTH:
- case WACOM_HID_WD_BATTERY_LEVEL:
- case WACOM_HID_WD_BATTERY_CHARGING:
- features->quirks |= WACOM_QUIRK_BATTERY;
- break;
- }
+ return;
}
static void wacom_wac_battery_event(struct hid_device *hdev, struct hid_field *field,
@@ -1961,18 +1950,21 @@ static void wacom_wac_battery_event(struct hid_device *hdev, struct hid_field *f
wacom_wac->hid_data.bat_connected = 1;
wacom_wac->hid_data.bat_status = WACOM_POWER_SUPPLY_STATUS_AUTO;
}
+ wacom_wac->features.quirks |= WACOM_QUIRK_BATTERY;
break;
case WACOM_HID_WD_BATTERY_LEVEL:
value = value * 100 / (field->logical_maximum - field->logical_minimum);
wacom_wac->hid_data.battery_capacity = value;
wacom_wac->hid_data.bat_connected = 1;
wacom_wac->hid_data.bat_status = WACOM_POWER_SUPPLY_STATUS_AUTO;
+ wacom_wac->features.quirks |= WACOM_QUIRK_BATTERY;
break;
case WACOM_HID_WD_BATTERY_CHARGING:
wacom_wac->hid_data.bat_charging = value;
wacom_wac->hid_data.ps_connected = value;
wacom_wac->hid_data.bat_connected = 1;
wacom_wac->hid_data.bat_status = WACOM_POWER_SUPPLY_STATUS_AUTO;
+ wacom_wac->features.quirks |= WACOM_QUIRK_BATTERY;
break;
}
}
@@ -1988,18 +1980,15 @@ static void wacom_wac_battery_report(struct hid_device *hdev,
{
struct wacom *wacom = hid_get_drvdata(hdev);
struct wacom_wac *wacom_wac = &wacom->wacom_wac;
- struct wacom_features *features = &wacom_wac->features;
- if (features->quirks & WACOM_QUIRK_BATTERY) {
- int status = wacom_wac->hid_data.bat_status;
- int capacity = wacom_wac->hid_data.battery_capacity;
- bool charging = wacom_wac->hid_data.bat_charging;
- bool connected = wacom_wac->hid_data.bat_connected;
- bool powered = wacom_wac->hid_data.ps_connected;
+ int status = wacom_wac->hid_data.bat_status;
+ int capacity = wacom_wac->hid_data.battery_capacity;
+ bool charging = wacom_wac->hid_data.bat_charging;
+ bool connected = wacom_wac->hid_data.bat_connected;
+ bool powered = wacom_wac->hid_data.ps_connected;
- wacom_notify_battery(wacom_wac, status, capacity, charging,
- connected, powered);
- }
+ wacom_notify_battery(wacom_wac, status, capacity, charging,
+ connected, powered);
}
static void wacom_wac_pad_usage_mapping(struct hid_device *hdev,
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.2 16/20] HID: Ignore battery for ELAN touchscreen on ROG Flow X13 GV301RA
From: Sasha Levin @ 2023-05-07 0:32 UTC (permalink / raw)
To: linux-kernel, stable
Cc: weiliang1503, Benjamin Tissoires, Sasha Levin, jikos, linux-input
In-Reply-To: <20230507003237.4074305-1-sashal@kernel.org>
From: weiliang1503 <weiliang1503@gmail.com>
[ Upstream commit 35903009dbde804a1565dc89e431c0f15179f054 ]
Ignore the reported battery level of the built-in touchscreen to suppress
battery warnings when a stylus is used. The device ID was added and the
battery ignore quirk was enabled.
Signed-off-by: weiliang1503 <weiliang1503@gmail.com>
Link: https://lore.kernel.org/r/20230330115638.16146-1-weiliang1503@gmail.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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 2235d78784b1b..53c6692d77714 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -415,6 +415,7 @@
#define I2C_DEVICE_ID_HP_SPECTRE_X360_15 0x2817
#define I2C_DEVICE_ID_HP_SPECTRE_X360_13_AW0020NG 0x29DF
#define I2C_DEVICE_ID_ASUS_TP420IA_TOUCHSCREEN 0x2BC8
+#define I2C_DEVICE_ID_ASUS_GV301RA_TOUCHSCREEN 0x2C82
#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 c3c7d0abb01ad..071d2f3aaf27f 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -372,6 +372,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_ASUS_TP420IA_TOUCHSCREEN),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_ASUS_GV301RA_TOUCHSCREEN),
+ HID_BATTERY_QUIRK_IGNORE },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ASUS_UX550_TOUCHSCREEN),
HID_BATTERY_QUIRK_IGNORE },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ASUS_UX550VE_TOUCHSCREEN),
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.2 15/20] HID: apple: Set the tilde quirk flag on the Geyser 3
From: Sasha Levin @ 2023-05-07 0:32 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alex Henrie, Benjamin Tissoires, Sasha Levin, jikos, linux-input
In-Reply-To: <20230507003237.4074305-1-sashal@kernel.org>
From: Alex Henrie <alexhenrie24@gmail.com>
[ Upstream commit 29e1ecc197d410ee59c8877098d54cf417075f7d ]
I was finally able to obtain a MacBook1,1 to test and I've now confirmed
that it has the tilde key quirk as well:
Product Model Year System CPU Shape Labels Country Quirky
============================================================================
05ac:0218 A1181 2006 MacBook1,1 T2500 ISO British 13 Yes
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Link: https://lore.kernel.org/r/20230404024829.13982-1-alexhenrie24@gmail.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-apple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 5c145775482bc..e2c73a78b5972 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -875,7 +875,8 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
+ APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 21/24] HID: wacom: generic: Set battery quirk only when we see battery data
From: Sasha Levin @ 2023-05-07 0:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jason Gerecke, Jason Gerecke, Mario Limonciello, Jiri Kosina,
Sasha Levin, ping.cheng, jikos, benjamin.tissoires, linux-input
In-Reply-To: <20230507003022.4070535-1-sashal@kernel.org>
From: Jason Gerecke <killertofu@gmail.com>
[ Upstream commit bea407a427baa019758f29f4d31b26f008bb8cc6 ]
Some devices will include battery status usages in the HID descriptor
but we won't see that battery data for one reason or another. For example,
AES sensors won't send battery data unless an AES pen is in proximity.
If a user does not have an AES pen but instead only interacts with the
AES touchscreen with their fingers then there is no need for us to create
a battery object. Similarly, if a family of peripherals shares the same
HID descriptor between wired-only and wireless-capable SKUs, users of the
former may never see a battery event and will not want a power_supply
object created.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217062
Link: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2354
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/wacom_wac.c | 33 +++++++++++----------------------
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9312d611db8e5..7fa3b6ccdb53b 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1929,18 +1929,7 @@ static void wacom_map_usage(struct input_dev *input, struct hid_usage *usage,
static void wacom_wac_battery_usage_mapping(struct hid_device *hdev,
struct hid_field *field, struct hid_usage *usage)
{
- struct wacom *wacom = hid_get_drvdata(hdev);
- struct wacom_wac *wacom_wac = &wacom->wacom_wac;
- struct wacom_features *features = &wacom_wac->features;
- unsigned equivalent_usage = wacom_equivalent_usage(usage->hid);
-
- switch (equivalent_usage) {
- case HID_DG_BATTERYSTRENGTH:
- case WACOM_HID_WD_BATTERY_LEVEL:
- case WACOM_HID_WD_BATTERY_CHARGING:
- features->quirks |= WACOM_QUIRK_BATTERY;
- break;
- }
+ return;
}
static void wacom_wac_battery_event(struct hid_device *hdev, struct hid_field *field,
@@ -1961,18 +1950,21 @@ static void wacom_wac_battery_event(struct hid_device *hdev, struct hid_field *f
wacom_wac->hid_data.bat_connected = 1;
wacom_wac->hid_data.bat_status = WACOM_POWER_SUPPLY_STATUS_AUTO;
}
+ wacom_wac->features.quirks |= WACOM_QUIRK_BATTERY;
break;
case WACOM_HID_WD_BATTERY_LEVEL:
value = value * 100 / (field->logical_maximum - field->logical_minimum);
wacom_wac->hid_data.battery_capacity = value;
wacom_wac->hid_data.bat_connected = 1;
wacom_wac->hid_data.bat_status = WACOM_POWER_SUPPLY_STATUS_AUTO;
+ wacom_wac->features.quirks |= WACOM_QUIRK_BATTERY;
break;
case WACOM_HID_WD_BATTERY_CHARGING:
wacom_wac->hid_data.bat_charging = value;
wacom_wac->hid_data.ps_connected = value;
wacom_wac->hid_data.bat_connected = 1;
wacom_wac->hid_data.bat_status = WACOM_POWER_SUPPLY_STATUS_AUTO;
+ wacom_wac->features.quirks |= WACOM_QUIRK_BATTERY;
break;
}
}
@@ -1988,18 +1980,15 @@ static void wacom_wac_battery_report(struct hid_device *hdev,
{
struct wacom *wacom = hid_get_drvdata(hdev);
struct wacom_wac *wacom_wac = &wacom->wacom_wac;
- struct wacom_features *features = &wacom_wac->features;
- if (features->quirks & WACOM_QUIRK_BATTERY) {
- int status = wacom_wac->hid_data.bat_status;
- int capacity = wacom_wac->hid_data.battery_capacity;
- bool charging = wacom_wac->hid_data.bat_charging;
- bool connected = wacom_wac->hid_data.bat_connected;
- bool powered = wacom_wac->hid_data.ps_connected;
+ int status = wacom_wac->hid_data.bat_status;
+ int capacity = wacom_wac->hid_data.battery_capacity;
+ bool charging = wacom_wac->hid_data.bat_charging;
+ bool connected = wacom_wac->hid_data.bat_connected;
+ bool powered = wacom_wac->hid_data.ps_connected;
- wacom_notify_battery(wacom_wac, status, capacity, charging,
- connected, powered);
- }
+ wacom_notify_battery(wacom_wac, status, capacity, charging,
+ connected, powered);
}
static void wacom_wac_pad_usage_mapping(struct hid_device *hdev,
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 20/24] HID: Ignore battery for ELAN touchscreen on ROG Flow X13 GV301RA
From: Sasha Levin @ 2023-05-07 0:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: weiliang1503, Benjamin Tissoires, Sasha Levin, jikos, linux-input
In-Reply-To: <20230507003022.4070535-1-sashal@kernel.org>
From: weiliang1503 <weiliang1503@gmail.com>
[ Upstream commit 35903009dbde804a1565dc89e431c0f15179f054 ]
Ignore the reported battery level of the built-in touchscreen to suppress
battery warnings when a stylus is used. The device ID was added and the
battery ignore quirk was enabled.
Signed-off-by: weiliang1503 <weiliang1503@gmail.com>
Link: https://lore.kernel.org/r/20230330115638.16146-1-weiliang1503@gmail.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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 c2e9b6d1fd7d3..8f3e0a5d5f834 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -415,6 +415,7 @@
#define I2C_DEVICE_ID_HP_SPECTRE_X360_15 0x2817
#define I2C_DEVICE_ID_HP_SPECTRE_X360_13_AW0020NG 0x29DF
#define I2C_DEVICE_ID_ASUS_TP420IA_TOUCHSCREEN 0x2BC8
+#define I2C_DEVICE_ID_ASUS_GV301RA_TOUCHSCREEN 0x2C82
#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 5c65a584b3fa0..5a88866505eab 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -372,6 +372,8 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_ASUS_TP420IA_TOUCHSCREEN),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_ASUS_GV301RA_TOUCHSCREEN),
+ HID_BATTERY_QUIRK_IGNORE },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ASUS_UX550_TOUCHSCREEN),
HID_BATTERY_QUIRK_IGNORE },
{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ASUS_UX550VE_TOUCHSCREEN),
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 19/24] HID: apple: Set the tilde quirk flag on the Geyser 3
From: Sasha Levin @ 2023-05-07 0:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alex Henrie, Benjamin Tissoires, Sasha Levin, jikos, linux-input
In-Reply-To: <20230507003022.4070535-1-sashal@kernel.org>
From: Alex Henrie <alexhenrie24@gmail.com>
[ Upstream commit 29e1ecc197d410ee59c8877098d54cf417075f7d ]
I was finally able to obtain a MacBook1,1 to test and I've now confirmed
that it has the tilde key quirk as well:
Product Model Year System CPU Shape Labels Country Quirky
============================================================================
05ac:0218 A1181 2006 MacBook1,1 T2500 ISO British 13 Yes
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Link: https://lore.kernel.org/r/20230404024829.13982-1-alexhenrie24@gmail.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-apple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 5c145775482bc..e2c73a78b5972 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -875,7 +875,8 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
+ APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER3_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 12/24] HID: logitech-hidpp: Reconcile USB and Unifying serials
From: Sasha Levin @ 2023-05-07 0:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bastien Nocera, Benjamin Tissoires, Sasha Levin, jikos,
linux-input
In-Reply-To: <20230507003022.4070535-1-sashal@kernel.org>
From: Bastien Nocera <hadess@hadess.net>
[ Upstream commit 5b3691d15e04b6d5a32c915577b8dbc5cfb56382 ]
Now that USB HID++ devices can gather a serial number that matches the
one that would be gathered when connected through a Unifying receiver,
remove the last difference by dropping the product ID as devices
usually have different product IDs when connected through USB or
Unifying.
For example, on the serials on a G903 wired/wireless mouse:
- Unifying before patch: 4067-e8-ce-cd-45
- USB before patch: c086-e8-ce-cd-45
- Unifying and USB after patch: e8-ce-cd-45
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230302130117.3975-2-hadess@hadess.net
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 66380876937f6..da89e84c9cbeb 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -853,8 +853,7 @@ static int hidpp_unifying_init(struct hidpp_device *hidpp)
if (ret)
return ret;
- snprintf(hdev->uniq, sizeof(hdev->uniq), "%04x-%4phD",
- hdev->product, &serial);
+ snprintf(hdev->uniq, sizeof(hdev->uniq), "%4phD", &serial);
dbg_hid("HID++ Unifying: Got serial: %s\n", hdev->uniq);
name = hidpp_unifying_get_name(hidpp);
@@ -989,8 +988,7 @@ static int hidpp_serial_init(struct hidpp_device *hidpp)
if (ret)
return ret;
- snprintf(hdev->uniq, sizeof(hdev->uniq), "%04x-%4phD",
- hdev->product, &serial);
+ snprintf(hdev->uniq, sizeof(hdev->uniq), "%4phD", &serial);
dbg_hid("HID++ DeviceInformation: Got serial: %s\n", hdev->uniq);
return 0;
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 11/24] HID: logitech-hidpp: Don't use the USB serial for USB devices
From: Sasha Levin @ 2023-05-07 0:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bastien Nocera, Benjamin Tissoires, Sasha Levin, jikos,
linux-input
In-Reply-To: <20230507003022.4070535-1-sashal@kernel.org>
From: Bastien Nocera <hadess@hadess.net>
[ Upstream commit 7ad1fe0da0fa91bf920b79ab05ae97bfabecc4f4 ]
For devices that support the 0x0003 feature (Device Information) version 4,
set the serial based on the output of that feature, rather than relying
on the usbhid code setting the USB serial.
This should allow the serial when connected through USB to (nearly)
match the one when connected through a unifying receiver.
For example, on the serials on a G903 wired/wireless mouse:
- Unifying: 4067-e8-ce-cd-45
- USB before patch: 017C385C3837
- USB after patch: c086-e8-ce-cd-45
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Link: https://lore.kernel.org/r/20230302130117.3975-1-hadess@hadess.net
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 51 ++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 5fc88a0632978..66380876937f6 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -947,6 +947,55 @@ static int hidpp_root_get_protocol_version(struct hidpp_device *hidpp)
return 0;
}
+/* -------------------------------------------------------------------------- */
+/* 0x0003: Device Information */
+/* -------------------------------------------------------------------------- */
+
+#define HIDPP_PAGE_DEVICE_INFORMATION 0x0003
+
+#define CMD_GET_DEVICE_INFO 0x00
+
+static int hidpp_get_serial(struct hidpp_device *hidpp, u32 *serial)
+{
+ struct hidpp_report response;
+ u8 feature_type;
+ u8 feature_index;
+ int ret;
+
+ ret = hidpp_root_get_feature(hidpp, HIDPP_PAGE_DEVICE_INFORMATION,
+ &feature_index,
+ &feature_type);
+ if (ret)
+ return ret;
+
+ ret = hidpp_send_fap_command_sync(hidpp, feature_index,
+ CMD_GET_DEVICE_INFO,
+ NULL, 0, &response);
+ if (ret)
+ return ret;
+
+ /* See hidpp_unifying_get_serial() */
+ *serial = *((u32 *)&response.rap.params[1]);
+ return 0;
+}
+
+static int hidpp_serial_init(struct hidpp_device *hidpp)
+{
+ struct hid_device *hdev = hidpp->hid_dev;
+ u32 serial;
+ int ret;
+
+ ret = hidpp_get_serial(hidpp, &serial);
+ if (ret)
+ return ret;
+
+ snprintf(hdev->uniq, sizeof(hdev->uniq), "%04x-%4phD",
+ hdev->product, &serial);
+ dbg_hid("HID++ DeviceInformation: Got serial: %s\n", hdev->uniq);
+
+ return 0;
+}
+
/* -------------------------------------------------------------------------- */
/* 0x0005: GetDeviceNameType */
/* -------------------------------------------------------------------------- */
@@ -4210,6 +4259,8 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (hidpp->quirks & HIDPP_QUIRK_UNIFYING)
hidpp_unifying_init(hidpp);
+ else if (hid_is_usb(hidpp->hid_dev))
+ hidpp_serial_init(hidpp);
connected = hidpp_root_get_protocol_version(hidpp) == 0;
atomic_set(&hidpp->connected, connected);
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 03/24] HID: apple: Set the tilde quirk flag on the Geyser 4 and later
From: Sasha Levin @ 2023-05-07 0:29 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alex Henrie, Jiri Kosina, Sasha Levin, jikos, benjamin.tissoires,
linux-input
In-Reply-To: <20230507003022.4070535-1-sashal@kernel.org>
From: Alex Henrie <alexhenrie24@gmail.com>
[ Upstream commit c3388ddc74a863466c7c3fa24d3a9cea9c9bca53 ]
I recently tested several old MacBooks and as far as I can tell, all
MacBooks that have an ISO keyboard have the tilde key quirk:
Product Model Year System CPU Shape Labels Country Quirky
============================================================================
05ac:021b A1181 2006 MacBook2,1 T5600 ISO British 13 Yes
05ac:021b A1181 2007 MacBook2,1 T7200 ISO Québécois 13 Yes
05ac:0229 A1181 2007 MacBook4,1 T8300 ANSI Usonian 33 No
05ac:022a A1181 2007 MacBook4,1 T8100 ISO English 13 Yes
05ac:022a A1181 2007 MacBook5,2 P7350 ISO Québécois 13 Yes
05ac:0237 A1278 2008 MacBook5,1 P7350 ISO Dutch 13 Yes
05ac:0237 A1278 2009 MacBook5,5 P7550 ISO British 13 Yes
The model number and year are from the laptop case. Since Apple printed
the same model and year on many different laptops, the system name (as
reported in the SMBIOS tables) and CPU form a more precise identifier.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-apple.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 1ccab8aa326cd..5c145775482bc 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -882,7 +882,8 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
+ APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
@@ -901,7 +902,8 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_ISO),
- .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
+ .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
+ APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER4_HF_JIS),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN |
APPLE_RDESC_JIS },
@@ -942,31 +944,31 @@ static const struct hid_device_id apple_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING3_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING3_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING3_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ANSI),
.driver_data = APPLE_HAS_FN },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ISO),
- .driver_data = APPLE_HAS_FN },
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_TILDE_QUIRK },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ANSI),
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v2] Input: ili210x - Probe even if no resolution information
From: Marek Vasut @ 2023-05-07 0:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Joe Hung, Luca Hsu
In-Reply-To: <ZFagieka6H2cRRXi@google.com>
On 5/6/23 20:46, Dmitry Torokhov wrote:
> On Fri, Feb 17, 2023 at 03:52:00AM +0100, Marek Vasut wrote:
>> Probe the touch controller driver even if resolution information is not
>> available. This can happen e.g. in case the touch controller suffered a
>> failed firmware update and is stuck in bootloader mode.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>
> Applied, thank you.
Much appreciated, thanks !
^ permalink raw reply
* Re: [PATCH 1/2] Input: cs40l26: Support for CS40L26 Boosted Haptic Amplifier
From: Jeff LaBundy @ 2023-05-06 20:30 UTC (permalink / raw)
To: Fred Treven
Cc: Charles Keepax, dmitry.torokhov@gmail.com, Ben Bright,
James Ogletree, lee@kernel.org, jdelvare@suse.de, joel@jms.id.au,
cy_huang@richtek.com, rdunlap@infradead.org,
eajames@linux.ibm.com, ping.bai@nxp.com, msp@baylibre.com,
arnd@arndb.de, bartosz.golaszewski@linaro.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
patches@opensource.cirrus.com
In-Reply-To: <7E101F4B-782A-4B8B-B6AB-3E7E282C9A9C@cirrus.com>
Hi Fred,
On Thu, May 04, 2023 at 09:51:37PM +0000, Fred Treven wrote:
> Hi Jeff,
>
> I had one last question for you before I send the next version of this submission.
>
> >> +
> >> + return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(cs40l26_remove);
> >> +
> >> +static int cs40l26_suspend(struct device *dev)
> >> +{
> >> + struct cs40l26_private *cs40l26 = dev_get_drvdata(dev);
> >> + int ret;
> >> +
> >> + mutex_lock(&cs40l26->lock);
> >> + dev_dbg(dev, "%s: Enabling hibernation\n", __func__);
> >> +
> >> + ret = cs40l26_allow_hiber(cs40l26);
> >> +
> >> + mutex_unlock(&cs40l26->lock);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +static int cs40l26_sys_suspend(struct device *dev)
> >> +{
> >> + struct i2c_client *i2c_client = to_i2c_client(dev);
> >> +
> >> + dev_dbg(dev, "System suspend, disabling IRQ\n");
> >> +
> >> + disable_irq(i2c_client->irq);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int cs40l26_sys_suspend_noirq(struct device *dev)
> >> +{
> >> + struct i2c_client *i2c_client = to_i2c_client(dev);
> >> +
> >> + dev_dbg(dev, "Late system suspend, re-enabling IRQ\n");
> >> + enable_irq(i2c_client->irq);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int cs40l26_resume(struct device *dev)
> >> +{
> >> + dev_dbg(dev, "%s: Disabling hibernation\n", __func__);
> >> +
> >> + return cs40l26_prevent_hiber(dev_get_drvdata(dev));
> >> +}
> >> +
> >> +static int cs40l26_sys_resume(struct device *dev)
> >> +{
> >> + struct i2c_client *i2c_client = to_i2c_client(dev);
> >> +
> >> + dev_dbg(dev, "System resume, re-enabling IRQ\n");
> >> +
> >> + enable_irq(i2c_client->irq);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int cs40l26_sys_resume_noirq(struct device *dev)
> >> +{
> >> + struct i2c_client *i2c_client = to_i2c_client(dev);
> >> +
> >> + dev_dbg(dev, "Early system resume, disabling IRQ\n");
> >> +
> >> + disable_irq(i2c_client->irq);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +const struct dev_pm_ops cs40l26_pm_ops = {
> >> + SET_RUNTIME_PM_OPS(cs40l26_suspend, cs40l26_resume, NULL)
> >> + SET_SYSTEM_SLEEP_PM_OPS(cs40l26_sys_suspend, cs40l26_sys_resume)
> >> + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(cs40l26_sys_suspend_noirq, cs40l26_sys_resume_noirq)
> >> +};
> >> +EXPORT_SYMBOL_GPL(cs40l26_pm_ops);
> >
> > Please use latest macros (e.g. DEFINE_SIMPLE_DEV_PM_OPS).
>
> When looking at these *_PM_OPS* macros that replace the deprecated versions, it is unclear to me how to maintain support for *_sys_* and
> *_sys_*_noirq* functions. Would these all need to be separately defined via DEFINE_SIMPLE_DEV_PM_OPS?
> Would the *_sys_* definitions still be defined through a struct i.e.
> const struct dev_pm_ops cs40l26_sys_pm_ops which is then exported as it is in my initial submission?
> I’m unsure how to handle these cases with the latest macros.
I don't happen to see macros for suspend_noirq and resume_noirq, so maybe you
cannot use macros here after all and will instead have to fall back to tacking
on __maybe_unused to these callbacks to accommodate the !CONFIG_PM case.
That being said, what are you ultimately trying to accomplish here with these
noirq variants? For example the print statement says "early resume" when in
fact a different callback exists for that (resume_early).
On that note, why to disable interrupts during system suspend? I can imagine a
use-case where a customer ties the output of a force sensor to a CS40L26 GPIO
for low-latency haptic trigger, and then the CS40L26 interrupt output to the
SoC as a wake-up trigger. Does the part not support this use-case? I vaguely
seem to remember an issue with this on L25.
Also, why is the logic inverted for the noirq variants? These are simply meant
to accommodate additional tasks that need a guarantee the device's interrupt
handler is not running (for example, clear or acknowledge a pending interrupt).
In case I have misunderstood the intent, please let me know.
One last gripe, then I promise to stop bringing it up :) But the mental gymnastics
required to explain the no-fewer-than-six PM callbacks used here, as well as how
to support the !CONFIG_PM case, are in some ways additional nudges toward getting
rid of this massive amount of PM overhead and relying on the device's internal
power management as so many modern input devices now do. As a rule of thumb, if
you're having to jump through a lot of hoops to do simple things that others seem
to be doing with less work, something is wrong.
In your defense, however, you are unlikely to come across many devices that do
not enable CONFIG_PM given this device's target application. That being said, it
is not unheard of for OEMs building wall-powered devices to enable CONFIG_PM but
inhibit system suspend using a wake_lock because of some HW bug.
Therefore, it seems a bit unfortunate that those use-cases wouldn't get to enjoy
the power savings this devices offers. That's just my $.02; I also understand
the reasons behind the current implementation and won't push you to change it.
>
> Appreciate any guidance you can provide.
>
> Best regards,
> Fred
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [PATCH v2] Input: ili210x - Probe even if no resolution information
From: Dmitry Torokhov @ 2023-05-06 18:46 UTC (permalink / raw)
To: Marek Vasut; +Cc: linux-input, Joe Hung, Luca Hsu
In-Reply-To: <20230217025200.203833-1-marex@denx.de>
On Fri, Feb 17, 2023 at 03:52:00AM +0100, Marek Vasut wrote:
> Probe the touch controller driver even if resolution information is not
> available. This can happen e.g. in case the touch controller suffered a
> failed firmware update and is stuck in bootloader mode.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: ensure timely release of driver-allocated resources
From: Dmitry Torokhov @ 2023-05-06 18:38 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: Stephen Boyd, linux-input, linux-kernel
In-Reply-To: <ZFWarGkRAfPOmI6E@google.com>
On Fri, May 05, 2023 at 05:09:16PM -0700, Dmitry Torokhov wrote:
> + if (down_interruptible(&hdev->driver_input_lock))
> + return -EINTR;
> +
> + ret = __hid_device_probe(hdev);
There is an extra space snuck in before "ret", let me know if you want
me to repost it (or if there are bigger concerns).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC v1 0/4] Input: support virtual objects on touchscreens
From: Jeff LaBundy @ 2023-05-06 18:35 UTC (permalink / raw)
To: Peter Hutterer
Cc: Javier Carrasco, Thomas Weißschuh, linux-input, devicetree,
linux-kernel, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Henrik Rydberg, Ulf Hansson, Hans Verkuil, Stephen Boyd,
Sebastian Reichel, Linus Walleij, Jonathan Cameron, Uwe Kleine-g,
Bastian Hecht, Michael Riesch
In-Reply-To: <20230504042927.GA1129520@quokka>
Hi Peter and Javier,
On Thu, May 04, 2023 at 02:29:27PM +1000, Peter Hutterer wrote:
> On Thu, Apr 27, 2023 at 12:23:14PM -0500, Jeff LaBundy wrote:
> > Hi Javier,
> >
> > On Thu, Apr 27, 2023 at 05:59:42PM +0200, Javier Carrasco wrote:
> > > Hi,
> > >
> > > On 25.04.23 18:02, Jeff LaBundy wrote:
> > > > Hi Thomas,
> > > >
> > > > On Tue, Apr 25, 2023 at 05:29:39PM +0200, Thomas Weißschuh wrote:
> > > >> Hi Javier,
> > > >>
> > > >> On 2023-04-25 13:50:45+0200, Javier Carrasco wrote:
> > > >>> Some touchscreens are shipped with a physical layer on top of them where
> > > >>> a number of buttons and a resized touchscreen surface might be available.
> > > >>>
> > > >>> In order to generate proper key events by overlay buttons and adjust the
> > > >>> touch events to a clipped surface, these patches offer a documented,
> > > >>> device-tree-based solution by means of helper functions.
> > > >>> An implementation for a specific touchscreen driver is also included.
> > > >>>
> > > >>> The functions in ts-virtobj provide a simple workflow to acquire
> > > >>> physical objects from the device tree, map them into the device driver
> > > >>> structures as virtual objects and generate events according to
> > > >>> the object descriptions.
> > > >>>
> > > >>> This solution has been tested with a JT240MHQS-E3 display, which uses
> > > >>> the st1624 as a touchscreen and provides two overly buttons and a frame
> > > >>> that clips its effective surface.
> > > >>
> > > >> There are quite a few of notebooks from Asus that feature a printed
> > > >> numpad on their touchpad [0]. The mapping from the touch events to the
> > > >> numpad events needs to happen in software.
> > > >
> > > > That example seems a kind of fringe use-case in my opinion; I think the
> > > > gap filled by this RFC is the case where a touchscreen has a printed
> > > > overlay with a key that represents a fixed function.
> > >
> > > Exactly, this RFC addresses exactly such printed overlays.
> > > >
> > > > One problem I do see here is something like libinput or multitouch taking
> > > > hold of the input device, and swallowing the key presses because it sees
> > > > the device as a touchscreen and is not interested in these keys.
> > >
> > > Unfortunately I do not know libinput or multitouch and I might be
> > > getting you wrong, but I guess the same would apply to any event
> > > consumer that takes touchscreens as touch event producers and nothing else.
> > >
> > > Should they not check the supported events from the device instead of
> > > making such assumptions? This RFC adds key events defined in the device
> > > tree and they are therefore available and published as device
> > > capabilities. That is for example what evtest does to report the
> > > supported events and they are then notified accordingly. Is that not the
> > > right way to do it?
> >
> > evtest is just that, a test tool. It's handy for ensuring the device emits
> > the appropriate input events in response to hardware inputs, but it is not
> > necessarily representative of how the input device may be used in practice.
>
> ftr, I strongly recommend "libinput record" over evtest since it can be
> replayed. And for libinput testing "libinput debug-events" to see what
> comes out of libinput.
>
> > I would encourage you to test this solution with a simple use-case such as
> > Raspbian, and the virtual keys mapped to easily recognizable functions like
> > volume up/down.
> >
> > Here, you will find that libinput will grab the device and declare it to be
> > a touchscreen based on the input events it advertises. However, you will not
> > see volume up/down keys are handled.
>
> that would be a bug in libinput. libinput doesn't classify devices. It
> uses *internal* backends but the backend for keyboard and touchscreen
> devices is the same. So as long as your device advertises the various
> EV_KEY and EV_ABS bit correctly, things should just work. If that's not
> the case for a device please file a bug.
Please accept my apology for spreading misinformation; the sighting occurred
some time ago and I appear to have mixed up some observations.
I recreated my original issue just now and the problem is actually with LIRC,
which in this case is presenting the hybrid input device to VLC media player
as a remote control.
Prior to launching VLC media player, both touchscreen movement and key events
are handled just fine. Once VLC media player launches and LIRC begins handling
the key events, however, all touchscreen functionality is lost.
Upon closer inspection, it seems that LIRC creates another input device called
"lircd bypass" which relays the "left over" (i.e. touchscreen) events. However,
it seems LIRC does not copy the axis limits, so libinput rightfully rejects
the new device since min ABS_X = max ABS_X = 0.
Therefore, please ignore my sighting with regard to this RFC; it is neither a
bug in libinput nor a valid argument in shaping this RFC. This instead seems
like a possible bug in LIRC, so I will report it there.
>
> It's still "better" to split it up into different event nodes because
> a lot of userspace may not be able to handle touchscreen+keyboard
> devices but at least at the libinput level this shouldn't be a problem.
I still agree; if nothing else, for the ability to inhibit different functions
at a more granular level. Therefore it seems best that patch [1/4] not mandate
the two input devices to be the same, which it doesn't appear to do anyway.
That being said, Javier, feel free to disregard my suggestion that the input
devices in patch [3/4] remain separate. Sorry for the churn; this was still
very helpful for me at least :)
>
> And the xf86-input-libinput driver splits up such devices at the X
> level, so even where a device is touchscreen + keyboard you would end up
> with two X devices with separate capabilities so they fit into the X
> "everything is either a pointer or a keyboard" worldview.
>
> Cheers,
> Peter
>
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [PATCH v2] Input: ili210x - Probe even if no resolution information
From: Marek Vasut @ 2023-05-06 15:27 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Joe Hung, Luca Hsu
In-Reply-To: <83bf921d-e941-3f93-6264-2e5a70f1aff5@denx.de>
On 2/22/23 00:14, Marek Vasut wrote:
> On 2/21/23 22:14, Dmitry Torokhov wrote:
>> On Tue, Feb 21, 2023 at 09:12:29PM +0100, Marek Vasut wrote:
>>> On 2/21/23 20:40, Dmitry Torokhov wrote:
>>>> Hi Marek,
>>>>
>>>> On Fri, Feb 17, 2023 at 03:52:00AM +0100, Marek Vasut wrote:
>>>>> Probe the touch controller driver even if resolution information is
>>>>> not
>>>>> available. This can happen e.g. in case the touch controller
>>>>> suffered a
>>>>> failed firmware update and is stuck in bootloader mode.
>>>>>
>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>> ---
>>>>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>>> Cc: Joe Hung <joe_hung@ilitek.com>
>>>>> Cc: Luca Hsu <luca_hsu@ilitek.com>
>>>>> ---
>>>>> V2: Add dev_warn() in case resolution is invalid
>>>>> ---
>>>>> drivers/input/touchscreen/ili210x.c | 28
>>>>> +++++++++++++++++++---------
>>>>> 1 file changed, 19 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/touchscreen/ili210x.c
>>>>> b/drivers/input/touchscreen/ili210x.c
>>>>> index 4897fafa4204d..d64b6d77d2e08 100644
>>>>> --- a/drivers/input/touchscreen/ili210x.c
>>>>> +++ b/drivers/input/touchscreen/ili210x.c
>>>>> @@ -370,22 +370,33 @@ static int
>>>>> ili251x_firmware_update_resolution(struct device *dev)
>>>>> /* The firmware update blob might have changed the
>>>>> resolution. */
>>>>> error = priv->chip->read_reg(client, REG_PANEL_INFO, &rs,
>>>>> sizeof(rs));
>>>>> - if (error)
>>>>> - return error;
>>>>> + if (!error) {
>>>>> + resx = le16_to_cpup((__le16 *)rs);
>>>>> + resy = le16_to_cpup((__le16 *)(rs + 2));
>>>>> - resx = le16_to_cpup((__le16 *)rs);
>>>>> - resy = le16_to_cpup((__le16 *)(rs + 2));
>>>>> + /* The value reported by the firmware is invalid. */
>>>>> + if (!resx || resx == 0xffff || !resy || resy == 0xffff)
>>>>> + error = -EINVAL;
>>>>> + }
>>>>> - /* The value reported by the firmware is invalid. */
>>>>> - if (!resx || resx == 0xffff || !resy || resy == 0xffff)
>>>>> - return -EINVAL;
>>>>> + /*
>>>>> + * In case of error, the firmware might be stuck in bootloader
>>>>> mode,
>>>>> + * e.g. after a failed firmware update. Set maximum
>>>>> resolution, but
>>>>> + * do not fail to probe, so the user can re-trigger the firmware
>>>>> + * update and recover the touch controller.
>>>>> + */
>>>>> + if (error) {
>>>>> + dev_warn(dev, "Invalid resolution reported by
>>>>> controller.\n");
>>>>> + resx = 16384;
>>>>> + resy = 16384;
>>>>> + }
>>>>> input_abs_set_max(priv->input, ABS_X, resx - 1);
>>>>> input_abs_set_max(priv->input, ABS_Y, resy - 1);
>>>>> input_abs_set_max(priv->input, ABS_MT_POSITION_X, resx - 1);
>>>>> input_abs_set_max(priv->input, ABS_MT_POSITION_Y, resy - 1);
>>>>> - return 0;
>>>>> + return error;
>>>>
>>>> I think this will make ili251x_firmware_update_cached_state() continue
>>>> failing when it reports invalid coordinates. Was this intended?
>>>
>>> This is actually correct, ili251x_firmware_update_cached_state() will
>>> fail,
>>> but ili210x_i2c_probe() won't stop there anymore, see the second hunk of
>>> this patch. The driver will instantiate the controller, so user can load
>>> correct firmware into it and recover the hardware.
>>
>> I was concerned about call from ili210x_firmware_update_store() which
>> will continue returning error.
>
> It hopefully won't, because at that point the controller would be
> running new and working firmware, which would report the correct values.
> If the firmware is broken, then yes, it would fail.
Hi,
any news on this ?
I still have to track this downstream to recover those devices from
broken firmware update, it would be really useful to have this also
upstream.
^ permalink raw reply
* Re: [regression] Bug 217394 - IRQ override skipping breaks the Aya Neo Air Plus 6800U keyboard buttons
From: Chuanhong Guo @ 2023-05-06 8:25 UTC (permalink / raw)
To: Limonciello, Mario
Cc: Linux regressions mailing list, linux-input, Mario Limonciello,
Rafael J. Wysocki, ACPI Devel Maling List, LKML
In-Reply-To: <68d017d9-d815-01d4-23c1-49c0aaf5f20b@amd.com>
Hi Mario!
On Thu, May 4, 2023 at 12:11 AM Limonciello, Mario <mlimonci@amd.com> wrote:
>
> +linux-input
>
> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> > Hi, Thorsten here, the Linux kernel's regression tracker.
> >
> > I noticed a regression report in bugzilla.kernel.org. As many (most?)
> > kernel developers don't keep an eye on it, I decided to forward it by mail.
> >
> > Chuanhong Guo, apparently it's cause by a change of yours.
> >
> > Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
> > not CCed them in mails like this.
> >
> > Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
> >
> >> Matthew 2023-05-03 02:28:33 UTC
> >>
> >> Reverting the changes found in this patch fixes the issue:
> >>> https://lore.kernel.org/all/20220712020058.90374-1-gch981213@gmail.com/
> >> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
> >>
> >> Hardware:
> >>
> >> Aya Neo Air Plus
> >> AMD Ryzen 7 6800U
> > See the ticket for more details.
> >
> > BTW: there apparently is another IRQ override needed for a different
> > machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
> > details (ignore the comments before that, the quirk entry for that
> > machine was merged; comment 8 and all related to it really should have a
> > separate bug; that's also why this partly fall through the cracks here
> > :-/ ). The user is currently trying to create a patch.
> >
> Something I'm wondering about is if it's possible for i8042 to detect
> the polarity is incorrect when it probes and
> to try to correct it.
>
> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource:
> skip IRQ override on AMD Zen platforms")
> to fix this issue along with all the other quirks that have collected
> over time on i8042 polarity issues.
>
I don't really understand why there are more and more new laptops
appearing with broken IRQ settings in ACPI, especially considering
the fact that some of these laptops were released after the original
problem was already identified almost a year ago.
What exactly was the solution when AMD internally discovered this IRQ
mismatch problem? Did you guys changed the emulated IRQ polarity
without updating the ACPI table with the corresponding polarity
description in your reference design?
--
Regards,
Chuanhong Guo
^ permalink raw reply
* [dtor-input:master] BUILD SUCCESS 5672bd308ef23b81eb40dd2963f925fd671a66c2
From: kernel test robot @ 2023-05-06 7:16 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master
branch HEAD: 5672bd308ef23b81eb40dd2963f925fd671a66c2 Input: edt-ft5x06 - add delay after waking up
elapsed time: 722m
configs tested: 237
configs skipped: 17
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r001-20230502 gcc
alpha defconfig gcc
alpha randconfig-r002-20230430 gcc
alpha randconfig-r003-20230504 gcc
alpha randconfig-r033-20230430 gcc
alpha randconfig-r035-20230505 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r006-20230502 gcc
arc defconfig gcc
arc randconfig-r001-20230504 gcc
arc randconfig-r006-20230501 gcc
arc randconfig-r024-20230506 gcc
arc randconfig-r033-20230501 gcc
arc randconfig-r034-20230501 gcc
arc randconfig-r035-20230501 gcc
arc randconfig-r043-20230430 gcc
arc randconfig-r043-20230501 gcc
arc randconfig-r043-20230502 gcc
arc randconfig-r043-20230503 gcc
arc randconfig-r043-20230504 gcc
arc randconfig-r043-20230505 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r011-20230501 gcc
arm randconfig-r015-20230430 gcc
arm randconfig-r023-20230430 gcc
arm randconfig-r046-20230430 gcc
arm randconfig-r046-20230501 gcc
arm randconfig-r046-20230502 clang
arm randconfig-r046-20230503 gcc
arm randconfig-r046-20230504 clang
arm randconfig-r046-20230505 gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r002-20230505 gcc
arm64 randconfig-r004-20230504 clang
csky buildonly-randconfig-r001-20230505 gcc
csky buildonly-randconfig-r005-20230505 gcc
csky defconfig gcc
csky randconfig-r011-20230502 gcc
csky randconfig-r025-20230506 gcc
csky randconfig-r026-20230506 gcc
csky randconfig-r031-20230430 gcc
csky randconfig-r031-20230501 gcc
csky randconfig-r035-20230430 gcc
csky randconfig-r036-20230505 gcc
hexagon randconfig-r002-20230504 clang
hexagon randconfig-r005-20230504 clang
hexagon randconfig-r016-20230430 clang
hexagon randconfig-r035-20230430 clang
hexagon randconfig-r041-20230430 clang
hexagon randconfig-r041-20230501 clang
hexagon randconfig-r041-20230502 clang
hexagon randconfig-r041-20230503 clang
hexagon randconfig-r041-20230504 clang
hexagon randconfig-r041-20230505 clang
hexagon randconfig-r045-20230430 clang
hexagon randconfig-r045-20230501 clang
hexagon randconfig-r045-20230502 clang
hexagon randconfig-r045-20230503 clang
hexagon randconfig-r045-20230504 clang
hexagon randconfig-r045-20230505 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230501 gcc
i386 randconfig-a001 gcc
i386 randconfig-a002-20230501 gcc
i386 randconfig-a002 clang
i386 randconfig-a003-20230501 gcc
i386 randconfig-a003 gcc
i386 randconfig-a004-20230501 gcc
i386 randconfig-a004 clang
i386 randconfig-a005-20230501 gcc
i386 randconfig-a005 gcc
i386 randconfig-a006-20230501 gcc
i386 randconfig-a006 clang
i386 randconfig-a011-20230501 clang
i386 randconfig-a012-20230501 clang
i386 randconfig-a013-20230501 clang
i386 randconfig-a014-20230501 clang
i386 randconfig-a015-20230501 clang
i386 randconfig-a016-20230501 clang
i386 randconfig-r013-20230501 clang
i386 randconfig-r016-20230501 clang
ia64 allmodconfig gcc
ia64 defconfig gcc
ia64 randconfig-r003-20230501 gcc
ia64 randconfig-r004-20230505 gcc
ia64 randconfig-r011-20230430 gcc
ia64 randconfig-r021-20230501 gcc
ia64 randconfig-r023-20230506 gcc
ia64 randconfig-r025-20230430 gcc
ia64 randconfig-r032-20230501 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r012-20230501 gcc
loongarch randconfig-r012-20230502 gcc
loongarch randconfig-r021-20230506 gcc
loongarch randconfig-r022-20230501 gcc
loongarch randconfig-r025-20230501 gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r004-20230505 gcc
m68k defconfig gcc
m68k randconfig-r006-20230502 gcc
m68k randconfig-r011-20230501 gcc
m68k randconfig-r014-20230430 gcc
m68k randconfig-r026-20230430 gcc
m68k randconfig-r034-20230430 gcc
microblaze buildonly-randconfig-r003-20230505 gcc
microblaze randconfig-r006-20230430 gcc
microblaze randconfig-r013-20230430 gcc
microblaze randconfig-r022-20230430 gcc
microblaze randconfig-r031-20230501 gcc
microblaze randconfig-r033-20230505 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips buildonly-randconfig-r006-20230505 clang
mips randconfig-r005-20230501 clang
mips randconfig-r012-20230430 gcc
mips randconfig-r012-20230505 gcc
mips randconfig-r014-20230505 gcc
mips randconfig-r016-20230505 gcc
mips randconfig-r023-20230501 gcc
mips randconfig-r032-20230430 clang
mips randconfig-r033-20230505 clang
mips randconfig-r034-20230430 clang
mips randconfig-r035-20230505 clang
nios2 buildonly-randconfig-r002-20230505 gcc
nios2 defconfig gcc
nios2 randconfig-r001-20230430 gcc
nios2 randconfig-r004-20230501 gcc
nios2 randconfig-r014-20230502 gcc
nios2 randconfig-r015-20230502 gcc
nios2 randconfig-r021-20230430 gcc
nios2 randconfig-r022-20230506 gcc
nios2 randconfig-r032-20230501 gcc
nios2 randconfig-r032-20230505 gcc
nios2 randconfig-r035-20230501 gcc
openrisc randconfig-r016-20230501 gcc
openrisc randconfig-r032-20230505 gcc
parisc defconfig gcc
parisc randconfig-r016-20230430 gcc
parisc randconfig-r034-20230501 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-r001-20230505 gcc
powerpc randconfig-r002-20230502 clang
powerpc randconfig-r006-20230505 gcc
powerpc randconfig-r024-20230501 clang
powerpc randconfig-r031-20230430 gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r005-20230505 clang
riscv defconfig gcc
riscv randconfig-r003-20230502 clang
riscv randconfig-r004-20230430 gcc
riscv randconfig-r012-20230502 gcc
riscv randconfig-r015-20230501 clang
riscv randconfig-r016-20230502 gcc
riscv randconfig-r036-20230430 gcc
riscv randconfig-r042-20230430 clang
riscv randconfig-r042-20230501 clang
riscv randconfig-r042-20230502 gcc
riscv randconfig-r042-20230503 clang
riscv randconfig-r042-20230504 gcc
riscv randconfig-r042-20230505 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r005-20230502 gcc
s390 defconfig gcc
s390 randconfig-r003-20230505 gcc
s390 randconfig-r011-20230430 clang
s390 randconfig-r011-20230502 gcc
s390 randconfig-r014-20230502 gcc
s390 randconfig-r031-20230505 gcc
s390 randconfig-r033-20230430 gcc
s390 randconfig-r044-20230430 clang
s390 randconfig-r044-20230501 clang
s390 randconfig-r044-20230502 gcc
s390 randconfig-r044-20230503 clang
s390 randconfig-r044-20230504 gcc
s390 randconfig-r044-20230505 clang
sh allmodconfig gcc
sh randconfig-r005-20230505 gcc
sh randconfig-r012-20230430 gcc
sh randconfig-r014-20230501 gcc
sh randconfig-r015-20230501 gcc
sh randconfig-r026-20230501 gcc
sh randconfig-r033-20230501 gcc
sh randconfig-r036-20230430 gcc
sparc defconfig gcc
sparc randconfig-r003-20230430 gcc
sparc randconfig-r004-20230502 gcc
sparc randconfig-r013-20230502 gcc
sparc randconfig-r015-20230505 gcc
sparc64 randconfig-r001-20230502 gcc
sparc64 randconfig-r005-20230430 gcc
sparc64 randconfig-r005-20230502 gcc
sparc64 randconfig-r013-20230505 gcc
sparc64 randconfig-r031-20230505 gcc
sparc64 randconfig-r034-20230505 gcc
sparc64 randconfig-r036-20230501 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230501 gcc
x86_64 randconfig-a002-20230501 gcc
x86_64 randconfig-a003-20230501 gcc
x86_64 randconfig-a004-20230501 gcc
x86_64 randconfig-a005-20230501 gcc
x86_64 randconfig-a006-20230501 gcc
x86_64 randconfig-a011-20230501 clang
x86_64 randconfig-a012-20230501 clang
x86_64 randconfig-a013-20230501 clang
x86_64 randconfig-a014-20230501 clang
x86_64 randconfig-a015-20230501 clang
x86_64 randconfig-a016-20230501 clang
x86_64 randconfig-r036-20230501 gcc
x86_64 rhel-8.3 gcc
xtensa randconfig-r001-20230501 gcc
xtensa randconfig-r002-20230501 gcc
xtensa randconfig-r006-20230504 gcc
xtensa randconfig-r011-20230505 gcc
xtensa randconfig-r014-20230430 gcc
xtensa randconfig-r015-20230430 gcc
xtensa randconfig-r015-20230502 gcc
xtensa randconfig-r032-20230430 gcc
xtensa randconfig-r034-20230505 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 978134c4b192ed04ecf699be3e1b4d23b5d20457
From: kernel test robot @ 2023-05-06 7:15 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 978134c4b192ed04ecf699be3e1b4d23b5d20457 Input: fix open count when closing inhibited device
elapsed time: 721m
configs tested: 150
configs skipped: 16
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allyesconfig gcc
alpha buildonly-randconfig-r001-20230502 gcc
alpha defconfig gcc
alpha randconfig-r003-20230501 gcc
alpha randconfig-r003-20230505 gcc
alpha randconfig-r012-20230501 gcc
alpha randconfig-r013-20230502 gcc
arc allyesconfig gcc
arc buildonly-randconfig-r006-20230502 gcc
arc defconfig gcc
arc randconfig-r011-20230430 gcc
arc randconfig-r012-20230505 gcc
arc randconfig-r024-20230506 gcc
arc randconfig-r043-20230430 gcc
arc randconfig-r043-20230501 gcc
arc randconfig-r043-20230505 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm defconfig gcc
arm randconfig-r002-20230430 clang
arm randconfig-r002-20230501 clang
arm randconfig-r046-20230430 gcc
arm randconfig-r046-20230501 gcc
arm randconfig-r046-20230505 gcc
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r001-20230501 gcc
arm64 randconfig-r015-20230430 clang
arm64 randconfig-r015-20230501 clang
csky buildonly-randconfig-r001-20230505 gcc
csky defconfig gcc
csky randconfig-r006-20230502 gcc
csky randconfig-r025-20230506 gcc
csky randconfig-r026-20230506 gcc
csky randconfig-r036-20230430 gcc
hexagon randconfig-r001-20230430 clang
hexagon randconfig-r005-20230502 clang
hexagon randconfig-r006-20230501 clang
hexagon randconfig-r016-20230501 clang
hexagon randconfig-r041-20230430 clang
hexagon randconfig-r041-20230501 clang
hexagon randconfig-r041-20230505 clang
hexagon randconfig-r045-20230430 clang
hexagon randconfig-r045-20230501 clang
hexagon randconfig-r045-20230505 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230501 gcc
i386 randconfig-a002-20230501 gcc
i386 randconfig-a003-20230501 gcc
i386 randconfig-a004-20230501 gcc
i386 randconfig-a005-20230501 gcc
i386 randconfig-a006-20230501 gcc
i386 randconfig-a011-20230501 clang
i386 randconfig-a012-20230501 clang
i386 randconfig-a013-20230501 clang
i386 randconfig-a014-20230501 clang
i386 randconfig-a015-20230501 clang
i386 randconfig-a016-20230501 clang
i386 randconfig-r032-20230501 gcc
ia64 allmodconfig gcc
ia64 defconfig gcc
ia64 randconfig-r015-20230502 gcc
ia64 randconfig-r016-20230430 gcc
ia64 randconfig-r023-20230506 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-r014-20230505 gcc
loongarch randconfig-r021-20230506 gcc
m68k allmodconfig gcc
m68k defconfig gcc
m68k randconfig-r006-20230430 gcc
microblaze buildonly-randconfig-r003-20230505 gcc
microblaze randconfig-r034-20230430 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips randconfig-r004-20230502 gcc
mips randconfig-r011-20230505 gcc
mips randconfig-r036-20230501 clang
nios2 defconfig gcc
nios2 randconfig-r006-20230505 gcc
nios2 randconfig-r013-20230501 gcc
nios2 randconfig-r022-20230506 gcc
nios2 randconfig-r031-20230430 gcc
openrisc randconfig-r014-20230501 gcc
openrisc randconfig-r033-20230430 gcc
openrisc randconfig-r035-20230430 gcc
parisc defconfig gcc
parisc randconfig-r001-20230502 gcc
parisc randconfig-r005-20230430 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-r012-20230430 clang
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r005-20230505 clang
riscv defconfig gcc
riscv randconfig-r011-20230502 gcc
riscv randconfig-r042-20230430 clang
riscv randconfig-r042-20230501 clang
riscv randconfig-r042-20230505 clang
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r005-20230502 gcc
s390 defconfig gcc
s390 randconfig-r032-20230430 gcc
s390 randconfig-r044-20230430 clang
s390 randconfig-r044-20230501 clang
s390 randconfig-r044-20230505 clang
sh allmodconfig gcc
sh randconfig-r001-20230505 gcc
sh randconfig-r004-20230430 gcc
sh randconfig-r005-20230505 gcc
sh randconfig-r015-20230505 gcc
sh randconfig-r016-20230505 gcc
sparc defconfig gcc
sparc randconfig-r003-20230430 gcc
sparc randconfig-r003-20230502 gcc
sparc randconfig-r012-20230502 gcc
sparc randconfig-r014-20230430 gcc
sparc64 randconfig-r005-20230501 gcc
sparc64 randconfig-r013-20230430 gcc
sparc64 randconfig-r013-20230505 gcc
sparc64 randconfig-r031-20230501 gcc
sparc64 randconfig-r035-20230501 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230501 gcc
x86_64 randconfig-a002-20230501 gcc
x86_64 randconfig-a003-20230501 gcc
x86_64 randconfig-a004-20230501 gcc
x86_64 randconfig-a005-20230501 gcc
x86_64 randconfig-a006-20230501 gcc
x86_64 randconfig-a011-20230501 clang
x86_64 randconfig-a012-20230501 clang
x86_64 randconfig-a013-20230501 clang
x86_64 randconfig-a014-20230501 clang
x86_64 randconfig-a015-20230501 clang
x86_64 randconfig-a016-20230501 clang
x86_64 rhel-8.3 gcc
xtensa randconfig-r014-20230502 gcc
xtensa randconfig-r033-20230501 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
^ permalink raw reply
* Re: [regression] Bug 217394 - IRQ override skipping breaks the Aya Neo Air Plus 6800U keyboard buttons
From: Thorsten Leemhuis @ 2023-05-06 6:47 UTC (permalink / raw)
To: Dmitry Torokhov, Limonciello, Mario
Cc: Linux regressions mailing list, Chuanhong Guo, linux-input,
Mario Limonciello, Rafael J. Wysocki, ACPI Devel Maling List,
LKML
In-Reply-To: <ZFKvVKMesT+3NthN@google.com>
On 03.05.23 21:00, Dmitry Torokhov wrote:
> On Wed, May 03, 2023 at 11:11:33AM -0500, Limonciello, Mario wrote:
>> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>
>>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>>> kernel developers don't keep an eye on it, I decided to forward it by mail.
>>>
>>> Chuanhong Guo, apparently it's cause by a change of yours.
BTW, there is another report caused by the change:
https://bugzilla.kernel.org/show_bug.cgi?id=217406
```
I have an HP Pavilion Aero 13 laptop that comes with an AMD Ryzen 7735U
CPU and an up-to-date BIOS. Using any kernel version that is strictly
greater than 5.19.9 on it is causing the typing with the integrated
keyboard to be extremely slow. "Slow" is subjective but let's say [...]"
```
/me wonders how many machines out there show problems we never hear about
Anyway:
>>> Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
>>> not CCed them in mails like this.
>>>
>>> Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
>>>
>>>> Matthew 2023-05-03 02:28:33 UTC
>>>>
>>>> Reverting the changes found in this patch fixes the issue:
>>>>> https://lore.kernel.org/all/20220712020058.90374-1-gch981213@gmail.com/
>>>> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
>>>>
>>>> Hardware:
>>>>
>>>> Aya Neo Air Plus
>>>> AMD Ryzen 7 6800U
>>> See the ticket for more details.
>>>
>>> BTW: there apparently is another IRQ override needed for a different
>>> machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
>>> details (ignore the comments before that, the quirk entry for that
>>> machine was merged; comment 8 and all related to it really should have a
>>> separate bug; that's also why this partly fall through the cracks here
>>> :-/ ). The user is currently trying to create a patch.
>>>
>> Something I'm wondering about is if it's possible for i8042 to detect the
>> polarity is incorrect when it probes and
>> to try to correct it.
>>
>> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource: skip
>> IRQ override on AMD Zen platforms")
>> to fix this issue along with all the other quirks that have collected over
>> time on i8042 polarity issues.
>
> 8042 is shared between multiple platforms and is quite fragile as it is.
> If there are issues in AMD firmware and you know the polarity that is
> needed for 8042 on these platforms you should add a proper fixup for
> override. Maybe you should only skip override for IRQ 1?
Stupid question from the peanut gallery: does anyone know what Windows
is doing on those machines? I wonder if this is one of those situation
where we just must follow suite to make things work reliably long term
for users, even if that might mean 8042 needs to be modified.
Or is the problem likely to go away with new hardware?
Ciao, Thorsten
P.S.: BTW:
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=217406
^ permalink raw reply
* [PATCH] HID: ensure timely release of driver-allocated resources
From: Dmitry Torokhov @ 2023-05-06 0:09 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: Stephen Boyd, linux-input, linux-kernel
More and more drivers rely on devres to manage their resources, however
if bus' probe() and release() methods are not trivial and control some
of resources as well (for example enable or disable clocks, or attach
device to a power domain), we need to make sure that driver-allocated
resources are released immediately after driver's remove() method
returns, and not postponed until driver core gets around to releasing
resources.
In case of HID we should not try to close the report and release
associated memory until after all devres callbacks are executed. To fix
that we open a new devres group before calling driver's probe() and
explicitly release it when we return from driver's remove().
This is similar to what we did for I2C bus in commit 5b5475826c52 ("i2c:
ensure timely release of driver-allocated resources"). It is tempting to
try and move this into driver core, but actually doing so is challenging,
we need to split bus' remove() method into pre- and post-remove methods,
which would make the logic even less clear.
Reported-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20230505232417.1377393-1-swboyd@chromium.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-core.c | 55 ++++++++++++++++++++++++++++--------------
include/linux/hid.h | 1 +
2 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c4ac9081194c..02a43bba9091 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2602,35 +2602,29 @@ static bool hid_device_check_match(struct hid_device *hdev,
return !hid_ignore_special_drivers;
}
-static int hid_device_probe(struct device *dev)
+static int __hid_device_probe(struct hid_device *hdev)
{
- struct hid_driver *hdrv = to_hid_driver(dev->driver);
- struct hid_device *hdev = to_hid_device(dev);
+ struct hid_driver *hdrv = to_hid_driver(hdev->dev.driver);
const struct hid_device_id *id;
int ret;
- if (down_interruptible(&hdev->driver_input_lock)) {
- ret = -EINTR;
- goto end;
- }
hdev->io_started = false;
-
clear_bit(ffs(HID_STAT_REPROBED), &hdev->status);
- if (hdev->driver) {
- ret = 0;
- goto unlock;
- }
+ if (hdev->driver)
+ return 0;
- if (!hid_device_check_match(hdev, hdrv, &id)) {
- ret = -ENODEV;
- goto unlock;
- }
+ if (!hid_device_check_match(hdev, hdrv, &id))
+ return -ENODEV;
/* Reset the quirks that have been previously set */
hdev->quirks = hid_lookup_quirk(hdev);
hdev->driver = hdrv;
+ hdev->devres_group_id = devres_open_group(&hdev->dev, NULL, GFP_KERNEL);
+ if (!hdev->devres_group_id)
+ return -ENOMEM;
+
if (hdrv->probe) {
ret = hdrv->probe(hdev, id);
} else { /* default probe */
@@ -2639,15 +2633,36 @@ static int hid_device_probe(struct device *dev)
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
}
+ /*
+ * Note that we are not closing the devres group opened above so
+ * even resources that were attached to the device after probe is
+ * run are released when hid_device_remove() is executed. This is
+ * needed as some drivers would allocate additional resources,
+ * for example when updating firmware.
+ */
+
if (ret) {
+ devres_release_group(&hdev->dev, hdev->devres_group_id);
hid_close_report(hdev);
hdev->driver = NULL;
}
-unlock:
+ return ret;
+}
+
+static int hid_device_probe(struct device *dev)
+{
+ struct hid_device *hdev = to_hid_device(dev);
+ int ret;
+
+ if (down_interruptible(&hdev->driver_input_lock))
+ return -EINTR;
+
+ ret = __hid_device_probe(hdev);
+
if (!hdev->io_started)
up(&hdev->driver_input_lock);
-end:
+
return ret;
}
@@ -2665,6 +2680,10 @@ static void hid_device_remove(struct device *dev)
hdrv->remove(hdev);
else /* default remove */
hid_hw_stop(hdev);
+
+ /* Release all devres resources allocated by the driver */
+ devres_release_group(&hdev->dev, hdev->devres_group_id);
+
hid_close_report(hdev);
hdev->driver = NULL;
}
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 1ea8c7a3570b..4e4cb3873468 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -596,6 +596,7 @@ struct hid_device { /* device report descriptor */
struct semaphore driver_input_lock; /* protects the current driver */
struct device dev; /* device */
struct hid_driver *driver;
+ void *devres_group_id; /* ID of probe devres group */
const struct hid_ll_driver *ll_driver;
struct mutex ll_open_lock;
--
2.40.1.521.gf1e218fcd8-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] HID: google: Don't use devm for hid_hw_stop()
From: Dmitry Torokhov @ 2023-05-06 0:06 UTC (permalink / raw)
To: Stephen Boyd
Cc: Jiri Kosina, Benjamin Tissoires, linux-kernel, patches,
linux-input
In-Reply-To: <20230505232417.1377393-1-swboyd@chromium.org>
On Fri, May 05, 2023 at 04:24:16PM -0700, Stephen Boyd wrote:
>
...
> Unfortunately, the hid google hammer driver hand rolls a devm function
> to call hid_hw_stop() when the driver is unbound and implements an
> hid_driver::remove() function. The driver core doesn't call the devm
> release functions until _after_ the bus unbinds the driver, so the order
> of operations is like this:
Excellent analysis, but the problem is not limited to the hammer driver
(potentially) and shalt be dealt with appropriately, at the HID bus
level.
Actually, it is not even limited to HID, but exists in most buses with
non-trivial ->remove() implementation. For example I fixed similar issue
in I2C in 5b5475826c52 ("i2c: ensure timely release of driver-allocated
resources"). I tried fixing it in SPI but Mark has some objections, and
wanted to fix it in the driver core, so I was thinking about it and then
dropped the ball. At this time I do not think fixing it at driver core
makes logic any clearer, so I think we just need to fix a handful of
buses.
Anyway, I'll CC you on an alternative patch.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: google: Don't use devm for hid_hw_stop()
From: Stephen Boyd @ 2023-05-05 23:24 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-kernel, patches, linux-input, Dmitry Torokhov
We (ChromeOS) got a syzkaller report of a KASAN use after free read in
hidinput_find_key(). The callstack is from evdev_ioctl() calling
hidinput_setkeycode():
__asan_report_load4_noabort+0x44/0x50
hidinput_find_key+0x25c/0x340
hidinput_locate_usage+0x31c/0x400
hidinput_setkeycode+0x70/0x460
input_set_keycode+0xd4/0x3f8
evdev_do_ioctl+0x2508/0x6678
evdev_ioctl_handler+0x12c/0x180
evdev_ioctl+0x40/0x54
The memory being read was allocated during hammer_probe() by
hid_open_report():
Allocated by task 19025:
kasan_save_stack+0x38/0x68
__kasan_kmalloc+0x90/0xac
__kmalloc+0x27c/0x45c
hid_add_field+0x4b0/0x125c
hid_parser_main+0x214/0x994
hid_open_report+0x388/0x7a8
hammer_probe+0x80/0x698 [hid_google_hammer]
and the memory was freed by hid_close_report() called from
hid_destroy_device().
Freed by task 19025:
kasan_save_stack+0x38/0x68
kasan_set_track+0x28/0x3c
kasan_set_free_info+0x28/0x4c
____kasan_slab_free+0x110/0x164
__kasan_slab_free+0x18/0x28
kfree+0x208/0x950
hid_close_report+0xd0/0x29c
hid_device_remove+0x104/0x198
device_release_driver_internal+0x204/0x400
device_release_driver+0x30/0x40
bus_remove_device+0x2a0/0x390
device_del+0x49c/0x858
hid_destroy_device+0x78/0x11c
usbhid_disconnect+0xb4/0x100
usb_unbind_interface+0x178/0x6f4
device_release_driver_internal+0x240/0x400
device_release_driver+0x30/0x40
bus_remove_device+0x2a0/0x390
The memory that's being read by the ioctl is an HID report that's been
freed when the HID device is destroyed because the usb interface is
unbound. In hid_device_remove() we assume that the hid report can be
closed with hid_close_report() after the hid_driver is unbound, which is
generally safe because the driver should have stopped the hardware with
hid_hw_stop() when it was unbound. In fact, hid_device_remove() falls
back to calling hid_hw_stop() directly if the hid driver doesn't have a
remove() function, so the assumption is that hid_hw_stop() has been
called once the hid_driver::remove() function returns. hid_hw_stop()
will eventually call hidinput_disconnect() which will unregister the
hidinput device; ensuring that userspace can't call ioctls on the
hidinput device when hid_hw_stop() returns.
Unfortunately, the hid google hammer driver hand rolls a devm function
to call hid_hw_stop() when the driver is unbound and implements an
hid_driver::remove() function. The driver core doesn't call the devm
release functions until _after_ the bus unbinds the driver, so the order
of operations is like this:
__device_release_driver()
...
device_remove(dev)
hid_device_remove(hdev)
hdrv->remove(hdev);
hid_close_report(hdev) <---- Frees the report
device_unbind_cleanup(dev)
devres_release_all(dev)
...
hid_hw_stop(hdev) <--- Removes the hid_input device
We want the order of operations to be hid_hw_stop() and then
hid_close_report() so that the report can be freed without the hid_input
device hanging around attempting to deref the report. Remove the hand
rolled devm function and call hid_hw_stop() from the hammer_remove()
function to fix the ordering.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: d950db3f80a8 ("HID: google: switch to devm when registering keyboard backlight LED")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/hid/hid-google-hammer.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 7ae5f27df54d..e7f7c3c68747 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -495,11 +495,6 @@ static void hammer_get_folded_state(struct hid_device *hdev)
kfree(buf);
}
-static void hammer_stop(void *hdev)
-{
- hid_hw_stop(hdev);
-}
-
static int hammer_probe(struct hid_device *hdev,
const struct hid_device_id *id)
{
@@ -520,10 +515,6 @@ static int hammer_probe(struct hid_device *hdev,
if (error)
return error;
- error = devm_add_action(&hdev->dev, hammer_stop, hdev);
- if (error)
- return error;
-
/*
* We always want to poll for, and handle tablet mode events from
* devices that have folded usage, even when nobody has opened the input
@@ -533,8 +524,10 @@ static int hammer_probe(struct hid_device *hdev,
if (hammer_has_folded_event(hdev)) {
hdev->quirks |= HID_QUIRK_ALWAYS_POLL;
error = hid_hw_open(hdev);
- if (error)
+ if (error) {
+ hid_hw_stop(hdev);
return error;
+ }
hammer_get_folded_state(hdev);
}
@@ -576,7 +569,8 @@ static void hammer_remove(struct hid_device *hdev)
spin_unlock_irqrestore(&cbas_ec_lock, flags);
}
- /* Unregistering LEDs and stopping the hardware is done via devm */
+ /* Unregistering LEDs is done via devm */
+ hid_hw_stop(hdev);
}
static const struct hid_device_id hammer_devices[] = {
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
https://chromeos.dev
^ permalink raw reply related
* [syzbot] Monthly input report (May 2023)
From: syzbot @ 2023-05-05 21:40 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 0 new issues were detected and 1 were fixed.
In total, 10 issues are still open and 48 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 2347 Yes WARNING in input_mt_init_slots
https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
<2> 933 Yes WARNING in implement
https://syzkaller.appspot.com/bug?extid=38e7237add3712479d65
<3> 82 Yes general protection fault in hidraw_release
https://syzkaller.appspot.com/bug?extid=953a33deaf38c66a915e
<4> 49 Yes inconsistent lock state in find_vmap_area
https://syzkaller.appspot.com/bug?extid=8d19062486784d15dda9
<5> 33 Yes WARNING in bcm5974_start_traffic/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH] Input: synaptics-rmi4: Use %pe for error codes.
From: Michał Mirosław @ 2023-05-05 20:48 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <ZFBcF0ZcBfMFdZLu@google.com>
On Mon, May 01, 2023 at 05:40:55PM -0700, Dmitry Torokhov wrote:
> On Sat, Apr 29, 2023 at 08:41:19PM +0200, Michał Mirosław wrote:
> > Make the error messages a bit easier to understand by showing
> > error names where that's enabled.
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > ---
> > drivers/input/rmi4/rmi_driver.c | 66 +++++++++++++++++----------------
> > 1 file changed, 34 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> > index 258d5fe3d395..82d85c02a873 100644
> > --- a/drivers/input/rmi4/rmi_driver.c
> > +++ b/drivers/input/rmi4/rmi_driver.c
> > @@ -69,8 +69,8 @@ static int reset_one_function(struct rmi_function *fn)
> > if (fh->reset) {
> > retval = fh->reset(fn);
> > if (retval < 0)
> > - dev_err(&fn->dev, "Reset failed with code %d.\n",
> > - retval);
> > + dev_err(&fn->dev, "Reset failed: %pe\n",
> > + ERR_PTR(retval));
>
> If this is desired we should have a format option for
> non-err-ptr-encoded errors.
This is a common case in the kernel source to use "%pe" with ERR_PTR().
The code in `lib/vsprintf.c` has only '%p' with extended treatment and
I'm not sure how much work would be needed to extend other format
specifier (I would consider confusing if "%p" would possibly take
something that's not a pointer).
Best Regards
Michał Mirosław
^ 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