* led-gpios binding reporting a weird error @ 2021-01-14 11:15 Maxime Ripard 2021-02-01 9:52 ` Maxime Ripard 0 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2021-01-14 11:15 UTC (permalink / raw) To: Rob Herring; +Cc: Frank Rowand, devicetree [-- Attachment #1: Type: text/plain, Size: 1499 bytes --] Hi Rob, I just encountered a weird error with the led-gpios bindings. 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? Thanks! Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-01-14 11:15 led-gpios binding reporting a weird error Maxime Ripard @ 2021-02-01 9:52 ` Maxime Ripard 2021-02-19 9:24 ` Maxime Ripard 0 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2021-02-01 9:52 UTC (permalink / raw) To: Rob Herring; +Cc: Frank Rowand, devicetree [-- Attachment #1: Type: text/plain, Size: 1684 bytes --] 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. > > 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? Ping? This error is still there on today's -next Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-02-01 9:52 ` Maxime Ripard @ 2021-02-19 9:24 ` Maxime Ripard 2021-02-19 23:21 ` Rob Herring 0 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2021-02-19 9:24 UTC (permalink / raw) To: Rob Herring; +Cc: Frank Rowand, devicetree [-- Attachment #1: Type: text/plain, Size: 1863 bytes --] 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. > > > > 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? > > Ping? This error is still there on today's -next and it looks like it's still there with yesterday's too Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-02-19 9:24 ` Maxime Ripard @ 2021-02-19 23:21 ` Rob Herring 2021-02-24 9:54 ` Maxime Ripard 0 siblings, 1 reply; 9+ messages in thread From: Rob Herring @ 2021-02-19 23:21 UTC (permalink / raw) To: Maxime Ripard; +Cc: Frank Rowand, devicetree 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'? > > Ping? This error is still there on today's -next > > and it looks like it's still there with yesterday's too I'm not seeing it in my CI test: https://gitlab.com/robherring/linux-dt-bindings/-/jobs/1041817756 I am seeing a change of yours causing warnings. :( Rob ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-02-19 23:21 ` Rob Herring @ 2021-02-24 9:54 ` Maxime Ripard 2021-03-01 22:29 ` Rob Herring 0 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2021-02-24 9:54 UTC (permalink / raw) To: Rob Herring; +Cc: Frank Rowand, devicetree [-- Attachment #1: Type: text/plain, Size: 3241 bytes --] 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 Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-02-24 9:54 ` Maxime Ripard @ 2021-03-01 22:29 ` Rob Herring 2021-03-02 10:25 ` Maxime Ripard 0 siblings, 1 reply; 9+ messages in thread From: Rob Herring @ 2021-03-01 22:29 UTC (permalink / raw) To: Maxime Ripard; +Cc: Frank Rowand, devicetree 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()) def load_schema(schema): for path in schema_user_paths: ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-03-01 22:29 ` Rob Herring @ 2021-03-02 10:25 ` Maxime Ripard 2021-03-02 14:19 ` Rob Herring 0 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2021-03-02 10:25 UTC (permalink / raw) To: Rob Herring; +Cc: Frank Rowand, devicetree [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-03-02 10:25 ` Maxime Ripard @ 2021-03-02 14:19 ` Rob Herring 2021-03-02 15:17 ` Maxime Ripard 0 siblings, 1 reply; 9+ messages in thread From: Rob Herring @ 2021-03-02 14:19 UTC (permalink / raw) To: Maxime Ripard; +Cc: Frank Rowand, devicetree On Tue, Mar 2, 2021 at 4:25 AM Maxime Ripard <maxime@cerno.tech> wrote: > > 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) I'm curious how do you not have it? It's a dependency for ruamel at least with pip and ubuntu/debian. Rob ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: led-gpios binding reporting a weird error 2021-03-02 14:19 ` Rob Herring @ 2021-03-02 15:17 ` Maxime Ripard 0 siblings, 0 replies; 9+ messages in thread From: Maxime Ripard @ 2021-03-02 15:17 UTC (permalink / raw) To: Rob Herring; +Cc: Frank Rowand, devicetree [-- Attachment #1: Type: text/plain, Size: 5800 bytes --] On Tue, Mar 02, 2021 at 08:19:16AM -0600, Rob Herring wrote: > On Tue, Mar 2, 2021 at 4:25 AM Maxime Ripard <maxime@cerno.tech> wrote: > > > > 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) > > I'm curious how do you not have it? It's a dependency for ruamel at > least with pip and ubuntu/debian. I don't remember (and history doesn't either) how I installed ruamel in the first place. I'm using fedora and the package wasn't installed, but I think I installed all the dt-schema dependencies through pip. So I might have had it all along Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-03-02 20:30 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-14 11:15 led-gpios binding reporting a weird error Maxime Ripard 2021-02-01 9:52 ` Maxime Ripard 2021-02-19 9:24 ` Maxime Ripard 2021-02-19 23:21 ` Rob Herring 2021-02-24 9:54 ` Maxime Ripard 2021-03-01 22:29 ` Rob Herring 2021-03-02 10:25 ` Maxime Ripard 2021-03-02 14:19 ` Rob Herring 2021-03-02 15:17 ` Maxime Ripard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.