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 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. > > > > > 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. 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. > > > DT bindings alone would ease the compliance process for u-boot drivers > > in quite similar manner to Linux drivers. > > > > [1] > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml > > > >> > >>> AFAIK, DT bindings should be forwards and backwards > >>> compatible. > >> > >> The same with DTS. > >> > >>> So if you pick up DTS or DTB from any project tree > >>> (upstream kernel or stable kernel or u-boot) then DT schema validation > >>> would ensure that corresponding DTS or DTB doesn't regress the DT > >>> bindings. > >> > >> And why is this argument to decouple DTS from bindings? > >> > > > > See above. > > It's not really explained there. You can pick up DTS from any project > and validate it against the repo Rob mentioned or against kernel. > Whether DTS is in that repo or not, does not matter for your validation. > It is similar to your earlier argument to use the whole mainline kernel repo. What is the real benefit to keep DT bindings and DTS together when every project has to maintain a copy of DTS in its own source tree? It will be just a source of confusion for developers: - One DTS coming from devicetree-rebasing repo - One DTS coming from local project -Sumit _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
