Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C876C54E94 for ; Thu, 26 Jan 2023 03:10:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235623AbjAZDKt (ORCPT ); Wed, 25 Jan 2023 22:10:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229537AbjAZDKr (ORCPT ); Wed, 25 Jan 2023 22:10:47 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E5CA64D88; Wed, 25 Jan 2023 19:10:46 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 227C0616D6; Thu, 26 Jan 2023 03:10:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89B8FC4339B; Thu, 26 Jan 2023 03:10:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674702645; bh=gGU2qpf4E6IYabatWz+DP3c6588TlcC/e2M83ROhCic=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MsOPlr9Rb/H/5VmKtdtdlTkUTSOQofVg6vPe8Y7Tf6Go15vD4p+eybE5/mjkeGNBz O3HdHHi8nXLi2hDlqfBTvnAAckGGENGcxW/L0tEsfhcfJ1gVSrlTn5fAwZi886xlrt 82LY89HJDSDImVzsnaLIBPUcGfbVFAtE8h7hrVkncPNSuVJzP69s9g13knj1c9e0RY SN+dXlkoivUqq/No6iv2IJsUzj1LRqRlpNtO6gTlcdrO7axvejybEke5bMdoUUxNyi KW25SMXuj7bHL3ttVwYXXAMsfDms3fBSMs5/5YOq+kAlYJWupWUaMGw1X1hp9pKmst ZbMNMALKiJNJA== Received: by mail-ua1-f42.google.com with SMTP id b11so93122uae.4; Wed, 25 Jan 2023 19:10:45 -0800 (PST) X-Gm-Message-State: AFqh2koLoFPLTzcB68O+tnq5AhTIzLs9GDx+kcjRzST/6TgPhCQYxL+X ynsXPEMuq84HL02BJYJJ+wW5K58AR6myPdnYpw== X-Google-Smtp-Source: AMrXdXsrbCxPJ7pRSKrwmGEY3aP3Gqd9JPRr21bno+D9U9+C5qfGQguRknCJYb8IskL9zBCz+i0/4LxufKgAw4323Ak= X-Received: by 2002:ab0:e03:0:b0:617:ca9e:e9fd with SMTP id g3-20020ab00e03000000b00617ca9ee9fdmr3139356uak.54.1674702644462; Wed, 25 Jan 2023 19:10:44 -0800 (PST) MIME-Version: 1.0 References: <20230125221416.3058051-1-robh@kernel.org> In-Reply-To: From: Rob Herring Date: Wed, 25 Jan 2023 21:10:33 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] dt-bindings: input: azoteq: Fix differing types To: Jeff LaBundy Cc: Dmitry Torokhov , Krzysztof Kozlowski , linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 25, 2023 at 7:51 PM Jeff LaBundy wrote: > > Hi Rob, > > On Wed, Jan 25, 2023 at 04:14:16PM -0600, Rob Herring wrote: > > 'azoteq,ati-base' and 'azoteq,thresh' properties are defined in multiple > > bindings, but have differing types defined. Both 'uint32' and > > 'uint32-array' are used. Unify these to use 'uint32-array' everywhere. > > > > Signed-off-by: Rob Herring > > Thank you for the patch. While this is a step forward in moving toward > a common binding for this vendor like we have discussed in the past, I > do not agree with this approach and will instead propose an alternative > that accomplishes the same goal. > > For all of these devices, a single sensing channel takes a base and a > threshold property. IQS626A is unique in that a fixed number of channels > form a trackpad, and I decided at the time to simply define the base and > target properties for all channels as a uint32-array. > > For all other existing drivers, as well as others coming down the pipe, > base and threshold are uint32s. I find it confusing to redefine all of > those as single-element arrays, especially on account of one device. > > In hindsight, a better design would have been to define a child node > for each channel under the trackpad node, with each child node accepting > a uint32 base and threshold. That would follow other devices, be more > representative of the actual hardware, and keep the definitions the same > across each binding. > > So, that's what I propose to do here instead. I happen to have a fix in > review [1] that addresses a bug related to this parsing code, and would > be happy to build this solution on top assuming it can wait until the > next cycle. Does this compromise sound OK? Shrug How exactly are you going to change an existing property and not break existing users? Or are there not any users? We have the same properties with 2 definitions. At the end of the day, I just want to fix that... Rob