From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E903C64E8A for ; Wed, 2 Dec 2020 06:02:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BFC982223C for ; Wed, 2 Dec 2020 06:01:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726935AbgLBGBn (ORCPT ); Wed, 2 Dec 2020 01:01:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726160AbgLBGBn (ORCPT ); Wed, 2 Dec 2020 01:01:43 -0500 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52444C0613CF; Tue, 1 Dec 2020 22:01:03 -0800 (PST) Received: by mail-pj1-x1043.google.com with SMTP id ms7so395987pjb.4; Tue, 01 Dec 2020 22:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5N4lOAXBNBhx3a8OTOO+5gPk9whELt81SdkaMwKcQTU=; b=NzgFMktUqUEhsV8C8vYWcX94cgYZfGD+Xx6dy6afmEfv1Deu5KTE1c5Aoyc2n+Iy/N sNdfaJRP6z5ojOVcLVIN5fN19yOj+YwDtFHEilXkzpTd+wLYH7TqJ0EjyDFkXptaNDN3 AfUAIUjWU34vOE+Z3mqGWioHHhLxUWJFeMkTDsv1gWZh1G9vMZjM3bcHAVUm+xssMcc8 ecgaScP66i5AyrCF4ZKpw89VgvjesDYDzS5e/KB1/RWNEzBt7KRcNQRgxfXkVfT9e00Q aytzZQ+kuFVmHBSl0N8tdcq4+tDDzx4Wq5+n9NT7N0M9AXbLsCFVYaFfxPyNYDX3A+01 ydkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5N4lOAXBNBhx3a8OTOO+5gPk9whELt81SdkaMwKcQTU=; b=EW0hC2OOuNbj3jL6vVrtmpPNZCOSued7QGOQWXS4cYbusOIesNQyGza2F+hMf7ireR ZjXPlk2fF6cKUfzFaAXTahI1eRBajY74vslIxV76z3HabrDRySoUTkbyQdf0CpREE9kg 1PrjscTW6ma383pE0rGFkCUQ1mvGqTGh1i2BIOWpl5xhk41T7KUWOuyWL2ZPzwZRxpZO M8qpZ6hpBLgntJJhyiNvsm55Dg/zbaK/tEJpZUmVOHzbTcnTXjQ0tC2kH2vwOk46Hl/L KDhcnctG8OUsfHHWsJWXFn4VaLO+tvfnbDdpbRXYHaOohjnFm5eLMcy0Elw9kOBhmyHV nNuw== X-Gm-Message-State: AOAM530UdQ+dCl7PXDwlsx2msR7q7F8BGaza3rOeGSukMwmRNfq1Prs/ s1YpCANWymJCuZnle385jNE= X-Google-Smtp-Source: ABdhPJzsVAuDuG0361021/T0y+UCltxIEW9TAyZxjAO2YYSOMzQwCM29eE/w/1zc5gs0DNHRbGy4QQ== X-Received: by 2002:a17:90a:fa0c:: with SMTP id cm12mr893847pjb.87.1606888862767; Tue, 01 Dec 2020 22:01:02 -0800 (PST) Received: from dtor-ws ([2620:15c:202:201:a6ae:11ff:fe11:fcc3]) by smtp.gmail.com with ESMTPSA id u7sm765715pfh.115.2020.12.01.22.01.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Dec 2020 22:01:02 -0800 (PST) Date: Tue, 1 Dec 2020 22:00:59 -0800 From: Dmitry Torokhov To: Jeff LaBundy Cc: robh+dt@kernel.org, linux-input@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 2/2] input: Add support for Azoteq IQS626A Message-ID: <20201202060059.GZ2034289@dtor-ws> References: <1606084748-4097-1-git-send-email-jeff@labundy.com> <1606084748-4097-3-git-send-email-jeff@labundy.com> <20201123070307.GE2034289@dtor-ws> <20201124001516.GA6249@labundy.com> <20201201070106.GS2034289@dtor-ws> <20201202055350.GA2709@labundy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201202055350.GA2709@labundy.com> Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org Hi Jeff, On Tue, Dec 01, 2020 at 11:53:50PM -0600, Jeff LaBundy wrote: > Hi Dmitry, > > On Mon, Nov 30, 2020 at 11:01:06PM -0800, Dmitry Torokhov wrote: > > On Mon, Nov 23, 2020 at 06:15:16PM -0600, Jeff LaBundy wrote: > > > Hi Dmitry, > > > > > > Thank you for taking a look. > > > > > > On Sun, Nov 22, 2020 at 11:03:07PM -0800, Dmitry Torokhov wrote: > > > > Hi Jeff, > > > > > > > > On Sun, Nov 22, 2020 at 04:39:08PM -0600, Jeff LaBundy wrote: > > > > > + > > > > > + if ((sys_reg->active & tp_mask) == tp_mask) > > > > > + input_set_abs_params(iqs626->trackpad, > > > > > + ABS_X, 0, 255, 0, 0); > > > > > + else > > > > > + input_set_abs_params(iqs626->trackpad, > > > > > + ABS_X, 0, 128, 0, 0); > > > > > +#ifdef CONFIG_TOUCHSCREEN_PROPERTIES > > > > > + touchscreen_parse_properties(iqs626->trackpad, false, > > > > > + &iqs626->prop); > > > > > +#endif /* CONFIG_TOUCHSCREEN_PROPERTIES */ > > > > > > > > This should not be separately selectable from CONFIG_INPUT, so there is > > > > not need to have this guard. > > > > > > > > The reason it is a separate symbol is historical - it used to depend on > > > > OF in addition to INPUT. I suppose I can drop it now. > > > > > > Without these guards, the build fails if CONFIG_INPUT_TOUCHSCREEN=n and > > > I felt it too heavy-handed to add a 'depends on' for what is ultimately > > > a corner-case of sorts for this device. > > > > Ah, I missed the fat that we got outside of the > > drivers/input/toucscreen. > > > > > > > > The touchscreen helpers are useful for more than just touchscreens, and > > > we can extend them to all of input with something like the patch below. > > > If it looks OK to you, I can insert it into v2 after I collect feedback > > > from Rob for the binding. > > > > Yes, I guess we should move into core. Can you move the file into > > drivers/input and maybe we should rename it into touch-properties.c? And > > start renaming the API form touchscreen_*() to touch_()? > > Sure thing, I can move it. I guess we want to do the same for the binding > too? There are only a handful of other bindings that will need references > to touchscreen.yaml updated with a new relative path. > > I'm hesitant to rename the API because we still need to support bindings > that start with touchscreen-* and having an API with different namespace > seems inconsistent.i I was thinking about allowing both "touch-" and "touchscreen-" for the allowed property names. > How about I volunteer the following for this series: > > 1. Move of_touchscreen.c to drivers/input, and rename it to touchscreen.c > since it is not actually related to OF at this point. This would match > the header file too. That is fine, we can rename the file later if we decide to change the namespace. > 2. Update its introductory comments from: > "Generic DT helper functions for touchscreen devices" > to: > "Generic helper functions for touchscreens and other two-dimensional > pointing devices" > 3. Move touchscreen.* from bindings/input/touchscreen to bindings/input, > and update the handful of touchscreen bindings that assume a relative > path to touchscreen.yaml. > > Let me know if this seems like a reasonable compromise. Yep, that sounds great, thank you. -- Dmitry