* Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> [210206 19:48]: > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > 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
