Re: [PATCH v3 2/2] dt-bindings: iio: Add ltc2983 documentation

["Sa, Nuno" <Nuno.Sa@analog.com>]

Hi Rob,

Somethings that I would like to clarify before sending a v4 since I'm
having errors and I'm not really sure about the fix I'm using.

On Tue, 2019-10-08 at 07:45 +0000, Sa, Nuno wrote:
> 
> On Mon, 2019-10-07 at 12:46 -0500, Rob Herring wrote:
> > On Mon, Oct 7, 2019 at 11:17 AM Sa, Nuno <Nuno.Sa@analog.com>
> > wrote:
> > > 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
> > > > > .y
> > > > > aml
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > > > 83
> > > > > .yam
> > > > > l
> > > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > > > 83
> > > > > .yam
> > > > > l
> > > > > new file mode 100644
> > > > > index 000000000000..b7101a0e84db
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc29
> > > > > 83
> > > > > .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
> > 
> > Yes.
> > 
> > > working. I understood and tried something like:
> > > 
> > > patternProperties:
> > >   "@([1-9]|1[0-9]|20)$":
> > >    (...)
> > > 
> > >    patternProperties:
> > 
> > What you are saying here is you have a patternProperty called
> > 'patternProperty'.
> > 
> > >      "^thermocouple@.*"
> > 
> > And then this is not a valid json-schema keyword for the property's
> > schema.
> > 
> > >      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@.*"?
> > 
> > Yes.
> > 
> > > > > +        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?
> > 
> > No, they have to be at the correct level. You can keep the
> > descriptions here. Just do:
> > 
> > adi,sensor-type:
> >  description: ...
> >  $ref: /schemas/types.yaml#/definitions/uint32
> > 
> > under ".*@([1-9]|1[0-9]|20)$" and drop the 'allOf: [ $ref: ...]'
> > part.
> > 

So, Im doing like:

".*@([1-9]|1[0-9]|20)$":
  type: object

  properties:
    reg:
      description: ...
      minimum: 1
      maximum: 20
   
    adi,sensor-type:
      description: ...
      $ref: /schemas/types.yaml#/definitions/uint32
  
  required:
    - reg
    - adi,sensor-type

Then in:

"^thermocouple@":
  type: object
  description: ...
  
  properties:
    adi,sensor-type:
      description: ...
      minimum: 1
      maximum: 9
   
This gives me that adi,sensor-type is not a valid schema. Adding allOf
before min/max fixes it. The same error comes in:

"^diode@":
type: object
  description: ...
  
  properties:
    adi,sensor-type:
      description: ...
      const: 28 #adding allOf here also fixes it...

One last issue that I was not seeing before is with the reg property.
If you recall, you also suggested to have it under ".*@([1-9]|1[0-
9]|20)$": and then add the 'minimum: 2' where needed. Doing that now
also gives me invalid schema:

"^rtd@":
type: object
  description: ...

  properties:
    reg:
      minimum: 2

Changing to
    reg:
      items:
        minimum: 2

fixes it but it feels that the first one should work?
The other issue I have is with int64-matrix which for now i guess it's
expected...

I updated the dtschema with `pip3 install --upgrade git+
https://github.com/devicetree-org/dt-schema.git@master`

Thanks for your help!
Nuno Sá

> > > > > +              - 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.y
> > > > am
> > > > l:
> > > > 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.
> > 
> > I can add those as well. At least for now, they are going to end up
> > being the exact same definition because IIRC while dtc takes signed
> > input, that's lost by the time we emit the output.
> 
> So, can I just add something like int64-matrix?
> 
> > > > > +            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.
> > 
> > I don't really know enough about this device to say... What does
> > 'custom' mean here?
> 
> Custom, is really if a user wants to provide a custom sensor, which
> is
> only supported for thermocouples, thermistors and RTDs. In those
> cases,
> the user provides a table of points describing the sensor response,
> which for example, on a thermocouple is voltage-temperature.
> 
> > > > > +            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?
> > 
> > Seems like it as the data is completely different.
> 
> I'm also feeling like I should have this property split in 2.
> 
> > > > > +        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?
> > 
> > We could add -milli-ohms. According to the datasheet, it's 0-
> > 131kohms
> > in 1/1024ohm steps.
> 
> We will loose a bit of resolution, but I guess milli-ohms is more
> than
> sufficient for practical/real usage.
> 
> > Rob

-- 
Analog Devices GmbH      Otl-Aicher Strasse 60-64      80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Stefan Steyerl, Thomas Edward Cribben, Michael Paul
Sondel