Hi Marek, On Mon, 22 Jan 2024 at 05:47, Marek Vasut <ma...@denx.de> wrote: > > 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). >
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. > 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. > > > 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. [1] https://lore.kernel.org/all/cal_jsqlo4nxrj93ddsfp3uyls08v02amnbccnsdj0mbbomc...@mail.gmail.com/ -Sumit