On Sat, 16 Dec 2023 at 00:49, Tom Rini <tr...@konsulko.com> wrote: > > On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote: > > On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote: > > > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote: > > > > On 14/12/2023 20:48, Rob Herring wrote: > > > > >> > > > > >> 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.) > > > > > > > > If some U-Boot platform decides to aggressively sync with kernel DTS, > > > > then probably the kernel subarch maintainer should be aware of it. > > > > Mentioned forward compatibility issue is a result of assumption that > > > > there are no out-of-tree upstream consumers of our DTS. I am certainly > > > > not aware of any such consumer for Samsung. If someone told me (me > > > > wearing Samsung hat), hey U-Boot now cares, I would start caring as > > > > well. > > > > > > > > The usual argument of contributors wanting to break the backward and > > > > forward compatibility, is "there is no other OS depending on this" > > > > (recent discussion with Johan about order of interrupts: > > > > https://lore.kernel.org/all/zwcpzpx-et-xh...@hovoldconsulting.com/ ). > > > > You need to tell the maintainers of that platform, that now they have > > > > other OS/firmware/bootloader depending on DTS compatibility. > > > > > > I think this hints at one of the bigger impacts this might have. > > > Reminding everyone that other projects do use the device trees and have > > > for years. > > > > TBF, we do try to ask these questions as much as possible, usually (for > > me at least) citing U-Boot or the BSDs as users. It largely seems to me > > like we are all bark and no bite though, so a project like U-Boot having > > a defined "schedule" as you suggest below would add more meaning to our > > questioning. > > > > > Without rehashing history, BSD does use the trees as-is and > > > for platforms U-Boot supports they are supposed to be re-synced > > > periodically. > > > > I know this is the theory, but I also know that how well this is > > implemented varies wildly per-platform. I generally don't pay all > > that much attention to the various arm platforms, but I do pay > > attention to what's going on for RISC-V and there appear to be no > > active maintainers of individual platforms and the architecture > > maintainers are not aware of the status of the equivalent patches > > for Linux when they apply patches. > > > > In recent memory, this has lead to the clock indices in the DT > > differing between U-Boot and Linux for one such platform, which, IMO, > > is an insidious difference that is hard to spot during review and highly > > unlikely to crop up while comparing dts files, since the defines were named > > identically. To be clear, I am not expecting the architecture code > > maintainers to be aware of the minutiae of the various RISC-V platforms, > > but rather suggesting they might have an easier time reviewing if both > > projects' dts files and binding headers were tied together. > > > > That said, automatically synced devicetrees will, as has been pointed out, > > require the platform maintainers in Linux to be more aware of the affect of > > what they accept on other users, but it will also require the equivalent > > maintainers on the U-Boot side to engage too, so that the "upstream" dts > > files do not change in a way that screws the usecase in U-Boot. > > Yeah, it will hopefully lead to better coordination between maintainers > in some places. There are SoCs where the kernel DTS people are the > U-Boot DTS people too. All in all, I should probably CC more people than > I usually do on these resync patches just to try and head off any > tricky changes like you've mentioned above.
Makes sense. > > > Also, if people send fixes to the U-Boot copies of these devicetrees, > > would the plan be to request that these are sent to Linux and the fixes > > pulled in via a resync after each -rc release of Linux (or similar, just > > throwing some example schedule out there)? > > The way we've always tried to operate is that changes should be pushed > to Linux and resynced down, or at least submitted simultaneously. If > there's some specific bugfixes that need to come in out of cycle I > _think_ subtree handles cherry picked commits in a reasonable fashion. > Agree. -Sumit > -- > Tom