| Message ID | 20210125191240.11278-3-krzk@kernel.org (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Commit | 3803f461bd28c1c817281348509399778633e82f |
| Headers | show |
| Series | Samsung for v5.12 | expand |
On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote: > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12 > > for you to fetch changes up to 3803f461bd28c1c817281348509399778633e82f: > > ARM: dts: exynos: Add top-off charging regulator node for I9100 (2021-01-03 17:33:29 +0100) > > ---------------------------------------------------------------- > Samsung DTS ARM changes for v5.12 > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing > it suspend/resume cycle. > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards. > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off > charger. > Hi everyone, Any progress or new comments about this pull request? Best regards, Krzysztof > ---------------------------------------------------------------- > Krzysztof Kozlowski (6): > ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5 > ARM: dts: exynos: correct PMIC interrupt trigger level on Monk > ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato > ARM: dts: exynos: correct PMIC interrupt trigger level on Spring > ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa > ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family > > Marek Szyprowski (1): > ARM: dts: exynos: use Exynos5420 dedicated USB2 PHY compatible > > Timon Baetz (2): > ARM: dts: exynos: Fix charging regulator voltage and current for I9100 > ARM: dts: exynos: Add top-off charging regulator node for I9100 > > arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +- > arch/arm/boot/dts/exynos3250-monk.dts | 2 +- > arch/arm/boot/dts/exynos3250-rinato.dts | 2 +- > arch/arm/boot/dts/exynos4210-i9100.dts | 30 ++++++++++++++++----------- > arch/arm/boot/dts/exynos5250-spring.dts | 2 +- > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +- > arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +- > arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- > 8 files changed, 27 insertions(+), 21 deletions(-)
On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote: > > > > ---------------------------------------------------------------- > > Samsung DTS ARM changes for v5.12 > > > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing > > it suspend/resume cycle. > > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards. > > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off > > charger. > > > > Hi everyone, > > Any progress or new comments about this pull request? Hi Krzysztof, Sorry for not getting back to you on this earlier. I discussed this with Olof the other day and we decided to merge this, I just haven't gone through the pull requests over the past few days. My plan is to do the next round on Monday. 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? Arnd [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/
On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote: > On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote: > > > > > > ---------------------------------------------------------------- > > > Samsung DTS ARM changes for v5.12 > > > > > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing > > > it suspend/resume cycle. > > > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards. > > > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off > > > charger. > > > > > > > Hi everyone, > > > > Any progress or new comments about this pull request? > > Hi Krzysztof, > > Sorry for not getting back to you on this earlier. I discussed this with > Olof the other day and we decided to merge this, I just haven't > gone through the pull requests over the past few days. My plan is > to do the next round on Monday. > > 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. Thank you for explanation. I would love to receive kind of guidance, best practices, guide for future patches. I will them write it down and try to follow during my review. However it made me a sad that a patch, adhering in my mind to all rules, was postponing the pull request. > > 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? Good summary, thanks Arnd. I would like to add that the discussed change was bringing a new compatible. It was saying: hey, this hardware so far we treated as old one, but it's not, sorry, it is different, so here you have a new compatible with a change in few properties as well (and new bindings which appeared a release earlier). Best regards, Krzysztof > > Arnd > > [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/
Hi Arnd, On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> 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 <geert@linux-m68k.org> [210206 19:48]: > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> 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 <arnd@kernel.org> 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 <arnd@kernel.org> 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
On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@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
Hello, On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@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. > > I don't think forward compatibility was ever considered. I've seen it being mentioned a few times on #armlinux but honestly this simply can't be achieved. This would mean being able to write complete DT bindings for a particular SoC at day 0 which will realistically never happen. You may noteven have a complete datasheet and even if you have a datasheet, it may not be complete or it may be missing hw errata that are discovered later on and need a new binding to handle. > > 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. > Any serious update strategy will update both the kernel and device tree at the same time, exactly like you already have to update the initramfs with the kernel as soon as it is including kernel modules. I would expect any embedded platform to actually use a container format, like a FIT image that will ship the kernel, DT and intiramfs in a single image and will allow to sign all parts. > 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. > Are there really any platforms with the dtb built into the firmware? I feel like this is a mythical creature used to scare people into keeping the DTB ABI stable. Aren't all the distribution already able to cope with keeping DTB and kernel in sync?
On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@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. > > > > > I don't think forward compatibility was ever considered. I've seen it > being mentioned a few times on #armlinux but honestly this simply can't > be achieved. This would mean being able to write complete DT bindings > for a particular SoC at day 0 which will realistically never happen. You > may noteven have a complete datasheet and even if you have a datasheet, > it may not be complete or it may be missing hw errata that are > discovered later on and need a new binding to handle. You do not have to write the correct DT for this, the only requirement is that any changes to a node are backward-compatible, which is typically the case if you add properties or compatible strings without removing the old one. A bugfix in this case is also backward-compatible. The part that can not happen instead is to write a DT that can expose features that any future kernel will use. > > > > 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. > > > > Any serious update strategy will update both the kernel and device tree > at the same time, exactly like you already have to update the initramfs > with the kernel as soon as it is including kernel modules. > I would expect any embedded platform to actually use a container format, > like a FIT image that will ship the kernel, DT and intiramfs in a single > image and will allow to sign all parts. Embedded systems that do this have no requirement for backward or forward compatibility at all, the only requirement for these is bisectability of git commits. > > 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. > > > > Are there really any platforms with the dtb built into the firmware? > I feel like this is a mythical creature used to scare people into keeping > the DTB ABI stable. Aren't all the distribution already able to cope > with keeping DTB and kernel in sync? I think most traditional PowerPC systems fall into this category, most systems that boot using UEFI+grub (as I explained), and anyone who uses a distro kernel on custom hardware with their own dtb. Arnd
On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote: > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni > <alexandre.belloni@bootlin.com> wrote: > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@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. > > > > > > > > I don't think forward compatibility was ever considered. I've seen it > > being mentioned a few times on #armlinux but honestly this simply can't > > be achieved. This would mean being able to write complete DT bindings > > for a particular SoC at day 0 which will realistically never happen. You > > may noteven have a complete datasheet and even if you have a datasheet, > > it may not be complete or it may be missing hw errata that are > > discovered later on and need a new binding to handle. > > You do not have to write the correct DT for this, the only requirement > is that any changes to a node are backward-compatible, which is > typically the case if you add properties or compatible strings without > removing the old one. A bugfix in this case is also backward-compatible. > > The part that can not happen instead is to write a DT that can expose > features that any future kernel will use. > But I think we are speaking about the other way around were you would be e.g. removing properties or splitting a node is multiple different nodes following a different understanding of the hardware. And in this case, any rework of the bindings will be forbidden, like 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will break older kernels trying to use the new dtb. 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is an other case. I'm not sure want to keep the older properties or the older compatible string as a fallback for this use case. > > > 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. > > > > > > > Any serious update strategy will update both the kernel and device tree > > at the same time, exactly like you already have to update the initramfs > > with the kernel as soon as it is including kernel modules. > > I would expect any embedded platform to actually use a container format, > > like a FIT image that will ship the kernel, DT and intiramfs in a single > > image and will allow to sign all parts. > > Embedded systems that do this have no requirement for backward > or forward compatibility at all, the only requirement for these is bisectability > of git commits. > Yes and I can't see any drawbacks in this approach. > > > 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. > > > > > > > Are there really any platforms with the dtb built into the firmware? > > I feel like this is a mythical creature used to scare people into keeping > > the DTB ABI stable. Aren't all the distribution already able to cope > > with keeping DTB and kernel in sync? > > I think most traditional PowerPC systems fall into this category, most My understanding was that the traditional PPC systems had a small device tree and usually are not affected by driver changes but I may be wrong. > systems that boot using UEFI+grub (as I explained), and anyone who > uses a distro kernel on custom hardware with their own dtb. > Aren't the ones using a distro kernel with a custom dtb more concerned by backward compatibility (i.e. new kernel with old dtb) rather than old kernel on new dtb? If they have an old dtb, an old kernel, and update to a new kernel, backward compatibility will ensure this continues to work. If then they work on updating their dtb, they still have the old one and can make the distribution match dtb and kernel. This is already handled properly by debian and I guess the other distributions as it is anyway already matching kernel and initramfs. This is what I have on my NAS: $ ls /boot config-4.12.0-1-marvell initrd.img-4.12.0-1-marvell uImage.bak config-4.13.0-1-marvell initrd.img-4.13.0-1-marvell uInitrd dtb initrd.img.old uInitrd.bak dtb-4.12.0-1-marvell lost+found vmlinuz dtb-4.13.0-1-marvell System.map-4.12.0-1-marvell vmlinuz-4.12.0-1-marvell dtbs System.map-4.13.0-1-marvell vmlinuz-4.13.0-1-marvell initrd.img uImage vmlinuz.old So dtbs and kernels are already matching even when the dtbs didn't change between 4.9 and 4.13. I don't have any solution for the UEFI+grub use case but I will also question the sanity of doing that ;)
Hi Alexandre, On Tue, Feb 9, 2021 at 12:10 AM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote: > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni > > <alexandre.belloni@bootlin.com> wrote: > > > Are there really any platforms with the dtb built into the firmware? > > > I feel like this is a mythical creature used to scare people into keeping > > > the DTB ABI stable. Aren't all the distribution already able to cope > > > with keeping DTB and kernel in sync? > > > > I think most traditional PowerPC systems fall into this category, most > > My understanding was that the traditional PPC systems had a small device > tree and usually are not affected by driver changes but I may be wrong. They were much simpler than a modern SoC, with most functionality implemented by modularity (e.g. PCI devices, I still like 'compatible = "pci1186,100"'[1] ;-) And the bindings were simple and stable (i.e. they did exist before the platform was shipped). [1] http://users.telenet.be/geertu/Linux/PPC/pci/ethernetAT4/ Gr{oetje,eeting}s, Geert
On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote: > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni > > <alexandre.belloni@bootlin.com> wrote: > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@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. > > > > > > > > > > > I don't think forward compatibility was ever considered. I've seen it > > > being mentioned a few times on #armlinux but honestly this simply can't > > > be achieved. This would mean being able to write complete DT bindings > > > for a particular SoC at day 0 which will realistically never happen. You > > > may noteven have a complete datasheet and even if you have a datasheet, > > > it may not be complete or it may be missing hw errata that are > > > discovered later on and need a new binding to handle. > > > > You do not have to write the correct DT for this, the only requirement > > is that any changes to a node are backward-compatible, which is > > typically the case if you add properties or compatible strings without > > removing the old one. A bugfix in this case is also backward-compatible. > > > > The part that can not happen instead is to write a DT that can expose > > features that any future kernel will use. > > > > But I think we are speaking about the other way around were you would be > e.g. removing properties or splitting a node is multiple different > nodes following a different understanding of the hardware. > And in this case, any rework of the bindings will be forbidden, like > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will > break older kernels trying to use the new dtb. > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is > an other case. > I'm not sure want to keep the older properties or the older compatible > string as a fallback for this use case. > > > > > 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. > > > > > > > > > > Any serious update strategy will update both the kernel and device tree > > > at the same time, exactly like you already have to update the initramfs > > > with the kernel as soon as it is including kernel modules. > > > I would expect any embedded platform to actually use a container format, > > > like a FIT image that will ship the kernel, DT and intiramfs in a single > > > image and will allow to sign all parts. > > > > Embedded systems that do this have no requirement for backward > > or forward compatibility at all, the only requirement for these is bisectability > > of git commits. > > > > Yes and I can't see any drawbacks in this approach. > > > > > 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. > > > > > > > > > > Are there really any platforms with the dtb built into the firmware? > > > I feel like this is a mythical creature used to scare people into keeping > > > the DTB ABI stable. Aren't all the distribution already able to cope > > > with keeping DTB and kernel in sync? > > > > I think most traditional PowerPC systems fall into this category, most > > My understanding was that the traditional PPC systems had a small device > tree and usually are not affected by driver changes but I may be wrong. > > > systems that boot using UEFI+grub (as I explained), and anyone who > > uses a distro kernel on custom hardware with their own dtb. > > > > Aren't the ones using a distro kernel with a custom dtb more concerned > by backward compatibility (i.e. new kernel with old dtb) rather than old > kernel on new dtb? If they have an old dtb, an old kernel, and update to > a new kernel, backward compatibility will ensure this continues to work. > If then they work on updating their dtb, they still have the old one and > can make the distribution match dtb and kernel. This is already handled > properly by debian and I guess the other distributions as it is anyway > already matching kernel and initramfs. SUSE is doing the opposite AIUI. This is a bit harder because adding any new provider breaks compatibility as the old kernel will wait for a non-existent driver for the new provider. That was the motivation for deferred probe timeouts. Of course, I wouldn't really call a platform stable if you are still adding clock, pinctrl, power-domain, etc. providers. Rob
On Tue 09 Feb 08:27 CST 2021, Rob Herring wrote: > On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni > <alexandre.belloni@bootlin.com> wrote: > > > > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote: > > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni > > > <alexandre.belloni@bootlin.com> wrote: > > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@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. > > > > > > > > > > > > > > I don't think forward compatibility was ever considered. I've seen it > > > > being mentioned a few times on #armlinux but honestly this simply can't > > > > be achieved. This would mean being able to write complete DT bindings > > > > for a particular SoC at day 0 which will realistically never happen. You > > > > may noteven have a complete datasheet and even if you have a datasheet, > > > > it may not be complete or it may be missing hw errata that are > > > > discovered later on and need a new binding to handle. > > > > > > You do not have to write the correct DT for this, the only requirement > > > is that any changes to a node are backward-compatible, which is > > > typically the case if you add properties or compatible strings without > > > removing the old one. A bugfix in this case is also backward-compatible. > > > > > > The part that can not happen instead is to write a DT that can expose > > > features that any future kernel will use. > > > > > > > But I think we are speaking about the other way around were you would be > > e.g. removing properties or splitting a node is multiple different > > nodes following a different understanding of the hardware. > > And in this case, any rework of the bindings will be forbidden, like > > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will > > break older kernels trying to use the new dtb. > > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is > > an other case. > > I'm not sure want to keep the older properties or the older compatible > > string as a fallback for this use case. > > > > > > > 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. > > > > > > > > > > > > > Any serious update strategy will update both the kernel and device tree > > > > at the same time, exactly like you already have to update the initramfs > > > > with the kernel as soon as it is including kernel modules. > > > > I would expect any embedded platform to actually use a container format, > > > > like a FIT image that will ship the kernel, DT and intiramfs in a single > > > > image and will allow to sign all parts. > > > > > > Embedded systems that do this have no requirement for backward > > > or forward compatibility at all, the only requirement for these is bisectability > > > of git commits. > > > > > > > Yes and I can't see any drawbacks in this approach. > > > > > > > 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. > > > > > > > > > > > > > Are there really any platforms with the dtb built into the firmware? > > > > I feel like this is a mythical creature used to scare people into keeping > > > > the DTB ABI stable. Aren't all the distribution already able to cope > > > > with keeping DTB and kernel in sync? > > > > > > I think most traditional PowerPC systems fall into this category, most > > > > My understanding was that the traditional PPC systems had a small device > > tree and usually are not affected by driver changes but I may be wrong. > > > > > systems that boot using UEFI+grub (as I explained), and anyone who > > > uses a distro kernel on custom hardware with their own dtb. > > > > > > > Aren't the ones using a distro kernel with a custom dtb more concerned > > by backward compatibility (i.e. new kernel with old dtb) rather than old > > kernel on new dtb? If they have an old dtb, an old kernel, and update to > > a new kernel, backward compatibility will ensure this continues to work. > > If then they work on updating their dtb, they still have the old one and > > can make the distribution match dtb and kernel. This is already handled > > properly by debian and I guess the other distributions as it is anyway > > already matching kernel and initramfs. > > SUSE is doing the opposite AIUI. This is a bit harder because adding > any new provider breaks compatibility as the old kernel will wait for > a non-existent driver for the new provider. That was the motivation > for deferred probe timeouts. Of course, I wouldn't really call a > platform stable if you are still adding clock, pinctrl, power-domain, > etc. providers. > IMHO "stable" in this context means that we've hit the point in development when these questions are no longer relevant. Either because the development is _done_ or more likely it's too old for anyone to care. Unfortunately this is the state that we're optimizing for and we're simply relying on luck to boot Linux on a reasonably complex machine. Regards, Bjorn
On 2/6/21 8:35 AM, Arnd Bergmann wrote: > On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote: >>> >>> ---------------------------------------------------------------- >>> Samsung DTS ARM changes for v5.12 >>> >>> 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing >>> it suspend/resume cycle. >>> 2. Correct Samsung PMIC interrupt trigger levels on multiple boards. >>> 3. Correct the voltages of Samsung GT-I9100 charger and add top-off >>> charger. >>> >> >> Hi everyone, >> >> Any progress or new comments about this pull request? > > Hi Krzysztof, > > Sorry for not getting back to you on this earlier. I discussed this with > Olof the other day and we decided to merge this, I just haven't > gone through the pull requests over the past few days. My plan is > to do the next round on Monday. > > 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? The current policy (since before 2013) is that newer kernels, implementing new bindings, do not break with old existing dtbs. Old existing kernels are not required to work with new dtbs. See Documentation/devicetree/bindings/ABI.rst We can choose to change the rules, so I'm not saying that the discussion should not occur. I'm just pointing out the current policy. I think that ABI.rst does not state "Old existing kernels are not required to work with new dtbs" clearly enough, and should be updated to do so. I also think it would be good to explicitly say that care should be taken with new bindings to not break existing kernels, if reasonably possible. -Frank > > Arnd > > [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/ >
From: Arnd Bergmann <arnd@arndb.de> On Mon, 25 Jan 2021 20:12:39 +0100, Krzysztof Kozlowski wrote: > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12 > > [...] Merged into arm/dt at least, sorry for the long delay. merge commit: f3d8876acac00e7430e46679fb1da26e50c006d5 Arnd
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12 for you to fetch changes up to 3803f461bd28c1c817281348509399778633e82f: ARM: dts: exynos: Add top-off charging regulator node for I9100 (2021-01-03 17:33:29 +0100) ---------------------------------------------------------------- Samsung DTS ARM changes for v5.12 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing it suspend/resume cycle. 2. Correct Samsung PMIC interrupt trigger levels on multiple boards. 3. Correct the voltages of Samsung GT-I9100 charger and add top-off charger. ---------------------------------------------------------------- Krzysztof Kozlowski (6): ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5 ARM: dts: exynos: correct PMIC interrupt trigger level on Monk ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato ARM: dts: exynos: correct PMIC interrupt trigger level on Spring ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family Marek Szyprowski (1): ARM: dts: exynos: use Exynos5420 dedicated USB2 PHY compatible Timon Baetz (2): ARM: dts: exynos: Fix charging regulator voltage and current for I9100 ARM: dts: exynos: Add top-off charging regulator node for I9100 arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +- arch/arm/boot/dts/exynos3250-monk.dts | 2 +- arch/arm/boot/dts/exynos3250-rinato.dts | 2 +- arch/arm/boot/dts/exynos4210-i9100.dts | 30 ++++++++++++++++----------- arch/arm/boot/dts/exynos5250-spring.dts | 2 +- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +- arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +- arch/arm/boot/dts/exynos54xx.dtsi | 6 +++--- 8 files changed, 27 insertions(+), 21 deletions(-)