On Wed, Feb 24, 2021 at 3:54 AM Maxime Ripard <maxime@xxxxxxxxxx> 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@xxxxxxxxxx> 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()) def load_schema(schema): for path in schema_user_paths:
