Message-ID: <YCGBIvRfoP0BeyrP@builder.lan>
Date:   Mon, 8 Feb 2021 12:21:22 -0600
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
        arm-soc <arm@...nel.org>, SoC Team <soc@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" 
        <linux-samsung-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Sylwester Nawrocki <snawrocki@...nel.org>,
        DTML <devicetree@...r.kernel.org>,
        Tony Lindgren <tony@...mide.com>,
        Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Kevin Hilman <khilman@...libre.com>,
        Maxime Ripard <mripard@...nel.org>
Subject: Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:

> Hi Arnd,
> 
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@...nel.org> wrote:
> > That said, I'm still not happy about the patch we discussed in the
> > other email thread[1] and I'd like to handle it a little more strictly in
> > the future, but I agree this wasn't obvious and we have been rather
> > inconsistent about it in the past, with some platform maintainers
> > handling it way more strictly than others.
> >
> > I've added the devicetree maintainers and a few other platform
> > maintainers to Cc here, maybe they can provide some further
> > opinions on the topic so we can come to an approach that
> > works for everyone.
> >
> > My summary of the thread in [1] is there was a driver bug that
> > required a DT binding change. Krzysztof and the other involved
> > parties made sure the driver handles it in a backward-compatible
> > way (an old dtb file will still run into the bug but keep working
> > with new kernels), but decided that they did not need to worry
> > about the opposite case (running an old kernel with an updated
> > dtb). I noticed the compatibility break and said that I would
> > prefer this to be done in a way that is compatible both ways,
> > or at the minimum be alerted about the binding break in the
> > pull request, with an explanation about why this had to be done,
> > even when we don't think anyone is going to be affected.
> >
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 

This is the case for the Qualcomm tree as well, it's expected that a new
kernel should work with older DT. But, while we don't actively try to
break it, there are plenty of examples where we don't/can't give the
promise in the other direction.

These examples ranges from advancements in power management
(implementation and binding) to DT validation forcing deprecation and
adoption of new bindings.

Regards,
Bjorn

Powered by blists - more mailing lists