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: <CAK8P3a0Q8eOTeRmd5-G8rNCKAcH+4HReCsOAGKd4Vq30C9TaEA@mail.gmail.com>
Date:   Fri, 25 Mar 2022 10:11:41 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Kuldeep Singh <singh.kuldeep87k@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>,
        Shiraz Hashim <shiraz.linux.kernel@...il.com>,
        SoC Team <soc@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] ARM: dts: spear13xx: Update SPI dma properties

On Fri, Mar 25, 2022 at 2:58 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 24-03-22, 11:55, Kuldeep Singh wrote:
> > Fixed order of values is important in case of properties like
> > compatibles etc. In case of dma-names, yes order shouldn't matter here.
> >
> > This patch is more of appeasing dtbs_check warning rather than fixing
> > something.
>
> Exactly my point. We have seen similar type of issues with other tools, like
> coccinelle, earlier and such patches were rejected as the kernel was just fine
> and tooling needs to be fixed.
>
> > It's safe to go with this patch.
> > I am not sure if there's a provision to exclude dma-names from fix
> > ordering checks. Rob can help here in providing better insights.

I think it's a question of the scale of the warnings: my understanding is that
there are only a handful of dts files that trigger the warning at all, and it
would be rather hard to change the tooling around this. Since the proposed
dts change is clearly harmless, I don't mind applying it.

Kuldeep, you have probably looked at all dts files in the kernel, can you
say how many of them are affected by the dma property reordering?

         Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ