From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Cc: benjamin.tissoires@redhat.com, jikos@kernel.org,
hdegoede@redhat.com, bjorn.andersson@linaro.org,
agross@kernel.org, lee.jones@linaro.org, xnox@ubuntu.com,
robh+dt@kernel.org, mark.rutland@arm.com,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 2/5] HID: quirks: Refactor ELAN 400 and 401 handling
Date: Wed, 12 Jun 2019 14:46:36 -0700 [thread overview]
Message-ID: <20190612214636.GA40779@dtor-ws> (raw)
In-Reply-To: <20190612212721.32195-1-jeffrey.l.hugo@gmail.com>
On Wed, Jun 12, 2019 at 02:27:21PM -0700, Jeffrey Hugo wrote:
> There needs to be coordination between hid-quirks and the elan_i2c driver
> about which devices are handled by what drivers. Currently, both use
> whitelists, which results in valid devices being unhandled by default,
> when they should not be rejected by hid-quirks. This is quickly becoming
> an issue.
>
> Since elan_i2c has a maintained whitelist of what devices it will handle,
> which is now in a header file that hid-quirks can access, use that to
> implement a blacklist in hid-quirks so that only the devices that need to
> be handled by elan_i2c get rejected by hid-quirks, and everything else is
> handled by default.
>
> Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> ---
> drivers/hid/hid-quirks.c | 27 ++++++++++++++++-----------
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index e5ca6fe2ca57..bd81bb090222 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -16,6 +16,7 @@
> #include <linux/export.h>
> #include <linux/slab.h>
> #include <linux/mutex.h>
> +#include <linux/input/elan-i2c-ids.h>
>
> #include "hid-ids.h"
>
> @@ -914,6 +915,8 @@ static const struct hid_device_id hid_mouse_ignore_list[] = {
>
> bool hid_ignore(struct hid_device *hdev)
> {
> + int i;
> +
> if (hdev->quirks & HID_QUIRK_NO_IGNORE)
> return false;
> if (hdev->quirks & HID_QUIRK_IGNORE)
> @@ -978,18 +981,20 @@ bool hid_ignore(struct hid_device *hdev)
> break;
> case USB_VENDOR_ID_ELAN:
> /*
> - * Many Elan devices have a product id of 0x0401 and are handled
> - * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev
> - * is not (and cannot be) handled by that driver ->
> - * Ignore all 0x0401 devs except for the ELAN0800 dev.
> + * Blacklist of everything that gets handled by the elan_i2c
> + * input driver. This avoids disabling valid touchpads and
> + * other ELAN devices.
> */
> - if (hdev->product == 0x0401 &&
> - strncmp(hdev->name, "ELAN0800", 8) != 0)
> - return true;
> - /* Same with product id 0x0400 */
> - if (hdev->product == 0x0400 &&
> - strncmp(hdev->name, "QTEC0001", 8) != 0)
> - return true;
> + if ((hdev->product == 0x0401 || hdev->product == 0x0400)) {
> + for (i = 0; strlen(elan_acpi_id[i].id); ++i)
> + if (!strncmp(hdev->name, elan_acpi_id[i].id,
> + strlen(elan_acpi_id[i].id)))
> + return true;
> + for (i = 0; strlen(elan_of_match[i].name); ++i)
> + if (!strncmp(hdev->name, elan_of_match[i].name,
> + strlen(elan_of_match[i].name)))
> + return true;
Do we really need to blacklist the OF case here? I thought that in ACPI
case we have clashes as HID gets matched by elan_i2c and CID is matched
by i2c-hid, but I do not believe we'll run into the same situation on OF
systems.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2019-06-13 17:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 21:26 [PATCH v6 0/5] Basic DT support for Lenovo Miix 630 Jeffrey Hugo
2019-06-12 21:27 ` [PATCH v6 1/5] Input: elan_i2c: Export the device id whitelist Jeffrey Hugo
2019-06-12 21:27 ` [PATCH v6 2/5] HID: quirks: Refactor ELAN 400 and 401 handling Jeffrey Hugo
2019-06-12 21:46 ` Dmitry Torokhov [this message]
2019-06-12 22:20 ` Jeffrey Hugo
2019-06-13 8:55 ` Benjamin Tissoires
2019-06-19 15:39 ` Jeffrey Hugo
2019-06-19 17:10 ` Dmitry Torokhov
2019-06-19 17:40 ` Jeffrey Hugo
2019-06-12 21:27 ` [PATCH v6 3/5] arm64: dts: qcom: Add Lenovo Miix 630 Jeffrey Hugo
2019-06-14 13:44 ` Rob Clark
2019-06-14 14:08 ` Rob Clark
2019-06-12 21:27 ` [PATCH v6 4/5] arm64: dts: qcom: Add HP Envy x2 Jeffrey Hugo
2019-06-12 21:28 ` [PATCH v6 5/5] arm64: dts: qcom: Add Asus NovaGo TP370QL Jeffrey Hugo
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=20190612214636.GA40779@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=agross@kernel.org \
--cc=benjamin.tissoires@redhat.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=hdegoede@redhat.com \
--cc=jeffrey.l.hugo@gmail.com \
--cc=jikos@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=xnox@ubuntu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).