linux-kernel - Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Feb 2021 10:40:26 +0200
From:   Tony Lindgren <tony@...mide.com>
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>,
        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>,
        Bjorn Andersson <bjorn.andersson@...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

* Geert Uytterhoeven <geert@...ux-m68k.org> [210206 19:48]:
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@...nel.org> wrote:
> > 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.
> 
> In case there was a real issue fixed, and using the new DTB with the old
> kernel would cause a regression, and we're aware of it, we do make sure
> the DTS update is postponed until the corresponding driver update has
> hit upstream.

Yeah agreed. Adding new devicetree properties should not be a problem
for device drivers.

For renamed devicetree properties, the driver won't be aware of them
if a newer dtb is used. The only thing the driver can possibly do at
this point is maybe warn about some missing old property and bail out.

Making sure the driver changes are in place first helps a bit..
But naturally fixing the driver in advance won't help booting kernels
before the driver changes with a newer dtb :)

What helps though is to make sure git bisect works for building and
booting already at -rc1 kernel to make debugging the issue easy. As
-rc1 is used typically as the merge base the problem causing branches
can be tested separately that way.

Regards,

Tony