>> (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 ques"> >> (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 ques"> >> (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 ques">

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

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