Re: [PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Apr 17, 2021 at 07:51:27AM -0500, Nishanth Menon wrote:
> 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@xxxxxx>
> > > +
> > > +allOf:
> > > +  - $ref: /schemas/clock/clock.yaml#
> > 
> > Is this needed?

No. It is already applied to every node.

> 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.

No, the meta-schema is what checks the schemas just as the schemas check 
dts files.

> 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.

If this schema was standalone and not defined as part of another, then 
yes it would be required. In your case, you can enforce the node name 
from the parent schema. For consistency though, it would be better to 
just always require $nodename. 

Actually, this schema will be applied twice. On it's own matching the 
compatible string and by the parent schema. You can prevent that with 
'select: false'. I don't mind the double validation as if the parent 
node had a compatible typo you'd get zero validation.

> 
> > 
> > > +
> > > +  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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux