linux-kernel - Re: [RESEND PATCH] arm64: dts: tegra: Fix boolean properties with values

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: <CAK8P3a1fyibqtkNMXDA6JXFWc2856B40C6oD8hBaieR8jTD-Ng@mail.gmail.com>
Date:   Mon, 25 Apr 2022 13:55:37 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Rob Herring <robh@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Avi Fishman <avifishman70@...il.com>,
        Tomer Maimon <tmaimon77@...il.com>,
        Tali Perry <tali.perry1@...il.com>,
        Patrick Venture <venture@...gle.com>,
        Nancy Yuen <yuenn@...gle.com>,
        Benjamin Fair <benjaminfair@...gle.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        linux-stm32@...md-mailman.stormreply.com,
        SoC Team <soc@...nel.org>, DTML <devicetree@...r.kernel.org>,
        "open list:TEGRA ARCHITECTURE SUPPORT" <linux-tegra@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH] arm64: dts: tegra: Fix boolean properties with values

On Mon, Apr 25, 2022 at 1:20 PM Jon Hunter <jonathanh@...dia.com> wrote:
> On 12/04/2022 10:05, Thierry Reding wrote:
> > On Wed, Apr 06, 2022 at 02:17:30PM -0500, Rob Herring wrote:
> >> Boolean properties in DT are present or not present and don't take a value.
> >> A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't
> >> matter.
> >>
> >> It may have been intended that 0 values are false, but there is no change
> >> in behavior with this patch.
> >>
> >> Signed-off-by: Rob Herring <robh@...nel.org>
> >> ---
> >> Can someone apply this for 5.18.
> >>
> >>   arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi            | 8 ++++----
> >>   .../boot/dts/nvidia/tegra186-p3509-0000+p3636-0001.dts    | 8 ++++----
> >>   arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi            | 6 +++---
> >>   arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi            | 6 +++---
> >>   arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi            | 6 +++---
> >>   arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi            | 8 ++++----
> >>   arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts        | 8 ++++----
> >>   arch/arm64/boot/dts/nvidia/tegra210-smaug.dts             | 4 ++--
> >>   8 files changed, 27 insertions(+), 27 deletions(-)
> >
> > This causes multiple regressions on Tegra boards. The reason for this is
> > that these properties are not in fact boolean, despite what the DT
> > bindings say. If you look at the code that handles these, you'll notice
> > that they are single-cell properties, typically with <0> and <1> values.
> > What may have led to the conclusion that these are boolean is that there
> > is also a special case where these can be left out, but the meaning of
> > that is not the "false" (<0>) value. Instead, leaving these out means
> > that the values should be left at whatever is currently in the register.
> >
> > See pinconf_generic_parse_dt_config() and parse_dt_cfg() specifically in
> > drivers/pinctrl/pinconf-generic.c.
> >
> > Arnd, can you please revert this so that these boards can be unbroken?
>
>
> Arnd, any feedback on this? A lot of Tegra boards are still not booting
> with v5.18-rc4.

I have reverted this commit now, sorry for missing the earlier report.
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=arm/fixes

> > Adding Bjorn for MSM, the Nuvoton and STM32 folks.

I'll wait for the others to reply, but I do agree that these are likely broken
as well. Could one of you propose a patch to make the binding
describe what the kernel code actually expects here?

       Arnd