[PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

[Michael Nazzareno Trimarchi]

Hi Marek

On Wed, Jun 12, 2024 at 11:32 AM Marek Vasut <marek.vasut at mailbox.org> wrote:
>
> On 6/3/24 5:07 PM, Patrick Barsanti wrote:
> > Always prioritizing u-boot includes causes problems when trying to migrate
> > boards to OF_UPSTREAM that have different local devicetree files with
> > respect to the upstream ones, if local DT headers are not dropped.
> > At the same time if local and upstream files are the same, migrations
> > can be, and have been, introduced without dropping local DT headers.
> > This also causes problems whenever upstream DTS and DT headers are patched.
> >
> > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> > breaks it, as there are some missing defines in a local DT header file
> > (`imx6ul-clock.h`); the solution would be to drop it, which has not always
> > been done in previous OF_UPSTREAM migration patches for other boards
> > because most of the time the two are the same. This solution is also
> > vulnerable to ABI breakage, although this has not yet happened since the
> > introduction of OF_UPSTREAM support and is unlikely.
> >
> > Maintainers assure backwards compatibility for DT headers when syncing the
> > upstream folder with the kernel.
>
> ... upstream directory ...
>
> > The problem is that, at the current state, all boards that have not dropped
> > their local headers when migrating to OF_UPSTREAM will break once the
> > upstream devicetrees are patched, for example, to use any newly added
> > define which is not present in the local DT header file, even if those
> > changes are backwards compatible.
>
> Why not simply remove the headers ?
>

If we remove the headers then other boards that are not migrated, can
have some problem
on building. We should consider not only new boards but even those
that ones are still not migrated.
I think that is already described here

> Add a WARNING if there are local duplicates .
>

Why should a WARNING help here? We would like to have some migration
plans but not break them.

Michael


> [...]