linux-kernel - Re: [PATCH v5 07/13] dt-bindings: pwm: add a property "num-pwms"

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: <20190902160445.fitoa65t4ndzjq6v@pengutronix.de>
Date:   Mon, 2 Sep 2019 18:04:45 +0200
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Rob Herring <robh@...nel.org>
Cc:     Sam Shih <sam.shih@...iatek.com>,
        Mark Rutland <mark.rutland@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Ryder Lee <ryder.lee@...iatek.com>,
        John Crispin <john@...ozen.org>, linux-pwm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v5 07/13] dt-bindings: pwm: add a property "num-pwms"

On Tue, Aug 27, 2019 at 01:39:24PM -0500, Rob Herring wrote:
> On Thu, Aug 22, 2019 at 02:58:37PM +0800, Sam Shih wrote:
> > From: Ryder Lee <ryder.lee@...iatek.com>
> 
> The subject should indicate this is for Mediatek.
> 
> > 
> > This adds a property "num-pwms" in example so that we could
> > specify the number of PWM channels via device tree.
> > 
> > Signed-off-by: Ryder Lee <ryder.lee@...iatek.com>
> > Signed-off-by: Sam Shih <sam.shih@...iatek.com>
> > Reviewed-by: Matthias Brugger <matthias.bgg@...il.com>
> > Acked-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> > ---
> > Changes since v5:
> > - Add an Acked-by tag
> > - This file is original v4 patch 5/10
> > (https://patchwork.kernel.org/patch/11102577/)
> > 
> > Change-Id: I429048afeffa96f3f14533910efe242f88776043
> > ---
> >  Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > index 991728cb46cb..ea95b490a913 100644
> > --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > @@ -14,12 +14,12 @@ Required properties:
> >                  has no clocks
> >     - "top": the top clock generator
> >     - "main": clock used by the PWM core
> > -   - "pwm1-8": the eight per PWM clocks for mt2712
> > -   - "pwm1-6": the six per PWM clocks for mt7622
> > -   - "pwm1-5": the five per PWM clocks for mt7623
> > +   - "pwm1-N": the PWM clocks for each channel
> > +   where N starting from 1 to the maximum number of PWM channels
> 
> Once converted to schema, you are going to be back to listing them out.
> 
> >   - pinctrl-names: Must contain a "default" entry.
> >   - pinctrl-0: One property must exist for each entry in pinctrl-names.
> >     See pinctrl/pinctrl-bindings.txt for details of the property values.
> > + - num-pwms: the number of PWM channels.
> 
> You can't add new required properties without breaking compatibility. 
> 
> You already have to imply the number of channels from the compatible (or 
> number of clocks) and you have to keep doing so to maintain 
> compatibility, so why not just keep doing that for new chips?

This was a suggestion by me. The driver still handles compatibility
(i.e. falls back to the number of PWMs that was implied by the
compatible before). Given that there are various drivers that all solve
the same problem (i.e. different variants with different number of PWMs)
I thought it would be a good idea to introduce a property in the device
tree that specifies this number.

Only for newly introduced compatibles the num-pwms property is really
required. Differentiating the ones that need it and the ones that don't
seems over-engineered to me.

(BTW, using the number of clks doesn't really work because there are
also some variants without clocks. It is still under discussion if in
this case dummy-clocks should be provided IIRC.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |