linux-kernel - Re: [PATCH v2 4/4] dt-bindings: clk: versaclock5: convert to yaml

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6177ebd1-b39a-3b53-3f5b-92f8d1f9881b@lucaceresoli.net>
Date:   Tue, 14 Jul 2020 11:15:52 +0200
From:   Luca Ceresoli <luca@...aceresoli.net>
To:     Rob Herring <robh@...nel.org>
Cc:     linux-clk@...r.kernel.org,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Marek Vasut <marek.vasut@...il.com>,
        Adam Ford <aford173@...il.com>
Subject: Re: [PATCH v2 4/4] dt-bindings: clk: versaclock5: convert to yaml

Hi Rob,

thanks for you review!

On 14/07/20 05:11, Rob Herring wrote:
> On Wed, Jul 08, 2020 at 09:40:35AM +0200, Luca Ceresoli wrote:
>> Convert to yaml the VersaClock bindings document. The mapping between
>> clock specifier and physical pins cannot be described formally in yaml
>> schema, then keep it verbatim in the description field.
>>
>> Signed-off-by: Luca Ceresoli <luca@...aceresoli.net>

[...]

>> +  reg:
>> +    maxItems: 1
>> +    description: I2C device address, shall be 0x68 or 0x6a.
> 
> Can be a schema:
> 
> enum: [ 0x68, 0x6a ]

Nice, will fix.

>> +
>> +  '#clock-cells':
>> +    const: 1
>> +
>> +patternProperties:
>> +  "^OUT[1-4]$":
>> +    type: object
>> +    description:
>> +      Description of one of the outputs (OUT1..OUT4). See "Clock1 Output
>> +      Configuration" in the Versaclock 5/6/6E Family Register Description
>> +      and Programming Guide.
>> +    properties:
>> +      idt,mode:
>> +        description:
>> +          The output drive mode. Values defined in dt-bindings/clk/versaclock.h
>> +        enum:
>> +          - VC5_LVPECL
> 
> This is defining a string. Can't use defines here.

How do I use the defines from include/dt-bindings then? Or should I just
use the numeric values then, like:

  idt,mode:
    description:
      The output drive mode. Values defined in
      dt-bindings/clk/versaclock.h
    minimum: 0
    maximum: 6

?

>> +      idt,voltage-microvolts:
>> +        description: The output drive voltage.
>> +        $ref: /schemas/types.yaml#/definitions/uint32
> 
> Standard unit suffixes have a type already, so drop.

Ok.

>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - idt,5p49v5933
>> +              - idt,5p49v5935
>> +    then:
>> +      # Devices with builtin crystal, optional external input
>> +      properties:
>> +        clock-names:
>> +          const: clkin
>> +        clocks:
>> +          maxItems: 1
>> +    else:
>> +      # Devices without builtin crystal
>> +      properties:
>> +        clock-names:
>> +          anyOf:
>> +            - required: [ xin ]
>> +            - required: [ clkin ]
> 
> This isn't valid. I think you want:
> 
> clock-names:
>   minItems: 1
>   items:
>     - const: xin
>     - const: clkin
> 
> This would mean 'xin' is always required, clkin is optional.

No, what I wanted to mean is that allowed cases are:
 * for idt,5p49v5933 and idt,5p49v5935:
   - only 'xin' (required)
 * for the other parts one of these:
   - only 'xin'
   - only 'clkin'
   - both 'xin' and 'clkin'

How do I express that?


A general note: as a newcomer to yaml bindings I found a steep learning
curve. Finding a correct construct (not to mention the best one) for
each situation is time consuming and frustrating. I've been looking at
existing files for suitable examples but it doesn't work very well.

Is there any guide to yaml bindings for beginners with examples of
typical cases? It would greatly help in producing better patches and
saving time for everybody.

Thanks,
-- 
Luca