linux-kernel - Re: [PATCH 1/2] regulator: dt-bindings: gpio-regulator: Fix {gpios-,}states limits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdWmVs2m3bX=21Ocw8y=8WDJfFy2dami3aC9Kj-4PokDEQ@mail.gmail.com>
Date: Fri, 2 Feb 2024 09:11:00 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Rob Herring <robh@...nel.org>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, 
	Linus Walleij <linus.walleij@...aro.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Marek Szyprowski <m.szyprowski@...sung.com>, devicetree@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] regulator: dt-bindings: gpio-regulator: Fix
 {gpios-,}states limits

Hi Rob,

On Thu, Feb 1, 2024 at 11:11 PM Rob Herring <robh@...nel.org> wrote:
> On Thu, Feb 01, 2024 at 04:58:41PM +0100, Geert Uytterhoeven wrote:
> > make dtbs_check:
> >
> >     arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb: regulator-vccq-sdhi0: Unevaluated properties are not allowed ('gpios-states', 'states' were unexpected)
> >           from schema $id: http://devicetree.org/schemas/regulator/gpio-regulator.yaml#
>
> Unevaluated properties warning here is not interesting. If a property
> fails validation, then it is considered unevaluated. It's that warning
> which is interesting:
>
> arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb: regulator-vccq-sdhi0: gpios-states:0: [1] is too short
>         from schema $id: http://devicetree.org/schemas/regulator/gpio-regulator.yaml#

Oops (again, I'm afraid my mind is already living at FOSDEM ;-),
I copy-'n-pasted the wrong message...

> > The number of items in "gpios-states" must match the number of items in
> > "gpios", so their limits should be identical.
> >
> > The number of items in "states" must lie within the range from zero up
> > to 2^{number of gpios}.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > ---
> > The second issue did not cause any dtbs_check errors?
>
> I'm not seeing 'states' fail, but it looks like you did? Is that the
> issue you mean? Looks like in the matrix case, we're now setting
> minItems if unspecified.

No, I did not see states fail, only gpios-states.
Hence "the second issue did not cause errors".

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds