[PATCH 00/21] Qualcomm generic board support

[Rob Herring]

On Mon, Dec 11, 2023 at 11:47 PM Sumit Garg <sumit.garg at linaro.org> wrote:
>
> Hi Tom,
>
> On Sun, 10 Dec 2023 at 03:33, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
> >
> > [snip]
> > > But currently u-boot doesn't have a proper way to validate those DTS
> > > against DT bindings (maintained in Linux kernel). Although there are
> > > Devicetree schema tools available here [2], there isn't a versioned
> > > release package of DT bindings which one should use to validate DTS
> > > files.
> >
> > I will have more / other things to say but I want to chime in here. That
> > U-Boot cannot validate the DTS files is a bug, not a feature. I would
> > very much appreciate if someone(s) with time and skills to do so would
> > re-sync us with the kernel Kbuild again so that we can both stay in sync
> > again and have the validation targets / functionality available here
> > too.
> >
>
> Agree, the Kbuild changes to add dtbs_check was the first thing I
> implemented after importing devicetree-rebasing repo in u-boot (see
> commit [1] for details). Usage with PR [2] included:
>
> While building any u-boot target, just add make target: "dtbs_check"
> and you will see the DT schema checks being performed. Steps:
>
> $ make <target>_defconfig
> $ make -j`nproc` dtbs_check
>
> Currently there are a lot of incompatibility warnings I have seen for
> the platforms I built. This shows how much difficult it has been to
> keep DT in sync with upstream DT bindings.

The versions in the Linux tree generally still have lots of warnings
too. It's a mountain of warnings. The warnings get amplified when
there are N boards for 1 SoC. Some platforms are more active than
others to get rid of them. Newer platforms like Apple are warning free
(or nearly so). If you want an overview of the state of platforms, I
have a CI job[1] doing just that. Look at platform-warnings.log in the
artifacts. It does some deduplicating of the warnings. Linux-next and
Linus' master are built daily.

Fixing the warnings alone will not solve potential incompatibility
issues. The schemas can and do change (and in turn the dts files). We
try to catch that in review, but the rule is that the platform must be
okay with the ABI change (recent mistake, early stages, limited users,
etc.) and the commit message must spell out 'this is an ABI change'.
That's all manual and not easily identifiable. I'm working on a
tool[2] to compare versions of the schema to identify some ABI
changes.  Though it is limited by thinking of what schema changes are
ABI changes and my ability to write python code to parse those cases.
Right now it looks for new required properties, removed properties,
and changed number of entries. I'm interested in any ideas for other
checks.

Rob

[1] https://gitlab.com/robherring/linux-dt/-/jobs
[2] https://github.com/robherring/dt-schema/tree/abi-check