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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 16, 2019 at 10:20 AM Sa, Nuno <Nuno.Sa@xxxxxxxxxx> wrote:
>
> Hi Rob and Jonathan,
>
> Some comments/questions inline.
>
> Nuno Sá
>
> On Sun, 2019-09-15 at 12:07 +0100, Jonathan Cameron wrote:
> >
> > On Fri, 13 Sep 2019 15:36:21 +0100
> > Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > > On Mon, Sep 09, 2019 at 04:45:50PM +0200, Nuno Sá wrote:
> > > > Document the LTC2983 temperature sensor devicetree bindings.
> > > >
> > > > Signed-off-by: Nuno Sá <nuno.sa@xxxxxxxxxx>
> > > > ---
> > > >  .../bindings/iio/temperature/adi,ltc2983.yaml | 442
> > > > ++++++++++++++++++
> > > >  MAINTAINERS                                   |   1 +
> > > >  2 files changed, 443 insertions(+)
> > > >  create mode 100644
> > > > Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yam
> > > > l
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.y
> > > > aml
> > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.y
> > > > aml
> > > > new file mode 100644
> > > > index 000000000000..2b468b3ed177
> > > > --- /dev/null
> > > > +++
> > > > b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.y
> > > > aml
> > > > @@ -0,0 +1,442 @@
> > > > +# SPDX-License-Identifier: GPL-2.0
> > > > +%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@xxxxxxxxxx>
> > > > +
> > > > +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:
> > > > +    description:
> > > > +      If this property is present, the temperature is reported
> > > > in Celsius.
> > > > +    type: boolean
> > > > +    maxItems: 1
> > >
> > > It's a boolean, not an array so 'maxItems' doesn't make sense.
> > >
> > > Running 'make dt_binding_check' should tell you this. You may need
> > > to
> > > update dt-schema install though.
>
> Rob, I'm having some issues with `make dt_binding_check`. I updated dt-
> schema and I get this when run it:
>
> ...
> "ruamel.yaml.constructor.DuplicateKeyError: while constructing a
> mapping
>   in "<unicode string>", line 4, column 1
> found duplicate key "patternProperties" with value "{}" (original
> value: "{}")
>   in "<unicode string>", line 113, column 1"

Simply drop all but the first 'patternProperties'. You can have
multiple patterns under one.

>
> If you want, I can paste the complete traceback in a following email.
> However I could use `dt-doc-validate
> Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml`
> directly by doing a manual change in `dt-doc-validate `. I changed the
> call `testtree = dtschema.load(filename, line_number=line_number,
> duplicate_keys=False)` to `testtree = dtschema.load(filename,
> line_number=line_number, duplicate_keys=True)`. Is this something
> already known? I would not be surprised if it is some problem in my
> environment. However, I even tried this in a clean docker container
> based on ubuntu 18.04 and got the same behavior.

[...]

> > > > +patternProperties:
> > > > +  "^rtd@([2-9]|1[0-9]|20)$":
> > > > +    type: object
> > > > +    description: Represents a rtd sensor which is connected to
> > > > one of the device channels.
> > > > +
> > > > +    properties:
> > > > +      reg:
> > > > +        description: |
> > > > +          The channel number. It can be connected to one of the
> > > > 20 channels of the device.
> > > > +        minimum: 2
> > > > +        maximum: 20
> > > > +        maxItems: 1
> > >
> > > As this is pretty much the same for all child nodes, make a pattern
> > > that
> > > matches all child nodes and put this there rather than duplicating
> > > it.
> > > Then you only need 'minimum: 2' in the cases needing that.
>
> I'm not sure I'm following your point here. So it's better to clarify
> it before sending a v2. Do you mean to add something like:
>
> patternProperties:
>   "^(thermocouple|diode|rtd|thermistor|adc|rsense)@([1-9]|1[0-9]|20)$"

Just ".*@([1-9]|1[0-9]|20)$" is fine.

>     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
>
> And then, for instance, for a RTD I would have:
>
> patternProperties:
>   "^rtd@([2-9]|1[0-9]|20)$"

You've already defined the unit-address format above, so '^rtd@.*'
would be sufficient here.

>
>     ...
>
>     properties:
>       reg:
>        minimum: 2
>
>     ...
>
> Would this also make sense, or it's not really necessary?

Yes, makes sense.

>
> patternProperties:
>   "^thermocouple@([1-9]|1[0-9]|20)$"
>     type: object
>
>     ...
>
>     properties:
>       reg:
>        description: For differential thermocouples, the minimum is 2.

Why do you have a constraint in free form text here?

>
>     ...
>
> Am I understanding it correctly?
> > > > +thermistor
> > > > +      adi,sensor-type:
> > > > +        description: |
> > > > +          Identifies the type of RTD connected to the device.
> > > > +        allOf:
> > > > +          - $ref: /schemas/types.yaml#/definitions/uint32
> > > > +          - enum: [10 11 12 13 14 15 16 17]
> > > > +        maxItems: 1
> > > > +
> > > > +      adi,rsense-handle:
> > > > +        description: |
> > > > +          Phandle pointing to a rsense object associated with
> > > > this RTD.
> > > > +        $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +        maxItems: 1
> > > > +
> > > > +      adi,sensor-config:
> > > > +        description: |
> > > > +          Raw value which set's the sensor configuration. Look
> > > > at table 28 of the
> > > > +          datasheet for how to set this value for RTD's.
> > > > +        allOf:
> > > > +          - $ref: /schemas/types.yaml#/definitions/uint32
> > > > +          - enum: [0 1 4 5 8 9 10 12 13 14]
> > > > +        maxItems: 1
> > > > +
> > > > +      adi,excitation-current:
> > > > +        description: |
> > > > +          This property controls the magnitude of the excitation
> > > > current applied
> > > > +          to the RTD. Look at table 29 of the datasheet for more
> > > > info.
> >
> > Any way we can make this real units?  Can list valid value here.
>
> For RTD's and diodes, it is possible to have it with real units.
> However, for thermistors it's not really doable since, for instance,
> for them we have an "Auto Range" setting. So, I just wanted to be
> consistent through all sensors having excitation-current configuration.
> Do you prefer to have it in real units where possible?

That's the preference if it makes sense. I have no idea what an RTD is
to comment further.

Rob




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux