linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: "robh+dt@kernel.org" <robh+dt@kernel.org>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"jic23@kernel.org" <jic23@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"knaack.h@gmx.de" <knaack.h@gmx.de>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
	"lars@metafoo.de" <lars@metafoo.de>
Subject: Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation
Date: Mon, 7 Oct 2019 16:17:02 +0000	[thread overview]
Message-ID: <27ff86f12b6f0e667c75014dfa0ce8f87087ba4e.camel@analog.com> (raw)
In-Reply-To: <CAL_Jsq+a7t5ZGf+7=LD2BnGRexJb6wpbBvvSFncgBKV-h3-7MA@mail.gmail.com>

On Mon, 2019-10-07 at 09:45 -0500, Rob Herring wrote:
> On Fri, Oct 4, 2019 at 8:55 AM Nuno Sá <nuno.sa@analog.com> wrote:
> > Document the LTC2983 temperature sensor devicetree bindings.
> > 
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > ---
> > Changes in v2:
> >  * Drop maxItems in non-array elements;
> >  * Set adi,mux-delay-config-us instead of adi,mux-delay-config;
> >  * Wrapped lines at 80 char;
> >  * Added comas to enum elements;
> >  * Use real units in adi,excitation-current;
> >  * Moved some enums to minimum and maximum;
> >  * Grouped patternProperties and moved reg property as a generic
> > property.
> > 
> > Changes in v3:
> >  * Add meaning to adi,sensor-type values which are not const;
> >  * Add meaning to adi,filter-notch-freq values;
> >  * Break up adi,sensor-config into human readable elements;
> >  * Set maxItems/minItems at the same identation as allOf in
> > adi,custom-sensor;
> >  * Fixed the maximum value for adi,sensor-type for sensors with
> > custom support;
> >  * Changed license to GPL-2.0-only as it should be for new
> > bindings;
> >  * Changed spi0 to spi in the dts example;
> >  * Updated the dts example to the new properties.
> > 
> >  .../bindings/iio/temperature/adi,ltc2983.yaml | 479
> > ++++++++++++++++++
> >  MAINTAINERS                                   |   1 +
> >  2 files changed, 480 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > l
> > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > l
> > new file mode 100644
> > index 000000000000..b7101a0e84db
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > l
> > @@ -0,0 +1,479 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> 
> (GPL-2.0-only OR BSD-2-Clause) for new bindings please.

ack.

> > +%YAML 1.2
> > +---
> > +$id: 
> > http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices LTC2983 Multi-sensor Temperature system
> > +
> > +maintainers:
> > +  - Nuno Sá <nuno.sa@analog.com>
> > +
> > +description: |
> > +  Analog Devices LTC2983 Multi-Sensor Digital Temperature
> > Measurement System
> > +  
> > https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - adi,ltc2983
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  interrupts:
> > +    maxItems: 1
> > +
> > +  adi,temperature-celcius:
> 
> -celsius. However, that suffix is reserved for properties whose value
> is in Celsius, so you'll have to come up with something else.
> 
> How does one decide how to set this? Seems like the driver should
> just
> decide based on what it needs to present to the user.

The device can report temperature in Celsius or Fahrenheit and that
should be decided once. Hmm but now that I think about this, the iio
standard attributes expect the value to be reported in milli degrees
Celsius so I guess I should just drop this and don't report in
Fahrenheit. Would this be ok Jonathan?

> > +    description:
> > +      If this property is present, the temperature is reported in
> > Celsius.
> > +    type: boolean
> > +
> > +  adi,mux-delay-config-us:
> > +    description:
> > +      The LTC2983 performs 2 or 3 internal conversion cycles per
> > temperature
> > +      result. Each conversion cycle is performed with different
> > excitation and
> > +      input multiplexer configurations. Prior to each conversion,
> > these
> > +      excitation circuits and input switch configurations are
> > changed and an
> > +      internal 1ms delay ensures settling prior to the conversion
> > cycle in most
> > +      cases. An extra delay can be configured using this property.
> > The value is
> > +      rounded to nearest 100us.
> > +    allOf:
> > +      - $ref: /schemas/types.yaml#/definitions/uint32
> > +      - maximum: 255
> 
> Standard unit suffixes already have a type, so just:
> 
> maximum: 255

got it.

> > +
> > +  adi,filter-notch-freq:
> > +    description:
> > +      Set's the default setting of the digital filter. The default
> > is
> > +      simultaneous 50/60Hz rejection.
> > +      0 - 50/60Hz rejection
> > +      1 - 60Hz rejection
> > +      2 - 50Hz rejection
> > +    allOf:
> > +      - $ref: /schemas/types.yaml#/definitions/uint32
> > +      - minimum: 0
> > +      - maximum: 2
> 
> Drop the '-' on the last entry (making the min/max a single schema).

got it.

> > +
> > +  '#address-cells':
> > +    const: 1
> > +
> > +  '#size-cells':
> > +    const: 0
> > +
> > +patternProperties:
> > +  ".*@([1-9]|1[0-9]|20)$":
> 
> '.*' can be dropped.
> 
> > +    type: object
> > +
> > +    properties:
> > +      reg:
> > +        description: |
> > +          The channel number. It can be connected to one of the 20
> > channels of
> > +          the device.
> > +        minimum: 1
> > +        maximum: 20
> > +
> > +    required:
> > +      - reg
> > +
> > +    patternProperties:
> > +      "^thermocouple@.*":
> 
> You've made this node a child of '.*@([1-9]|1[0-9]|20)$'. This needs
> to be at the same level.

You mean dropping "patternProperties" and having "^thermocouple@.*": on
the same indent as ".*@([1-9]|1[0-9]|20)$":? It seems to be only one
working. I understood and tried something like:

patternProperties:
  "@([1-9]|1[0-9]|20)$":
   (...)
   
   patternProperties:
     "^thermocouple@.*"
     description: "..."
     type: object
     properties:
     (...)

But this throws "'^thermocouple@' is not one of ['$ref',
'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const',
'contains', 'default', 'dependencies', 'deprecated', 'description',
'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems',
'maximum', 'not', 'oneOf', 'pattern', 'patternProperties',
'properties', 'required', 'then', 'type', 'typeSize']"

Also, should I also drop the ".*" in "^thermocouple@.*"?
> > +        type: object
> > +        description: |
> 
> You can drop the '|' where you don't need any formatting.

got it.

> > +          Represents a thermocouple sensor which is connected to
> > one of the device
> > +          channels.
> > +
> > +        properties:
> > +          adi,sensor-type:
> > +            description: |
> > +              Identifies the type of thermocouple connected to the
> > device.
> > +              1 - Type J Thermocouple
> > +              2 - Type K Thermocouple
> > +              3 - Type E Thermocouple
> > +              4 - Type N Thermocouple
> > +              5 - Type R Thermocouple
> > +              6 - Type S Thermocouple
> > +              7 - Type T Thermocouple
> > +              8 - Type B Thermocouple
> > +              9 - Custom Thermocouple
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> 
> You can move the type definition under ".*@([1-9]|1[0-9]|20)$" and
> then just have the min/max here.

And how could I add meaning to the values. Could I add all in the
"parent" node?

> > +              - minimum: 1
> > +              - maximum: 9
> > +
> > +          adi,single-ended:
> > +            description: |
> > +              Boolean property which set's the thermocouple as
> > single-ended.
> > +            type: boolean
> > +
> > +          adi,sensor-oc-current-microamp:
> > +            description: |
> > +              This property set's the pulsed current value applied
> > during
> > +              open-circuit detect.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - enum: [10, 100, 500, 1000]
> > +
> > +          adi,cold-junction-handle:
> > +            description: |
> > +              Phandle which points to a sensor object responsible
> > for measuring
> > +              the thermocouple cold junction temperature.
> > +            $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > +          adi,custom-sensor:
> > +            description: |
> > +              This is a table, where each entry should be a pair
> > of
> > +              voltage(mv)-temperature(K). The entries must be
> > given in nv and uK
> > +              so that, the original values must be multiplied by
> > 1000000. For
> 
> We normally do things in microVolts. It seems strange to need 64-bits
> of range for voltage and temperature.

This device support very high resolutions (so we have fractional
values). That is why I'm multiplying by 1000000 and using nV. And even
so, I already loose some bits. The 64bits are needed mainly because of
the Temperature and again the resolution I want to maximize. Doing
int(max(temp)) * 1000000, we need 64bits.

> 
> > +              more details look at table 69 and 70.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/int64-array
> 
> Fails on 'make dt_binding_check':
> 
> Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml:
> Unresolvable JSON pointer: 'definitions/int64-array'

I was aware of this but I do not know how to proceed so I was waiting
for your comment. I do have negative values, so uint does not apply.
What can I use here?

> If this is pairs of values, it should really be defined as a matrix:
> 
> minItems: 3
> maxItems: 64
> items:
>   minItems: 2
>   maxItems: 2
> 
> Though I'll need to add uint64-matrix as a type (assuming this really
> needs to be 64-bit).

I reinforce that I do need signed values here.

> 
> > +            minItems: 6
> > +            maxItems: 128
> > +
> > +        required:
> > +          - adi,sensor-type
> > +
> > +      "^diode@.*":
> > +        type: object
> > +        description: |
> > +          Represents a diode sensor which is connected to one of
> > the device
> > +          channels.
> > +
> > +        properties:
> > +          adi,sensor-type:
> > +            description: Identifies the sensor as a diode.
> > +            const: 28
> > +
> > +          adi,single-ended:
> > +            description: Boolean property which set's the diode as
> > single-ended.
> > +            type: boolean
> > +
> > +          adi,three-conversion-cycles:
> > +            description: |
> > +              Boolean property which set's three conversion cycles
> > removing
> > +              parasitic resistance effects between the LTC2983 and
> > the diode.
> > +            type: boolean
> > +
> > +          adi,average-on:
> > +            description: |
> > +              Boolean property which enables a running average of
> > the diode
> > +              temperature reading. This reduces the noise when the
> > diode is used
> > +              as a cold junction temperature element on an
> > isothermal block
> > +              where temperatures change slowly.
> > +            type: boolean
> > +
> > +          adi,excitation-current-microamp:
> > +            description: |
> > +              This property controls the magnitude of the
> > excitation current
> > +              applied to the diode. Depending on the number of
> > conversions
> > +              cycles, this property will assume different
> > predefined values on
> > +              each cycle. Just set the value of the first cycle
> > (1l).
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - enum: [10, 20, 40, 80]
> > +
> > +          adi,ideal-factor-value:
> > +            description: |
> > +              This property sets the diode ideality factor. The
> > real value must
> > +              be multiplied by 1000000 to remove the fractional
> > part. For more
> > +              information look at table 20 of the datasheet.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +        required:
> > +          - adi,sensor-type
> > +
> > +      "^rtd@.*":
> > +        type: object
> > +        description: |
> > +          Represents a rtd sensor which is connected to one of the
> > device channels.
> > +
> > +        properties:
> > +          reg:
> > +            minimum: 2
> > +
> > +          adi,sensor-type:
> > +            description: |
> > +              Identifies the type of RTD connected to the device.
> > +              10 - RTD PT-10
> > +              11 - RTD PT-50
> > +              12 - RTD PT-100
> > +              13 - RTD PT-200
> > +              14 - RTD PT-500
> > +              15 - RTD PT-1000
> > +              16 - RTD PT-1000 (0.00375)
> > +              17 - RTD NI-120
> > +              18 - RTD Custom
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - minimum: 10
> > +              - maximum: 18
> > +
> > +          adi,rsense-handle:
> > +            description: |
> > +              Phandle pointing to a rsense object associated with
> > this RTD.
> > +            $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > +          adi,number-of-wires:
> > +            description: |
> > +              Identifies the number of wires used by the RTD.
> > Setting this
> > +              property to 5 means 4 wires with Kelvin Rsense.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - enum: [2, 3, 4, 5]
> > +
> > +          adi,rsense-share:
> > +            description: |
> > +              Boolean property which enables Rsense sharing, where
> > one sense
> > +              resistor is used for multiple 2-, 3-, and/or 4-wire
> > RTDs.
> > +            type: boolean
> > +
> > +          adi,current-rotate:
> > +            description: |
> > +              Boolean property which enables excitation current
> > rotation to
> > +              automatically remove parasitic thermocouple effects.
> > Note that
> > +              this property is not allowed for 2- and 3-wire RTDs.
> > +            type: boolean
> > +
> > +          adi,excitation-current-microamp:
> > +            description: |
> > +              This property controls the magnitude of the
> > excitation current
> > +              applied to the RTD.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> 
> You can drop the type here too.

got it.

> > +              - enum: [5, 10, 25, 50, 100, 250, 500, 1000]
> > +
> > +          adi,rtd-curve:
> > +            description: |
> > +              This property set the RTD curve used and the
> > corresponding
> > +              Callendar-VanDusen constants. Look at table 30 of
> > the datasheet.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - minimum: 0
> > +              - maximum: 3
> > +
> > +          adi,custom-sensor:
> > +            description: |
> > +              This is a table, where each entry should be a pair
> > of
> > +              resistance(ohm)-temperature(K). The entries added
> > here are in uohm
> > +              and uK. For more details values look at table 74 and
> > 75.
> 
> It's not great to make one property name have different meanings.

Would you prefer to have something like "custom-rtd", "custom-
thermoucouple" and so on? I would have to adapt the code but I don't
think it would need to much of a change.

> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint64-
> > array
> > +            minItems: 6
> > +            maxItems: 128
> > +
> > +        required:
> > +          - adi,sensor-type
> > +          - adi,rsense-handle
> > +
> > +        dependencies:
> > +          adi,current-rotate: [ adi,rsense-share ]
> > +
> > +      "^thermistor@.*":
> > +        type: object
> > +        description: |
> > +          Represents a thermistor sensor which is connected to one
> > of the device
> > +          channels.
> > +
> > +        properties:
> > +          adi,sensor-type:
> > +            description: |
> > +              Identifies the type of thermistor connected to the
> > +              device.
> > +              19 - Thermistor 44004/44033 2.252kohm at 25°C
> > +              20 - Thermistor 44005/44030 3kohm at 25°C
> > +              21 - Thermistor 44007/44034 5kohm at 25°C
> > +              22 - Thermistor 44006/44031 10kohm at 25°C
> > +              23 - Thermistor 44008/44032 30kohm at 25°C
> > +              24 - Thermistor YSI 400 2.252kohm at 25°C
> > +              25 - Thermistor Spectrum 1003k 1kohm
> > +              26 - Thermistor Custom Steinhart-Hart
> > +              27 - Custom Thermistor
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - minimum: 19
> > +              - maximum: 27
> > +
> > +          adi,rsense-handle:
> > +            description: |
> > +              Phandle pointing to a rsense object associated with
> > this
> > +              thermistor.
> > +            $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > +          adi,single-ended:
> > +            description: |
> > +              Boolean property which set's the thermistor as
> > single-ended.
> > +            type: boolean
> > +
> > +          adi,rsense-share:
> > +            description: |
> > +              Boolean property which enables Rsense sharing, where
> > one sense
> > +              resistor is used for multiple thermistors. Note that
> > this property
> > +              is ignored if adi,single-ended is set.
> > +            type: boolean
> > +
> > +          adi,current-rotate:
> > +            description: |
> > +              Boolean property which enables excitation current
> > rotation to
> > +              automatically remove parasitic thermocouple effects.
> > +            type: boolean
> > +
> > +          adi,excitation-current-nanoamp:
> > +            description: |
> > +              This property controls the magnitude of the
> > excitation current
> > +              applied to the thermistor. Value 0 set's the sensor
> > in auto-range
> > +              mode.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint32
> > +              - enum: [0, 250, 500, 1000, 5000, 10000, 25000,
> > 50000, 100000,
> > +                       250000, 500000, 1000000]
> > +
> > +          adi,custom-sensor:
> > +            description: |
> > +              This is a table, where each entry should be a pair
> > of
> > +              resistance(ohm)-temperature(K). The entries added
> > here are in uohm
> > +              and uK only for custom thermistors. For more details
> > look at table
> > +              78 and 79. Steinhart-Hart coefficients are also
> > supported and can
> > +              be programmed into the device memory using this
> > property. For
> > +              Steinhart sensors, this table has a constant size of
> > 6 entries
> > +              (defining the coefficients) and the values are given
> > in the raw
> > +              format. Look at table 82 for more information.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint64-
> > array
> > +            minItems: 6
> > +            maxItems: 128
> > +

If I'm to replace this property as proposed before, would it make sense
also to split this in custom-thermistor and custom-steinhart or just
steinhart?

> > +        required:
> > +          - adi,sensor-type
> > +          - adi,rsense-handle
> > +
> > +        dependencies:
> > +          adi,current-rotate: [ adi,rsense-share ]
> > +
> > +      "^adc@.*":
> > +        type: object
> > +        description: Represents a channel which is being used as a
> > direct adc.
> > +
> > +        properties:
> > +          adi,sensor-type:
> > +            description: Identifies the sensor as a direct adc.
> > +            const: 30
> > +
> > +          adi,single-ended:
> > +            description: Boolean property which set's the adc as
> > single-ended.
> > +            type: boolean
> > +
> > +        required:
> > +          - adi,sensor-type
> > +
> > +      "^rsense@.*":
> > +        type: object
> > +        description: |
> > +          Represents a rsense which is connected to one of the
> > device channels.
> > +          Rsense are used by thermistors and RTD's.
> > +
> > +        properties:
> > +          reg:
> > +            minimum: 2
> > +
> > +          adi,sensor-type:
> > +            description: Identifies the sensor as a rsense.
> > +            const: 29
> > +
> > +          adi,rsense-val-micro-ohms:
> > +            description: |
> > +              Sets the value of the sense resistor. Look at table
> > 20 of the
> > +              datasheet for information.
> > +            allOf:
> > +              - $ref: /schemas/types.yaml#/definitions/uint64
> 
> -micro-ohms is already defined to be 32-bit.
 
I do need a 64-bit variable here. Should I still remove the $ref or how
can I proceed?

> > +
> > +        required:
> > +          - adi,sensor-type
> > +          - adi, rsense-val
> 
> spurious space.

got it.

> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    spi {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        sensor_ltc2983: ltc2983@0 {
> > +                compatible = "adi,ltc2983";
> > +                reg = <0>;
> > +
> > +                #address-cells = <1>;
> > +                #size-cells = <0>;
> > +
> > +                adi,temperature-celcius;
> > +                interrupts = <20 IRQ_TYPE_EDGE_RISING>;
> > +                interrupt-parent = <&gpio>;
> > +
> > +                thermocouple@18 {
> > +                        reg = <18>;
> > +                        adi,sensor-type = <8>; //Type B
> > +                        adi,sensor-oc-current-microamp = <10>;
> > +                        adi,cold-junction-handle = <&diode5>;
> > +                };
> > +
> > +                diode5: diode@5 {
> > +                        reg = <5>;
> > +                        adi,sensor-type = <28>;
> > +                };
> > +
> > +                rsense2: rsense@2 {
> > +                        reg = <2>;
> > +                        adi,sensor-type = <29>;
> > +                        adi,rsense-val-micro-ohms = /bits/ 64
> > <1200000000>; //1.2Kohms
> > +                };
> > +
> > +                rtd@14 {
> > +                        reg = <14>;
> > +                        adi,sensor-type = <15>; //PT1000
> > +                        /*2-wire, internal gnd, no current
> > rotation*/
> > +                        adi,number-of-wires = <2>;
> > +                        adi,rsense-share;
> > +                        adi,excitation-current-microamp = <500>;
> > +                        adi,rsense-handle = <&rsense2>;
> > +                };
> > +
> > +                adc@10 {
> > +                        reg = <10>;
> > +                        adi,sensor-type = <30>;
> > +                        adi,single-ended;
> > +                };
> > +
> > +                thermistor@12 {
> > +                        reg = <12>;
> > +                        adi,sensor-type = <26>; //Steinhart
> > +                        adi,rsense-handle = <&rsense2>;
> > +                        adi,custom-sensor = /bits/ 64 <0x00F371EC
> > 0x12345678
> > +                                        0x2C0F8733 0x10018C66
> > 0xA0FEACCD
> > +                                        0x90021D99>; //6 entries
> > +                };
> > +
> > +                thermocouple@20 {
> > +                        reg = <20>;
> > +                        adi,sensor-type = <9>; //custom
> > thermocouple
> > +                        adi,single-ended;
> > +                        adi,custom-sensor = /bits/ 64
> > +                                 <(-50220000) 0
> > +                                  (-30200000) 99100000
> > +                                  (-5300000) 135400000
> > +                                  0 273150000
> > +                                  40200000 361200000
> > +                                  55300000 522100000
> > +                                  88300000 720300000
> > +                                  132200000 811200000
> > +                                  188700000 922500000
> > +                                  460400000 1000000000>; //10
> > pairs
> > +               };
> > +
> > +        };
> > +    };
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 14a256e785ca..f747a9dc27f5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9497,6 +9497,7 @@ W:        
> > http://ez.analog.com/community/linux-device-drivers
> >  L:     linux-iio@vger.kernel.org
> >  S:     Supported
> >  F:     drivers/iio/temperature/ltc2983.c
> > +F:     Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > 83.yaml
> > 
> >  LTC4261 HARDWARE MONITOR DRIVER
> >  M:     Guenter Roeck <linux@roeck-us.net>
> > --
> > 2.23.0
> > 


  reply	other threads:[~2019-10-07 16:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 13:55 [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Nuno Sá
2019-10-04 13:55 ` [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation Nuno Sá
2019-10-06 10:29   ` Jonathan Cameron
2019-10-07 14:45   ` Rob Herring
2019-10-07 16:17     ` Sa, Nuno [this message]
2019-10-07 17:46       ` Rob Herring
2019-10-08  7:45         ` Sa, Nuno
2019-10-08 10:22           ` Sa, Nuno
2019-10-10 20:03             ` Rob Herring
2019-10-12 10:41       ` Jonathan Cameron
2019-10-06 10:37 ` [PATCH v3 1/2] iio: temperature: Add support for LTC2983 Jonathan Cameron
2019-10-07  9:10   ` Sa, Nuno
2019-10-07 11:52     ` Jonathan Cameron
2019-10-07 12:33       ` Sa, Nuno
2019-10-08 10:55 ` Sa, Nuno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27ff86f12b6f0e667c75014dfa0ce8f87087ba4e.camel@analog.com \
    --to=nuno.sa@analog.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).