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: <20210417125127.vigq23mdoodje6b5@velcro>
Date:   Sat, 17 Apr 2021 07:51:27 -0500
From:   Nishanth Menon <nm@...com>
To:     Stephen Boyd <sboyd@...nel.org>
CC:     Michael Turquette <mturquette@...libre.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Tero Kristo <kristo@...nel.org>, <linux-clk@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema

On 16:55-20210416, Stephen Boyd wrote:
> Quoting Nishanth Menon (2021-04-15 23:37:19)
> > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > new file mode 100644
> > index 000000000000..72633651f0c7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: TI-SCI clock controller node bindings
> > +
> > +maintainers:
> > +  - Nishanth Menon <nm@...com>
> > +
> > +allOf:
> > +  - $ref: /schemas/clock/clock.yaml#
> 
> Is this needed?

https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
This standardizes provider properties like '#clock-cells' etc, allowing
you to add more stricter checks or controls in the future if necessary.

while:

https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
is more a consumer node description.

Should I have picked a different yaml as base for a standard clock-controller
base?

> 
> > +
> > +description: |
> > +  Some TI SoCs contain a system controller (like the Power Management Micro
> > +  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > +  the state of the various hardware modules present on the SoC. Communication
> > +  between the host processor running an OS and the system controller happens
> > +  through a protocol called TI System Control Interface (TI-SCI protocol).
> > +
> > +  This clock controller node uses the TI SCI protocol to perform various clock
> > +  management of various hardware modules (devices) present on the SoC. This
> > +  node must be a child node of the associated TI-SCI system controller node.
> > +
> > +properties:
> > +  $nodename:
> > +    pattern: "^clock-controller$"
> 
> Is this nodename pattern check required?

I'd like the definition on rails and not subject to interpretation, and
restrict the kind of subnodes under TISCI controller node.

> 
> > +
> > +  compatible:
> > +    const: ti,k2g-sci-clk
> 
> I thought most things keyed off the compatible string.

Yes, they are. I am not sure I understand your question here. Did you
mean to indicate that having $nodename and compatible both are
redundant?

Redundancy was'nt the intent of this schema definition, rather, I'd like
to make sure that it is not upto interpretation or debate as to what the
node name should be: I believe clock-controller is the correct nodename
(without @0x... since this does'nt use reg property) instead of using
clocks, tisci-clock as the node names.


Do you suggest something  different?

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ