[PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

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
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