On Wed, May 15, 2024 at 09:29:41AM +0200, Jonas Karlman 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. Next dts/upstream sync will probably be good to do together with a merge of master into next :-)
Yeah, with -rc3 I'll pull that in to next. And I did this sync now since Quentin reminded me on IRC about it. The massive CC list comes from using qconfig.py to see who enables it, and then a quick one-off to get a list out of get_maintainers.pl.
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?
So, I need to put something in to doc/develop/process.rst about when the full dts/upstream resyncs happen, and where. The plan currently is every Linux kernel release gets pulled in, and master or next depends on if the -next branch is open (which is with -rc2). This should give us the most time to get changes tested, while minimizing drift away from upstream sources. This is also because, and related to, that I try and make sure that nothing breaking comes in to master once next is open, and so if a board maintainer has time to test things at -rc3 or what have you, it should still work in the release proper. More testing is always great, but given our release cadence and generally predictable schedule, I am hopeful this provides the best trade-offs in terms of time demands on board maintainers.
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.
The issue in my mind is that we just don't have a lot of people with time to test things in U-Boot. So I'd rather avoid possible broken upstream and then fixed later upstream problems. And having done it now, I can also say it's really easy to use dts/update-dts-subtree.sh so if someone has time they can do that locally.