Re: led-gpios binding reporting a weird error

[Maxime Ripard <maxime@cerno.tech>]

[-- Attachment #1: Type: text/plain, Size: 4873 bytes --]

Hi,

On Mon, Mar 01, 2021 at 04:29:10PM -0600, Rob Herring wrote:
> On Wed, Feb 24, 2021 at 3:54 AM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > Hi Rob,
> >
> > On Fri, Feb 19, 2021 at 05:21:49PM -0600, Rob Herring wrote:
> > > On Fri, Feb 19, 2021 at 3:24 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > >
> > > > On Mon, Feb 01, 2021 at 10:52:35AM +0100, Maxime Ripard wrote:
> > > > > On Thu, Jan 14, 2021 at 12:15:04PM +0100, Maxime Ripard wrote:
> > > > > > Hi Rob,
> > > > > >
> > > > > > I just encountered a weird error with the led-gpios bindings.
> > >
> > > Sorry lost in the ether...
> > >
> > > > > >
> > > > > > Indeed, if we run, on today's next and the current master of the
> > > > > > dt-schema tools:
> > > > > >
> > > > > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/leds/leds-gpio.yaml make -j18 dt_binding_check
> > > > > >
> > > > > > we end up with:
> > > > > >   CHECK   Documentation/devicetree/bindings/leds/leds-gpio.example.dt.yaml
> > > > > > /home/max/Work/allwinner/build/arm64/Documentation/devicetree/bindings/leds/leds-gpio.example.dt.yaml: leds: led-1:default-state:0: 'keep' is not of type 'array'
> > > > > >     From schema: /home/max/Work/repos/linux/Documentation/devicetree/bindings/leds/leds-gpio.yaml
> > > > > > /home/max/Work/allwinner/build/arm64/Documentation/devicetree/bindings/leds/leds-gpio.example.dt.yaml: run-control: led-0:default-state:0: 'off' is not of type 'array'
> > > > > >     From schema: /home/max/Work/repos/linux/Documentation/devicetree/bindings/leds/leds-gpio.yaml
> > > > > > /home/max/Work/allwinner/build/arm64/Documentation/devicetree/bindings/leds/leds-gpio.example.dt.yaml: run-control: led-1:default-state:0: 'on' is not of type 'array'
> > > > > >     From schema: /home/max/Work/repos/linux/Documentation/devicetree/bindings/leds/leds-gpio.yaml
> > > > > >
> > > > > > What's being especially weird is that linux,default-trigger has the
> > > > > > exact same definition than default-state in leds/common.yaml (aside from
> > > > > > the set of valid values), and just works fine.
> > > > > >
> > > > > > Changing the name of default-state to something else also doesn't change
> > > > > > anything, so it doesn't look like this is some other schema interfering.
> > > > > > Do you have an idea?
> > >
> > > What does processed-schema-examples.json (run thru json_pp) look like
> > > for 'default-state'?
> >
> > The whole file is here: https://paste.ack.tf/fd7597@raw
> >
> > But the default-state schema itself is:
> >
> >          "default-state" : {
> >             "additionalItems" : false,
> >             "allOf" : [
> >                {
> >                   "$ref" : "/schemas/types.yaml#/definitions/string"
> >                }
> >             ],
> >             "default" : false,
> >             "items" : [
> >                {
> >                   "additionalItems" : false,
> >                   "items" : [
> >                      {
> >                         "enum" : [
> >                            true,
> >                            false,
> >                            "keep"
> >                         ]
> >                      }
> >                   ],
> >                   "maxItems" : 1,
> >                   "minItems" : 1,
> >                   "type" : "array"
> >                }
> >             ],
> >             "maxItems" : 1,
> >             "minItems" : 1,
> >             "type" : "array"
> >          },
> >
> > It looks like the error comes from on and off being expanded to true and
> > false for some reason, instead of being considered as string
> 
> on/off was treated as boolean in YAML 1.1. While the files say 1.2,
> dtschema changes them to 1.1 because ruamel.yaml at one point didn't
> support 1.2 with the C parser. It looks like the C and python parsers
> have different behavior, and I think you don't have the C based parser
> installed. The patch below fixes the problem for me if I force using
> the Python parser. Really, we should probably ensure the C parser is
> installed.
> 
> I am confused now why I added this code a year ago, but 1.2 support
> was added back in 2018.
> 
> 8<---------------------------------------------------
> diff --git a/dtschema/lib.py b/dtschema/lib.py
> index b18eda43fb12..d51ace7fe14f 100644
> --- a/dtschema/lib.py
> +++ b/dtschema/lib.py
> @@ -107,9 +107,7 @@ def do_load(filename):
>          if filename.endswith('.json'):
>              return json.load(f)
> 
> -        # ruamel C loader doesn't support 1.2, but 1.1 is good enough for us
> -        tmp = f.read().replace('YAML 1.2', 'YAML 1.1')
> -        return yaml.load(tmp)
> +        return yaml.load(f.read())

Yeah, that fixes things for me too (together with installing the C
version of ruamel)

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]