Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
fixes the resume behavior of several devices. However, this breaks the
resume on the ELAN2097, used on Dell Inspiron laptops, with the same flood
of messages:
[27009.817110] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
[27009.818867] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
[27009.820623] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
This change adds a new I2C_HID_QUIRK_RESET_AFTER_RESUME and replaces the
original reset behavior for this device.
Signed-off-by: Jim Broadus <[email protected]>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/i2c-hid/i2c-hid-core.c | 20 ++++++++++++++------
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 24f846d67478..38cc7033712a 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -387,6 +387,7 @@
#define USB_DEVICE_ID_TOSHIBA_CLICK_L9W 0x0401
#define USB_DEVICE_ID_HP_X2 0x074d
#define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
+#define USB_DEVICE_ID_ELAN2097 0x2504
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index c5edfa966343..fdbad29b4406 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -50,6 +50,7 @@
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
#define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
#define I2C_HID_QUIRK_DELAY_AFTER_SLEEP BIT(3)
+#define I2C_HID_QUIRK_RESET_AFTER_RESUME BIT(4)
/* flags */
#define I2C_HID_STARTED 0
@@ -181,6 +182,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_NO_RUNTIME_PM },
{ I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
I2C_HID_QUIRK_NO_RUNTIME_PM },
+ { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN2097,
+ I2C_HID_QUIRK_RESET_AFTER_RESUME },
{ 0, 0 }
};
@@ -1279,12 +1282,17 @@ static int i2c_hid_resume(struct device *dev)
enable_irq(client->irq);
- /* Instead of resetting device, simply powers the device on. This
- * solves "incomplete reports" on Raydium devices 2386:3118 and
- * 2386:4B33 and fixes various SIS touchscreens no longer sending
- * data after a suspend/resume.
- */
- ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
+ if (ihid->quirks & I2C_HID_QUIRK_RESET_AFTER_RESUME) {
+ ret = i2c_hid_hwreset(client);
+ } else {
+ /* Instead of resetting device, simply powers the device on.
+ * This solves "incomplete reports" on Raydium devices 2386:3118
+ * and 2386:4B33 and fixes various SIS touchscreens no longer
+ * sending data after a suspend/resume.
+ */
+ ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
+ }
+
if (ret)
return ret;
--
2.20.1
On Sun, 10 Feb 2019, Jim Broadus wrote:
> Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
> fixes the resume behavior of several devices. However, this breaks the
> resume on the ELAN2097, used on Dell Inspiron laptops, with the same flood
> of messages:
>
> [27009.817110] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
> [27009.818867] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
> [27009.820623] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
>
> This change adds a new I2C_HID_QUIRK_RESET_AFTER_RESUME and replaces the
> original reset behavior for this device.
>
> Signed-off-by: Jim Broadus <[email protected]>
This should be fixed in hid.git#for-5.1/i2c-hid already by commit
1475af255e18f. Could you please confirm that?
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/i2c-hid/i2c-hid-core.c | 20 ++++++++++++++------
> 2 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 24f846d67478..38cc7033712a 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -387,6 +387,7 @@
> #define USB_DEVICE_ID_TOSHIBA_CLICK_L9W 0x0401
> #define USB_DEVICE_ID_HP_X2 0x074d
> #define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
> +#define USB_DEVICE_ID_ELAN2097 0x2504
>
> #define USB_VENDOR_ID_ELECOM 0x056e
> #define USB_DEVICE_ID_ELECOM_BM084 0x0061
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index c5edfa966343..fdbad29b4406 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -50,6 +50,7 @@
> #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
> #define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
> #define I2C_HID_QUIRK_DELAY_AFTER_SLEEP BIT(3)
> +#define I2C_HID_QUIRK_RESET_AFTER_RESUME BIT(4)
>
> /* flags */
> #define I2C_HID_STARTED 0
> @@ -181,6 +182,8 @@ static const struct i2c_hid_quirks {
> I2C_HID_QUIRK_NO_RUNTIME_PM },
> { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
> I2C_HID_QUIRK_NO_RUNTIME_PM },
> + { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN2097,
> + I2C_HID_QUIRK_RESET_AFTER_RESUME },
> { 0, 0 }
> };
>
> @@ -1279,12 +1282,17 @@ static int i2c_hid_resume(struct device *dev)
>
> enable_irq(client->irq);
>
> - /* Instead of resetting device, simply powers the device on. This
> - * solves "incomplete reports" on Raydium devices 2386:3118 and
> - * 2386:4B33 and fixes various SIS touchscreens no longer sending
> - * data after a suspend/resume.
> - */
> - ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> + if (ihid->quirks & I2C_HID_QUIRK_RESET_AFTER_RESUME) {
> + ret = i2c_hid_hwreset(client);
> + } else {
> + /* Instead of resetting device, simply powers the device on.
> + * This solves "incomplete reports" on Raydium devices 2386:3118
> + * and 2386:4B33 and fixes various SIS touchscreens no longer
> + * sending data after a suspend/resume.
> + */
> + ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> + }
> +
> if (ret)
> return ret;
>
> --
> 2.20.1
>
--
Jiri Kosina
SUSE Labs
On Wed, Feb 13, 2019 at 3:37 PM Jiri Kosina <[email protected]> wrote:
>
> On Sun, 10 Feb 2019, Jim Broadus wrote:
>
> > Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
> > fixes the resume behavior of several devices. However, this breaks the
> > resume on the ELAN2097, used on Dell Inspiron laptops, with the same flood
> > of messages:
> >
> > [27009.817110] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
> > [27009.818867] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
> > [27009.820623] i2c_hid i2c-ELAN2097:00: i2c_hid_get_input: incomplete report (67/65535)
> >
> > This change adds a new I2C_HID_QUIRK_RESET_AFTER_RESUME and replaces the
> > original reset behavior for this device.
> >
> > Signed-off-by: Jim Broadus <[email protected]>
>
> This should be fixed in hid.git#for-5.1/i2c-hid already by commit
> 1475af255e18f. Could you please confirm that?
>
Hi Jiri. That change mutes the log messages, but I'm still counting around
35000 interrupts per second after resume and touch does not work. With the
reset, the device works properly.
Jim
> > ---
> > drivers/hid/hid-ids.h | 1 +
> > drivers/hid/i2c-hid/i2c-hid-core.c | 20 ++++++++++++++------
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > index 24f846d67478..38cc7033712a 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -387,6 +387,7 @@
> > #define USB_DEVICE_ID_TOSHIBA_CLICK_L9W 0x0401
> > #define USB_DEVICE_ID_HP_X2 0x074d
> > #define USB_DEVICE_ID_HP_X2_10_COVER 0x0755
> > +#define USB_DEVICE_ID_ELAN2097 0x2504
> >
> > #define USB_VENDOR_ID_ELECOM 0x056e
> > #define USB_DEVICE_ID_ELECOM_BM084 0x0061
> > diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> > index c5edfa966343..fdbad29b4406 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> > @@ -50,6 +50,7 @@
> > #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
> > #define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
> > #define I2C_HID_QUIRK_DELAY_AFTER_SLEEP BIT(3)
> > +#define I2C_HID_QUIRK_RESET_AFTER_RESUME BIT(4)
> >
> > /* flags */
> > #define I2C_HID_STARTED 0
> > @@ -181,6 +182,8 @@ static const struct i2c_hid_quirks {
> > I2C_HID_QUIRK_NO_RUNTIME_PM },
> > { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
> > I2C_HID_QUIRK_NO_RUNTIME_PM },
> > + { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN2097,
> > + I2C_HID_QUIRK_RESET_AFTER_RESUME },
> > { 0, 0 }
> > };
> >
> > @@ -1279,12 +1282,17 @@ static int i2c_hid_resume(struct device *dev)
> >
> > enable_irq(client->irq);
> >
> > - /* Instead of resetting device, simply powers the device on. This
> > - * solves "incomplete reports" on Raydium devices 2386:3118 and
> > - * 2386:4B33 and fixes various SIS touchscreens no longer sending
> > - * data after a suspend/resume.
> > - */
> > - ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> > + if (ihid->quirks & I2C_HID_QUIRK_RESET_AFTER_RESUME) {
> > + ret = i2c_hid_hwreset(client);
> > + } else {
> > + /* Instead of resetting device, simply powers the device on.
> > + * This solves "incomplete reports" on Raydium devices 2386:3118
> > + * and 2386:4B33 and fixes various SIS touchscreens no longer
> > + * sending data after a suspend/resume.
> > + */
> > + ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> > + }
> > +
> > if (ret)
> > return ret;
> >
> > --
> > 2.20.1
> >
>
> --
> Jiri Kosina
> SUSE Labs
>
On Thu, 14 Feb 2019, james broadus wrote:
> > This should be fixed in hid.git#for-5.1/i2c-hid already by commit
> > 1475af255e18f. Could you please confirm that?
> >
>
> Hi Jiri. That change mutes the log messages, but I'm still counting
> around 35000 interrupts per second after resume and touch does not work.
> With the reset, the device works properly.
Ah, I see. Should your patch then actually replace 1475af255e18f?
Thanks,
--
Jiri Kosina
SUSE Labs
Hi Jiri and James,
> On Feb 15, 2019, at 15:35, Jiri Kosina <[email protected]> wrote:
>
> On Thu, 14 Feb 2019, james broadus wrote:
>
>>> This should be fixed in hid.git#for-5.1/i2c-hid already by commit
>>> 1475af255e18f. Could you please confirm that?
>>>
>>
>> Hi Jiri. That change mutes the log messages, but I'm still counting
>> around 35000 interrupts per second after resume and touch does not work.
>> With the reset, the device works properly.
>
> Ah, I see. Should your patch then actually replace 1475af255e18f?
Sorry for the late reply, was off because of Lunar new year.
Commit 1475af255e18f is to silence the message when using the touchpad, so it’s different to this patch.
I’ve seen similar bugs happens on new platforms that defaults S2Idle (Modern Standby), but user uses S3 instead.
On those systems, S3 was never tested, so the BIOS doesn’t cut the touchpad’s power off during S3, and the IRQ line wasn’t getting properly reset.
So if the platform defaults to S2Idle but user wants to use S3, this issue happens.
If that’s the case, maybe it’s better to report to the platform vendor.
Kai-Heng
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
Happy new year.
I think you might be right. I found some discussions about Dell
disabling S3 support in a recent bios due to a C-state bug.
I'll try to investigate a bit more this weekend.
Jim
On Fri, Feb 15, 2019 at 1:25 AM Kai-Heng Feng
<[email protected]> wrote:
>
> Hi Jiri and James,
>
> > On Feb 15, 2019, at 15:35, Jiri Kosina <[email protected]> wrote:
> >
> > On Thu, 14 Feb 2019, james broadus wrote:
> >
> >>> This should be fixed in hid.git#for-5.1/i2c-hid already by commit
> >>> 1475af255e18f. Could you please confirm that?
> >>>
> >>
> >> Hi Jiri. That change mutes the log messages, but I'm still counting
> >> around 35000 interrupts per second after resume and touch does not work.
> >> With the reset, the device works properly.
> >
> > Ah, I see. Should your patch then actually replace 1475af255e18f?
>
> Sorry for the late reply, was off because of Lunar new year.
>
> Commit 1475af255e18f is to silence the message when using the touchpad, so it’s different to this patch.
>
> I’ve seen similar bugs happens on new platforms that defaults S2Idle (Modern Standby), but user uses S3 instead.
> On those systems, S3 was never tested, so the BIOS doesn’t cut the touchpad’s power off during S3, and the IRQ line wasn’t getting properly reset.
>
> So if the platform defaults to S2Idle but user wants to use S3, this issue happens.
> If that’s the case, maybe it’s better to report to the platform vendor.
>
> Kai-Heng
>
> >
> > Thanks,
> >
> > --
> > Jiri Kosina
> > SUSE Labs
> >
>