Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp215721ybb; Thu, 19 Mar 2020 20:15:49 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuJpbuerIdRmXzdCd0HSsbSArFhhKDtoirM5yEDOAvPkC616fsewP83ZFHin33CmLehGsa8 X-Received: by 2002:a05:6808:a08:: with SMTP id n8mr4918179oij.91.1584674149105; Thu, 19 Mar 2020 20:15:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584674149; cv=none; d=google.com; s=arc-20160816; b=E4OWDglnmP+aFRzuJ+1smwV+YP6ymOcU2ZjNHplqJ4Q/xzKu1i/TXF8TKOOjxMhpHL qbgTGxPsA2SwV4kcdbbEnBfVQD2qbYBHd2ipBBihxVJoOWXv5OG2WmO6JMovX0xI61RZ PO8nVRP7t4XSaX4D4APdUoM+XyUwOjXd09CmET02e90aaTCdVzH3hdB0p2lxmlmrZkaA JK4cdy9XYJqdqaU2EV7P4dymTe6mW9VGX1/y+clfj4yXb5V1MbIt9BytlrFM/DYYOIHn V2moSnubgUVbxwCE6bqhDuxW2ZLHdOJjYsMKaNogejGnH3jBODYq7IO7EyV07q1K1eC9 XgPQ== 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=hZBfZQ7TDOIn8FbDEd6NoIor7pCIUszqCI8Cd797v4Q=; b=y8XviQLQD8A/QTPa1f8nxQAtVC7UsdjhIUL27+PEqEAMD/cdM4yRcu3uNjwqLJscuV eeefkJdyxVhF8YXd3PBw2fpo3TD6qwz/GZ+h0FC9hoaGLOPKISC7QWwZlOboVLOxkwNA Ar6iMhFZQTESK9GBRD2s4e38jIA/AtnLPcSiq/l6dHkMvSZSdgxy7J5ErTbz+b3XgPT9 sgwQOvK/9XU8cNndOleW2A+MORmRei7Y0bfvAPBaRE+jeJvskSoKPrQ+wuQ1SG9HFKOu kL2XCJM7ejdEAXS6I3jxRKiAJPmnpYI9niRAjekGOLxgEecf8ye0myk5rNmnoC2V94U+ b6sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=w3GKc92c; 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 p15si2350586otq.4.2020.03.19.20.15.36; Thu, 19 Mar 2020 20:15:49 -0700 (PDT) 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=w3GKc92c; 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 S1726774AbgCTDPS (ORCPT + 99 others); Thu, 19 Mar 2020 23:15:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:37532 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726103AbgCTDPS (ORCPT ); Thu, 19 Mar 2020 23:15:18 -0400 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 E68AD20732; Fri, 20 Mar 2020 03:15:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584674117; bh=Qy4Drd2ux8KYY4KgJCZdJOObAhqMSo77y6zNWn+q4MM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=w3GKc92cnRRSzt66icI55KS0YEpfwJqCiylsk1UA/e0G2dtEuTFM3ktG48tXpJvQH RUqJDJyM6DfJjtqBLJ5d/7Iv/23jWn4gz1/qanH0EYx3PWYHQZ5NnQOzLXVoT7V7yP pa/AWhK78n39Pbt4bzMzZAspmVtoVHhhot1C7FLo= Received: by mail-qt1-f180.google.com with SMTP id d22so3881277qtn.0; Thu, 19 Mar 2020 20:15:16 -0700 (PDT) X-Gm-Message-State: ANhLgQ2RuSClpIGjk4Ol/gbJ7iJHsGYum2kCfd2o9VuF3OvTt+9X2Zws x+3Vhu6Q89az0ImCEVdkqVNYO7MufTDXJVc4GA== X-Received: by 2002:ac8:1b33:: with SMTP id y48mr6410475qtj.136.1584674115935; Thu, 19 Mar 2020 20:15:15 -0700 (PDT) MIME-Version: 1.0 References: <1584464453-28200-1-git-send-email-tharvey@gateworks.com> <1584464453-28200-2-git-send-email-tharvey@gateworks.com> In-Reply-To: <1584464453-28200-2-git-send-email-tharvey@gateworks.com> From: Rob Herring Date: Thu, 19 Mar 2020 21:15:04 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 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, "linux-kernel@vger.kernel.org" , 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 Tue, Mar 17, 2020 at 11:01 AM Tim Harvey wrote: > > This patch adds documentation of device-tree bindings for the > Gateworks System Controller (GSC). > > Signed-off-by: Tim Harvey > --- > v6: > - fix commit message typo > - drop invalid description from #interrupt-cells property > - fix adc pattern property > - add unit suffix > - replace hwmon/adc with adc/channel > - changed adc type to gw,mode > - add unit suffix and drop ref for voltage-divider > - add unit suffix for voltage-offset > - moved fan to its own subnode with base register > > 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 | 172 +++++++++++++++++++++ > 1 file changed, 172 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..e921e67 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml > @@ -0,0 +1,172 @@ > +# 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 Monitor with ADC's for temperature and voltage rails and > + fan controller > + > +maintainers: > + - Tim Harvey > + - Robert Jones > + > +properties: > + $nodename: > + pattern: "gsc@[0-9a-f]{1,2}" > + compatible: > + const: gw,gsc > + > + reg: > + description: I2C device address > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + interrupt-controller: true > + > + "#interrupt-cells": > + const: 1 > + > + adc: > + type: object > + description: Optional Hardware Monitoring module > + > + properties: > + compatible: > + const: gw,gsc-adc > + > + "#address-cells": > + const: 1 > + > + "#size-cells": > + const: 0 > + > + patternProperties: > + "^channel@[0-9]+$": > + 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 > + > + gw,mode: > + description: | > + conversion mode: > + 0 - temperature, in C*10 > + 1 - pre-scaled voltage value > + 2 - scaled voltage based on an optional resistor divider > + and optional offset > + allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2] > + > + gw,voltage-divider-milli-ohms: > + description: values of resistors for divider on raw ADC input > + items: > + - description: R1 > + - description: R2 Aren't there some constraints on the values? You could do something like this: maxItems: 2 items: minimum: 1 maximum: 2000 I know I said the way you have it is fine, but the example fails with it like this. It's related to how we encode the DT data for validation and some schema fixups we do to cut down on some boilerplate. We could just fix the example (with <> around each value), but having constraints is better. > + > + gw,voltage-offset-microvolt: > + $ref: /schemas/types.yaml#/definitions/uint32 Can drop this as .*-microvolt has a defined type. Are there some constraints? > + description: | > + A positive voltage offset to apply to a raw ADC > + (ie to compensate for a diode drop). > + > + required: > + - gw,mode > + - reg > + - label > + > + required: > + - compatible > + - "#address-cells" > + - "#size-cells" > + > + fan: fan-controller Save 'fan' for if/when we have a node representing the fan itself. > + type: object > + description: Optional FAN controller > + > + properties: > + compatible: > + const: gw,gsc-fan > + > + base: What happened to 'reg'? While inconsistent that adc doesn't have an address, better that than inventing your own address property. > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: The fan controller base address > + maxItems: 1 > + > + required: > + - compatible > + - base > + > +required: > + - compatible > + - reg > + - interrupts > + - interrupt-controller > + - "#interrupt-cells" > + > +examples: > + - | > + #include > + i2c { > + #address-cells = <1>; > + #size-cells = <0>; > + > + gsc@20 { > + compatible = "gw,gsc"; > + reg = <0x20>; > + interrupt-parent = <&gpio1>; > + interrupts = <4 GPIO_ACTIVE_LOW>; > + interrupt-controller; > + #interrupt-cells = <1>; > + > + adc { > + compatible = "gw,gsc-adc"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + channel@0 { /* A0: Board Temperature */ > + gw,mode = <0>; > + reg = <0x00>; > + label = "temp"; > + }; > + > + channel@2 { /* A1: Input Voltage (raw ADC) */ > + gw,mode = <1>; > + reg = <0x02>; > + label = "vdd_vin"; > + gw,voltage-divider-milli-ohms = <22100 1000>; > + gw,voltage-offset-microvolt = <800000>; > + }; > + > + channel@b { /* A2: Battery voltage */ > + gw,mode = <1>; > + reg = <0x0b>; > + label = "vdd_bat"; > + }; > + }; > + > + fan { > + compatible = "gw,gsc-fan"; > + base = <0x2c>; > + }; > + }; > + }; > -- > 2.7.4 >