Hi,
On 12-09-18 17:52, anisse@xxxxxxxxx wrote:
On Wed, Sep 12, 2018 at 03:36:08PM +0200, Hans de Goede wrote:
Hi,
On 12-09-18 15:07, Anisse Astier wrote:
This hantick HTIX5288 touchpad can quickly fall in a wrong state if
there are too many open/close operations. This will either make it stop
reporting any input, or will shift all the input reads by a few bytes,
making it impossible to decode.
Here, we never release the probed touchpad runtime pm while the driver
is loaded, which should disable all runtime pm suspend/resumes.
This fast repetition of sleep/wakeup is also more likely to happen when
using runtime PM, which is why the quirk is done there, and not for all
power downs, which would include suspend or module removal.
Signed-off-by: Anisse Astier <anisse@xxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
---
Changes since v1: (thanks Hans de Goede)
- no longer uses msleep to delay suspend, but disables runtime suspend it
entirely
- quirk is now named NO_RUNTIME_PM and OR-ed with the other Hantick quirk
Hmm, this conflicts with my:
"HID: i2c-hid: Remove RESEND_REPORT_DESCR quirk and its handling"
patch. Jiri, how do you want to handle this ?
Jiri, this should be an easy merge, but for completeness I rebased on
top of Hans' patch and built and tested the patch below:
Thanks, but I think that we should consider your patch for -fixes / for
4.19, so then I would need to rebase my patch on yours, after a back
merge of -fixes into -next.
Or we could put both patches in -fixes I guess.
Anyways lets wait what Jiri has to say about this.
Regards,
Hans
From: Anisse Astier <anisse@xxxxxxxxx>
Date: Wed, 12 Sep 2018 09:34:33 +0000
Subject: [PATCH] HID: i2c-hid: disable runtime PM operations on hantick
touchpad
This hantick HTIX5288 touchpad can quickly fall in a wrong state if
there are too many open/close operations. This will either make it stop
reporting any input, or will shift all the input reads by a few bytes,
making it impossible to decode.
Here, we never release the probed touchpad runtime pm while the driver
is loaded, which should disable all runtime pm suspend/resumes.
This fast repetition of sleep/wakeup is also more likely to happen when
using runtime PM, which is why the quirk is done there, and not for all
power downs, which would include suspend or module removal.
Signed-off-by: Anisse Astier <anisse@xxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Acked-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
Reviewed-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
Changes since v2:
- rebased on top of Hans de Goede
"HID: i2c-hid: Remove RESEND_REPORT_DESCR quirk and its handling"
patch
- took Benjamin and Hans' ack/reviewed-by
drivers/hid/i2c-hid/i2c-hid.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 9e1800a74bbe..4e3592e7a3f7 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -47,6 +47,7 @@
/* quirks to control the device */
#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV BIT(0)
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
+#define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
/* flags */
#define I2C_HID_STARTED 0
@@ -168,7 +169,8 @@ static const struct i2c_hid_quirks {
{ USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8755,
I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
{ I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
- I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
+ I2C_HID_QUIRK_NO_IRQ_AFTER_RESET |
+ I2C_HID_QUIRK_NO_RUNTIME_PM },
{ 0, 0 }
};
@@ -1102,7 +1104,9 @@ static int i2c_hid_probe(struct i2c_client *client,
goto err_mem_free;
}
- pm_runtime_put(&client->dev);
+ if (!(ihid->quirks & I2C_HID_QUIRK_NO_RUNTIME_PM))
+ pm_runtime_put(&client->dev);
+
return 0;
err_mem_free:
@@ -1127,7 +1131,8 @@ static int i2c_hid_remove(struct i2c_client *client)
struct i2c_hid *ihid = i2c_get_clientdata(client);
struct hid_device *hid;
- pm_runtime_get_sync(&client->dev);
+ if (!(ihid->quirks & I2C_HID_QUIRK_NO_RUNTIME_PM))
+ pm_runtime_get_sync(&client->dev);
pm_runtime_disable(&client->dev);
pm_runtime_set_suspended(&client->dev);
pm_runtime_put_noidle(&client->dev);
