> Le 6 déc. 2023 à 21:42, Rob Herring <robh...@kernel.org> a écrit : > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.g...@linaro.org> wrote: >> >>> On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski >>> <krzysztof.kozlow...@linaro.org> wrote: >>> >>> On 05/12/2023 10:45, Sumit Garg wrote: >>>> + U-boot custodians list >>>> >>>> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski >>>> <krzysztof.kozlow...@linaro.org> wrote: >>>>> >>>>> On 05/12/2023 08:13, Sumit Garg wrote: >>>>>>>> @DT bindings maintainers, >>>>>>>> >>>>>>>> Given the ease of maintenance of DT bindings within Linux kernel >>>>>>>> source tree, I don't have a specific objection there. But can we ease >>>>>>>> DTS testing for firmware/bootloader projects by providing a versioned >>>>>>>> release package for DT bindings? Or if someone else has a better idea >>>>>>>> here please feel free to chime in. >>>>>>> >>>>>>> This doesn't work for you?: >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ >>>>>> >>>>>> Thanks, this is certainly a good step which I wasn't aware of. Further >>>>>> simplification can be done to decouple devicetree source files from DT >>>>>> bindings. >>>>> >>>>> Why? >>>> >>>> I suppose you are already aware that Linux DTS files are a subset of >>>> what could be supported by devicetree schemas. There can be >>>> firmware/bootloader specific properties (one example being [1]) which >>>> Linux kernel can simply ignore. Will you be willing to add all of >>>> those DT properties to Linux DTS files and maintain them? >>> >>> We already added them and we already maintain them. DTS describes the >>> hardware, not the OS-subset of the hardware. >> >> Let look at some numbers if your statement is justified or not for the >> example I gave: >> >> u-boot$ git grep -nr bootph-* arch/arm* | wc -l >> 4079 >> >> linux$ git grep -nr bootph-* arch/arm* | wc -l >> 267 > > I have no control over whether anyone has submitted the other 3812 instances. > >> It looks like there is always going to be a catch up game regarding DT >> properties which either Linux kernel or u-boot or any other >> firmware/bootloader project don't care about. > > As long as dts files in u-boot are manually sync'ed, yes. That is the > problem and it doesn't matter if we have a standalone repository or > not. > > If you want to move in that direction, start automating what u-boot > imports. You need to do that for bindings if you want to run > validation, so why not dts files too? > >>>> However, DT bindings are something which should be common, the >>>> hardware description of a device should be universal. IMO, splitting >>> >>> Both DT bindings and DTS should be common. I don't see the difference. >> >> If we really care about DTS to be common then the contribution model >> has to change where there is a single repo hosting DT bindings and >> DTS. All other projects whether it is Linux kernel or u-boot or any >> other OS/firmware/bootloader are just consuming DTS files from that >> single repo. > > Really, only the kernel and u-boot matter. No, I don't mean I don't > care about other projects, but those are the 2 with the widest h/w > support by far and which have a major effort to sync copies of dts > files in both projects. The rest are just noise in terms of this > problem. > >> I suppose this is something that Linux DT maintainers >> have objected to in the past for ease of maintenance. I am not sure if >> you folks are willing to change that stance. > > The issue is no one steps up to help maintain such a repository while > there is lots of review and maintainer work on what goes into the > kernel tree. I'm happy to direct my binding review attention to > wherever the majority of the bindings go. But the work on the DTS side > is mostly SoC tree maintainers and sub-maintainers. > > Assume for a minute we have this standalone repo. What happens next? > We start with an empty repo and then merge and move platforms 1 by 1?
What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? > How many years will that take? Should all platforms following that organization be a goal? > What do we do with platforms no one is > interested in moving? Or do we start with devicetree-rebasing instead > (That was the plan at one time) and sync u-boot back to that? > All the work needed to get u-boot and kernel dts files in sync has > virtually no dependency on a standalone repo. If the dts files aren't > already kept in sync, someone has to figure the differences and > eliminate them. Maybe some platforms are in good shape, but it is > still a manual process. Fix that part, because a standalone repo does > nothing for you until you do. > >>>> DT bindings alone would ease the compliance process for u-boot drivers >>>> in quite similar manner to Linux drivers. > > There's no compliance of drivers really beyond checking if compatible > strings used by drivers have a schema. > > Why is extracting the bindings out a problem? SystemReady has no issue > doing just that for its compliance test. > > Rob > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
