Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7073898ybf; Fri, 6 Mar 2020 09:51:30 -0800 (PST) X-Google-Smtp-Source: ADFU+vt5q9iaksWHSwUd60FRocmLf2UI/246Q1mQVxgu3CI3nQaeFncCQrvT8DejmgB5ezbQjHFS X-Received: by 2002:a9d:4b10:: with SMTP id q16mr3539069otf.72.1583517090051; Fri, 06 Mar 2020 09:51:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583517090; cv=none; d=google.com; s=arc-20160816; b=ZtfGO82xRDfeYBR1LrUx2UYmvURJ3LZAy59a9Qs7gszYV4KNmkGqSBmOMqvMuadOYf IKbqTRvUqeWk71XHcuM33pkxCjntk9Efl4eZN1LP3dO2U5Tv8Qs5J58Y/HAVX+lyVQpS yfx+d/xWua2yhJQo5osTmk2+IYcGtc/Esd3V0HF6Y0oFu0F6GHhs0H6JgWfbrZt3eJ3y MpC+NS5ZFH/P/hliFpK/e1xiSSbyc57P8AjCvRSab7faSFbPu0HvaHsD1Y8Yb9Z+k2zR KSk589foH7eN2VyEC1GfNMAPKD/5Od4DltSCAi6sxRCpyuqy0LyMdH/6okM9gWPN7TLl 1DOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nHtu0UthNncaFM+oIt/uT8QF4VkB36vsEYzL2hwzNMc=; b=kIVyumfCbQLFoYCTJvbk1s+v8dL++BHY2ps/Al9E5CGGD4VcoaudPlngAVdBj/NaFf dWyNR2hKIOuk+um7pb/VZy4iis2XlaL8A4Vyfe/15zFlwTvuNx0kmOVf2X6SL67k+YMd +hJ4RwuZVMb4gdztqRFd3I7cz9wafcihjz68Z9/C4/zKLSX+9EKfm+dVfWjbY04SvzNC M+kkc+g96LZYOtGVmzYpRDOUx1Ammh2iR8o2yekm3Cgg09ejwnoESE2jQlJL26Lz6BVR LiXyEiEI89cOicH352W8sGYQL9p/P1I1YbtxCb0bcx9f1szGxGXxp4NzbC194lE9IbOo lmhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=w6XMGxCB; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si50754oia.200.2020.03.06.09.51.18; Fri, 06 Mar 2020 09:51:30 -0800 (PST) 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=@kernel.org header.s=default header.b=w6XMGxCB; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726579AbgCFRur (ORCPT + 99 others); Fri, 6 Mar 2020 12:50:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:44218 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725835AbgCFRur (ORCPT ); Fri, 6 Mar 2020 12:50:47 -0500 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BFE5D2084E; Fri, 6 Mar 2020 17:50:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583517046; bh=5rMJ7WU8kihvc/95pzuL9wp/s1bKJesptPNnSjIQkb0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=w6XMGxCBVlC8t1Olh/w9bzeElFbljQ+vK4RO7Dto6taAy9J1BWhwg6PP+iBSM8qCf 1VCFzMwEA+0PCHnYjQMAJXwYG42lfPokdP7a/ziNkBH1/43gbXp38ColDCmyyvnksk r+zwHAoCU+FBK8jpGGoFrWcYI1mmZojdoVPzK6zw= Received: by mail-qv1-f54.google.com with SMTP id e7so1318531qvy.9; Fri, 06 Mar 2020 09:50:46 -0800 (PST) X-Gm-Message-State: ANhLgQ1Aq5kEo3R20pxydo2XphsTYhfSOL34vXDzpXE1QFi6ltUmmalT wiwYCG3xKTHFWNOAKJ+YZ9pqN5nSloh5PCW5qA== X-Received: by 2002:ad4:45e3:: with SMTP id q3mr3794285qvu.135.1583517045699; Fri, 06 Mar 2020 09:50:45 -0800 (PST) MIME-Version: 1.0 References: <1582577665-13554-1-git-send-email-tharvey@gateworks.com> <1582577665-13554-2-git-send-email-tharvey@gateworks.com> <20200302204949.GA6649@bogus> In-Reply-To: From: Rob Herring Date: Fri, 6 Mar 2020 11:50:33 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/3] dt-bindings: mfd: Add Gateworks System Controller bindings To: Tim Harvey Cc: Lee Jones , Jean Delvare , Guenter Roeck , Linux HWMON List , Frank Rowand , devicetree@vger.kernel.org, open list , Robert Jones Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 6, 2020 at 9:58 AM Tim Harvey wrote: > > On Mon, Mar 2, 2020 at 12:49 PM Rob Herring wrote: > > > > Rob, > > Thanks for the review! Some questions below: > > > On Mon, Feb 24, 2020 at 12:54:23PM -0800, Tim Harvey wrote: > > > This patch adds documentation of device-tree bindings for the > > > Gateworks System Controller (GSC). > > > > > > Signed-off-by: Tim Harvey > > > --- > > > v5: > > > - resolve dt_binding_check issues > > > > > > v4: > > > - move to using pwm_auto_point_{pwm,temp} for FAN PWM > > > - remove unncessary resolution/scaling properties for ADCs > > > - update to yaml > > > - remove watchdog > > > > > > v3: > > > - replaced _ with - > > > - remove input bindings > > > - added full description of hwmon > > > - fix unit address of hwmon child nodes > > > --- > > > .../devicetree/bindings/mfd/gateworks-gsc.yaml | 158 +++++++++++++++++++++ > > > 1 file changed, 158 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml > > > new file mode 100644 > > > index 00000000..f7c1a05 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml > > > @@ -0,0 +1,158 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/gateworks-gsc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Gateworks System Controller multi-function device > > > + > > > +description: | > > > + The GSC is a Multifunction I2C slave device with the following submodules: > > > + - Watchdog Timer > > > + - GPIO > > > + - Pushbutton controller > > > + - Hardware Monitore with ADC's for temperature and voltage rails and > > > > typo > > will fix > > > > > > + fan controller > > > + > > > +maintainers: > > > + - Tim Harvey > > > + - Robert Jones > > > + > > > +properties: > > > + $nodename: > > > + pattern: "gsc@[0-9a-f]{1,2}" > > > + compatible: > > > + const: gw,gsc > > > > That's not very specific. > > > > Do you mean something like 'gw,system-controller' would be better > instead of the gsc abbreviation for 'Gateworks System Controller'? No, I mean is there or will there be only one version of this? > > > + > > > + reg: > > > + description: I2C device address > > > + maxItems: 1 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + interrupt-controller: true > > > + > > > + "#interrupt-cells": > > > + const: 1 > > > + description: The IRQ number > > > > description is wrong. You can just drop it. > > > > ok > > > > + > > > + hwmon: > > > > 'hwmon' is a Linux thing. I'm suspicious... > > > > Yes, we've discussed this before and I understand that DT shouldn't > use terminology that is Linux specific (which is why I replaced > 'hwmon' with 'adc' in the ADC nodes below) but I still see a long of > dt bindings in Documentation/devicetree/bindings with the word 'hwmon' > in them. > > Perhaps this makes more sense? Yes, that's more aligned with IIO ADC bindings. Yes, IIO is again a Linuxism, but I think the ADC bindings are fairly independent other than the directory name. > > adc { > compatible = "gw,gsc-adc"; > #address-cells = <1>; > #size-cells = <0>; > > channel@6 { > type = "gw,hwmon-temperature"; > reg = <0x06>; > label = "temp"; > }; > ... > }; > > > > > + type: object > > > + description: Optional Hardware Monitoring module > > > + > > > + properties: > > > + compatible: > > > + const: gw,gsc-hwmon > > > + > > > + "#address-cells": > > > + const: 1 > > > + > > > + "#size-cells": > > > + const: 0 > > > + > > > + gw,fan-base: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: The fan controller base address > > > > Shouldn't this be described as a node in the DT or be implied by the > > compatible? > > It does look out of place there. Would adding another subnode outside > of the (perhaps misnamed) 'hwmon' node make more sense?: > > fan: > properties: > compatible: gw,gsc-fancontroller > reg: > description: address of the fan controller base register > maxItems: 1 Seems somewhat better location in that the first level is sub-functions of this chip. But now you have 'adc' with no address and 'fan' (w/ reg should be fan@...) with an address, so that's not consistent. Also, I think fan controllers and fans need to have separate nodes as there are different types of fans such as with and without tach signals. I've tried to steer other fan bindings that way. Depends how complex the fan controller is whether that's necessary. > > > + patternProperties: > > > + "^adc@[0-2]$": > > > > There's only one number space at any level. So if you ever need anything > > else at this level, it can't have an address. Just something to > > consider. > > > > yes, one number space is ok if I understand what you mean but I meant > this to be "^adc@[0-9]+$" to support the number of ADC pins the part > supports. > > > > + type: object > > > + description: | > > > + Properties for a single ADC which can report cooked values > > > + (ie temperature sensor based on thermister), raw values > > > + (ie voltage rail with a pre-scaling resistor divider). > > > + > > > + properties: > > > + reg: > > > + description: Register of the ADC > > > + maxItems: 1 > > > + > > > + label: > > > + description: Name of the ADC input > > > + > > > + type: > > > > Very generic property name, but it's not generic. Needs a vendor prefix > > at least. > > You mean the property name of 'type' is fine, but the values will need > to be vendor specific like 'gw,temperature', 'gw,voltage', > 'gw,voltage-raw' or is it inappropriate to use 'type'? Don't use 'type'. Is this for 'how to setup/program the adc' or 'what am I measuring'? For example, configure the adc for temperature readings vs. measure CPU temperature. Seems like a common thing needed for ADC. 'label' already covers the latter case. > > > + description: | > > > + temperature in C*10 (temperature), > > > + pre-scaled voltage value (voltage), > > > + or scaled based on an optional resistor divider and optional > > > + offset (voltage-raw) > > > + enum: > > > + - temperature > > > + - voltage > > > + - voltage-raw > > > + > > > + gw,voltage-divider: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: values of resistors for divider on raw ADC input > > > + items: > > > + - description: R1 > > > + - description: R2 > > > > Needs a standard unit suffix. With that, you can drop the type > > reference. > > I understand the unit suffix but not sure what you mean by type > reference. Do you mean: > > gw,voltage-divider-milli-ohms: > description: values of resistors for divider on raw ADC input > items: > - description: R1 > - description: R2 Yes, drop the '$ref'. Rob