[{"id":1770440,"web_url":"http://patchwork.ozlabs.org/comment/1770440/","msgid":"<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>","list_archive_url":null,"date":"2017-09-18T19:26:38","subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Fri, Sep 08, 2017 at 02:39:17PM +1000, Andrew Jeffery wrote:\n> Signed-off-by: Andrew Jeffery \n> ---\n> .../devicetree/bindings/hwmon/pmbus/max31785.txt | 158 +++++++++++++++++++++\n\nI think this needs to be located by what it does (fan control), not what \ninterface it has (pmbus).\n\nI'm not all that happy with hwmon either because things here seem to \njust be based on being Linux hwmon devices which is sometimes arbitrary. \n\n> 1 file changed, 158 insertions(+)\n> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> \n> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt b/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> new file mode 100644\n> index 000000000000..af9578e7742c\n> --- /dev/null\n> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> @@ -0,0 +1,158 @@\n> +Bindings for the Maxim MAX31785 Intelligent Fan Controller\n> +==========================================================\n> +\n> +Reference:\n> +\n> +https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf\n> +\n> +Required properties:\n> +- compatible : One of \"maxim,max31785\" or \"maxim,max31785a\"\n> +- reg : I2C address, one of 0x52, 0x53, 0x54, 0x55.\n> +- #address-cells : Must be 1\n> +- #size-cells : Must be 0\n> +- #thermal-sensor-cells : Should be 1. The device supports:\n> + - One internal sensor\n> + - Four external I2C digital sensors\n> + - Six external thermal diodes\n\nYou should define the IDs here, not just how many of each type.\n\n> +\n> +Optional properties:\n> +- use-stored-presence : Do not treat the devicetree description as canon for\n> + fan presence (the 'installed' bit of FAN_CONFIG_*).\n> + Instead, rely on the on the default value store of\n> + the device to populate it.\n\nBoolean? Please be explicit.\n\nNeeds a vendor prefix.\n\n> +\n> +Capabilities are configured through subnodes of the controller's node.\n> +\n> +Fans\n> +----\n> +\n> +Only fans with subnodes present will be considered as installed. If\n> +use-stored-presence is present in the parent node, then only fans that are both\n> +defined in the devicetree and have their installed bit set are considered\n> +installed.\n> +\n> +Required subnode properties:\n> +- compatible : Must be \"pmbus-fan\"\n\n\"pmbus\" is a property of the controller, not the fan, right? We should \nhave compatibles along the lines of the type of fan like 4-wire, 3-wire, \netc. \n\n> +- reg : The PMBus page the properties apply to.\n> +- #cooling-cells : Should be 2. See the thermal bindings at [1].\n> +- maxim,fan-rotor-input : The type of rotor measurement provided to the\n> + controller. Must be either \"tach\" for tachometer\n> + pulses or \"lock\" for a locked-rotor signal.\n> +- maxim,fan-lock-polarity: Required iff maxim,fan-rotor-input is \"lock\". Valid\n> + values are \"low\" for active low, \"high\" for active\n> + high.\n> +\n> +Optional subnode properties:\n> +- fan-mode : \"rpm\" or \"pwm\". Default value is \"pwm\".\n> +- tach-pulses : Tachometer pulses per revolution. Valid values are\n> + 1, 2, 3 or 4. The default is 1.\n> +- cooling-min-level : Smallest cooling state accepted. See [1].\n> +- cooling-max-level : Largest cooling state accepted. See [1].\n> +- maxim,fan-no-fault-ramp: Do not ramp the fan to 100% PWM duty on detecting a\n> + fan fault\n> +- maxim,fan-startup : The number of rotations required before taking\n> + emergency action for an unresponsive fan and driving\n> + it with 100% or 0% PWM duty, depending on the state\n> + of maxim,fan-no-fault-ramp. Valid values are 0\n> + (automatic spin-up disabled), 2, 4, or 8. Default\n> + value is 0.\n> +- maxim,fan-health : Enable automated fan health check\n> +- maxim,fan-ramp : Configures how fast the device ramps the PWM duty\n> + cycle from one value to another. Valid values are 0\n> + to 7 inclusive, with values 0 - 2 configuring a\n> + 1000ms update rate and 1 - 3% duty respective duty\n> + increase, and 3 - 7 a 200ms update rate with a 1 -\n> + 5% respective duty increase. Default value is 0.\n> +- maxim,fan-no-watchdog : Do not ramp fan to 100% PWM duty on failure to\n> + update desired fan rate inside 10s. This implies\n> + maxim,tmp-no-fault-ramp\n> +- maxim,tmp-no-fault-ramp: Do not ramp fan to 100% PWM duty on temperature\n> + sensor fault detection. This implies\n> + maxim,fan-no-watchdog\n> +- maxim,tmp-hysteresis : The temperature hysteresis used to determine\n> + transitions to lower fan speed bands in the\n> + temperature/fan rate lookup table. Valid values are\n> + 2, 4, 6 or 8 (degrees celcius). Default value is 2.\n> +- maxim,fan-dual-tach : Enable dual tachometer functionality\n> +- maxim,fan-pwm-freq : The PWM frequency. Valid values are 30, 50, 100, 150\n> + and 25000 (Hz). Default value is 30Hz.\n> +- maxim,fan-lookup-table : A 16-element cell array of alternating temperature\n> + and rate values representing the look up table. The\n> + rate units are set through the fan-mode property.\n> +- maxim,fan-fault-pin-mon: Ramp fans to 100% PWM duty when the FAULT pin is\n> + asserted\n\nIn general, I think a good portion of these should be either implied by \na fan compatible string or be part of a common fan binding.\n\n> +\n> +Temperature\n> +-----------\n> +\n> +Required subnode properties:\n> +- compatible : Must be \"pmbus-temperature\"\n> +- reg : The PMBus page the properties apply to.\n> +\n> +Optional subnode properties:\n> +- maxim,tmp-offset : Valid values are 0 - 30 (degrees celcius) inclusive.\n> + Default value is 0.\n> +- maxim,tmp-fans : An array of phandles to fans controlled by the\n> + current temperature sensor.\n\nIs this a feature of the Maxim chip or just a mapping of temperature \nsensors to fans. The latter should be a common property.\n\nRob","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","openbmc@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","openbmc@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwwxH6jkzz9s7G\n\tfor ;\n\tTue, 19 Sep 2017 05:26:59 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xwwxH4gdFzDqGq\n\tfor ;\n\tTue, 19 Sep 2017 05:26:59 +1000 (AEST)","from mail-io0-f195.google.com (mail-io0-f195.google.com\n\t[209.85.223.195])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xwwwz49KXzDq5k\n\tfor ; Tue, 19 Sep 2017 05:26:43 +1000 (AEST)","by mail-io0-f195.google.com with SMTP id e9so431330iod.5\n\tfor ; Mon, 18 Sep 2017 12:26:42 -0700 (PDT)","from localhost (216-188-254-6.dyn.grandenetworks.net.\n\t[216.188.254.6]) by smtp.gmail.com with ESMTPSA id\n\tp62sm1131763oic.50.2017.09.18.12.26.39\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 18 Sep 2017 12:26:39 -0700 (PDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=209.85.223.195; helo=mail-io0-f195.google.com;\n\tenvelope-from=robherring2@gmail.com; receiver=)","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=ybuTXlMnmRYJR3SxhyNx4KmvjEJ0Yzn4P1bK/8Feqxo=;\n\tb=ClGBWcMLLZr2weUFPYkl90ZO3MCwsUPJuU6oCU3tn8dHFJ/ivJHzTr5717zj7PORJq\n\t1M/ZxdjUbTpv3wkeHdxfU5ccWZJmRoOKpf0h1mvchFatN872t+s1/d/hLFZd6vc9zouc\n\tQpLkcB7TUagknwCTCpydcprHpmb1uZgcOSHRDqiPbo8RUwx/59p8ujrkZga/EsyGfU0s\n\t1KIYECvtjz830JGvTC6GqIlnvszMg4CKMEck9eeI+c7BOd2DpY2x7gGaKAa5qmbQu7ea\n\tYf3P1tXBNKpZj7lLhIJNVP6/LS+w/JoI1z+4JgxfERmVpoeZTcAZFGxiYvLNMSpEk8qv\n\ty3gg==","X-Gm-Message-State":"AHPjjUgQnChgYdwSUIfRgW6LeSW/D1MXzE9woydkNfwDyMRklImhTh/2\n\tbpLLcOePmBFPpQ==","X-Google-Smtp-Source":"AOwi7QClUB3Rbl/XOzUFFPLWQNamVnm41HFiOOQUK4gy5wEyIVRK3vzEtMGorfQrzCxLrOgOxbTvgg==","X-Received":"by 10.202.228.201 with SMTP id\n\tb192mr25821446oih.132.1505762800486; \n\tMon, 18 Sep 2017 12:26:40 -0700 (PDT)","Date":"Mon, 18 Sep 2017 14:26:38 -0500","From":"Rob Herring ","To":"Andrew Jeffery ","Subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","Message-ID":"<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>","References":"<20170908043919.6924-1-andrew@aj.id.au>\n\t<20170908043919.6924-2-andrew@aj.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170908043919.6924-2-andrew@aj.id.au>","User-Agent":"NeoMutt/20170113 (1.7.2)","X-BeenThere":"openbmc@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Development list for OpenBMC ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-hwmon@vger.kernel.org, mark.rutland@arm.com, jdelvare@suse.com,\n\tdevicetree@vger.kernel.org, openbmc@lists.ozlabs.org,\n\tlinux-kernel@vger.kernel.org, linux@roeck-us.net","Errors-To":"openbmc-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"openbmc\"\n\t"}},{"id":1770467,"web_url":"http://patchwork.ozlabs.org/comment/1770467/","msgid":"<20170918201528.GA27615@roeck-us.net>","list_archive_url":null,"date":"2017-09-18T20:15:28","subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","submitter":{"id":21889,"url":"http://patchwork.ozlabs.org/api/people/21889/","name":"Guenter Roeck","email":"linux@roeck-us.net"},"content":"On Mon, Sep 18, 2017 at 02:26:38PM -0500, Rob Herring wrote:\n> On Fri, Sep 08, 2017 at 02:39:17PM +1000, Andrew Jeffery wrote:\n> > Signed-off-by: Andrew Jeffery \n> > ---\n> > .../devicetree/bindings/hwmon/pmbus/max31785.txt | 158 +++++++++++++++++++++\n> \n> I think this needs to be located by what it does (fan control), not what \n> interface it has (pmbus).\n> \n> I'm not all that happy with hwmon either because things here seem to \n> just be based on being Linux hwmon devices which is sometimes arbitrary. \n> \nThe chip also measures temperatures. Other PMBus chips may do fan control,\nmeasure temperatures, measure and/or control voltages, current, power ...\nStrictly speaking pretty much all PMBus chips are multi-function devices.\nI personally don't really care if the documentation is spread across\nseveral directories, but even here this is already challenging.\n\nOnly solution I can think of would be to create separate documents for each\nfunctionality, ie here one for the device itself, one for fan control,\nand one for temperature control (if that needs separate bindings). That\nwould be similar to mfd. But then we would still have to sort out where\nto store the various bindings. Like iio, in subdirectories ? Like mfd,\nin the matching subsystems ? If so, what to do if there is no matching\nsubsystem ?\n\nLots of questions. I'll be happy to spend some time sorting it out,\nbut I would need some directions.\n\nThanks,\nGuenter\n\n> > 1 file changed, 158 insertions(+)\n> > create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> > \n> > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt b/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> > new file mode 100644\n> > index 000000000000..af9578e7742c\n> > --- /dev/null\n> > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> > @@ -0,0 +1,158 @@\n> > +Bindings for the Maxim MAX31785 Intelligent Fan Controller\n> > +==========================================================\n> > +\n> > +Reference:\n> > +\n> > +https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf\n> > +\n> > +Required properties:\n> > +- compatible : One of \"maxim,max31785\" or \"maxim,max31785a\"\n> > +- reg : I2C address, one of 0x52, 0x53, 0x54, 0x55.\n> > +- #address-cells : Must be 1\n> > +- #size-cells : Must be 0\n> > +- #thermal-sensor-cells : Should be 1. The device supports:\n> > + - One internal sensor\n> > + - Four external I2C digital sensors\n> > + - Six external thermal diodes\n> \n> You should define the IDs here, not just how many of each type.\n> \n> > +\n> > +Optional properties:\n> > +- use-stored-presence : Do not treat the devicetree description as canon for\n> > + fan presence (the 'installed' bit of FAN_CONFIG_*).\n> > + Instead, rely on the on the default value store of\n> > + the device to populate it.\n> \n> Boolean? Please be explicit.\n> \n> Needs a vendor prefix.\n> \n> > +\n> > +Capabilities are configured through subnodes of the controller's node.\n> > +\n> > +Fans\n> > +----\n> > +\n> > +Only fans with subnodes present will be considered as installed. If\n> > +use-stored-presence is present in the parent node, then only fans that are both\n> > +defined in the devicetree and have their installed bit set are considered\n> > +installed.\n> > +\n> > +Required subnode properties:\n> > +- compatible : Must be \"pmbus-fan\"\n> \n> \"pmbus\" is a property of the controller, not the fan, right? We should \n> have compatibles along the lines of the type of fan like 4-wire, 3-wire, \n> etc. \n> \n> > +- reg : The PMBus page the properties apply to.\n> > +- #cooling-cells : Should be 2. See the thermal bindings at [1].\n> > +- maxim,fan-rotor-input : The type of rotor measurement provided to the\n> > + controller. Must be either \"tach\" for tachometer\n> > + pulses or \"lock\" for a locked-rotor signal.\n> > +- maxim,fan-lock-polarity: Required iff maxim,fan-rotor-input is \"lock\". Valid\n> > + values are \"low\" for active low, \"high\" for active\n> > + high.\n> > +\n> > +Optional subnode properties:\n> > +- fan-mode : \"rpm\" or \"pwm\". Default value is \"pwm\".\n> > +- tach-pulses : Tachometer pulses per revolution. Valid values are\n> > + 1, 2, 3 or 4. The default is 1.\n> > +- cooling-min-level : Smallest cooling state accepted. See [1].\n> > +- cooling-max-level : Largest cooling state accepted. See [1].\n> > +- maxim,fan-no-fault-ramp: Do not ramp the fan to 100% PWM duty on detecting a\n> > + fan fault\n> > +- maxim,fan-startup : The number of rotations required before taking\n> > + emergency action for an unresponsive fan and driving\n> > + it with 100% or 0% PWM duty, depending on the state\n> > + of maxim,fan-no-fault-ramp. Valid values are 0\n> > + (automatic spin-up disabled), 2, 4, or 8. Default\n> > + value is 0.\n> > +- maxim,fan-health : Enable automated fan health check\n> > +- maxim,fan-ramp : Configures how fast the device ramps the PWM duty\n> > + cycle from one value to another. Valid values are 0\n> > + to 7 inclusive, with values 0 - 2 configuring a\n> > + 1000ms update rate and 1 - 3% duty respective duty\n> > + increase, and 3 - 7 a 200ms update rate with a 1 -\n> > + 5% respective duty increase. Default value is 0.\n> > +- maxim,fan-no-watchdog : Do not ramp fan to 100% PWM duty on failure to\n> > + update desired fan rate inside 10s. This implies\n> > + maxim,tmp-no-fault-ramp\n> > +- maxim,tmp-no-fault-ramp: Do not ramp fan to 100% PWM duty on temperature\n> > + sensor fault detection. This implies\n> > + maxim,fan-no-watchdog\n> > +- maxim,tmp-hysteresis : The temperature hysteresis used to determine\n> > + transitions to lower fan speed bands in the\n> > + temperature/fan rate lookup table. Valid values are\n> > + 2, 4, 6 or 8 (degrees celcius). Default value is 2.\n> > +- maxim,fan-dual-tach : Enable dual tachometer functionality\n> > +- maxim,fan-pwm-freq : The PWM frequency. Valid values are 30, 50, 100, 150\n> > + and 25000 (Hz). Default value is 30Hz.\n> > +- maxim,fan-lookup-table : A 16-element cell array of alternating temperature\n> > + and rate values representing the look up table. The\n> > + rate units are set through the fan-mode property.\n> > +- maxim,fan-fault-pin-mon: Ramp fans to 100% PWM duty when the FAULT pin is\n> > + asserted\n> \n> In general, I think a good portion of these should be either implied by \n> a fan compatible string or be part of a common fan binding.\n> \n> > +\n> > +Temperature\n> > +-----------\n> > +\n> > +Required subnode properties:\n> > +- compatible : Must be \"pmbus-temperature\"\n> > +- reg : The PMBus page the properties apply to.\n> > +\n> > +Optional subnode properties:\n> > +- maxim,tmp-offset : Valid values are 0 - 30 (degrees celcius) inclusive.\n> > + Default value is 0.\n> > +- maxim,tmp-fans : An array of phandles to fans controlled by the\n> > + current temperature sensor.\n> \n> Is this a feature of the Maxim chip or just a mapping of temperature \n> sensors to fans. The latter should be a common property.\n> \n> Rob","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","openbmc@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","openbmc@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwy1S48CCz9s7v\n\tfor ;\n\tTue, 19 Sep 2017 06:15:40 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xwy1S2XnGzDqGq\n\tfor ;\n\tTue, 19 Sep 2017 06:15:40 +1000 (AEST)","from mail-pf0-x244.google.com (mail-pf0-x244.google.com\n\t[IPv6:2607:f8b0:400e:c00::244])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xwy1K3BVqzDq5k\n\tfor ; Tue, 19 Sep 2017 06:15:33 +1000 (AEST)","by mail-pf0-x244.google.com with SMTP id g65so621661pfe.1\n\tfor ; Mon, 18 Sep 2017 13:15:33 -0700 (PDT)","from localhost (108-223-40-66.lightspeed.sntcca.sbcglobal.net.\n\t[108.223.40.66]) by smtp.gmail.com with ESMTPSA id\n\tc85sm260732pfj.118.2017.09.18.13.15.29\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 18 Sep 2017 13:15:29 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"meVQmUp5\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"meVQmUp5\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c00::244; helo=mail-pf0-x244.google.com;\n\tenvelope-from=groeck7@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"meVQmUp5\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=sender:date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=1DO6179WXbpXeJ1kK6v1puVr36umwkR6Qd+WOrmNBoY=;\n\tb=meVQmUp5vMTP8QMgsLdWjkYXkAEmgCVBY4I683ZBdYJcPN+2vwMStVhAg3xiOkJ8Bd\n\ti1lpmTRswHwuEnjf1VPJg/mUXIX5vyKAQ8/Q1JzlD2+Shq/lBel3satr97UbpJVTVApu\n\t8oiRLEWjAc2mZ9DhJ4ZK759YHhVxmZVW1i09Yhs/aSTflH9F0vAhP4XzhEc87OIHKUVZ\n\trQu1O400nMSC6wEtlR+RL06TtmAXwBjk2947kscrsq4/+MorHotFimv1YamWnGZkqo2c\n\tAsjXEIamWcLeBM9ACKQg12ZFq9fYibZ7mpA4ptjn3gAIYUCB/OmZHR0P15wncp0crXfu\n\tRSLw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:sender:date:from:to:cc:subject:message-id\n\t:references:mime-version:content-disposition:in-reply-to:user-agent; \n\tbh=1DO6179WXbpXeJ1kK6v1puVr36umwkR6Qd+WOrmNBoY=;\n\tb=W8lFUt4oDvoj6RX7HTsrg29nq65dgWTE48e+dMpIQ13yFk65zmxC6zLcAW/00kEfQ2\n\tDO0tHohk/YdryrKF19A0vKQw3kb4AFapXmikRji3n/q0mkn83Des9zhaglVtQU76VsVp\n\t+5/7qYipnxdgwUMafg0PhMtjLa9qfokYuuJkMl0ba+1Sg90PNbJenCe97BL3DpNAtwIr\n\tnJpH7HPplizCIUu+vObPpAMNsmMyVzMqwr2cT/qTYgd0djIQmrtONb9c8I9MvoAvgUvm\n\tGSP8pIdk6h23S6AwMmVtXSaZDf+E/oxxV1f6mzeDqpEUomvwRjr/4sAXYAEznFyYbCJD\n\tCecA==","X-Gm-Message-State":"AHPjjUgnlcSJC4dctrY/z18bdQmmWNS59NZmUWHMCqIyWScQXml3ozUe\n\tw8FsYfbEWYPEqA==","X-Google-Smtp-Source":"ADKCNb49fo42dmxMVdS1JiaIyiPNVgwRICeK1Pcbl2czxKQo04deq5ofvJmyNKOKpF9vBG+hPGnAqg==","X-Received":"by 10.98.216.132 with SMTP id\n\te126mr33833562pfg.276.1505765731160; \n\tMon, 18 Sep 2017 13:15:31 -0700 (PDT)","Date":"Mon, 18 Sep 2017 13:15:28 -0700","From":"Guenter Roeck ","To":"Rob Herring ","Subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","Message-ID":"<20170918201528.GA27615@roeck-us.net>","References":"<20170908043919.6924-1-andrew@aj.id.au>\n\t<20170908043919.6924-2-andrew@aj.id.au>\n\t<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>","User-Agent":"Mutt/1.5.24 (2015-08-30)","X-BeenThere":"openbmc@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Development list for OpenBMC ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-hwmon@vger.kernel.org, mark.rutland@arm.com, jdelvare@suse.com,\n\tdevicetree@vger.kernel.org, Andrew Jeffery ,\n\topenbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org","Errors-To":"openbmc-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"openbmc\"\n\t"}},{"id":1770682,"web_url":"http://patchwork.ozlabs.org/comment/1770682/","msgid":"<1505804214.4080.26.camel@aj.id.au>","list_archive_url":null,"date":"2017-09-19T06:56:54","subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","submitter":{"id":68332,"url":"http://patchwork.ozlabs.org/api/people/68332/","name":"Andrew Jeffery","email":"andrew@aj.id.au"},"content":"On Mon, 2017-09-18 at 14:26 -0500, Rob Herring wrote:\n> On Fri, Sep 08, 2017 at 02:39:17PM +1000, Andrew Jeffery wrote:\n> > > > Signed-off-by: Andrew Jeffery \n> > ---\n> >  .../devicetree/bindings/hwmon/pmbus/max31785.txt   | 158 +++++++++++++++++++++\n> \n> I think this needs to be located by what it does (fan control), not what \n> interface it has (pmbus).\n> \n> I'm not all that happy with hwmon either because things here seem to \n> just be based on being Linux hwmon devices which is sometimes arbitrary.\n\nI'll follow-up on this on Guenter's reply if necessary.\n\n>  \n> \n> >  1 file changed, 158 insertions(+)\n> >  create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> > \n> > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt b/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> > new file mode 100644\n> > index 000000000000..af9578e7742c\n> > --- /dev/null\n> > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/max31785.txt\n> > @@ -0,0 +1,158 @@\n> > +Bindings for the Maxim MAX31785 Intelligent Fan Controller\n> > +==========================================================\n> > +\n> > +Reference:\n> > +\n> > +https://datasheets.maximintegrated.com/en/ds/MAX31785.pdf\n> > +\n> > +Required properties:\n> > +- compatible     : One of \"maxim,max31785\" or \"maxim,max31785a\"\n> > +- reg            : I2C address, one of 0x52, 0x53, 0x54, 0x55.\n> > +- #address-cells : Must be 1\n> > +- #size-cells    : Must be 0\n> > +- #thermal-sensor-cells  : Should be 1. The device supports:\n> > +                           - One internal sensor\n> > +                           - Four external I2C digital sensors\n> > +                           - Six external thermal diodes\n> \n> You should define the IDs here, not just how many of each type.\n\nOkay.\n\n> \n> > +\n> > +Optional properties:\n> > +- use-stored-presence    : Do not treat the devicetree description as canon for\n> > +                           fan presence (the 'installed' bit of FAN_CONFIG_*).\n> > +                           Instead, rely on the on the default value store of\n> > +                           the device to populate it.\n> \n> Boolean? Please be explicit.\n\nOkay.\n\n> \n> Needs a vendor prefix.\n\nWe've discussed this previously. It's describing how to interpret part\nof the PMBus spec, not something Maxim have done, so I don't think it\nshould have a vendor prefix.\n\nBut maybe I'm representing it wrong?\n\n> \n> > +\n> > +Capabilities are configured through subnodes of the controller's node.\n> > +\n> > +Fans\n> > +----\n> > +\n> > +Only fans with subnodes present will be considered as installed. If\n> > +use-stored-presence is present in the parent node, then only fans that are both\n> > +defined in the devicetree and have their installed bit set are considered\n> > +installed.\n> > +\n> > +Required subnode properties:\n> > +- compatible             : Must be \"pmbus-fan\"\n> \n> \"pmbus\" is a property of the controller, not the fan, right? We should \n> have compatibles along the lines of the type of fan like 4-wire, 3-wire, \n> etc. \n\nYes, PMBus is a property of the controller. But a controller that\nimplements PMBus fan control and monitoring abstracts away most of the\ndetails of the fan hardware, so I don't see it fit to describe e.g. 4-\nwire or 3-wire properties here.\n\nPerhaps this is resolved by having a \"pmbus-fan-control\" compatible\nnode, and nesting a fan node under that? My concern would be that the\nonly element of the fan subnode would be the \"tach-pulses\" property\n(though maybe also dual-tach if we generalise the maxim,fan-dual-tach\nproperty below).\n\nRegardless, what I'm trying to describe here with the non-vendor-\nprefixed properties are configurable elements of the PMBus interface\nfor fan control. Adherence to PMBus by a device dictates the command\ninterface, and is therefore a property of the controller hardware at\nthe end of the day. In this instance (PMBus) I don't see how we can\ndraw the distinction between \"what it does\" and \"what interface it has\"\n- adherence to relevant parts of the PMBus spec defines the minimum of\nwhat the controller does (PMBus allows for vendor extensions).\nUnfortunately the PMBus spec is fairly loose in terms of what it\n*requires* you to implement, but I don't think that's relevant here.\n\n> \n> > +- reg                    : The PMBus page the properties apply to.\n> > +- #cooling-cells         : Should be 2. See the thermal bindings at [1].\n> > +- maxim,fan-rotor-input  : The type of rotor measurement provided to the\n> > +                           controller. Must be either \"tach\" for tachometer\n> > +                           pulses or \"lock\" for a locked-rotor signal.\n> > +- maxim,fan-lock-polarity: Required iff maxim,fan-rotor-input is \"lock\". Valid\n> > +                           values are \"low\" for active low, \"high\" for active\n> > +                           high.\n> > +\n> > +Optional subnode properties:\n> > +- fan-mode               : \"rpm\" or \"pwm\". Default value is \"pwm\".\n> > +- tach-pulses            : Tachometer pulses per revolution. Valid values are\n> > +                           1, 2, 3 or 4. The default is 1.\n> > +- cooling-min-level      : Smallest cooling state accepted. See [1].\n> > +- cooling-max-level      : Largest cooling state accepted. See [1].\n> > +- maxim,fan-no-fault-ramp: Do not ramp the fan to 100% PWM duty on detecting a\n> > +                           fan fault\n> > +- maxim,fan-startup      : The number of rotations required before taking\n> > +                           emergency action for an unresponsive fan and driving\n> > +                           it with 100% or 0% PWM duty, depending on the state\n> > +                           of maxim,fan-no-fault-ramp. Valid values are 0\n> > +                           (automatic spin-up disabled), 2, 4, or 8. Default\n> > +                           value is 0.\n> > +- maxim,fan-health       : Enable automated fan health check\n> > +- maxim,fan-ramp         : Configures how fast the device ramps the PWM duty\n> > +                           cycle from one value to another. Valid values are 0\n> > +                           to 7 inclusive, with values 0 - 2 configuring a\n> > +                           1000ms update rate and 1 - 3% duty respective duty\n> > +                           increase, and 3 - 7 a 200ms update rate with a 1 -\n> > +                           5% respective duty increase. Default value is 0.\n> > +- maxim,fan-no-watchdog  : Do not ramp fan to 100% PWM duty on failure to\n> > +                           update desired fan rate inside 10s. This implies\n> > +                           maxim,tmp-no-fault-ramp\n> > +- maxim,tmp-no-fault-ramp: Do not ramp fan to 100% PWM duty on temperature\n> > +                           sensor fault detection. This implies\n> > +                           maxim,fan-no-watchdog\n> > +- maxim,tmp-hysteresis   : The temperature hysteresis used to determine\n> > +                           transitions to lower fan speed bands in the\n> > +                           temperature/fan rate lookup table. Valid values are\n> > +                           2, 4, 6 or 8 (degrees celcius). Default value is 2.\n> > +- maxim,fan-dual-tach    : Enable dual tachometer functionality\n> > +- maxim,fan-pwm-freq     : The PWM frequency. Valid values are 30, 50, 100, 150\n> > +                           and 25000 (Hz). Default value is 30Hz.\n> > +- maxim,fan-lookup-table : A 16-element cell array of alternating temperature\n> > +                           and rate values representing the look up table. The\n> > +                           rate units are set through the fan-mode property.\n> > +- maxim,fan-fault-pin-mon: Ramp fans to 100% PWM duty when the FAULT pin is\n> > +                           asserted\n> \n> In general, I think a good portion of these should be either implied by \n> a fan compatible string or be part of a common fan binding.\n\nAbove you made the distinction between fan and fan controller, but I\nfeel like following your suggestion here is mixing things up in the\nopposite direction to what you desired above. In my mind most of these\nproperties describe a fan controller's capability rather than a\nproperty of a fan, save say \"tach-pulses\", which is a property of the\nfan's tacho, and maybe \"maxim,fan-dual-tach\" which applies to any dual-\nrotor fan and should probably be generalised.\n\n> \n> > +\n> > +Temperature\n> > +-----------\n> > +\n> > +Required subnode properties:\n> > +- compatible    : Must be \"pmbus-temperature\"\n> > +- reg           : The PMBus page the properties apply to.\n> > +\n> > +Optional subnode properties:\n> > +- maxim,tmp-offset      : Valid values are 0 - 30 (degrees celcius) inclusive.\n> > +                          Default value is 0.\n> > +- maxim,tmp-fans        : An array of phandles to fans controlled by the\n> > +                          current temperature sensor.\n> \n> Is this a feature of the Maxim chip or just a mapping of temperature \n> sensors to fans. The latter should be a common property.\n\nIt's a manufacturer-specific feature of the Maxim chip, which can do\nthe full closed-loop fan control using a lookup table mapping\ntemperatures to fan speeds. The lookup table can be described with the\nmaxim,fan-lookup-table property specified above, and maxim,tmp-fans\nmaps the temperature sensor to a set of fans to control using its\ntemperature readings with respect to each fan's lookup table.\n\nCheers,\n\nAndrew\n\n> \n> Rob","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","openbmc@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","openbmc@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxDFv654mz9rvt\n\tfor ;\n\tTue, 19 Sep 2017 16:57:23 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xxDFv4qCkzDqY3\n\tfor ;\n\tTue, 19 Sep 2017 16:57:23 +1000 (AEST)","from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com\n\t[66.111.4.25])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xxDFc2RgfzDqNh\n\tfor ; Tue, 19 Sep 2017 16:57:07 +1000 (AEST)","from compute4.internal (compute4.nyi.internal [10.202.2.44])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 89E2020D60;\n\tTue, 19 Sep 2017 02:57:05 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute4.internal (MEProxy); Tue, 19 Sep 2017 02:57:05 -0400","from keelia16 (unknown [203.0.153.9])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id 9BF097E372;\n\tTue, 19 Sep 2017 02:57:01 -0400 (EDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=aj.id.au header.i=@aj.id.au header.b=\"gl81ZEss\";\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"hflrKwtE\"; \n\tdkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=aj.id.au header.i=@aj.id.au header.b=\"gl81ZEss\";\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"hflrKwtE\"; \n\tdkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=aj.id.au\n\t(client-ip=66.111.4.25; helo=out1-smtp.messagingengine.com;\n\tenvelope-from=andrew@aj.id.au; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=aj.id.au header.i=@aj.id.au header.b=\"gl81ZEss\";\n\tdkim=pass (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com\n\theader.b=\"hflrKwtE\"; dkim-atps=neutral"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h=cc\n\t:content-type:date:from:in-reply-to:message-id:mime-version\n\t:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc\n\t:x-sasl-enc; s=fm1; bh=dex4U3lTsVlkgyPiGQrpGiX/ffz93k5zZ+MNEUe7g\n\tOs=; b=gl81ZEssXw3ZGJ+msQt6fX/afQpXCtc/zPcUIgx/bkqQE4iP93sLIgp6m\n\tvCEyRbr8+Iiy8llHQxYasVtuw1H7f4eSigh3selrduh/9UVkwWGyxIy/HXE2u59R\n\tNxzNyzlH4C27TeNEz+Q0UvHfAdr/JO6JLsbobbr9rDYJ/RieCieqm2Gqbo5MdX9D\n\tL67lt8cU9zVNNxvQpEYxHHqPvfHoyTlqYZciF5SGJ2yycpD0Lvhfnhc4oUfvBv2e\n\t95ZR5La+e/nbVJ2sHIdsReTKyzImcBfVbEbJ1JyxFDbArqDpiUBkrrOda9IlSQzJ\n\toN0Zc9mk9IGpzg1Tswur8y/0WtMZQ==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=dex4U3lTsVlkgyPiGQ\n\trpGiX/ffz93k5zZ+MNEUe7gOs=; b=hflrKwtEQjVtvZXinhrMvV0uCmx6DRSqB3\n\tJc9tGw7bY3jwQ7b5s9mggj0MUoccV4pJ8VVg3g1Qlg4DExq2KLIMlGXnDAaMNe3N\n\tAaQif1Wd+IgUTOKpkfvxfz8LWcTJDq9yDRVcEZN2yUrmr0qPIqF68DAgLVwqpXw2\n\tak6BWOP6iBfd5+PD97F5dGIFqsSR0uTKEtGccHXSG+Kv8p+odNHaaCQyb28DB/vg\n\tgps50xytX4IMmQhUieLRhlen6zcVWno+enjk8xFCJsxsOsUq5A5Oy5cp+vyZqGQY\n\t8srEcU4DIBEILTIiIKw54sNbFvSN4OMo+vD/19KFnZfaPGPXPibQ=="],"X-ME-Sender":"","X-Sasl-enc":"qCnIqbzI5OJ3bq6VeNuyR/juZY/E551SxnISs5rdNdfF 1505804224","Message-ID":"<1505804214.4080.26.camel@aj.id.au>","Subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","From":"Andrew Jeffery ","To":"Rob Herring ","Date":"Tue, 19 Sep 2017 16:26:54 +0930","In-Reply-To":"<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>","References":"<20170908043919.6924-1-andrew@aj.id.au>\n\t<20170908043919.6924-2-andrew@aj.id.au>\n\t<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>","Content-Type":"multipart/signed; micalg=\"pgp-sha512\";\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"=-v9g5Sjz6UiACRiidMV2k\"","X-Mailer":"Evolution 3.22.6-1ubuntu1 ","Mime-Version":"1.0","X-BeenThere":"openbmc@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Development list for OpenBMC ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-hwmon@vger.kernel.org, mark.rutland@arm.com, jdelvare@suse.com,\n\tdevicetree@vger.kernel.org, openbmc@lists.ozlabs.org,\n\tlinux-kernel@vger.kernel.org, linux@roeck-us.net","Errors-To":"openbmc-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"openbmc\"\n\t"}},{"id":1775161,"web_url":"http://patchwork.ozlabs.org/comment/1775161/","msgid":"<1506402405.30138.35.camel@aj.id.au>","list_archive_url":null,"date":"2017-09-26T05:06:45","subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","submitter":{"id":68332,"url":"http://patchwork.ozlabs.org/api/people/68332/","name":"Andrew Jeffery","email":"andrew@aj.id.au"},"content":"On Mon, 2017-09-18 at 13:15 -0700, Guenter Roeck wrote:\n> On Mon, Sep 18, 2017 at 02:26:38PM -0500, Rob Herring wrote:\n> > On Fri, Sep 08, 2017 at 02:39:17PM +1000, Andrew Jeffery wrote:\n> > > > > > Signed-off-by: Andrew Jeffery \n> > > ---\n> > >  .../devicetree/bindings/hwmon/pmbus/max31785.txt   | 158 +++++++++++++++++++++\n> > \n> > I think this needs to be located by what it does (fan control), not what \n> > interface it has (pmbus).\n> > \n> > I'm not all that happy with hwmon either because things here seem to \n> > just be based on being Linux hwmon devices which is sometimes arbitrary. \n> > \n> \n> The chip also measures temperatures. Other PMBus chips may do fan control,\n> measure temperatures, measure and/or control voltages, current, power ...\n> Strictly speaking pretty much all PMBus chips are multi-function devices.\n> I personally don't really care if the documentation is spread across\n> several directories, but even here this is already challenging.\n> \n> Only solution I can think of would be to create separate documents for each\n> functionality, ie here one for the device itself, one for fan control,\n> and one for temperature control (if that needs separate bindings). That\n> would be similar to mfd. But then we would still have to sort out where\n> to store the various bindings. Like iio, in subdirectories ? Like mfd,\n> in the matching subsystems ? If so, what to do if there is no matching\n> subsystem ?\n> \n> Lots of questions. I'll be happy to spend some time sorting it out,\n> but I would need some directions.\n> \n\nLikewise - I'm keen to discuss and iterate on this so we get something\nsatisfactory.\n\nAt least I could split out the PMBus-specific bindings from the Maxim-\nspecific bindings in the current document, but there's still the\nquestion of how to arrange it as Guenter has queried above, and also\nhow much of PMBus to define bindings for. I'm hesitant to take a stab\nat describing bindings across the whole spec if I don't have useful\ndriver implementations to test against. I know that the bindings\ndescribe the hardware and not the driver, but there are probably more\nor less clumsy ways to describe devices that could be ironed out with a\ncorresponding implementation (e.g. the Aspeed PWM/Tacho...).\n\nThoughts?\n\nAndrew","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","openbmc@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","openbmc@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1TTb6Synz9t4X\n\tfor ;\n\tTue, 26 Sep 2017 15:07:15 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3y1TTb45lKzDsP7\n\tfor ;\n\tTue, 26 Sep 2017 15:07:15 +1000 (AEST)","from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com\n\t[66.111.4.26])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3y1TTN44yjzDsMB\n\tfor ; Tue, 26 Sep 2017 15:07:03 +1000 (AEST)","from compute4.internal (compute4.nyi.internal [10.202.2.44])\n\tby mailout.nyi.internal (Postfix) with ESMTP id 411EF20CF5;\n\tTue, 26 Sep 2017 01:06:56 -0400 (EDT)","from frontend1 ([10.202.2.160])\n\tby compute4.internal (MEProxy); Tue, 26 Sep 2017 01:06:56 -0400","from keelia16 (unknown [203.0.153.9])\n\tby mail.messagingengine.com (Postfix) with ESMTPA id D447E7E430;\n\tTue, 26 Sep 2017 01:06:51 -0400 (EDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=aj.id.au header.i=@aj.id.au header.b=\"F3ecRL2u\";\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"sQ8lNH78\"; \n\tdkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=aj.id.au header.i=@aj.id.au header.b=\"F3ecRL2u\";\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com header.b=\"sQ8lNH78\"; \n\tdkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=aj.id.au\n\t(client-ip=66.111.4.26; helo=out2-smtp.messagingengine.com;\n\tenvelope-from=andrew@aj.id.au; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=aj.id.au header.i=@aj.id.au header.b=\"F3ecRL2u\";\n\tdkim=pass (2048-bit key;\n\tunprotected) header.d=messagingengine.com\n\theader.i=@messagingengine.com\n\theader.b=\"sQ8lNH78\"; dkim-atps=neutral"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h=cc\n\t:content-type:date:from:in-reply-to:message-id:mime-version\n\t:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc\n\t:x-sasl-enc; s=fm1; bh=TSUbxzDR9oFJPTuGJ5k3pcxbNn346i7DTUV1fix0Q\n\tbQ=; b=F3ecRL2u2ZXOCXtnkyyDh1bds0UpHWghntvI1jRze/4LMi9kPFk09sHzI\n\t2K2ASdT7RTi0SwOIGS9xYDwySD1MuRqLgyAUc8lD2dCIeQth/oMkda1uK2RG0lPs\n\tWBeKiiI8KPgMBCisrWO1ukGF9nkjLGuFk2/1/+gmXXYAJhrbe4xjPaygDZT8xIct\n\t8TmsHJsq+kSZb856g+5L49tcmjS971dHAutXzxnIL9fAad9HlsCFJgktxUNBEpg7\n\tcfY/QbXxqs0i33RoZpaGSWDiMBPQN2bHtTAfqJteObk44odq9lY9mA3VNZhXIAjV\n\tT3tEp7gacvpl2CSunEtUoEzUxynog==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to:x-me-sender\n\t:x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=TSUbxzDR9oFJPTuGJ5\n\tk3pcxbNn346i7DTUV1fix0QbQ=; b=sQ8lNH78eV1DJnyGf0THHYPjZwGEQNY/3o\n\t/rY1k72kZubdoCubmlN3+R1bWBfe4DnjX1Exf9JtgVssbfjzSapGgUs1Fp194wrW\n\t1/VPmEsyR2jWmppDKzEVx+nsiR32hyBnFYklTwox+KZBFZB6Ke2VysM7A+S/1lHK\n\tHhppsoTcw1BIv/dkmwgiuDbwsaM1z6pwgB4NfkOjUxVcD7xcDE7FzOnKFtG0qEha\n\tViU7QYvGANsVJvyqEHIXVR8od+CxMLi+v6LDuc5ydY8n45cfthBpJjniWX1Y9xf2\n\tlQJZruG+4WNrPg0XGjw4YShCXhXuGM9J5LyK9pbifVzhyUFZ9kKQ=="],"X-ME-Sender":"","X-Sasl-enc":"Lvmp+AwCg0SDT/FhgRMZetZdO/YGby/Bfb4w1BrfJExN 1506402415","Message-ID":"<1506402405.30138.35.camel@aj.id.au>","Subject":"Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add Maxim MAX31785\n\tdocumentation","From":"Andrew Jeffery ","To":"Guenter Roeck , Rob Herring ","Date":"Tue, 26 Sep 2017 14:36:45 +0930","In-Reply-To":"<20170918201528.GA27615@roeck-us.net>","References":"<20170908043919.6924-1-andrew@aj.id.au>\n\t<20170908043919.6924-2-andrew@aj.id.au>\n\t<20170918192638.4xqszyj466lrnpbz@rob-hp-laptop>\n\t<20170918201528.GA27615@roeck-us.net>","Content-Type":"multipart/signed; micalg=\"pgp-sha512\";\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"=-KAruN5h0taGOo6R+Ub+B\"","X-Mailer":"Evolution 3.22.6-1ubuntu1 ","Mime-Version":"1.0","X-BeenThere":"openbmc@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Development list for OpenBMC ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linux-hwmon@vger.kernel.org, mark.rutland@arm.com, jdelvare@suse.com,\n\tdevicetree@vger.kernel.org, openbmc@lists.ozlabs.org,\n\tlinux-kernel@vger.kernel.org","Errors-To":"openbmc-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"openbmc\"\n\t"}}]