All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	hotwater438@tutanota.com
Cc: Jiri Kosina <jikos@kernel.org>,
	Kai Heng Feng <kai.heng.feng@canonical.com>,
	Stephen Boyd <swboyd@chromium.org>,
	bigeasy@linutronix.de, Dmitry Torokhov <dtor@chromium.org>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ELAN touchpad i2c_hid bugs fix
Date: Wed, 20 Mar 2019 16:39:16 +0100	[thread overview]
Message-ID: <9151d116-958c-9298-9427-fe803a163e9f@redhat.com> (raw)
In-Reply-To: <CAO-hwJLGABHATo-fOc_jgc8uNeLDv7cemsHuQMj7zRJWmfyp4g@mail.gmail.com>

H,

On 3/20/19 3:37 PM, Benjamin Tissoires wrote:

<snip>

>> The reason why i2c_hid_init_irq was moved is told by Hans De Goede
>> <hdegoede@redhat.com>:
>> i2c_hid_init_irq now checks for a quirk, so we must setup the quirks before we init the irq, and we cannot setup the quirk earlier, so we must init the irq later.
> 
> I am pretty sure you can paraphrase Hans in your commit message
> without having to formally quote him (Hans, please shout if you
> disagree).

Right, it is fine to explain why the irq init is moved without
quoting or even referring to me.

>> --- a/drivers/hid/hid-ids.h
>> +++ b/drivers/hid/hid-ids.h
>> @@ -389,6 +389,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_ELAN_TOUCHPAD 0x303e
> 
> I know Hans wanted you to use USB here, but I'd think we should have a
> I2C_DEVICE_ID_*
> There is no guarantees that this same PID will be used in a different
> chip over USB.
> We tend to not car about USB/I2C for the vendor IDs: the vendors
> decided to reuse their USB VID, which makes our life easier.

Ok, no objection from me to use an I2C_DEVICE_ID prefix, here it
is after all an I2C device.

>> #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 90164fed08d3..16b55c45e2e8 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>> @@ -50,7 +50,8 @@
>> #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_BOGUS_IRQ BIT(4)
>> +#define I2C_HID_QUIRK_BOGUS_IRQ BIT(4)
>> +#define I2C_HID_QUIRK_FORCE_TRIGGER_FALLING BIT(5)
>>
>> /* flags */
>> #define I2C_HID_STARTED 0
>> @@ -182,8 +183,10 @@ 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_ELAN_TOUCHPAD,
>> + I2C_HID_QUIRK_BOGUS_IRQ | I2C_HID_QUIRK_FORCE_TRIGGER_FALLING },
>> { USB_VENDOR_ID_ELAN, HID_ANY_ID,
>> - I2C_HID_QUIRK_BOGUS_IRQ },
>> + I2C_HID_QUIRK_BOGUS_IRQ },

Benjamin, what I find interesting here is that the BOGUS_IRQ quirk
is also used on Elan devices, I suspect that these Elan devices
likely also need the I2C_HID_QUIRK_FORCE_TRIGGER_FALLING quirk
and then they probably will no longer need the bogus IRQ flag,
if you know about bugreports with an acpidump for any of the devices
needing the bogus IRQ quirk, then I (or you) can check how the IRQ is
declared there, I suspect it will be declared as level-low, just like
with the laptop this patch was written for. And it probably need to
be edge-falling instead of level-low just like this case.

Regards,

Hans


  reply	other threads:[~2019-03-20 15:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <LaQHUFs--3-1@tutanota.com>
2019-03-20 14:37 ` [PATCH] ELAN touchpad i2c_hid bugs fix Benjamin Tissoires
2019-03-20 15:39   ` Hans de Goede [this message]
2019-03-20 16:53     ` Kai-Heng Feng
2019-03-20 17:18       ` Andy Shevchenko
2019-03-21  4:08         ` Kai-Heng Feng
2019-03-21  8:55           ` Andy Shevchenko
2019-03-21  9:28             ` Kai Heng Feng
2019-03-21  8:57           ` Hans de Goede
2019-03-21  9:48           ` Andy Shevchenko
2019-04-01 21:37             ` Mario.Limonciello
2019-04-01 21:37               ` Mario.Limonciello
2019-04-02  4:18               ` Kai Heng Feng
2019-04-02 14:08                 ` Mario.Limonciello
2019-04-02 14:08                   ` Mario.Limonciello
2019-04-03  9:24                   ` Kai-Heng Feng
2019-03-20 17:11   ` Andy Shevchenko
     [not found] ` <LaUpAlT--3-1@tutanota.com>
     [not found]   ` <LaeGPSe--3-1@tutanota.com>
2019-03-24 12:27     ` Hans de Goede
     [not found]       ` <LakgsCJ--3-1@tutanota.com>
2019-03-24 18:37         ` Hans de Goede
2019-03-24 19:10 Vladislav Dalechyn
2019-03-25  9:23 ` Benjamin Tissoires
2019-03-25 12:57 Vladislav Dalechyn
2019-03-25 16:02 ` Dmitry Torokhov
2019-03-25 16:38   ` Hans de Goede
2019-03-25 16:56     ` Dmitry Torokhov
     [not found]       ` <Laq4ykv--3-1@tutanota.com>
2019-03-25 18:30         ` Dmitry Torokhov
2019-03-29 12:18       ` Hans de Goede
2019-03-29 18:23         ` Dmitry Torokhov
2019-04-01 12:26           ` 廖崇榮
2019-04-01 12:26             ` 廖崇榮
     [not found]         ` <LbI7kio--3-1@tutanota.com>
2019-04-03 11:18           ` Hans de Goede
     [not found]             ` <LbZjy9p--3-1@tutanota.com>
2019-04-11 16:17               ` Kai-Heng Feng
     [not found]                 ` <LcKqhgD--3-1@tutanota.com>
2019-04-13  8:42                   ` Kai-Heng Feng
     [not found]                     ` <LcVmBjG--3-1@tutanota.com>
2019-04-15 11:42                       ` Hans de Goede
2019-04-16  3:59                         ` Kai-Heng Feng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9151d116-958c-9298-9427-fe803a163e9f@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=dtor@chromium.org \
    --cc=hotwater438@tutanota.com \
    --cc=jikos@kernel.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.