On Thu, 25 Jan 2024 at 07:36, Marek Vasut marex@denx.de wrote:
On 1/24/24 09:16, Sumit Garg wrote:
Hi,
How do you propose to handle fixes to DTs which are applied to linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which has some defect that is fixed in 6.6.1, how will that fix get into U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would find its way here - as I understand it patches aren't accepted into Linux stable unless they land in torvalds tree.
See the devicetree-rebasing.git:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
That only contains refs for release versions (v6.6-dts, v6.7-dts etc), not any follow-up updates from linux-stable (like current 6.6.13 etc).
Here we should only consider fixes which are critical to U-Boot. I think -u-boot.dtsi files would be suitable to carry those fixes until next uprev. However, if there is a fix affecting many platforms than we can consider pulling that standalone too.
That would mean extra duplicate work -- the critical fixes have already been selected into linux-stable, that work is already done, I don't think it makes sense to re-do it again.
Furthermore, I do not like the new necessity to start porting those fixes from linux-stable and converting them to adjustments to *-u-boot.dtsi files, this is tedious and error prone, so it would have to be automated.
But I still think it is much better to simply take the fixes directly from linux-stable as-is instead.
That's fair, it would essentially be a DT ABI breakage for U-Boot for which a fix has to be taken in U-Boot from Linux stable release. So I am fine with that.
But at this point we have to move away from apprehensions about DT ABI breakages and provide real examples of the DT ABI breakages in the past. Are you aware of any DT ABI breaking change backported to Linux stable releases? This is the sort of information we would like to make DT bindings maintainers aware about.
Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ?
Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So its a chicken and egg problem as per your comments below. However, we can revisit our syncing strategy based on how the current one pans out.
Assume that there is some large breaking change in Linux 6.(n+1), something which would be problematic for specific U-Boot platform (e.g. i.MX) or would require a lot of work to sort out, will there be a way to temporarily pin DTs for specific platform to older DT version until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were such a breaking change to get merged without prior discussion with DT users (i.e. U-Boot) then I think the correct course of action would be to revert it.
Not really, this could be a perfectly valid change, and would work for Linux just fine, it might simply be pulling in something which is not supported by U-Boot just yet and therefore syncing the DTs into U-Boot would break U-Boot on that platform . Using older version of DTs for a platform could work as a stopgap measure until the functionality is implemented. Is this possible ?
For this particular reason we want to pull once during beginning on U-Boot next window and allow sufficient time for platform maintainers to adapt to it. However, OF_UPSTREAM=n can be an alternative for a stopgap solution.
That pull would break other peoples platforms. It would be no different than adding broken patch into the code base.
The platforms which get converted to OF_UPSTREAM=y are the ones which would be compliant with upstream DT bindings. So any DT ABI change among major Linux .0 releases would be the reason for that breakage. And we are happy to accept a revert for that change and feed that information back to Linux DT bindings maintainers.
Also as above, are you aware of any past DT ABI breakages for U-Boot since people have already been doing DT syncing from Linux manually. This series allows to reduce that pain and try to bring DT bindings compliance in U-Boot.
What I think would be an option is that there is a pull (as in patch) and people should be able to test it before it is applied.
We can't modify that pull but rather accept changes on top of it. IMO, it will get widely tested in U-Boot next branch.
If one platform is severely affected while other platforms are fine, the one platform should be able to use the current working version of DTs, while the other platforms should not be blocked by it. Is that what OF_UPSTREAM=n does ?
As far as I understand OF_UPSTREAM=n, it would require re-importing DTs into the codebase ?
No you don't have to re-import everything but rather import a board DTS file to the arch/ folder and reuse all the DT includes from dts/upstream subtree as per this [1] patch.
[1] https://lore.kernel.org/all/20240110103547.719757-5-sumit.garg@linaro.org/
On a tangential note: as I understand it, DTs built from dt-rebasing are still subject to U-Boot customisations via the "-u-boot.dtsi" include files, this allows for dealing with incompatibilities due to missing features in U-Boot.
Would it be possible to auto-update those -u-boot.dtsi files during sync, to minimize the resulting DT blob delta before/after update, and thus also minimize the likelihood of causing breakage ?
In the long run the DT community would like to avoid any DT ABI breakages at all. Rob is already working on a DT ABI check tool and seeking inputs for what could be an ABI break [1] from U-Boot perspective too. Feel free to provide your inputs.
Along with that we wouldn't need -u-boot.dtsi files once we make U-Boot fully compliant with DT bindings. Until that point U-Boot platform maintainers have to keep their -u-boot.dtsi files updated corresponding to latest DT rebasing releases.
I think upstreaming the bootph* properties would still take a while, but is not relevant to the aforementioned question.
Assume there is a sync, would the current in-tree -u-boot.dtsi files get updated to work correctly with the newly synced DTs ?
As long as they contain nodes/properties (eg. bootph* etc.) which are compliant with upstream DT bindings then yes they should work correctly with the newly synced DTs.
-Sumit