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: <YkK691VG6ON/6Ysn@atomide.com>
Date:   Tue, 29 Mar 2022 10:53:27 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Daniel Palmer <daniel@...f.com>
Cc:     Ansuel Smith <ansuelsmth@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-actions@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        linux-omap@...r.kernel.org, linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...s.com, linux-aspeed@...ts.ozlabs.org,
        linux-rpi-kernel@...ts.infradead.org,
        chrome-platform@...ts.linux.dev, linux-renesas-soc@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        kernel@...electronics.com, linux-mediatek@...ts.infradead.org,
        openbmc@...ts.ozlabs.org, linux-tegra@...r.kernel.org,
        linux-oxnas@...ups.io, linux-arm-msm@...r.kernel.org,
        linux-unisoc@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org,
        linux-realtek-soc@...ts.infradead.org
Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory

Hi,

* Daniel Palmer <daniel@...f.com> [220328 08:53]:
> Hi Ansuel
> 
> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith <ansuelsmth@...il.com> wrote:
> >
> > Hi,
> > as the title say, the intention of this ""series"" is to finally categorize
> > the ARM dts directory in subdirectory for each oem.
> 
> While I agree with this change and think it's for the good (browsing
> the ARM dts directory at the moment is frustrating..) I think
> buildroot and others need to be told about this as it'll potentially
> break their kernel build scripting for ARM and probably messes up the
> configs they have for existing boards.

Yeah.. And ideally this would be done in smaller steps as these will
conflict with all the other pending patches.

For example, I have a pile of pending omap clock clean-up dts patches
posted and tested waiting for v5.19-rc1 to apply. I'd rather not start
redoing or fixing up the patches with sed :)

What I'd like to have see is that at some point when suitable we move
one machine at a time with a script if possible.. Maybe the dtb files
generated would need to remain in the current directory until all of
the machine dts files are moved? That should help with the build
scripting too probably :)

In general I like the idea though and I think we should do it.

Regards,

Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ