* Geert Uytterhoeven [off-list ref] [210206 19:48]:

On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann [off-list ref] wrote:

quoted

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