* 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.