| Message ID | 20240110103547.719757-1-sumit.garg@linaro.org |
|---|---|
| Headers | show |
| Series | An effort to bring DT bindings compliance within U-Boot | expand |
On 16:05-20240110, Sumit Garg wrote: [...] > Prerequisite > ------------ > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-Boot repo via: > > $ git subtree add --prefix dts/upstream \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ Please use https:// also what is the baseline? didn't seem to apply on (fails at patch #2): next f28a77589e75 Merge tag 'dm-next-7jan23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next master f7cca7ccc511 Revert "test: hush: dollar: fix bugous behavior"
On 1/10/24 11:35, Sumit Garg wrote: > Changes in v4: > -------------- > - Switched subtree to be imported as dts/upstream sub-directory rather > than devicetree-rebasing sub-directory to better suite U-Boot > directory structure. > - Since we now have v6.7-dts tag available now, so switch subtree to > that from its beginning. > - Patch #2: Incorporate build fix to adjust Bindings Makefile rules to > old U-Boot Kbuild infrastructure. > - Patch #3: Incorporate fix to resolve rk3399 migration issue reported > by Simon. > - Patch #4: New patch to reuse upstream DT includes by U-Boot as per > Brian's use-case for TI K3 SoCs. > - Patch #5: Added a note to OF_UPSTREAM Kconfig option. > - Patch #6: New patch to add script dts/update-dts-subtree.sh as per > Rob's comments. > - Patch #7: Separate patch to align documentation to use Kconfig symbols > instead. > - Patch #8: Clarify subtree uprev schedule as a separate documentation > section. Also, fixed documentation typos. > - Patch #9: Added commit description. > > Changes in v3: > -------------- > - Patch #4: Minor commit message update > - Patch #5: Replace CONFIG_* with Kconfig options > - Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC > instead. > - Patch #1, #3, #6 and #8: Picked up review tags > > Changes in v2: > -------------- > - Patch #1: excluded gitab CI config check and added commit description. > - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/ > - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > - Patch #5: s/U-boot/U-Boot/ > - Patch #6 and #7: Picked up review tags > > Prerequisite > ------------ > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-Boot repo via: > > $ git subtree add --prefix dts/upstream \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > v6.7-dts --squash > > Background > ---------- > > This effort started while I was reviewing patch series corresponding to > Qcom platforms [1] which was about to import modified devicetree source > files from Linux kernel. I suppose keeping devicetree files sync with > Linux kernel without any DT bindings schema validation has been a pain > for U-Boot SoC/platform maintainers. There has been past discussions > about a single DT repo but that hasn't come up and Linux kernel remained > the place where DT source files as well as bindings are placed and > maintained. > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > use devicetree-rebasing repo [3] which is a forked copy from Linux > kernel for DT source files as well as bindings. It is tagged at every > Linux kernel major release or intermideate release candidates. So here I > have tried to reuse that to bring DT bingings compliance as well as a > standard way to maintain a regular sync of DT source files with Linux > kernel. > > In order to maintain devicetree files sync, U-Boot will maintains a Git > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > opens with the next available kernel major release. > `dts/update-dts-subtree.sh` script provides a wrapper around git subtree > pull command, usage from the top level U-Boot source tree, run: > > $ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag> > > The RFC/prototype for this series has been discussed with Linux DT > maintainers as well as U-Boot maintainers here [4]. Now we would like to > reach out to wider U-Boot community to seek feedback. I very much agree with the direction this is going in, but I do have two simple questions: 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 ? 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) ?
On 21/01/2024 15:33, Marek Vasut wrote: > On 1/10/24 11:35, Sumit Garg wrote: >> Changes in v4: >> -------------- >> - Switched subtree to be imported as dts/upstream sub-directory rather >> than devicetree-rebasing sub-directory to better suite U-Boot >> directory structure. >> - Since we now have v6.7-dts tag available now, so switch subtree to >> that from its beginning. >> - Patch #2: Incorporate build fix to adjust Bindings Makefile rules to >> old U-Boot Kbuild infrastructure. >> - Patch #3: Incorporate fix to resolve rk3399 migration issue reported >> by Simon. >> - Patch #4: New patch to reuse upstream DT includes by U-Boot as per >> Brian's use-case for TI K3 SoCs. >> - Patch #5: Added a note to OF_UPSTREAM Kconfig option. >> - Patch #6: New patch to add script dts/update-dts-subtree.sh as per >> Rob's comments. >> - Patch #7: Separate patch to align documentation to use Kconfig symbols >> instead. >> - Patch #8: Clarify subtree uprev schedule as a separate documentation >> section. Also, fixed documentation typos. >> - Patch #9: Added commit description. >> >> Changes in v3: >> -------------- >> - Patch #4: Minor commit message update >> - Patch #5: Replace CONFIG_* with Kconfig options >> - Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC >> instead. >> - Patch #1, #3, #6 and #8: Picked up review tags >> >> Changes in v2: >> -------------- >> - Patch #1: excluded gitab CI config check and added commit description. >> - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/ >> - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ >> - Patch #5: s/U-boot/U-Boot/ >> - Patch #6 and #7: Picked up review tags >> >> Prerequisite >> ------------ >> >> This patch series requires devicetree-rebasing git repo to be added as a >> subtree to the main U-Boot repo via: >> >> $ git subtree add --prefix dts/upstream \ >> >> git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ >> v6.7-dts --squash >> >> Background >> ---------- >> >> This effort started while I was reviewing patch series corresponding to >> Qcom platforms [1] which was about to import modified devicetree source >> files from Linux kernel. I suppose keeping devicetree files sync with >> Linux kernel without any DT bindings schema validation has been a pain >> for U-Boot SoC/platform maintainers. There has been past discussions >> about a single DT repo but that hasn't come up and Linux kernel remained >> the place where DT source files as well as bindings are placed and >> maintained. >> >> However, Linux kernel DT maintainers proposed [2] for U-Boot to rather >> use devicetree-rebasing repo [3] which is a forked copy from Linux >> kernel for DT source files as well as bindings. It is tagged at every >> Linux kernel major release or intermideate release candidates. So here I >> have tried to reuse that to bring DT bingings compliance as well as a >> standard way to maintain a regular sync of DT source files with Linux >> kernel. >> >> In order to maintain devicetree files sync, U-Boot will maintains a Git >> subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. >> U-Boot will regularly sync `dts/upstream/` subtree whenever the next >> window >> opens with the next available kernel major release. >> `dts/update-dts-subtree.sh` script provides a wrapper around git subtree >> pull command, usage from the top level U-Boot source tree, run: >> >> $ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag> >> >> The RFC/prototype for this series has been discussed with Linux DT >> maintainers as well as U-Boot maintainers here [4]. Now we would like to >> reach out to wider U-Boot community to seek feedback. > > I very much agree with the direction this is going in, but I do have two > simple questions: > > 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. > > 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. 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.
On Sun, Jan 21, 2024 at 10:41:51PM +0000, Caleb Connolly wrote: > > > On 21/01/2024 15:33, Marek Vasut wrote: [snip] > > 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. The caveat is "unless it was wrong before", which happens more often than is generally thought of I think. I'm not sure off-hand the best way to deal with that.
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 ?
On Wed, 10 Jan 2024 16:05:36 +0530 Sumit Garg <sumit.garg@linaro.org> wrote: Hi, I certainly welcome this more automatic synchronisation of the DTs, however have one comment about the upcoming sync process: > ... > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > use devicetree-rebasing repo [3] which is a forked copy from Linux > kernel for DT source files as well as bindings. It is tagged at every > Linux kernel major release or intermideate release candidates. So here I > have tried to reuse that to bring DT bingings compliance as well as a > standard way to maintain a regular sync of DT source files with Linux > kernel. > > In order to maintain devicetree files sync, U-Boot will maintains a Git > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > opens with the next available kernel major release. I hope this doesn't need to stay that restricted? Can we either sync more often, or at least on the kernel's -rc1, and not only on a "full" release? The reason I ask is that we have a chicken-egg problem here: without a DT merged into the kernel tree, no U-Boot board support can be merged. And without U-Boot support, we cannot boot a kernel, at least not in the canonical way. Since the U-Boot and kernel merge windows are not in phase, for sunxi I try to sync the kernel DTs either as early as possible (-rc1, sometimes even before, when the maintainers have merged them into their tree), or sometimes "out of season", if a board defconfig patch is coming up. Otherwise new board support, which typically has a very low regression risk for the rest of the code base, would need to be delayed until the next release. In the worst case the U-Boot merge windows opens one week before a kernel release, then new boards need to wait three months? Cheers, Andre > `dts/update-dts-subtree.sh` script provides a wrapper around git subtree > pull command, usage from the top level U-Boot source tree, run: > > $ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag> > > The RFC/prototype for this series has been discussed with Linux DT > maintainers as well as U-Boot maintainers here [4]. Now we would like to > reach out to wider U-Boot community to seek feedback. > > [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ > [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ > [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > [4] https://github.com/u-boot/u-boot/pull/451 >
On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote: > On Wed, 10 Jan 2024 16:05:36 +0530 > Sumit Garg <sumit.garg@linaro.org> wrote: > > Hi, > > I certainly welcome this more automatic synchronisation of the DTs, > however have one comment about the upcoming sync process: > > > ... > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > > use devicetree-rebasing repo [3] which is a forked copy from Linux > > kernel for DT source files as well as bindings. It is tagged at every > > Linux kernel major release or intermideate release candidates. So here I > > have tried to reuse that to bring DT bingings compliance as well as a > > standard way to maintain a regular sync of DT source files with Linux > > kernel. > > > > In order to maintain devicetree files sync, U-Boot will maintains a Git > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > > opens with the next available kernel major release. > > I hope this doesn't need to stay that restricted? Can we either sync more > often, or at least on the kernel's -rc1, and not only on a "full" release? > > The reason I ask is that we have a chicken-egg problem here: without a DT > merged into the kernel tree, no U-Boot board support can be merged. And > without U-Boot support, we cannot boot a kernel, at least not in the > canonical way. > > Since the U-Boot and kernel merge windows are not in phase, for sunxi I try > to sync the kernel DTs either as early as possible (-rc1, sometimes even > before, when the maintainers have merged them into their tree), or > sometimes "out of season", if a board defconfig patch is coming up. > > Otherwise new board support, which typically has a very low regression risk > for the rest of the code base, would need to be delayed until the next > release. In the worst case the U-Boot merge windows opens one week before > a kernel release, then new boards need to wait three months? Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot release, and then with the next one switch to OF_UPSTREAM=y (and delete the dts from arch/) for the next release, when we would have gotten back in sync?
On Mon, 22 Jan 2024 11:49:59 -0500 Tom Rini <trini@konsulko.com> wrote: Hi Tom, > On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote: > > On Wed, 10 Jan 2024 16:05:36 +0530 > > Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Hi, > > > > I certainly welcome this more automatic synchronisation of the DTs, > > however have one comment about the upcoming sync process: > > > > > ... > > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > > > use devicetree-rebasing repo [3] which is a forked copy from Linux > > > kernel for DT source files as well as bindings. It is tagged at every > > > Linux kernel major release or intermideate release candidates. So here I > > > have tried to reuse that to bring DT bingings compliance as well as a > > > standard way to maintain a regular sync of DT source files with Linux > > > kernel. > > > > > > In order to maintain devicetree files sync, U-Boot will maintains a Git > > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > > > opens with the next available kernel major release. > > > > I hope this doesn't need to stay that restricted? Can we either sync more > > often, or at least on the kernel's -rc1, and not only on a "full" release? > > > > The reason I ask is that we have a chicken-egg problem here: without a DT > > merged into the kernel tree, no U-Boot board support can be merged. And > > without U-Boot support, we cannot boot a kernel, at least not in the > > canonical way. > > > > Since the U-Boot and kernel merge windows are not in phase, for sunxi I try > > to sync the kernel DTs either as early as possible (-rc1, sometimes even > > before, when the maintainers have merged them into their tree), or > > sometimes "out of season", if a board defconfig patch is coming up. > > > > Otherwise new board support, which typically has a very low regression risk > > for the rest of the code base, would need to be delayed until the next > > release. In the worst case the U-Boot merge windows opens one week before > > a kernel release, then new boards need to wait three months? > > Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot > release, and then with the next one switch to OF_UPSTREAM=y (and delete > the dts from arch/) for the next release, when we would have gotten back > in sync? Ah, I didn't look into the actual patches, but if this provision is there, that sounds surely acceptable. It might still be good to sync earlier than the .0 kernel release: if it appears in Linus' tree, it had already seen a good share of review and testing. And with the U-Boot releases being always further away than the next kernel release, we could pull fixes still in time. So we could pick the latest -rc (or .0 release, whichever is more recent) when the U-Boot merge window opens? Cheers, Andre
On Mon, Jan 22, 2024 at 6:59 PM Andre Przywara <andre.przywara@arm.com> wrote: > > On Mon, 22 Jan 2024 11:49:59 -0500 > Tom Rini <trini@konsulko.com> wrote: > > Hi Tom, > > > On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote: > > > On Wed, 10 Jan 2024 16:05:36 +0530 > > > Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Hi, > > > > > > I certainly welcome this more automatic synchronisation of the DTs, > > > however have one comment about the upcoming sync process: > > > > > > > ... > > > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > > > > use devicetree-rebasing repo [3] which is a forked copy from Linux > > > > kernel for DT source files as well as bindings. It is tagged at every > > > > Linux kernel major release or intermideate release candidates. So here I > > > > have tried to reuse that to bring DT bingings compliance as well as a > > > > standard way to maintain a regular sync of DT source files with Linux > > > > kernel. > > > > > > > > In order to maintain devicetree files sync, U-Boot will maintains a Git > > > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > > > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > > > > opens with the next available kernel major release. > > > > > > I hope this doesn't need to stay that restricted? Can we either sync more > > > often, or at least on the kernel's -rc1, and not only on a "full" release? > > > > > > The reason I ask is that we have a chicken-egg problem here: without a DT > > > merged into the kernel tree, no U-Boot board support can be merged. And > > > without U-Boot support, we cannot boot a kernel, at least not in the > > > canonical way. > > > > > > Since the U-Boot and kernel merge windows are not in phase, for sunxi I try > > > to sync the kernel DTs either as early as possible (-rc1, sometimes even > > > before, when the maintainers have merged them into their tree), or > > > sometimes "out of season", if a board defconfig patch is coming up. > > > > > > Otherwise new board support, which typically has a very low regression risk > > > for the rest of the code base, would need to be delayed until the next > > > release. In the worst case the U-Boot merge windows opens one week before > > > a kernel release, then new boards need to wait three months? > > > > Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot > > release, and then with the next one switch to OF_UPSTREAM=y (and delete > > the dts from arch/) for the next release, when we would have gotten back > > in sync? > > Ah, I didn't look into the actual patches, but if this provision is > there, that sounds surely acceptable. It might still be good to sync > earlier than the .0 kernel release: if it appears in Linus' tree, it > had already seen a good share of review and testing. And with the > U-Boot releases being always further away than the next kernel release, > we could pull fixes still in time. So we could pick the latest -rc (or > .0 release, whichever is more recent) when the U-Boot merge window > opens? That should be mostly fine IMO, but there are the occasional "oops, let's change/fix the binding before it's released". Couldn't you pull in the latest rc in the merge window, but only if the .0 release will happen before the next u-boot release. And then update from rc to .0 before the u-boot release. Also, from a quick look at the dts changes during rc releases, they tend to come in the later rc releases. Probably that's just the latency of going to sub-arch maintainer->SoC->Linus. Rob
Hi Nishanth, Apologies for the delayed response as I was on a long weekend vacation. On Fri, 19 Jan 2024 at 21:27, Nishanth Menon <nm@ti.com> wrote: > > On 16:05-20240110, Sumit Garg wrote: > [...] > > Prerequisite > > ------------ > > > > This patch series requires devicetree-rebasing git repo to be added as a > > subtree to the main U-Boot repo via: > > > > $ git subtree add --prefix dts/upstream \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > Please use https:// Okay I can do that given the widespread use of https:// > > also what is the baseline? didn't seem to apply on (fails at patch #2): > next f28a77589e75 Merge tag 'dm-next-7jan23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next > master f7cca7ccc511 Revert "test: hush: dollar: fix bugous behavior" Okay looks like recent merges caused conflicts, needs a rebase. However, for v4 you can use this branch [1] for testing. [1] https://github.com/b49020/u-boot/tree/v4_dt -Sumit > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Mon, 22 Jan 2024 at 05:31, Tom Rini <trini@konsulko.com> wrote: > > On Sun, Jan 21, 2024 at 10:41:51PM +0000, Caleb Connolly wrote: > > > > > > On 21/01/2024 15:33, Marek Vasut wrote: > [snip] > > > 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. > > The caveat is "unless it was wrong before", which happens more often > than is generally thought of I think. I'm not sure off-hand the best way > to deal with that. I think that's the reason we just want to pull DT at once in the beginning of the next window and allow U-Boot developers/maintainers to detect and fix problems during the full U-Boot release cycle. However, we are open to discussions for a revert if there is a major DT ABI break among Linux major (.0) releases affecting many U-Boot platforms. -Sumit > > -- > Tom
Hi Marek, On Mon, 22 Jan 2024 at 05:47, Marek Vasut <marex@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_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc35w@mail.gmail.com/ -Sumit
Hi Rob, Andre, On Tue, 23 Jan 2024 at 22:12, Rob Herring <robh+dt@kernel.org> wrote: > > On Mon, Jan 22, 2024 at 6:59 PM Andre Przywara <andre.przywara@arm.com> wrote: > > > > On Mon, 22 Jan 2024 11:49:59 -0500 > > Tom Rini <trini@konsulko.com> wrote: > > > > Hi Tom, > > > > > On Mon, Jan 22, 2024 at 11:45:15AM +0000, Andre Przywara wrote: > > > > On Wed, 10 Jan 2024 16:05:36 +0530 > > > > Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > > > Hi, > > > > > > > > I certainly welcome this more automatic synchronisation of the DTs, > > > > however have one comment about the upcoming sync process: > > > > > > > > > ... > > > > > However, Linux kernel DT maintainers proposed [2] for U-Boot to rather > > > > > use devicetree-rebasing repo [3] which is a forked copy from Linux > > > > > kernel for DT source files as well as bindings. It is tagged at every > > > > > Linux kernel major release or intermideate release candidates. So here I > > > > > have tried to reuse that to bring DT bingings compliance as well as a > > > > > standard way to maintain a regular sync of DT source files with Linux > > > > > kernel. > > > > > > > > > > In order to maintain devicetree files sync, U-Boot will maintains a Git > > > > > subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. > > > > > U-Boot will regularly sync `dts/upstream/` subtree whenever the next window > > > > > opens with the next available kernel major release. > > > > > > > > I hope this doesn't need to stay that restricted? Can we either sync more > > > > often, or at least on the kernel's -rc1, and not only on a "full" release? > > > > > > > > The reason I ask is that we have a chicken-egg problem here: without a DT > > > > merged into the kernel tree, no U-Boot board support can be merged. And > > > > without U-Boot support, we cannot boot a kernel, at least not in the > > > > canonical way. > > > > > > > > Since the U-Boot and kernel merge windows are not in phase, for sunxi I try > > > > to sync the kernel DTs either as early as possible (-rc1, sometimes even > > > > before, when the maintainers have merged them into their tree), or > > > > sometimes "out of season", if a board defconfig patch is coming up. > > > > > > > > Otherwise new board support, which typically has a very low regression risk > > > > for the rest of the code base, would need to be delayed until the next > > > > release. In the worst case the U-Boot merge windows opens one week before > > > > a kernel release, then new boards need to wait three months? > > > > > > Would it be to bad to bring in board X with OF_UPSTREAM=n for one U-Boot > > > release, and then with the next one switch to OF_UPSTREAM=y (and delete > > > the dts from arch/) for the next release, when we would have gotten back > > > in sync? > > > > Ah, I didn't look into the actual patches, but if this provision is > > there, that sounds surely acceptable. It might still be good to sync > > earlier than the .0 kernel release: if it appears in Linus' tree, it > > had already seen a good share of review and testing. And with the > > U-Boot releases being always further away than the next kernel release, > > we could pull fixes still in time. So we could pick the latest -rc (or > > .0 release, whichever is more recent) when the U-Boot merge window > > opens? > > That should be mostly fine IMO, but there are the occasional "oops, > let's change/fix the binding before it's released". > > Couldn't you pull in the latest rc in the merge window, but only if > the .0 release will happen before the next u-boot release. And then > update from rc to .0 before the u-boot release. > > Also, from a quick look at the dts changes during rc releases, they > tend to come in the later rc releases. Probably that's just the > latency of going to sub-arch maintainer->SoC->Linus. > I agree with your intent to keep U-Boot updated with the latest Linux DT .0 releases. However, we would like to provide sufficient time (a full U-Boot release cycle) for U-Boot developers/maintainers to adapt, detect and fix problems for their platforms wrt. to a new Linux DT .0 release. We can always revisit the syncing strategy to be more aggressive if everything pans out as per plan. -Sumit > Rob
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-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. 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. >> 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. 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. 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 ? >>> 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 ?
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-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. > > 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
On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote: [snip] > 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. Well, how far back are we going? There was a serial related one, but it was probably closer than not to 10 years ago and lessons have been learned from it already. The real breakage comes in the form of (from the Linux kernel): commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi <peter.ujfalusi@ti.com> Date: Tue Feb 19 08:46:33 2019 -0800 ARM: dts: am335x-evm: Fix PHY mode for ethernet The PHY must add both tx and rx delay and not only on the tx clock. The board uses AR8031_AL1A PHY where the rx delay is enabled by default, the tx dealy is disabled. The reason why rgmii-txid worked because the rx delay was not disabled by the driver so essentially we ended up with rgmii-id PHY mode. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> And this is of the style "the DTS was wrong before so we can break it". This is the specific example (as the board is in my lab) that comes most clearly to mind but there have been similar examples in 2022/2023. The other just as painful examples I think may be where Marek is concerned and it's around nodes being renamed for correctness. We've had a number of cases where a - turned to _ (or vice versa?) and whoops, platform stops booting. Down the line, tooling would catch that, and it's a problem of not being able to use better tooling until we have the updates that might break the boards that need the better tooling. And really this gets to the crux of the problem, how much testing do we insist happens prior to a re-sync being merged? Do we want to go with the whole of the dts files are re-synced, or do we leave it per vendor? I think it's been noted that a subtree merge commit doesn't really "git send-email" well. I really am inclined to start with keeping everyone to the release tags for everyone and merging them as soon as the next window opens. I _think__ and we'll be able to find out quickly enough, that we can cherry-pick fixes from upstream in to our subtree and have subtree Do The Right Thing in the next merge window. [snip] > > 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. This is a good specific example. The bootph* properties should _now_ be easier to get accepted upstream as our tooling handles the transitive property of them correctly and so they don't need to be manually applied so much (a problem upstream maintainers had, after the binding was accepted, was the sheer number of them being added, this is now fixed). But also applying these properties via -u-boot.dtsi was tripped up in resyncs where the parent node was renamed for correctness and there's no tooling that we had that complained. In the future, this would have been caught because we would have been dtbs_check clean, or at least clean enough that I'd be running it and caring about deltas from before/after.
On 1/25/24 16:04, Tom Rini wrote: > On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote: > > [snip] >> 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. > > Well, how far back are we going? There was a serial related one, but it > was probably closer than not to 10 years ago and lessons have been > learned from it already. > > The real breakage comes in the form of (from the Linux kernel): > commit 37685f6a63eeca2135d1f704e7638409a071b1f6 > Author: Peter Ujfalusi <peter.ujfalusi@ti.com> > Date: Tue Feb 19 08:46:33 2019 -0800 > > ARM: dts: am335x-evm: Fix PHY mode for ethernet > > The PHY must add both tx and rx delay and not only on the tx clock. > The board uses AR8031_AL1A PHY where the rx delay is enabled by default, > the tx dealy is disabled. > > The reason why rgmii-txid worked because the rx delay was not disabled by > the driver so essentially we ended up with rgmii-id PHY mode. > > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > Signed-off-by: Tony Lindgren <tony@atomide.com> > > And this is of the style "the DTS was wrong before so we can break it". > This is the specific example (as the board is in my lab) that comes most > clearly to mind but there have been similar examples in 2022/2023. > > The other just as painful examples I think may be where Marek is > concerned and it's around nodes being renamed for correctness. We've had > a number of cases where a - turned to _ (or vice versa?) and whoops, > platform stops booting. Down the line, tooling would catch that, and > it's a problem of not being able to use better tooling until we have the > updates that might break the boards that need the better tooling. > > And really this gets to the crux of the problem, how much testing do we > insist happens prior to a re-sync being merged? Do we want to go with > the whole of the dts files are re-synced, or do we leave it per vendor? I'd much prefer to leave it per vendor, with the recommendation to use synced DTs. Eventually things will stabilize and vendors will start switching over.
On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote: > On 1/25/24 16:04, Tom Rini wrote: > > On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote: > > > > [snip] > > > 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. > > > > Well, how far back are we going? There was a serial related one, but it > > was probably closer than not to 10 years ago and lessons have been > > learned from it already. > > > > The real breakage comes in the form of (from the Linux kernel): > > commit 37685f6a63eeca2135d1f704e7638409a071b1f6 > > Author: Peter Ujfalusi <peter.ujfalusi@ti.com> > > Date: Tue Feb 19 08:46:33 2019 -0800 > > > > ARM: dts: am335x-evm: Fix PHY mode for ethernet > > > > The PHY must add both tx and rx delay and not only on the tx clock. > > The board uses AR8031_AL1A PHY where the rx delay is enabled by default, > > the tx dealy is disabled. > > > > The reason why rgmii-txid worked because the rx delay was not disabled by > > the driver so essentially we ended up with rgmii-id PHY mode. > > > > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > > > And this is of the style "the DTS was wrong before so we can break it". > > This is the specific example (as the board is in my lab) that comes most > > clearly to mind but there have been similar examples in 2022/2023. > > > > The other just as painful examples I think may be where Marek is > > concerned and it's around nodes being renamed for correctness. We've had > > a number of cases where a - turned to _ (or vice versa?) and whoops, > > platform stops booting. Down the line, tooling would catch that, and > > it's a problem of not being able to use better tooling until we have the > > updates that might break the boards that need the better tooling. > > > > And really this gets to the crux of the problem, how much testing do we > > insist happens prior to a re-sync being merged? Do we want to go with > > the whole of the dts files are re-synced, or do we leave it per vendor? > > I'd much prefer to leave it per vendor, with the recommendation to use > synced DTs. Eventually things will stabilize and vendors will start > switching over. To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM to start with. With that, I see switching to OF_UPSTREAM meaning that there's a commitment to keeping up with dts change in upstream dts that might lead to issues within U-Boot. Do you still feel it would be better to have the re-sync _also_ be per custodian tree? That might be a bit harder to handle.
On 1/26/24 00:19, Tom Rini wrote: > On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote: >> On 1/25/24 16:04, Tom Rini wrote: >>> On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote: >>> >>> [snip] >>>> 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. >>> >>> Well, how far back are we going? There was a serial related one, but it >>> was probably closer than not to 10 years ago and lessons have been >>> learned from it already. >>> >>> The real breakage comes in the form of (from the Linux kernel): >>> commit 37685f6a63eeca2135d1f704e7638409a071b1f6 >>> Author: Peter Ujfalusi <peter.ujfalusi@ti.com> >>> Date: Tue Feb 19 08:46:33 2019 -0800 >>> >>> ARM: dts: am335x-evm: Fix PHY mode for ethernet >>> >>> The PHY must add both tx and rx delay and not only on the tx clock. >>> The board uses AR8031_AL1A PHY where the rx delay is enabled by default, >>> the tx dealy is disabled. >>> >>> The reason why rgmii-txid worked because the rx delay was not disabled by >>> the driver so essentially we ended up with rgmii-id PHY mode. >>> >>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> >>> Signed-off-by: Tony Lindgren <tony@atomide.com> >>> >>> And this is of the style "the DTS was wrong before so we can break it". >>> This is the specific example (as the board is in my lab) that comes most >>> clearly to mind but there have been similar examples in 2022/2023. >>> >>> The other just as painful examples I think may be where Marek is >>> concerned and it's around nodes being renamed for correctness. We've had >>> a number of cases where a - turned to _ (or vice versa?) and whoops, >>> platform stops booting. Down the line, tooling would catch that, and >>> it's a problem of not being able to use better tooling until we have the >>> updates that might break the boards that need the better tooling. >>> >>> And really this gets to the crux of the problem, how much testing do we >>> insist happens prior to a re-sync being merged? Do we want to go with >>> the whole of the dts files are re-synced, or do we leave it per vendor? >> >> I'd much prefer to leave it per vendor, with the recommendation to use >> synced DTs. Eventually things will stabilize and vendors will start >> switching over. > > To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM > to start with. With that, I see switching to OF_UPSTREAM meaning that > there's a commitment to keeping up with dts change in upstream dts that > might lead to issues within U-Boot. Do you still feel it would be better > to have the re-sync _also_ be per custodian tree? That might be a bit > harder to handle. Maybe the best thing we can do is just give it a try and see how it works out, esp. since it is opt-in per board . It would still be good to solve the part about pulling in fixes from linux-stable though .
On 1/26/24 03:10, Marek Vasut wrote: > On 1/26/24 00:19, Tom Rini wrote: >> On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote: >>> On 1/25/24 16:04, Tom Rini wrote: >>>> On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote: >>>> >>>> [snip] >>>>> 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. >>>> >>>> Well, how far back are we going? There was a serial related one, but it >>>> was probably closer than not to 10 years ago and lessons have been >>>> learned from it already. >>>> >>>> The real breakage comes in the form of (from the Linux kernel): >>>> commit 37685f6a63eeca2135d1f704e7638409a071b1f6 >>>> Author: Peter Ujfalusi <peter.ujfalusi@ti.com> >>>> Date: Tue Feb 19 08:46:33 2019 -0800 >>>> >>>> ARM: dts: am335x-evm: Fix PHY mode for ethernet >>>> >>>> The PHY must add both tx and rx delay and not only on the tx clock. >>>> The board uses AR8031_AL1A PHY where the rx delay is enabled by default, >>>> the tx dealy is disabled. >>>> >>>> The reason why rgmii-txid worked because the rx delay was not disabled by >>>> the driver so essentially we ended up with rgmii-id PHY mode. >>>> >>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> >>>> Signed-off-by: Tony Lindgren <tony@atomide.com> >>>> >>>> And this is of the style "the DTS was wrong before so we can break it". >>>> This is the specific example (as the board is in my lab) that comes most >>>> clearly to mind but there have been similar examples in 2022/2023. >>>> >>>> The other just as painful examples I think may be where Marek is >>>> concerned and it's around nodes being renamed for correctness. We've had >>>> a number of cases where a - turned to _ (or vice versa?) and whoops, >>>> platform stops booting. Down the line, tooling would catch that, and >>>> it's a problem of not being able to use better tooling until we have the >>>> updates that might break the boards that need the better tooling. >>>> >>>> And really this gets to the crux of the problem, how much testing do we >>>> insist happens prior to a re-sync being merged? Do we want to go with >>>> the whole of the dts files are re-synced, or do we leave it per vendor? >>> >>> I'd much prefer to leave it per vendor, with the recommendation to use >>> synced DTs. Eventually things will stabilize and vendors will start >>> switching over. >> >> To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM >> to start with. With that, I see switching to OF_UPSTREAM meaning that >> there's a commitment to keeping up with dts change in upstream dts that >> might lead to issues within U-Boot. Do you still feel it would be better >> to have the re-sync _also_ be per custodian tree? That might be a bit >> harder to handle. > > Maybe the best thing we can do is just give it a try and see how it works out, > esp. since it is opt-in per board . > > It would still be good to solve the part about pulling in fixes from > linux-stable though . I would let board owners/custodians to deal with their boards. There is very high chance that if you do it globally that it is question of time when something will break. It make sense to talk about how to do that transition and describe that steps and having tools/script to help with. Thanks, Michal
On Fri, 26 Jan 2024 at 12:35, Michal Simek <michal.simek@amd.com> wrote: > > > On 1/26/24 03:10, Marek Vasut wrote: > > On 1/26/24 00:19, Tom Rini wrote: > >> On Thu, Jan 25, 2024 at 05:38:23PM +0100, Marek Vasut wrote: > >>> On 1/25/24 16:04, Tom Rini wrote: > >>>> On Thu, Jan 25, 2024 at 12:54:22PM +0530, Sumit Garg wrote: > >>>> > >>>> [snip] > >>>>> 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. > >>>> > >>>> Well, how far back are we going? There was a serial related one, but it > >>>> was probably closer than not to 10 years ago and lessons have been > >>>> learned from it already. > >>>> > >>>> The real breakage comes in the form of (from the Linux kernel): > >>>> commit 37685f6a63eeca2135d1f704e7638409a071b1f6 > >>>> Author: Peter Ujfalusi <peter.ujfalusi@ti.com> > >>>> Date: Tue Feb 19 08:46:33 2019 -0800 > >>>> > >>>> ARM: dts: am335x-evm: Fix PHY mode for ethernet > >>>> > >>>> The PHY must add both tx and rx delay and not only on the tx clock. > >>>> The board uses AR8031_AL1A PHY where the rx delay is enabled by default, > >>>> the tx dealy is disabled. > >>>> > >>>> The reason why rgmii-txid worked because the rx delay was not disabled by > >>>> the driver so essentially we ended up with rgmii-id PHY mode. > >>>> > >>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > >>>> Signed-off-by: Tony Lindgren <tony@atomide.com> > >>>> > >>>> And this is of the style "the DTS was wrong before so we can break it". > >>>> This is the specific example (as the board is in my lab) that comes most > >>>> clearly to mind but there have been similar examples in 2022/2023. I agree that these sorts of changes should be done in a DT ABI compatible manner to U-Boot or atleast proactively adapt U-Boot to those changes. But I am not sure how we can improve here without a regular DT sync cadence with upstream and a Linux kernel maintainer profile to say that DT ABI towards U-Boot has to be kept in mind. The existing ad hoc syncs won't be motivating Linux DT maintainers to care about U-Boot regressions. > >>>> > >>>> The other just as painful examples I think may be where Marek is > >>>> concerned and it's around nodes being renamed for correctness. We've had > >>>> a number of cases where a - turned to _ (or vice versa?) and whoops, > >>>> platform stops booting. Down the line, tooling would catch that, and > >>>> it's a problem of not being able to use better tooling until we have the > >>>> updates that might break the boards that need the better tooling. AFAIU from this [1], the DT node names aren't part of the ABI. Given that we should start motivating people to move away from relying on node names, for eg. using uclass_get_device_by_seq() instead of uclass_get_device_by_name(). [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-ofw > >>>> > >>>> And really this gets to the crux of the problem, how much testing do we > >>>> insist happens prior to a re-sync being merged? I am not sure why custodians/maintainers depend on the global re-sync to be merged for testing purposes. They can very well have their local vendor directories synced-up and proactively look for any regressions. > >>>> Do we want to go with > >>>> the whole of the dts files are re-synced, or do we leave it per vendor? Leaving it per vendor would be somewhat similar to existing ad hoc syncs. BTW, what about bindings directory? We won't be able to enforce binding checks given the different state of per vendor DTS directory. > >>> > >>> I'd much prefer to leave it per vendor, with the recommendation to use > >>> synced DTs. Eventually things will stabilize and vendors will start > >>> switching over. > >> > >> To be clear, every SoC (or really, board) has to opt-in to OF_UPSTREAM > >> to start with. With that, I see switching to OF_UPSTREAM meaning that > >> there's a commitment to keeping up with dts change in upstream dts that > >> might lead to issues within U-Boot. Do you still feel it would be better > >> to have the re-sync _also_ be per custodian tree? That might be a bit > >> harder to handle. > > > > Maybe the best thing we can do is just give it a try and see how it works out, > > esp. since it is opt-in per board . Yeah given that we are conservative about re-syncs with a full U-Boot release cycle to detect and fix regressions. > > > > It would still be good to solve the part about pulling in fixes from > > linux-stable though . So I did a demo experiment for this here [1] where cherry picking DT fixes into subtree just worked fine with the next uprev. Steps followed: $ cd <U-Boot tree>/ $ git remote add dt-rebasing https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git $ git fetch dt-rebasing master $ git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/ 9de355a75fdeffc26486508107bf644ca2749fdb $ ./dts/update-dts-subtree.sh v6.8-rc2-dts If you would like it to be documented then I can do that for the next rev. [1] https://github.com/b49020/u-boot/commits/v4_dt_demo_fixes/ > > I would let board owners/custodians to deal with their boards. > There is very high chance that if you do it globally that it is question of time > when something will break. > It make sense to talk about how to do that transition and describe that steps > and having tools/script to help with. Given my comments above, I think we should at least give U-Boot owners/custodians a chance to opt for this and see how it pans out. It will give a better opportunity for the U-Boot community to engage and be a part of the current DT contribution model. -Sumit > > Thanks, > Michal
On Wed, Jan 31, 2024 at 06:26:54PM +0530, Sumit Garg wrote: [snip] > So I did a demo experiment for this here [1] where cherry picking DT > fixes into subtree just worked fine with the next uprev. Steps > followed: > > $ cd <U-Boot tree>/ > $ git remote add dt-rebasing > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > $ git fetch dt-rebasing master > $ git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/ > 9de355a75fdeffc26486508107bf644ca2749fdb > $ ./dts/update-dts-subtree.sh v6.8-rc2-dts > > If you would like it to be documented then I can do that for the next rev. Yes please.
Changes in v4: -------------- - Switched subtree to be imported as dts/upstream sub-directory rather than devicetree-rebasing sub-directory to better suite U-Boot directory structure. - Since we now have v6.7-dts tag available now, so switch subtree to that from its beginning. - Patch #2: Incorporate build fix to adjust Bindings Makefile rules to old U-Boot Kbuild infrastructure. - Patch #3: Incorporate fix to resolve rk3399 migration issue reported by Simon. - Patch #4: New patch to reuse upstream DT includes by U-Boot as per Brian's use-case for TI K3 SoCs. - Patch #5: Added a note to OF_UPSTREAM Kconfig option. - Patch #6: New patch to add script dts/update-dts-subtree.sh as per Rob's comments. - Patch #7: Separate patch to align documentation to use Kconfig symbols instead. - Patch #8: Clarify subtree uprev schedule as a separate documentation section. Also, fixed documentation typos. - Patch #9: Added commit description. Changes in v3: -------------- - Patch #4: Minor commit message update - Patch #5: Replace CONFIG_* with Kconfig options - Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. - Patch #1, #3, #6 and #8: Picked up review tags Changes in v2: -------------- - Patch #1: excluded gitab CI config check and added commit description. - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/ - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ - Patch #5: s/U-boot/U-Boot/ - Patch #6 and #7: Picked up review tags Prerequisite ------------ This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-Boot repo via: $ git subtree add --prefix dts/upstream \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.7-dts --squash Background ---------- This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-Boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained. However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel. In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `dts/upstream` sub-directory. U-Boot will regularly sync `dts/upstream/` subtree whenever the next window opens with the next available kernel major release. `dts/update-dts-subtree.sh` script provides a wrapper around git subtree pull command, usage from the top level U-Boot source tree, run: $ ./dts/update-dts-subtree.sh <devicetree-rebasing-release-tag> The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback. [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ [4] https://github.com/u-boot/u-boot/pull/451 Changes ------- Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts` which can be selected via setting "<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. SoC/board maintainers are encouraged to migrate to use synced copies from `dts/upstream/src/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` for the SoC being used via Kconfig and set up "<vendor>/<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #10 and #11. Devicetree bindings schema checks --------------------------------- With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `dts/upstream/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree. Dependencies ------------ The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip: $ pip3 install dtschema Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems: $ apt install swig python3-dev Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). Recommended is also to install yamllint (used by dtschema when present). $ apt install yamllint Running checks -------------- In order to perform validation of DTB files, use the ``dtbs_check`` target: $ make dtbs_check It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'. $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml Sumit Garg (11): CI: Exclude devicetree-rebasing subtree for CONFIG checks Makefile: Add support for DT bindings schema checks scripts/Makefile.lib: Statically define *-u-boot.dtsi files location Makefile: Allow upstream DT subtree to provide DT includes dts: Add alternative location for upstream DTB builds dts: Add script to uprev dts/upstream subtree doc: devicetree: Align documentation to use Kconfig options doc: devicetree: Updates for devicetree-rebasing subtree MAINTAINERS: Add myself as devicetree-rebasing maintainer dts: meson-gxbb: Switch to using upstream DT dts: meson-gxbb: Drop redundant devicetree files .azure-pipelines.yml | 3 +- .gitlab-ci.yml | 3 +- MAINTAINERS | 5 + Makefile | 23 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 426 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 414 ----------- arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 870 ------------------------ arch/arm/mach-meson/Kconfig | 1 + configs/nanopi-k2_defconfig | 2 +- configs/odroid-c2_defconfig | 2 +- configs/p200_defconfig | 2 +- configs/p201_defconfig | 2 +- configs/videostrong-kii-pro_defconfig | 2 +- configs/wetek-hub_defconfig | 2 +- configs/wetek-play2_defconfig | 2 +- doc/develop/devicetree/control.rst | 158 +++-- dts/Kconfig | 16 + dts/Makefile | 17 +- dts/update-dts-subtree.sh | 24 + dts/upstream/Bindings/Makefile | 6 +- dts/upstream/src/arm64/Makefile | 14 + scripts/Makefile.lib | 49 +- 30 files changed, 256 insertions(+), 2780 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100755 dts/update-dts-subtree.sh create mode 100644 dts/upstream/src/arm64/Makefile