[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL7t47x-5U6STynwW-+4wJUhs_R9wuaQ0YOgX59aJ=vew@mail.gmail.com>
Date: Tue, 2 May 2023 14:01:01 -0500
From: Rob Herring <robh+dt@...nel.org>
To: Robin Murphy <robin.murphy@....com>
Cc: Nicolas Ferre <nicolas.ferre@...rochip.com>,
Daniel Palmer <daniel@...f.com>,
Ansuel Smith <ansuelsmth@...il.com>,
Claudiu Beznea <Claudiu.Beznea@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Santiago Esteban <Santiago.Esteban@...rochip.com>,
Cristian Birsan <Cristian.Birsan@...rochip.com>,
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
On Tue, Apr 25, 2023 at 11:21 AM Robin Murphy <robin.murphy@....com> wrote:
>
> On 29/03/2022 9:50 am, Nicolas Ferre wrote:
> > Ansuel, All,
> >
> > On 28/03/2022 at 10:55, Daniel Palmer wrote:
> >> 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.
> >
> > This aspect mustn't be underestimated and I anticipate lots of issues
> > during a long time on this particular topic of "build systems".
> >
> > Another aspect is CI and public or private testing farms we all have
> > running.
>
> Yet another is if this affects what `make dtbs_install` does (I don't
> know for sure, but I'd be inclined to suspect it might). Some distros
> use that to deliver the DTBs as part of their kernel package, so if
> paths suddenly change it could break end users' bootloader setups too.
Indeed, this came up last time. Turns out I had already implemented
support to maintain the flat install. I just re-wrote it since
Makefile.dtbinst changed completely since then.
Rob
Powered by blists - more mailing lists