On 1/21/24 23:41, Caleb Connolly 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-rebasing.git/refs/

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).

Would this require syncing in -rc versions of Linux DTs to get the latest fixes in ?

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 ?

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 ?

Reply via email to