Re: [PATCH 1/3] dt-bindings: arm: samsung: Force clkoutN names to be unique in PMU
From: Rob Herring
Date: Tue Oct 08 2019 - 10:05:48 EST
On Tue, Oct 8, 2019 at 7:50 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On Tue, Oct 08, 2019 at 07:38:14AM -0500, Rob Herring wrote:
> > On Fri, Oct 4, 2019 at 10:14 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > >
> > > The clkoutN names of clocks must be unique because they represent
> > > unique inputs of clock multiplexer.
> > >
> > > Signed-off-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> > > ---
> > > Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> > > index 73b56fc5bf58..d8e03716f5d2 100644
> > > --- a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> > > @@ -53,8 +53,10 @@ properties:
> > > List of clock names for particular CLKOUT mux inputs
> > > minItems: 1
> > > maxItems: 32
> > > - items:
> > > - pattern: '^clkout([0-9]|[12][0-9]|3[0-1])$'
> > > + allOf:
> > > + - items:
> > > + pattern: '^clkout([0-9]|[12][0-9]|3[0-1])$'
> > > + - uniqueItems: true
> >
> > You shouldn't need the 'allOf', just add uniqueItems at the same level as items.
>
> If you mean something like:
> 56 uniqueItems: true
> 57 items:
> 58 pattern: '^clkout([0-9]|[12][0-9]|3[0-1])$'
>
> Then the dt_binding_check fails:
>
> dev/linux/Documentation/devicetree/bindings/arm/samsung/pmu.yaml: properties:clock-names:
> 'uniqueItems' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'deprecated', 'description', 'else', 'enum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'type', 'typeSize', 'unevaluatedProperties']
I can add it.
The other option is to fix this in the clock schema. I'm not sure if
there's a need for duplicate clock-names. Seems unlikely. I'll test
that.
Rob