Message ID | 20240126115509.1459425-1-naresh.solanki@9elements.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-40074-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:e09d:b0:103:945f:af90 with SMTP id gm29csp621649dyb; Fri, 26 Jan 2024 04:25:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IHBkfvXcxIZ3bHe/qgOV6FVMYyCdeTJQn864Xq/ey1cIl0X4S0MDoLsf+2rI3P7AVImmzJm X-Received: by 2002:a05:6358:531f:b0:176:5615:3ddd with SMTP id n31-20020a056358531f00b0017656153dddmr1809750rwf.2.1706271956663; Fri, 26 Jan 2024 04:25:56 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706271956; cv=pass; d=google.com; s=arc-20160816; b=JwSt+EE27P1InmuFNGYzJ13qc+JhS+7Px9gztdTOCQzf+9rF5+yNEfXUrdilBUt6+o 1ehKI/Vt+84uNM/dT4UmL5cjszGFMqEKcs/r+H4NNq/P5UfXeSVdalF7qZK259JsFAv4 BRkYzpO1Sydw4srCn+fkpCOvXLT9cefnfDKJ/nbuUpDKhIcWIkfVsr2571nrtCNzmlS+ UY4SPucyEw6EXdfrYdybRffA8JxA9+UFoBowgFUDPwFYocKu9WYXIxggP1KgNjpBy64J prPJzHEPo9oIBQA7k/GgP9ppxZk6AXbBn+5EnftJ+wOj5foTJzHg38WaWuYBhVUNh+XE Zo5g== 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:message-id:date:subject:cc:to :from:dkim-signature; bh=5YD1avWXiDmKVPhJNDv4Z+Ew3Vz4aGu7X+vQARwJOeU=; fh=3x6H/92LjvDgbYWFNyAben6MbAnkfYYwSK3I30qj9qg=; b=LcyV5/Us1M+nPygWtIAr63SMvNyPJdN+ardHwemrCPryCfy125JXt9TIYGQ0Im6tvP TTsDLjwrvCtNxhnTG4nx1jdRv0x9L+sWTZm/vxwAcGg8ZM8F3StVLBn2cT2ND6OuCsml mc70TCd9w+JG00USw3LT+fo87TUNQ0x4eOmFzYoggRri4yLrIop5hVFN2bWNYspB+bAi f6unSAFKY8DTco99KFEiZFFJ2f+IedLdzHptwuSysyXqtkAApPFpDvFxr9gp99fa6hAN zZIp8mXxpf3xVbakyUknGoGy0YqkqvUp/Yk+fjCQcygnc068llFDgUlUxt73bUd4+wCW SfkA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@9elements.com header.s=google header.b=bEHO79tw; arc=pass (i=1 spf=pass spfdomain=9elements.com dkim=pass dkdomain=9elements.com dmarc=pass fromdomain=9elements.com); spf=pass (google.com: domain of linux-kernel+bounces-40074-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-40074-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=9elements.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id ig14-20020a17090b154e00b00290f94a9fbdsi1102072pjb.10.2024.01.26.04.25.56 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 04:25:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-40074-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@9elements.com header.s=google header.b=bEHO79tw; arc=pass (i=1 spf=pass spfdomain=9elements.com dkim=pass dkdomain=9elements.com dmarc=pass fromdomain=9elements.com); spf=pass (google.com: domain of linux-kernel+bounces-40074-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-40074-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=9elements.com 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 sy.mirrors.kernel.org (Postfix) with ESMTPS id ED4FDB2B72B for <ouuuleilei@gmail.com>; Fri, 26 Jan 2024 11:55:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0598D1B5B2; Fri, 26 Jan 2024 11:55:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=9elements.com header.i=@9elements.com header.b="bEHO79tw" Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FAD61AAAE for <linux-kernel@vger.kernel.org>; Fri, 26 Jan 2024 11:55:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706270121; cv=none; b=r//oKAd9ARNlmf0d1T7bUhaCo0QijT0r5v/hgG7MjQVPiHA4SnD6HIjUIvt6C/xxQ+cgDrgJNlordfaiaWg0Op9+uP9MHZ8bvqBdj+BfbZ32b7uQ8FrmVGIxvesMocARANTgXQ7TmRWYrIUNiXAJsGeKKpE2uljNJIb8xQp918k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706270121; c=relaxed/simple; bh=KvDW3oimirzaLZ+3LyQ7tjVmuNkF2WsoEwGt2Ec9I+U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NMKqlAPT93k0K2oQNA6hR8uQNH1mpxHMR9h0KGGEMQn1I8m/r+qsWnGwgW+MTT22TGs9lzFx0E82+yFJrGrHhvQwT6z1PrzGSp+aZjrZE4+wYKlem8Lb+UlO+CRO4MO2v5DCukxBWI1OPFGNvQMpNA88eq330LfNX9btFGfaXHs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=9elements.com; spf=pass smtp.mailfrom=9elements.com; dkim=pass (2048-bit key) header.d=9elements.com header.i=@9elements.com header.b=bEHO79tw; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=9elements.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=9elements.com Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-40ed252edd7so10731955e9.0 for <linux-kernel@vger.kernel.org>; Fri, 26 Jan 2024 03:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9elements.com; s=google; t=1706270118; x=1706874918; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5YD1avWXiDmKVPhJNDv4Z+Ew3Vz4aGu7X+vQARwJOeU=; b=bEHO79tw3TzVQ2l67Em3pJ1i2WQahpxukP6KAly1UgAx260fqefLl3M98Da/7ioDNF XWKoB1dzLEVQX8XhRR5Y1ynSUPBqF0+v0ONgwFhf5e1mrEQfFRRSkcjiKxCyacQ0DsS5 PrYP5/pnX2ElLzFAruz0byazQKEU29EEM9PlNDPGTkf+g1zhUlrfiOtR0jVeDZLDyyOW eHLNSNikLwUS2qLA9SflP7LcPdoDTqB4gL4jvLB2CAUwC6yyzZUP8rYR3jNNSmebcC1j ZOlCGl9OO+199o2VGsLo0F/6X1ktu5HxJpeME+CPpZJsXIhFAiYzu62Coln5Az+pxbQi uSzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706270118; x=1706874918; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5YD1avWXiDmKVPhJNDv4Z+Ew3Vz4aGu7X+vQARwJOeU=; b=PuSL56VHhQlg0eeSKJEtaEY7nNVIRoPGDp5sZdgFeuCq9Ldlomzv4qAQpo3YpEKj1L mWlEuX1pRm7RcHUJdHmKSvp5zBGP8fmu6CEon3qeoCKEz4oPoNO5Rjy0MkOq7eL5PTCR fQG7TzmQI4Ru7lSkY1+hJ8fjk2nVujsN7KSGOfVZxHwEYp9aQPCckNhJl6i6YQw9P5Ox BBGszYHnKiytSpXk4/go9LlwWUm/BKJHG1Rtew+RmIkL9t7BfR0YpsgGbVS1wb5UTOfU I0IbG36heS2I8g8pXs+CCq7CUOKcqjD0LE6UtjxpNLVbxKfkFXbMz6EGPChidkXIAFc2 SRiA== X-Gm-Message-State: AOJu0Yzd6s5z+1Meo0e/f/i2wrpbmEGYHLLENZCl4JwCfgJnjCgB0UyX UrCke5QjawL6H8o+vcujhHZwCbo/HTgqvsW3YcG+WWXLCirBcW5njSo3x7puZaM= X-Received: by 2002:a05:600c:3548:b0:40e:d5c7:8355 with SMTP id i8-20020a05600c354800b0040ed5c78355mr466668wmq.131.1706270117801; Fri, 26 Jan 2024 03:55:17 -0800 (PST) Received: from stroh80.sec.9e.network (ip-078-094-000-051.um19.pools.vodafone-ip.de. [78.94.0.51]) by smtp.gmail.com with ESMTPSA id f11-20020a05600c154b00b0040ed434ef66sm3387424wmg.25.2024.01.26.03.55.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 03:55:17 -0800 (PST) From: Naresh Solanki <naresh.solanki@9elements.com> To: Peter Rosin <peda@axentia.se>, Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> Cc: mazziesaccount@gmail.com, Naresh Solanki <naresh.solanki@9elements.com>, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] dt-bindings: iio: afe: voltage-divider: Add io-channel-cells Date: Fri, 26 Jan 2024 17:25:08 +0530 Message-ID: <20240126115509.1459425-1-naresh.solanki@9elements.com> X-Mailer: git-send-email 2.42.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789155823248786619 X-GMAIL-MSGID: 1789155823248786619 |
Series |
dt-bindings: iio: afe: voltage-divider: Add io-channel-cells
|
|
Commit Message
Naresh Solanki
Jan. 26, 2024, 11:55 a.m. UTC
Add #io-channel-cells expected by driver. i.e., below is the message
seen in kernel log:
OF: /iio-hwmon: could not get #io-channel-cells for /voltage_divider1
TEST=Run below command & make sure there is no error:
make DT_CHECKER_FLAGS=-m dt_binding_check -j1
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
---
Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++
1 file changed, 3 insertions(+)
base-commit: ecb1b8288dc7ccbdcb3b9df005fa1c0e0c0388a7
Comments
Hey, On Fri, Jan 26, 2024 at 05:25:08PM +0530, Naresh Solanki wrote: > Add #io-channel-cells expected by driver. i.e., below is the message > seen in kernel log: > OF: /iio-hwmon: could not get #io-channel-cells for /voltage_divider1 > > TEST=Run below command & make sure there is no error: > make DT_CHECKER_FLAGS=-m dt_binding_check -j1 This shouldn't be in the commit message. > > Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> > --- > Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > index dddf97b50549..b4b5489ad98e 100644 > --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > @@ -39,6 +39,9 @@ properties: > description: | > Channel node of a voltage io-channel. > > + '#io-channel-cells': > + const: 1 The example in this binding looks like the voltage-divider is intended to be an "IIO consumer" but "#io-channels-cells" is an "IIO provider" property. Are you sure this is correct? > + > output-ohms: > description: > Resistance Rout over which the output voltage is measured. See full-ohms. > > base-commit: ecb1b8288dc7ccbdcb3b9df005fa1c0e0c0388a7 > -- > 2.42.0 >
Hi, On Fri, 26 Jan 2024 at 21:47, Conor Dooley <conor@kernel.org> wrote: > > Hey, > > On Fri, Jan 26, 2024 at 05:25:08PM +0530, Naresh Solanki wrote: > > Add #io-channel-cells expected by driver. i.e., below is the message > > seen in kernel log: > > OF: /iio-hwmon: could not get #io-channel-cells for /voltage_divider1 > > > > > TEST=Run below command & make sure there is no error: > > make DT_CHECKER_FLAGS=-m dt_binding_check -j1 > > This shouldn't be in the commit message. ok Will remove. > > > > > Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> > > --- > > Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > index dddf97b50549..b4b5489ad98e 100644 > > --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > @@ -39,6 +39,9 @@ properties: > > description: | > > Channel node of a voltage io-channel. > > > > + '#io-channel-cells': > > + const: 1 > > The example in this binding looks like the voltage-divider is intended > to be an "IIO consumer" but "#io-channels-cells" is an "IIO provider" > property. > > Are you sure this is correct? I'm not aware that #io-channels-cells is only for IIO provider. But I do get some kernel message as mention in commit messages if this is specified in DT. Regards, Naresh > > > + > > output-ohms: > > description: > > Resistance Rout over which the output voltage is measured. See full-ohms. > > > > base-commit: ecb1b8288dc7ccbdcb3b9df005fa1c0e0c0388a7 > > -- > > 2.42.0 > >
On Fri, Jan 26, 2024 at 09:55:20PM +0530, Naresh Solanki wrote: > On Fri, 26 Jan 2024 at 21:47, Conor Dooley <conor@kernel.org> wrote: > > On Fri, Jan 26, 2024 at 05:25:08PM +0530, Naresh Solanki wrote: > > > Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> > > > --- > > > Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > index dddf97b50549..b4b5489ad98e 100644 > > > --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > @@ -39,6 +39,9 @@ properties: > > > description: | > > > Channel node of a voltage io-channel. > > > > > > + '#io-channel-cells': > > > + const: 1 > > > > The example in this binding looks like the voltage-divider is intended > > to be an "IIO consumer" but "#io-channels-cells" is an "IIO provider" > > property. > > > > Are you sure this is correct? > I'm not aware that #io-channels-cells is only for IIO provider. #foo-cells properties are always for resource providers > But I do get some kernel message as mention in commit messages > if this is specified in DT. Can you please share the DT in question? Or at least, the section that describes the IIO provider and consumer? It should look like the example: spi { #address-cells = <1>; #size-cells = <0>; adc@0 { compatible = "maxim,max1027"; reg = <0>; #io-channel-cells = <1>; interrupt-parent = <&gpio5>; interrupts = <15 IRQ_TYPE_EDGE_RISING>; spi-max-frequency = <1000000>; }; }; sysv { compatible = "voltage-divider"; io-channels = <&maxadc 1>; /* Scale the system voltage by 22/222 to fit the ADC range. */ output-ohms = <22>; full-ohms = <222>; /* 200 + 22 */ }; Thanks, Conor.
Hi Conor, On Fri, 26 Jan 2024 at 22:22, Conor Dooley <conor@kernel.org> wrote: > > On Fri, Jan 26, 2024 at 09:55:20PM +0530, Naresh Solanki wrote: > > On Fri, 26 Jan 2024 at 21:47, Conor Dooley <conor@kernel.org> wrote: > > > On Fri, Jan 26, 2024 at 05:25:08PM +0530, Naresh Solanki wrote: > > > > Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> > > > > --- > > > > Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > > index dddf97b50549..b4b5489ad98e 100644 > > > > --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > > +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > > @@ -39,6 +39,9 @@ properties: > > > > description: | > > > > Channel node of a voltage io-channel. > > > > > > > > + '#io-channel-cells': > > > > + const: 1 > > > > > > The example in this binding looks like the voltage-divider is intended > > > to be an "IIO consumer" but "#io-channels-cells" is an "IIO provider" > > > property. > > > > > > Are you sure this is correct? > > I'm not aware that #io-channels-cells is only for IIO provider. > > #foo-cells properties are always for resource providers > > > But I do get some kernel message as mention in commit messages > > if this is specified in DT. > > Can you please share the DT in question? Or at least, the section that > describes the IIO provider and consumer? Below is link to complete DT: https://github.com/torvalds/linux/commit/522bf7f2d6b085f69d4538535bfc1eb965632f54 > > It should look like the example: I reference the below example previously but didn't help. If io-channel-cell isn't provided then there is print in kernel dmesg as: OF: /iio-hwmon: could not get #io-channel-cells for /voltage_divider1 Thanks, Naresh > > spi { > #address-cells = <1>; > #size-cells = <0>; > adc@0 { > compatible = "maxim,max1027"; > reg = <0>; > #io-channel-cells = <1>; > interrupt-parent = <&gpio5>; > interrupts = <15 IRQ_TYPE_EDGE_RISING>; > spi-max-frequency = <1000000>; > }; > }; > > sysv { > compatible = "voltage-divider"; > io-channels = <&maxadc 1>; > > /* Scale the system voltage by 22/222 to fit the ADC range. */ > output-ohms = <22>; > full-ohms = <222>; /* 200 + 22 */ > }; > > Thanks, > Conor.
On Fri, Jan 26, 2024 at 11:10:36PM +0530, Naresh Solanki wrote: > Hi Conor, > > > On Fri, 26 Jan 2024 at 22:22, Conor Dooley <conor@kernel.org> wrote: > > > > On Fri, Jan 26, 2024 at 09:55:20PM +0530, Naresh Solanki wrote: > > > On Fri, 26 Jan 2024 at 21:47, Conor Dooley <conor@kernel.org> wrote: > > > > On Fri, Jan 26, 2024 at 05:25:08PM +0530, Naresh Solanki wrote: > > > > > Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> > > > > > --- > > > > > Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > > > index dddf97b50549..b4b5489ad98e 100644 > > > > > --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > > > +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml > > > > > @@ -39,6 +39,9 @@ properties: > > > > > description: | > > > > > Channel node of a voltage io-channel. > > > > > > > > > > + '#io-channel-cells': > > > > > + const: 1 > > > > > > > > The example in this binding looks like the voltage-divider is intended > > > > to be an "IIO consumer" but "#io-channels-cells" is an "IIO provider" > > > > property. > > > > > > > > Are you sure this is correct? > > > I'm not aware that #io-channels-cells is only for IIO provider. > > > > #foo-cells properties are always for resource providers > > > > > But I do get some kernel message as mention in commit messages > > > if this is specified in DT. > > > > Can you please share the DT in question? Or at least, the section that > > describes the IIO provider and consumer? > Below is link to complete DT: > https://github.com/torvalds/linux/commit/522bf7f2d6b085f69d4538535bfc1eb965632f54 If you're gonna link something that is in a vendor tree, you should link the actual vendor tree and not something that "does not belong to any branch on this repository, and may belong to a fork outside of the repository"! I did look at what you have there and I think your dts is wrong. The iio-hwmon binding says: | description: > | Bindings for hardware monitoring devices connected to ADC controllers | supporting the Industrial I/O bindings. | | io-channels: | minItems: 1 | maxItems: 51 # Should be enough | description: > | List of phandles to ADC channels to read the monitoring values And then you have: | iio-hwmon { | compatible = "iio-hwmon"; | // Voltage sensors top to down | io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>, <&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>, | <&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>, <&adc1 4>, <&adc0 2>, <&adc1 0>, | <&p2V5_aux_vd 0>, <&p3v3_rtc_vd 0>; | }; | | p12v_vd: voltage_divider1 { | compatible = "voltage-divider"; | io-channels = <&adc1 3>; | #io-channel-cells = <1>; | | /* Scale the system voltage by 1127/127 to fit the ADC range. | * Use small nominator to prevent integer overflow. | */ | output-ohms = <15>; | full-ohms = <133>; | }; A voltage divider is _not_ an ADC channel, so I don't know why you are treating it as one in the iio-hwmon entry. Can you explain this please? Thanks, Conor.
Hi! 2024-01-26 at 17:16, Conor Dooley wrote: > Hey, > > On Fri, Jan 26, 2024 at 05:25:08PM +0530, Naresh Solanki wrote: >> Add #io-channel-cells expected by driver. i.e., below is the message >> seen in kernel log: >> OF: /iio-hwmon: could not get #io-channel-cells for /voltage_divider1 >> > >> TEST=Run below command & make sure there is no error: >> make DT_CHECKER_FLAGS=-m dt_binding_check -j1 > > This shouldn't be in the commit message. > >> >> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> >> --- >> Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml >> index dddf97b50549..b4b5489ad98e 100644 >> --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml >> +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml >> @@ -39,6 +39,9 @@ properties: >> description: | >> Channel node of a voltage io-channel. >> >> + '#io-channel-cells': >> + const: 1 > > The example in this binding looks like the voltage-divider is intended > to be an "IIO consumer" but "#io-channels-cells" is an "IIO provider" > property. > > Are you sure this is correct? A voltage-divider is always an iio consumer. And like all iio things, you may access its output from user space (typically via libiio). At the same time a voltage-divider is optionally an iio provider for other in-kernel thingies, in which case you need to specify #io-channel-cells. BTW, this is the case for for all bindings handled by the iio-rescale driver. Cheers, Peter
2024-01-26 at 23:14, Conor Dooley wrote: > On Fri, Jan 26, 2024 at 11:10:36PM +0530, Naresh Solanki wrote: > I did look at what you have there and I think your dts is wrong. > > The iio-hwmon binding says: > | description: > > | Bindings for hardware monitoring devices connected to ADC controllers > | supporting the Industrial I/O bindings. > | > | io-channels: > | minItems: 1 > | maxItems: 51 # Should be enough > | description: > > | List of phandles to ADC channels to read the monitoring values > > And then you have: > | iio-hwmon { > | compatible = "iio-hwmon"; > | // Voltage sensors top to down > | io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>, <&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>, > | <&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>, <&adc1 4>, <&adc0 2>, <&adc1 0>, > | <&p2V5_aux_vd 0>, <&p3v3_rtc_vd 0>; > | }; > | > | p12v_vd: voltage_divider1 { > | compatible = "voltage-divider"; > | io-channels = <&adc1 3>; > | #io-channel-cells = <1>; > | > | /* Scale the system voltage by 1127/127 to fit the ADC range. > | * Use small nominator to prevent integer overflow. > | */ > | output-ohms = <15>; > | full-ohms = <133>; > | }; > > A voltage divider is _not_ an ADC channel, so I don't know why you are > treating it as one in the iio-hwmon entry. Can you explain this please? This is the exact intent of the voltage divider (and the other bindings handled by the iio-rescaler). The raw ADC reports the voltage at its input, which is fine, but if there is an analog frontend in front of the ADC such as a voltage divider the voltage at the ADC is not the interesting property. You are likely to want the "real" voltage before the voltage divider to better understand the value. In this case it's much more interesting to see values such as 12.050V which is presumably close to the nominal voltage (12V? guessing from the node name) rather than some unscaled raw ADC voltage (in this example it would be ~1.359V, which tells you rather little w/o rescaling it first). It's all in the description of the binding... Cheers, Peter
On Sat, Jan 27, 2024 at 10:40:31AM +0100, Peter Rosin wrote: > > > 2024-01-26 at 23:14, Conor Dooley wrote: > > On Fri, Jan 26, 2024 at 11:10:36PM +0530, Naresh Solanki wrote: > > > I did look at what you have there and I think your dts is wrong. > > > > The iio-hwmon binding says: > > | description: > > > | Bindings for hardware monitoring devices connected to ADC controllers > > | supporting the Industrial I/O bindings. > > | > > | io-channels: > > | minItems: 1 > > | maxItems: 51 # Should be enough > > | description: > > > | List of phandles to ADC channels to read the monitoring values > > > > And then you have: > > | iio-hwmon { > > | compatible = "iio-hwmon"; > > | // Voltage sensors top to down > > | io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>, <&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>, > > | <&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>, <&adc1 4>, <&adc0 2>, <&adc1 0>, > > | <&p2V5_aux_vd 0>, <&p3v3_rtc_vd 0>; > > | }; > > | > > | p12v_vd: voltage_divider1 { > > | compatible = "voltage-divider"; > > | io-channels = <&adc1 3>; > > | #io-channel-cells = <1>; > > | > > | /* Scale the system voltage by 1127/127 to fit the ADC range. > > | * Use small nominator to prevent integer overflow. > > | */ > > | output-ohms = <15>; > > | full-ohms = <133>; > > | }; > > > > A voltage divider is _not_ an ADC channel, so I don't know why you are > > treating it as one in the iio-hwmon entry. Can you explain this please? > > This is the exact intent of the voltage divider (and the other bindings > handled by the iio-rescaler). The raw ADC reports the voltage at its input, > which is fine, but if there is an analog frontend in front of the ADC > such as a voltage divider the voltage at the ADC is not the interesting > property. You are likely to want the "real" voltage before the voltage > divider to better understand the value. > > In this case it's much more interesting to see values such as 12.050V > which is presumably close to the nominal voltage (12V? guessing from > the node name) rather than some unscaled raw ADC voltage (in this > example it would be ~1.359V, which tells you rather little w/o rescaling > it first). Thanks for explaining it. Naresh, can you respin please with an explanation of why the property belongs in the binding please? > It's all in the description of the binding... Obviously it was not sufficiently clear, it's not as if I didn't look at it... Cheers, Conor.
On Sat, 27 Jan 2024 11:03:14 +0000 Conor Dooley <conor@kernel.org> wrote: > On Sat, Jan 27, 2024 at 10:40:31AM +0100, Peter Rosin wrote: > > > > > > 2024-01-26 at 23:14, Conor Dooley wrote: > > > On Fri, Jan 26, 2024 at 11:10:36PM +0530, Naresh Solanki wrote: > > > > > I did look at what you have there and I think your dts is wrong. > > > > > > The iio-hwmon binding says: > > > | description: > > > > | Bindings for hardware monitoring devices connected to ADC controllers > > > | supporting the Industrial I/O bindings. > > > | > > > | io-channels: > > > | minItems: 1 > > > | maxItems: 51 # Should be enough > > > | description: > > > > | List of phandles to ADC channels to read the monitoring values > > > > > > And then you have: > > > | iio-hwmon { > > > | compatible = "iio-hwmon"; > > > | // Voltage sensors top to down > > > | io-channels = <&p12v_vd 0>, <&p5v_aux_vd 0>, <&p5v_bmc_aux_vd 0>, <&p3v3_aux_vd 0>, > > > | <&p3v3_bmc_aux_vd 0>, <&p1v8_bmc_aux_vd 0>, <&adc1 4>, <&adc0 2>, <&adc1 0>, > > > | <&p2V5_aux_vd 0>, <&p3v3_rtc_vd 0>; > > > | }; > > > | > > > | p12v_vd: voltage_divider1 { > > > | compatible = "voltage-divider"; > > > | io-channels = <&adc1 3>; > > > | #io-channel-cells = <1>; > > > | > > > | /* Scale the system voltage by 1127/127 to fit the ADC range. > > > | * Use small nominator to prevent integer overflow. > > > | */ > > > | output-ohms = <15>; > > > | full-ohms = <133>; > > > | }; > > > > > > A voltage divider is _not_ an ADC channel, so I don't know why you are > > > treating it as one in the iio-hwmon entry. Can you explain this please? > > > > This is the exact intent of the voltage divider (and the other bindings > > handled by the iio-rescaler). The raw ADC reports the voltage at its input, > > which is fine, but if there is an analog frontend in front of the ADC > > such as a voltage divider the voltage at the ADC is not the interesting > > property. You are likely to want the "real" voltage before the voltage > > divider to better understand the value. > > > > In this case it's much more interesting to see values such as 12.050V > > which is presumably close to the nominal voltage (12V? guessing from > > the node name) rather than some unscaled raw ADC voltage (in this > > example it would be ~1.359V, which tells you rather little w/o rescaling > > it first). > > Thanks for explaining it. Naresh, can you respin please with an > explanation of why the property belongs in the binding please? Agreed - the explanation of 'why' is needed. As discussed, in this case the end consumer is iio-hwmon (reflecting that the thing we are ultimately 'measuring' as a voltage of a wire that needs monitoring for hwmon usecases) and that is measured via a voltage divider (hence that's providing the measurement service) which in turn needs to consume the reading from and ADC and hence the middle device is here acting as a provider to iio-hwmon and a consumer of the ADC channel. p.s. No one really likes the iio-hwmon binding because it is reflecting a usecase rather than hardware, but meh, it's been around a long time and we never figured out a better option. Things are much cleaner for circuits like the voltage divider. > > > It's all in the description of the binding... > > Obviously it was not sufficiently clear, it's not as if I didn't look at > it... Given this device fits in both categories, perhaps a tiny bit of additional documentation would help? '#io-channels-cells': description: In addition to consuming the measurement services of an ADC, the voltage divider can act as an provider of measurement services to other devices. const: 1 > > Cheers, > Conor.
On Sat, Jan 27, 2024 at 02:49:20PM +0000, Jonathan Cameron wrote: > > > It's all in the description of the binding... > > > > Obviously it was not sufficiently clear, it's not as if I didn't look at > > it... > > Given this device fits in both categories, perhaps a tiny bit of > additional documentation would help? That would be nice. > '#io-channels-cells': > description: > In addition to consuming the measurement services of an ADC, > the voltage divider can act as an provider of measurement > services to other devices. > const: 1 But I am not sure that that covers things. I think an example, like Peter gave, would be good?
On Sat, 27 Jan 2024 16:48:04 +0000 Conor Dooley <conor@kernel.org> wrote: > On Sat, Jan 27, 2024 at 02:49:20PM +0000, Jonathan Cameron wrote: > > > > > It's all in the description of the binding... > > > > > > Obviously it was not sufficiently clear, it's not as if I didn't look at > > > it... > > > > Given this device fits in both categories, perhaps a tiny bit of > > additional documentation would help? > > That would be nice. > > > '#io-channels-cells': > > description: > > In addition to consuming the measurement services of an ADC, > > the voltage divider can act as an provider of measurement > > services to other devices. > > const: 1 > > But I am not sure that that covers things. I think an example, like > Peter gave, would be good? Ok. An example is fine.
diff --git a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml index dddf97b50549..b4b5489ad98e 100644 --- a/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml +++ b/Documentation/devicetree/bindings/iio/afe/voltage-divider.yaml @@ -39,6 +39,9 @@ properties: description: | Channel node of a voltage io-channel. + '#io-channel-cells': + const: 1 + output-ohms: description: Resistance Rout over which the output voltage is measured. See full-ohms.