Re: [PATCH v2 1/2] dt-bindings: regulator: Add DA9121

[Rob Herring]

On Thu, Nov 5, 2020 at 3:39 AM Vincent Whitchurch
<vincent.whitchurch@xxxxxxxx> wrote:
>
> On Wed, Nov 04, 2020 at 07:57:55PM +0100, Rob Herring wrote:
> > On Tue, 03 Nov 2020 11:00:20 +0100, Vincent Whitchurch wrote:
> > > Add bindings for the Dialog Semiconductor DA9121 voltage regulator.
> > >
> > > Signed-off-by: Vincent Whitchurch <vincent.whitchurch@xxxxxxxx>
> > > ---
> > >  .../bindings/regulator/dlg,da9121.yaml        | 47 +++++++++++++++++++
> > >  1 file changed, 47 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
> > >
> >
> > My bot found errors running 'make dt_binding_check' on your patch:
> >
> > yamllint warnings/errors:
> >
> > dtschema/dtc warnings/errors:
> > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml: 'additionalProperties' is a required property
> > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml: ignoring, error in schema:
> > warning: no schema found in file: ./Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
> >
> > See https://patchwork.ozlabs.org/patch/1392753
>
> OK, thanks.  I'll fix it by changing the unevaluatedProperties to an
> additionalProperties (since the $ref has moved).
>
> I think I should also move the unevaluatedProperties to the buck1 level
> instead of removing it completely, because I see a bunch of other
> regulator bindings doing it, but the checks don't complain about that
> being missing and I can't see that making any difference for the
> validation.

Because the meta-schema is not recursing down levels. It probably
should, but that's another round of fixing all the current cases. And
the top-level is more well defined as to what the structure is (IOW,
we might not be able to define a rule that works everywhere).

> For example, I was hoping that this:
>
>   buck1:
>     description:
>       Initial data for the Buck1 regulator.
>     $ref: "regulator.yaml#"
>     type: object
>     unevaluatedProperties: false
>
> would complain about something like:
>
>         buck1 {
>           not-a-real-property;
>           regulator-min-microvolt = <680000>;
>           regulator-max-microvolt = <820000>;
>         };
>
> but it doesn't, so I don't quite understand what "unevaluatedProperties:
> false" prevents.

That's because it's currently a nop as the Python jsonschema package
doesn't yet support 2019.09 version of jsonschema.

If you aren't defining properties in addition to what's defined by a
$ref, then use additionalProperties.

Rob