Hi Arnd,
On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <[email protected]> wrote:
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
>
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
>
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
>
> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
* Geert Uytterhoeven <[email protected]> [210206 19:48]:
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <[email protected]> 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
On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:
> Hi Arnd,
>
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <[email protected]> wrote:
> > That said, I'm still not happy about the patch we discussed in the
> > other email thread[1] and I'd like to handle it a little more strictly in
> > the future, but I agree this wasn't obvious and we have been rather
> > inconsistent about it in the past, with some platform maintainers
> > handling it way more strictly than others.
> >
> > I've added the devicetree maintainers and a few other platform
> > maintainers to Cc here, maybe they can provide some further
> > opinions on the topic so we can come to an approach that
> > works for everyone.
> >
> > My summary of the thread in [1] is there was a driver bug that
> > required a DT binding change. Krzysztof and the other involved
> > parties made sure the driver handles it in a backward-compatible
> > way (an old dtb file will still run into the bug but keep working
> > with new kernels), but decided that they did not need to worry
> > about the opposite case (running an old kernel with an updated
> > dtb). I noticed the compatibility break and said that I would
> > prefer this to be done in a way that is compatible both ways,
> > or at the minimum be alerted about the binding break in the
> > pull request, with an explanation about why this had to be done,
> > even when we don't think anyone is going to be affected.
> >
> > 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.
>
This is the case for the Qualcomm tree as well, it's expected that a new
kernel should work with older DT. But, while we don't actively try to
break it, there are plenty of examples where we don't/can't give the
promise in the other direction.
These examples ranges from advancements in power management
(implementation and binding) to DT validation forcing deprecation and
adoption of new bindings.
Regards,
Bjorn
On Mon, Feb 08, 2021 at 12:21:22PM -0600, Bjorn Andersson wrote:
> On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:
>
> > Hi Arnd,
> >
> > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <[email protected]> wrote:
> > > That said, I'm still not happy about the patch we discussed in the
> > > other email thread[1] and I'd like to handle it a little more strictly in
> > > the future, but I agree this wasn't obvious and we have been rather
> > > inconsistent about it in the past, with some platform maintainers
> > > handling it way more strictly than others.
> > >
> > > I've added the devicetree maintainers and a few other platform
> > > maintainers to Cc here, maybe they can provide some further
> > > opinions on the topic so we can come to an approach that
> > > works for everyone.
> > >
> > > My summary of the thread in [1] is there was a driver bug that
> > > required a DT binding change. Krzysztof and the other involved
> > > parties made sure the driver handles it in a backward-compatible
> > > way (an old dtb file will still run into the bug but keep working
> > > with new kernels), but decided that they did not need to worry
> > > about the opposite case (running an old kernel with an updated
> > > dtb). I noticed the compatibility break and said that I would
> > > prefer this to be done in a way that is compatible both ways,
> > > or at the minimum be alerted about the binding break in the
> > > pull request, with an explanation about why this had to be done,
> > > even when we don't think anyone is going to be affected.
> > >
> > > 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.
> >
>
> This is the case for the Qualcomm tree as well, it's expected that a new
> kernel should work with older DT. But, while we don't actively try to
> break it, there are plenty of examples where we don't/can't give the
> promise in the other direction.
Thanks everyone for comments.
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!).
Best regards,
Krzysztof