Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5938852ybi; Wed, 12 Jun 2019 11:03:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqyNksC8Tz9orjpds14nHAPeDKaLAgUR0f/W4mTs5sOUwNoyjTsmTdgCD9zq8RqhCkIoQxHi X-Received: by 2002:a17:90a:9d81:: with SMTP id k1mr443854pjp.63.1560362596518; Wed, 12 Jun 2019 11:03:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560362596; cv=none; d=google.com; s=arc-20160816; b=geeRCw5hugOdH+Ar/vMvhFd2a2rMTWvzEqrodS2neHdC+E7o4zuWYvLFwTlrjbTtCl 2Wt3LR2ztDJmM2qsnH1fYYFnlFZk3iJsn8GZ4RpxPtwom/bZPNx1Bca7cGOuG65xPWMM egWghcgeX0ZYYRBQgFOWJkN13B2BViQj0hHQ2WWZaxDmXs1PupVo0xUqBpeAPliLz7+v UHcPefLX1pnA3V48PAdeIGOg0/r9rN5Zdtz61zptdbl3EXg1YPe+Gv27YOyFI/r58Q8C oApc69LembhVO1tY24AiKqpTYxLhVHf56D5qUT9pfjWUPHG4wZDiFmzrlJceYvYln1g7 gTpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature; bh=YS91HGnIT9HoIOwTQJdfJ0YTopHZ7JdIiYo368IcSdU=; b=OcrCpkSwaHPGPknk9WAcxnoj/S39r0ztVnAhvDTq9VrNHPEJZ10piR3fDAfl1fnNjh W5oU8NH4hh3RVELsMtmQmViBwzvSe5RpvHN3Y+Xx+kl/Pj/s/zQVo9UGx1g4LpeCowF8 yUk30/P73oQ95IMadKACnpMlgfT+0s7Q+uwAm9McDh8KAZgnYMIkcKPesCHKnsL2gQhE RHZUCf1M84kg9RyVJU1i508g2BE9dnlv78iCnVNTXHXLfOPeU8AmML46ztkS0KjgUt76 /F8JKJPT6gnEUoJuENw95BpW2hywblYvEPXUL/jxJBeX7pxkwx01IBAuIW64ffAb+itV VedA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=VEg4j6Ms; dkim=pass header.i=@codeaurora.org header.s=default header.b=j2oDfdqN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m25si386391pgv.481.2019.06.12.11.03.01; Wed, 12 Jun 2019 11:03:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=VEg4j6Ms; dkim=pass header.i=@codeaurora.org header.s=default header.b=j2oDfdqN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407580AbfFLOsk (ORCPT + 99 others); Wed, 12 Jun 2019 10:48:40 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:49764 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392030AbfFLOsj (ORCPT ); Wed, 12 Jun 2019 10:48:39 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 078EF6074C; Wed, 12 Jun 2019 14:48:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1560350918; bh=ogYzUcjHgCk+aG5ZVAvXyAiDxq61mB17ua8ybhd9qEg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VEg4j6MsN9sKZTQFf5spkgy7OTBADMwmoOhzBSLLXrCJ/c+rqWCek/yQhlDCghjM4 gixr3fQP3ozY6Df99fJDn5GZmEMQXPTrvWaSNvUL6PK280pBY6tqMjnDh8MKpUBlfZ dw9bgAvhiTyt2sBXVyt/f1fXdaSo4vIgfS+yoUVs= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED,SPF_NONE autolearn=no autolearn_force=no version=3.4.0 Received: from [10.226.58.28] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jhugo@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 96E7760256; Wed, 12 Jun 2019 14:48:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1560350915; bh=ogYzUcjHgCk+aG5ZVAvXyAiDxq61mB17ua8ybhd9qEg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=j2oDfdqNpUGj6YCGOEsImfaYefFvZdHO5Pttasvoq2m7sXDg+kWveprzehT6p+hGG /1TI5U6qwt1AeC5spMob0yPvRWUaPzpe+R1Rb2sbgLXZxY1+IOnlL+hRxhlcr6O7Ff gcCwsVYJEjW8tBa+acpGlZKomp4DgULqdpYe8s4s= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 96E7760256 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=jhugo@codeaurora.org Subject: Re: [PATCH v5 2/3] HID: quirks: Refactor ELAN 400 and 401 handling To: Lee Jones Cc: Dmitry Torokhov , Jeffrey Hugo , benjamin.tissoires@redhat.com, jikos@kernel.org, bjorn.andersson@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com, agross@kernel.org, david.brown@linaro.org, hdegoede@redhat.com, linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190606161055.47089-1-jeffrey.l.hugo@gmail.com> <20190606161322.47192-1-jeffrey.l.hugo@gmail.com> <20190612003507.GG143729@dtor-ws> <2282f3e1-e76a-4fe7-d447-51d9a4bee2de@codeaurora.org> <20190612143715.GC4660@dell> From: Jeffrey Hugo Message-ID: <77e54e66-c7c8-9fd3-995a-7633202bb81e@codeaurora.org> Date: Wed, 12 Jun 2019 08:48:33 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190612143715.GC4660@dell> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/12/2019 8:37 AM, Lee Jones wrote: > On Wed, 12 Jun 2019, Jeffrey Hugo wrote: > >> On 6/11/2019 6:35 PM, Dmitry Torokhov wrote: >>> On Thu, Jun 06, 2019 at 09:13:22AM -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, >>>> 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. The downside is the whitelist and >>>> blacklist need to be kept in sync. >>>> >>>> Suggested-by: Benjamin Tissoires >>>> Signed-off-by: Jeffrey Hugo >>>> --- >>>> drivers/hid/hid-quirks.c | 78 ++++++++++++++++++++++++++++++++++------ >>>> 1 file changed, 67 insertions(+), 11 deletions(-) >>>> >>>> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c >>>> index e5ca6fe2ca57..edebd0700e3d 100644 >>>> --- a/drivers/hid/hid-quirks.c >>>> +++ b/drivers/hid/hid-quirks.c >>>> @@ -912,8 +912,66 @@ static const struct hid_device_id hid_mouse_ignore_list[] = { >>>> { } >>>> }; >>>> +/* >>>> + * List of device names that elan_i2c is handling and HID should ignore. Must >>>> + * be kept in sync with elan_i2c >>>> + */ >>>> +static const char *hid_elan_i2c_ignore[] = { >>> >>> If this is a copy of elan whitelist, then, if we do not want to bother >>> with sharing it in object form (as a elan-i2c-ids module), can we at >>> least move it into include/linux/input/elan-i2c-ids.h and consume from >>> hid-quirks.c? >> >> I can put it in a shared header file, however elan-i2c and hid-quirks >> would need to be updated in the same change to prevent a breakage, but >> that would seem to violate a concern Benjamin brought up in v4 given >> that elan-i2c is maintained in your input tree, and hid-quirks is >> maintained in his hid tree. >> >> Are you ok with the elan-i2c changes going through Benjamin's hid tree? > > We co-ordinate cross-subsystem merges all the time. That is never a > reason to not do the 'right thing (tm)'. If this information can be > held in a single, central place, without the need for constant > re-alignment, I'm all for it. > I'm aware coordination is a thing. I'm trying to elicit some coordination between Dmitry and Benjamin.