[PATCH 00/21] Qualcomm generic board support

[Rob Herring]

On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg at linaro.org> wrote:
>
> 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

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?
How many years will that take? 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