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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 6 Feb 2021 16:06:55 +0100
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     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>,
        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

On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> > >
> > > ----------------------------------------------------------------
> > > Samsung DTS ARM changes for v5.12
> > >
> > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
> > >    it suspend/resume cycle.
> > > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> > > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
> > >    charger.
> > >
> >
> > Hi everyone,
> >
> > Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> 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.

Thank you for explanation. I would love to receive kind of guidance,
best practices, guide for future patches. I will them write it down and
try to follow during my review. However it made me a sad that a patch,
adhering in my mind to all rules, was postponing the pull request.

> 
> 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?

Good summary, thanks Arnd. I would like to add that the discussed change
was bringing a new compatible. It was saying: hey, this hardware so far we
treated as old one, but it's not, sorry, it is different, so here you
have a new compatible with a change in few properties as well (and new
bindings which appeared a release earlier).

Best regards,
Krzysztof


> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/