linux-kernel - Re: [PATCH v2 1/7] dt-bindings: pwm: allwinner: Add H6 PWM description

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: <CAJiuCcc7sQvuPX+FTErXS+_RzUDvbDrB3Z5EX9wE_2EZaex0qw@mail.gmail.com>
Date:   Tue, 5 Nov 2019 13:34:37 +0100
From:   Clément Péron <peron.clem@...il.com>
To:     Maxime Ripard <mripard@...nel.org>
Cc:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Thierry Reding <thierry.reding@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Chen-Yu Tsai <wens@...e.org>, linux-pwm@...r.kernel.org,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Pengutronix Kernel Team <kernel@...gutronix.de>
Subject: Re: [PATCH v2 1/7] dt-bindings: pwm: allwinner: Add H6 PWM description

Hi Maxime,

On Tue, 5 Nov 2019 at 12:11, Maxime Ripard <mripard@...nel.org> wrote:
>
> Hi Clement, Uwe,
>
> On Mon, Nov 04, 2019 at 09:03:59AM +0100, Uwe Kleine-König wrote:
> > On Sun, Nov 03, 2019 at 09:33:28PM +0100, Clément Péron wrote:
> > > From: Jernej Skrabec <jernej.skrabec@...l.net>
> > >
> > > H6 PWM block is basically the same as A20 PWM, except that it also has
> > > bus clock and reset line which needs to be handled accordingly.
> > >
> > > Expand Allwinner PWM binding with H6 PWM specifics.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@...l.net>
> > > Signed-off-by: Clément Péron <peron.clem@...il.com>
> > > ---
> > >  .../bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 45 ++++++++++++++++++-
> > >  1 file changed, 44 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> > > index 0ac52f83a58c..bf36ea509f31 100644
> > > --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> > > +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
> > > @@ -30,13 +30,46 @@ properties:
> > >        - items:
> > >            - const: allwinner,sun50i-h5-pwm
> > >            - const: allwinner,sun5i-a13-pwm
> > > +      - const: allwinner,sun50i-h6-pwm
> > >
> > >    reg:
> > >      maxItems: 1
> > >
> > > -  clocks:
> > > +  # Even though it only applies to subschemas under the conditionals,
> > > +  # not listing them here will trigger a warning because of the
> > > +  # additionalsProperties set to false.
> > > +  clocks: true
> > > +  clock-names: true
> > > +  resets:
> > >      maxItems: 1
> > >
> > > +  if:
> > > +    properties:
> > > +      compatible:
> > > +        contains:
> > > +          const: allwinner,sun50i-h6-pwm
> > > +
> > > +  then:
> > > +    properties:
> > > +      clocks:
> > > +        items:
> > > +          - description: Module Clock
> > > +          - description: Bus Clock
> > > +
> > > +      clock-names:
> > > +        items:
> > > +          - const: mod
> > > +          - const: bus
> > > +
> > > +    required:
> > > +      - clock-names
> > > +      - resets
> > > +
> > > +  else:
> > > +    properties:
> > > +      clocks:
> > > +        maxItems: 1
> > > +
> >
> > I guess this hunk says "If this is a allwinner,sun50i-h6-pwm, a mod and
> > bus clock is required.", right?
> >
> > I wonder if it is sensible to require a clock-names property in the else
> > branch, too. This would make it obvious if the clock there corresponds
> > to the "mod" or the "bus" clock on H6. (I guess it's "mod".)
>
> This can be done a bit differently and could address your concerns
>
> Something like
>
> properties:
>   ...
>
>   clocks:
>     minItems: 1
>     maxItems: 2
>     items:
>       - description: Bus Clock
>       - description: Module Clock
>
> required:
>   - clocks
>
> if:
>   ...
>
> then:
>   properties:
>     clocks:
>       maxItems: 2

Here we should set minItems to 2 right ?
so Max = Min = 2

Regards,
Clément

>
>     clocks-names:
>       items:
>         - const: mod
>         - const: bus
>
>     required:
>       - clock-names
>
> else:
>   properties:
>     clocks:
>       maxItems: 1
>
> That way, the definition of the order and which clock is which is
> pretty obvious in both cases, and we don't get any weird warnings.
>
> Maxime