[PATCH v2] dt-bindings: iio: adc: stm32-adc: convert bindings to json-schema

Rob Herring robh at kernel.org
Tue Jan 14 11:20:10 PST 2020


On Tue, Jan 14, 2020 at 10:02 AM Fabrice Gasnier <fabrice.gasnier at st.com> wrote:
>
> On 12/18/19 12:43 AM, Rob Herring wrote:
> > On Fri, Dec 06, 2019 at 05:17:08PM +0100, Fabrice Gasnier wrote:
> >> Convert the STM32 ADC binding to DT schema format using json-schema
> >>
> >> Signed-off-by: Fabrice Gasnier <fabrice.gasnier at st.com>
> >> ---
> >> Note: this applies on top of IIO tree currently (iio-for-5.5c).
> >>
> >> Changes in V2:
> >> - Take almost all of Rob suggestions (removed reg generic description,
> >>   added minItems, maxItems, st,max-clk-rate-hz range, drop some pipes,
> >>   simplify clock-names, remove unneeded allOfs)
> >> - For now, keep all in one file despite there are lots of if/thens in the
> >>   bindings
> >> ---
> >>  .../devicetree/bindings/iio/adc/st,stm32-adc.txt   | 149 -------
> >>  .../devicetree/bindings/iio/adc/st,stm32-adc.yaml  | 454 +++++++++++++++++++++
> >>  2 files changed, 454 insertions(+), 149 deletions(-)
> >>  delete mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> >>  create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
> >
> >
>
>
> [snip]
>
> >> +
> >> +      st,adc-channels:
> >> +        description: |
> >> +          List of single-ended channels muxed for this ADC. It can have up to:
> >> +            - 16 channels, numbered from 0 to 15 (for in0..in15) on stm32f4
> >> +            - 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and
> >> +              stm32mp1.
> >> +        allOf:
> >> +          - $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +
>
> [snip]
>
> >> +
> >> +    allOf:
> >> +      - if:
> >> +          properties:
> >> +            compatible:
> >> +              contains:
> >> +                const: st,stm32f4-adc
> >> +
> >> +        then:
> >> +          properties:
> >> +            reg:
> >> +              enum:
> >> +                - 0x0
> >> +                - 0x100
> >> +                - 0x200
> >> +
> >> +            interrupts:
> >> +              minimum: 0
> >> +              maximum: 2
> >> +
> >> +            assigned-resolution-bits:
> >> +              enum: [6, 8, 10, 12]
> >> +              default: 12
> >> +
> >> +            st,adc-channels:
> >> +              minItems: 1
> >> +              maxItems: 16
> >> +              minimum: 0
> >> +              maximum: 15
> >
> > You are mixing array and scalar constraints here. You need:
> >
> > minItems: 1
> > maxItems:16
> > items:
> >   minimum: 0
> >   maximum: 15
> >
> > Update dtschema. It will now catch this. There's a few others too.
>
> Hi Rob,
>
> Sorry for the late reply. I updated dtschema. Now it catches it.
>
> I've tried your suggestion, but when I test it, I don't get any error on
> maxItems.
>
> In the example: "st,adc-channels = <0>, <1>, ... more than 16 items;"
>
> Is it possible I face some other issue with dtschema ?

The problem is how "<0>, <1>" vs. "<0 1>" gets encoded. While those
are the same in the dtb, in yaml we have "[[0], [1]]" vs. "[[0, 1]]".
Making the brackets significant is helpful for some things like
phandle+args and 'reg' where we have a matrix of values, but for
arrays it just gets in the way. I think as I suggested is the right
form for the binding schema, and we need to either decide what's the
correct way for brackets or improve the tool to accept both ways.

Rob



More information about the linux-arm-kernel mailing list