[PATCH 00/21] Qualcomm generic board support

[Rob Herring]

On Thu, Dec 7, 2023 at 2:08 AM ff <ff at shokubai.tech> wrote:
>
>
>
> > Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt at kernel.org> a écrit :
> >
> > 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?
>
> What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ?

I think there are 2 ATM. Synquacer and i.MX8 variants. Synquacer only
has a DT in u-boot, so not really anything to do there. I'm pretty
sure the certified DTBs for i.MX8 don't match what's in u-boot or the
kernel tree. Hopefully, it's just a subset, but still, there's a gap.
I don't know that there is motivation there either.

Note that SystemReady currently only requires every node with
'compatible' have a schema. It does not yet require no schema
warnings. If we went with a 1 by 1 approach, I would push that
platforms have to be free of warnings.

> > How many years will that take?
>
> Should all platforms following that organization be a goal?

You mean should all platforms be moved? Absolutely. I don't think we
want to solve the problem of having DTS files in 2 places by creating
a 3rd place.

I don't really think 1 by 1 is the right approach. I was just
enumerating how this could work. It's not that useful to say we need a
standalone repo without working thru the logistics of how exactly that
will work.

Rob