On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: > On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: > > > Hi, > > > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > > Prerquisite > > > > > > s/Prerquisite/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 devicetree-rebasing \ > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > \ > > > > v6.6-dts --squash > > > > > > So I think the big question is: when should the subtree be updated ? > > > > > > Because as we discussed in the previous GH pull request, if a bindings > > > changes > > > was made in the upstream Linux DT, then the subtree update should wait > > > until > > > the u-boot support is merged before updating. This could cause a lot of > > > frustration. > > > > > > And this could cause a lot of regressions, even more if both Linux and > > > U-boot are > > > not maintained by the same people. > > > > I think some of the important questions to ask are, how often / likely > > are the breakages to occur? It seems like these days it's either: > > - U-Boot had an early version of the binding and we already state we > > don't support backwards compatibility here. It should be on the > > maintainer to be proactive in this case. > > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > incompatible DTS change now". This too is hopefully the kind of thing > > that at least board maintainers will be more actively aware of needing > > to deal with in U-Boot, if it's really a problem. > > A common issue in the kernel is with forward compatibility when > platforms add new resources from a new provider. Then the kernel > expects a driver for the provider and waits for the dependency. Of > course, older kernels don't have that provider driver and so the > dependency is never met. Not sure if u-boot will have similar issues? > At least you should/could know if the provider driver exists or not. > (The kernel doesn't because modules.)
I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really. -- Tom
signature.asc
Description: PGP signature
