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

[Arnd Bergmann]

On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
> Let me steer the discussion to original topic - it's about old kernel
> and new DTB, assuming that mainline kernel bisectability is not
> affected.
>
> Flow looks like this:
>
> 0. You have existing bidings and drivers.
> 1. Patch changing bindings (with new compatible) and drivers gets
>    accepted by maintainer.
> 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> 3. Patch changing in-tree DTS to new compatible gets accepted by
>    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
>
> So again: old kernel, using old bindings, new DTB.
>
> Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
> new DTS (at point of #3 above or later) but did not take the bindings.
> Such system would be broken but it's their fault - they took DTS without
> taking the bindings (which were there already for one release!).

The particular boot flow that I am worried about here is when the dtb and
kernel are not updated in sync. Traditionally this happens when the dtb
is contained in the firmware image or generated by the firmware, as would
be the case on any server class system, but also on embedded systems
that can run an upstream kernel but without having the dts contributed
into the kernel sources.

When you have this case, you can install a working system, and install
an upgraded kernel without problems. You might then want to update the
firmware as well, in order to take advantage of the features implemented
in the kernel kernel that require a DT description. Again, no problem.

However, once the firmware is updated, it may no longer be possible to
go back to the old kernel in case the new one is busted.

A similar problem can happen with the EBBR boot flow that relies on
a uefi-enabled firmware such as a u-boot, while using grub2 as the
actual boot loader. This is commonly supported across distros. While
grub2 can load a matching set of kernel+initrd+dtb from disk and run
that, this often fails in practice because u-boot needs to fill a
board specific set of DT properties (bootargs, detected memory,
mac address, ...). The usual way this gets handled is that u-boot loads
grub2 and the dtb from disk and then passes the modified dtb to grub,
which picks only kernel+initrd from disk and boots this with the dtb.

The result is similar to case with dtb built into the firmware: after
upgrading the dtb that gets loaded by u-boot, grub can still pick
old kernels but they may not work as they did in the past. There are
obviously ways to work around it, but it does lead to user frustration.

         Arnd