linux-kernel - Re: [PATCH v2] Documentation: clock: address more for clock-cells property

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] [day] [month] [year] [list]

Message-ID: <20170618140546.kbeeix3ckzshznmq@rob-hp-laptop>
Date:   Sun, 18 Jun 2017 09:05:46 -0500
From:   Rob Herring <robh@...nel.org>
To:     Chunyan Zhang <zhang.chunyan@...aro.org>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-clk <linux-clk@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Lyra Zhang <zhang.lyra@...il.com>
Subject: Re: [PATCH v2] Documentation: clock: address more for clock-cells
 property

On Wed, Jun 14, 2017 at 06:11:37PM +0800, Chunyan Zhang wrote:
> Hi Geert,
> 
> On 14 June 2017 at 17:42, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > Hi Chunyan,
> >
> > On Wed, Jun 14, 2017 at 11:21 AM, Chunyan Zhang
> > <zhang.chunyan@...aro.org> wrote:
> >> The value of property 'clock-cells' is not determined only by the number
> >> of clock outputs in one clock node, it is determined by whether the clock
> >> output in this node can be referenced directly without index. If the
> >> output clock has to be referenced by a index, the clock-cell of this
> >> clock node can't be defined 0.
> >>
> >> Signed-off-by: Chunyan Zhang <zhang.chunyan@...aro.org>
> >> ---
> >>  Documentation/devicetree/bindings/clock/clock-bindings.txt | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> index 2ec489e..e2b76b4 100644
> >> --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> @@ -18,6 +18,9 @@ Required properties:
> >>                    with a single clock output and 1 for nodes with multiple
> >>                    clock outputs.
> >>
> >> +                  There's one exception, please see the description for
> >> +                  clock-indices below.
> >> +
> >>  Optional properties:
> >>  clock-output-names: Recommended to be a list of strings of clock output signal
> >>                     names indexed by the first cell in the clock specifier.
> >> @@ -48,6 +51,13 @@ clock-indices:          If the identifying number for the clocks in the node
> >>                    is not linear from zero, then this allows the mapping of
> >>                    identifiers into the clock-output-names array.
> >>
> >> +                  This property not only servers for clocks with multiple
> >
> > serves
> 
> Thanks, I will fix that.
> 
> >
> >> +                  clock outputs, but also for clocks with a single clock
> >> +                  output whose identifying number is not zero.
> >
> > Why would you want a single clock and a non-zero identifying number?
> 
> Because of the probably weird hardwire design :)
> There indeed some clocks like that on the platform I'm working on.

But still, why do you care what the ID# is?

Rob