[PATCH 00/21] Qualcomm generic board support

[ff]

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

> How many years will that take?

Should all platforms following that organization be a goal? 

> 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
> _______________________________________________
> boot-architecture mailing list -- boot-architecture at lists.linaro.org
> To unsubscribe send an email to boot-architecture-leave at lists.linaro.org