Hi Sumit, On 2024-05-15 10:49, Sumit Garg wrote: > Hi Jonas, > > On Wed, 15 May 2024 at 13:11, Jonas Karlman <jo...@kwiboo.se> wrote: >> >> Hi Tom, >> >> On 2024-05-14 18:42, Tom Rini wrote:> >>> git-subtree-dir: dts/upstream >>> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a >>> --- >>> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the >>> -next branch. To test these changes yourself locally, either use my >>> "WIP/14May2024-next" branch or run: >>> ./dts/update-dts-subtree.sh pull v6.9-dts >>> yourself locally. I intend to wait a few days to apply this to -next, to >>> give people time to test. >>> >> >> There are currently more boards/SoCs that use OF_UPSTREAM in master >> branch than in next branch, a few Rockchip SoCs and other boards/SoCs. > > Glad to see more OF_UPSTREAM adoption. > >> Next dts/upstream sync will probably be good to do together with a merge >> of master into next :-) > > I don't have any particular opinion here and rather leave it upto Tom > how he would like to merge stuff. > >> >> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will >> probably be released shortly after U-Boot v2024.07. So will next sync be >> to v6.10-dts if that happens in the U-Boot merge window or do we expect >> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the >> U-Boot merge window? >> >> Linux kernel typically have all major DT changes in -rc1 and fixes in >> later -rcX, so for next branch I would suggest an early sync to a >> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10 >> gets released. That should give more time for testing, migration and >> cleanup using v6.10 DTs in time for a 2024.10 release. > > I can see the reasoning for an aggressive DT syncing approach, it has > been brought up in the past too. And the major reason for the current > moderate sync approach [1] is to limit any DT ABI breakages for > U-Boot, we are even prone to breakages with syncs against major Linux > kernel releases (eg. v6.10-dts etc.). It has been a long time > discussion topic where we have been advocating about requirements for > DT ABI stability [2]. > > So having DT syncs done during the merge window will shorten the > testing window for developers/maintainers. And more syncs means a > multiplicative factor for testing. However, time will tell with more > and more platforms adopting OF_UPSTREAM, if there are any real DT ABI > breakages seen in the future. But surely if they are very rare then I > am open to adopting aggressive DT sync approaches.
I agree that syncing multiple rcX tags may not be that helpful, but an approach where maybe rc1, rc2 or rc3 and then the final tag is merged or something similar. At least when we can foresee when next Linux version will be released close to an U-Boot release. At least early in U-Boot release cycle know what Linux version dts/upstream will be targeted. My main concern is how to best handle new boards and features/drivers. E.g. for Rockchip the RK3588 SoC is under active development, new boards and features/drivers are actively added/fixed in upstream Linux. New Rockchip boards have typically been added after board DT have been merged into linux maintainer tree. Now if we wait until merge window to do a dts/upstream sync, the result may be that it may take up to three U-Boot releases until a new board is easily added using dts/upstream. Another approach could be that we add new boards using !OF_UPSTREAM once they are merged into linux maintainer tree. And then migrate the board to use OF_UPSTREAM once the board finally ends up in dts/upstream. But that can also be problematic when board .dts-file start referencing nodes/symbols not yet added in the soc .dts-file in dts/upstream. Adding the "missing" but maintainer merged soc nodes to the soc u-boot.dtsi could be one way to work around such issue. Anyway, some guidance, predictability and earlier sync related to dts/upstream would be much appreciated :-) Regards, Jonas > > [1] > https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > [2] > https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg02162.html > > -Sumit > >> >> Regards, >> Jonas
