Received: by 2002:ab2:7903:0:b0:1fb:b500:807b with SMTP id a3csp460061lqj; Sun, 2 Jun 2024 06:35:08 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVGenMI8yQWPGnmcS13QoQuTNyvesZFFC2Xu60LHGS9/vg2agBCHFBJirZZ3WoIaQf6znwXqZabm1gu1AJVM8fzUfEG4HcVkvbzWqRCYg== X-Google-Smtp-Source: AGHT+IE7dnbW/XiMxyB6//Numq0z+wIGXdhkxK6YtYCavVqhArkFPfjGSTqetnFGY0QQEXy2bF8S X-Received: by 2002:a05:6214:4a09:b0:6af:4924:2965 with SMTP id 6a1803df08f44-6af49242ae9mr36030936d6.18.1717335308603; Sun, 02 Jun 2024 06:35:08 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717335308; cv=pass; d=google.com; s=arc-20160816; b=Ablk0UUcJeFHMT+0SQPTaBXZHQmTqdmtJm86eGVQn5n0DP6mH9VN7FxvwHd3/GNEb4 7tp8/07BoIEqFRXXDvyaX8sD69NXOn0cqWJcKCULsr+KQgVH4p6JgdIeh95X2fuvBAEs wWd347wbUAXmg1qgqTm0+FvTbC1VR6mmqhGmhOONFtkGPsV/6AaZnhi4w5vNIWedeIgi E4hub5IHAKF+lQjyyKN5qb4eI8Dhiaz1DbM8/LjTz8NBZrVRxIiP2Oijq3cS1eTP0V2P hzY8U+/FXW1nXxUcHIP48c9CoR35rQ2g+qWa64UlMM7pDScI8IAzsENU1VaIW8hHpwgZ Q2bg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=D8hjHfkBSM1PHvoSP3XBJdjBG5KlM5ruucIeYrBdf2g=; fh=LHOIUCpLfQj+0LFHySmisXS74rADgnQaFQTLhab3TyI=; b=A1iwIu0cc2eWe92xR/exN0Izti9EaDcCTUl218A+8AIFERiZlEDghmF9Rt+JwULAo4 W2z74T+c2bkItqC0hiv0fgd9sCp5Lu1ty6kHmbOnhmTVqESiiy5c6HWfov5mAW++2lNP Gzqm1p2XDfNLlY+f6Gvs330E0y71zwWzWJHqEvjd5BnQ12RzQLkN92j22mlxzlWjjmUv e1FiCWftcaALUCApB0YN9Wc7WR73QuicCDhQTv4YnWuKU9ILDyt2sHWaU/3HEZ4/qrPe 6fR+a9oRcNoi9dyRtnudbpORbP4uojTL6/pAeL7nqbaE0CCMsUm0XI/w7piCm9afFb1X C5Pw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kRdn+J97; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-198263-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-198263-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id 6a1803df08f44-6ae4b4148d8si62453096d6.344.2024.06.02.06.35.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jun 2024 06:35:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-198263-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kRdn+J97; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-198263-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-198263-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4862E1C20DF7 for ; Sun, 2 Jun 2024 13:35:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 897323FB01; Sun, 2 Jun 2024 13:35:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kRdn+J97" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C2E11173F; Sun, 2 Jun 2024 13:35:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717335300; cv=none; b=rC6PrURBjDciUfzZkIZaUhe6Tn18tXknFytcKzR2ThH4qeOg1+PhIjvO/163tciqTdchmtXclmDqjvYZTfsI3nBkiXviZoq9nKmu0lBmVW4COaEx11YzZHhLyUePEbzAOSJEoVw4hYPxAA+mw6m/IQ6jYgK73CTGbciIGJmK1lE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717335300; c=relaxed/simple; bh=fGo0CkAMVlwKZk/3VQRHsXRBENz0lBseVBEwFCY/wg0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ipr9LqFTxXeAFAlL2czUTReBcvCQpCYsMW3GtBAL+B5W8QBvan5rWt+VyVxZkWgKtI8fpWAPCuztR/EJ/x24LKc9ruQL2e0xfkaZmBUm1I53dKL7hFiWAI2GbiZTYifEWATxXKYYM8zQrBojkIvOX1xUyTzBNniGgXFUcuTo58U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kRdn+J97; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD1B8C2BBFC; Sun, 2 Jun 2024 13:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717335300; bh=fGo0CkAMVlwKZk/3VQRHsXRBENz0lBseVBEwFCY/wg0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kRdn+J97mVKvljg+4exXX0lmX9OKbJ4xFvbyIK8mYZsD/gsvRE5jmicKWU1Z0CxVd ukpyfUVReVBF3ubjghbtFdhm/ITvs3pXYBRJIS+z5UnXi1uQhK3aedWF2KMDdLUeXV FQreJfdtXtU2PoR4nnKDzgsdhEF0UK5uSgAGEoo1TytPioVXs0ObQKvxf/+OzcHE7U KTie0TTsdZoSxeJgJ6ig0ECUUbjslcRkV5nzzr/k+BisCfay2U/lfWe/IzfLitybRR sbJpjkhz333WTZd5HMYkOUuhonbNhuwogPPxow0vlA/i2bGo11jo9WstUDAtog5vXn PJjS777xFoOhg== Date: Sun, 2 Jun 2024 14:34:49 +0100 From: Jonathan Cameron To: Yasin Lee Cc: andy.shevchenko@gmail.com, lars@metafoo.de, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, nuno.a@analog.com, swboyd@chromium.org, u.kleine-koenig@pengutronix.de, yasin.lee.x@gmail.com Subject: Re: [PATCH v3 1/2] dt-bindings:iio:proximity: Add hx9023s binding Message-ID: <20240602143449.44491d98@jic23-huawei> In-Reply-To: References: <20240519162438.17af0ff8@jic23-huawei> <20240529045749.530039-1-yasin.lee.x@outlook.com> X-Mailer: Claws Mail 4.2.0 (GTK 3.24.42; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 29 May 2024 12:57:48 +0800 Yasin Lee wrote: > From: Yasin Lee >=20 > A capacitive proximity sensor >=20 > Signed-off-by: Yasin Lee Hi Yasin, Some comments inline. A lot of what you have here sounds like it should be under userspace control, not in the dt-binding. Also, look at how we handled optional channels for ADCs and copy that approach here. Jonathan > --- > .../bindings/iio/proximity/tyhx,hx9023s.yaml | 106 ++++++++++++++++++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > 2 files changed, 108 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/proximity/tyhx,= hx9023s.yaml >=20 > diff --git a/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s= .yaml b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml > new file mode 100644 > index 000000000000..ba4d7343bb30 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/proximity/tyhx,hx9023s.yaml > @@ -0,0 +1,106 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/iio/proximity/tyhx,hx9023s.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: TYHX HX9023S capacitive proximity sensor > + > +maintainers: > + - Yasin Lee > + > +description: | > + TYHX HX9023S proximity sensor > + > +allOf: > + - $ref: /schemas/iio/iio.yaml# > + > +properties: > + compatible: > + const: tyhx,hx9023s > + > + reg: > + maxItems: 1 > + > + interrupts: > + description: | > + Generated by device to announce preceding read request has finished > + and data is available or that a close/far proximity event has happ= ened. > + maxItems: 1 > + > + vdd-supply: > + description: Main power supply vdd-supply: true is enough. vdd is pretty much always used for the main power supply so the docs are are redundant. > + > + accuracy: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Accuracy level of the sensor No idea what this means! > + > + channel-used-flag: > + description: Bit flag indicating which channels are used > + $ref: /schemas/types.yaml#/definitions/uint32 As below - subnodes not a bunch of arrays. If the subnode is there it should be used. > + > + odr: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Set ODR for all channenls. I assume output data rate? That's something for userspace not the DT bindi= ng. > + > + integration-sample: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Set Integration number and Sample number for each chann= enl. Ok. This one might possibly be hardware related as it depends on the wiring and physical elements of the board. If so give a good description on how this should be set. > + > + osr: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: Set number of OSR for each channenl. Expand the acronym. This sounds like oversampling ratio which would be odd to see alongside an average control. Hence more detail needed and consider if it should be controlled by the dt binding. > + > + avg: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: Set number of AVG for each channenl. This sounds like oversampling? If so that is normally a userspace problem not a binding thing. Is it related to the physical wiring? If not don't put it in the binding. > + > + lp-alpha: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: Set lp-alpha for each channenl. Spell check. Also this needs more description. > + > + cs-position: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: | > + Position of the CS pins. > + Indicates the corresponding bit for each CS pin in the register. I've no idea what this. Add more description. Normally CS is chip select and there is only one of those. Also this not general dt binding material so vendor prefix this stuff. > + > + channel-positive: Use per channel nodes. There are examples in for example adc/adc.yaml on how to do this. Not having a child node is a lot easier to follow than magic values to say something isn't there. =46rom what is here these look like differential channels. Use the adc style binding for that. > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: Positive channel assignments. Use 255 for not connected > + > + channel-negative: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + description: | > + Negative channel assignments. Use 255 for not connected > + > +required: > + - compatible > + - reg > + > +unevaluatedProperties: false > + > +examples: > + - | > + #include > + i2c { > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + hx9023s@2a { As was pointed out in earlier patch review - generic node names only. > + compatible =3D "tyhx,hx9023s"; > + reg =3D <0x2a>; > + interrupt-parent =3D <&pio>; > + interrupts =3D <16 IRQ_TYPE_EDGE_FALLING>; > + vdd-supply =3D <&pp1800_prox>; > + accuracy =3D <16>; > + channel-used-flag =3D <0x1F>; > + odr =3D <0x17>; > + integration-sample =3D <0x0065>; > + osr =3D <0x4 0x4 0x4 0x0 0x0>; > + avg =3D <0x3 0x3 0x3 0x0 0x0>; > + lp-alpha =3D <0x8 0x8 0x8 0x8 0x2>; > + cs-position =3D <0 2 4 6 8>; > + channel-positive =3D <0 1 2 3 4>; > + channel-negative =3D <255 255 255 255 255>; > + }; > + }; > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Doc= umentation/devicetree/bindings/vendor-prefixes.yaml > index b97d298b3eb6..e2224eea9ab9 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1507,6 +1507,8 @@ patternProperties: > description: Turing Machines, Inc. > "^tyan,.*": > description: Tyan Computer Corporation > + "^tyhx,.*": > + description: NanjingTianyihexin Electronics Ltd. Convention is separate patch for vendor prefix editions. Makes it easier for people to cherrypick them for a different device driver binding. > "^u-blox,.*": > description: u-blox > "^u-boot,.*":