netdev - Re: [PATCH net-next RFC 0/3] net: dsa: realtek: drop custom slave MII

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] [day] [month] [year] [list]

Date:   Thu, 7 Jul 2022 10:45:49 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
        Arınç ÜNAL <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next RFC 0/3] net: dsa: realtek: drop custom slave MII

On Wed, Jul 6, 2022 at 5:29 PM Vladimir Oltean <olteanv@...il.com> wrote:
> On Thu, Jun 30, 2022 at 02:05:39PM -0300, Luiz Angelo Daros de Luca wrote:

> > > In principle I like your changes, but I'm not sure if what you are doing
> > > is allowed, since DT is ABI. The fact that you have to split this into
> > > two steps, with the first step warning about old "incompatible" DTs
> > > (your point 3 below) before the second step breaks that compatibility,
> > > suggests that you are aware that you could be breaking old DTs.
> >
> > Thanks Alvin for your review. Yes, that is a good question for the ML.
> > I don't know at what level we can break compatibility (DT and driver).
> > That's why it is a RFC.
>
> DT bindings are only extended in backwards-compatible ways. Only in the
> case where you can prove that there is no DT user of a certain binding,
> and that none should appear either, is when you can consider breaking
> the backward compatibility. The idea here is that old DT blobs may live
> forever and be provided by fixed firmware such as U-Boot, you can't
> really force anyone to update them.

We break it when it makes sense.

The central question is to ascertain if there are actually binary DTBs
deployed with these bindings, in mass-market products, and these are
not upgraded in tandem with the kernel.

A mistake (IMO) in the early days of DT was to assume that
it was used with Open Firmware (OF) which is like ACPI, a kind of BIOS.
Most users of DT do not use OF, the only thing we ever see relating
to it is the of_* prefix.

People actually using open firmware would embed the DTB with the
open firmware and flash it into a (desktop) computer as a blob, pretty
much like how the ACPI BIOS works now.

It turns out the majority of contemporary users of DT don't use DTBs
like this at all: instead they compile the kernel and the DTB, then flash
both into the platform at the same time. There is even the FIT format for
U-Boot which is a package of both kernel and DT and whatnot.

Actually very few people flash their DTB in such a way that it cannot get
upgraded, and in fact most flash both at the same time, after building
both from source. In that case it doesn't matter if we break compatibility.

While we strive to keep DT schemas strict and compatible (it is a good
ambition) I would reverse the burden of proof for backward compatibility:
if it can not be proven that irrevocable DTBs have been deployed, and
that kernels may get upgraded independently of the DTB, using this
specific binding, then it is fine to change it in incompatible ways if
we need to.

It could also be that the DT bindings started to get used
with another operating system. But these things have to be demonstrated,
they are the rare cases and should not be the assumption, as if a
DT binding is immediately used in a myriad of places the second
we merge it to Torvald's tree. Such adoption in the real world happens
much later.

If the only specimens are inside a company that has not yet released
any products we can certainly change it. What we don't want is the
general public running into these incompatibilities.

Notice that as we discuss this, I see some people being requested to
reflash their (ACPI) bioses rather than put fixes in the kernel for
erroneous ACPI DSDT:s. Not for end users, but for people working
with prototypes still in development. "Go fix your DSDT BIOS tables".

Yours,
Linus Walleij