[PATCH 00/21] Qualcomm generic board support

Sumit Garg sumit.garg at linaro.org
Wed Dec 6 06:05:02 CET 2023

On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski
<krzysztof.kozlowski at 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.kozlowski at 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

linux$ git grep -nr bootph-* arch/arm* | wc -l

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


More information about the U-Boot-Custodians mailing list