[PATCH] devicetree: Move include prefixes from arch to separate directory

[Rob Herring]

On Mon, May 15, 2017 at 11:09 AM, Olof Johansson <olof at lixom.net> wrote:
> On Mon, May 15, 2017 at 8:52 AM, Rob Herring <robh+dt at kernel.org> wrote:
>> On Mon, May 15, 2017 at 10:27 AM, Olof Johansson <olof at lixom.net> wrote:
>>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring <robh+dt at kernel.org> wrote:
>>>> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>>> <linux at armlinux.org.uk> wrote:
>>>>> On Mon, May 15, 2017 at 08:01:07AM -0500, Rob Herring wrote:
>>>>>> I'd prefer not to mix things in scripts/dtc that aren't the import of
>>>>>> dtc (yes, we do have a few other things already, but they are at least
>>>>>> scripts). Couldn't this go in include/dt-bindings/ instead?

[...]

>>>> Another idea. Could kbuild create all the symlinks at build time instead?
>>>
>>> I considered that, but given that we're talking about a few soft links
>>> that we need to find a good home for, it seemed like overkill that
>>> adds magic to the build process. Having somehting that is easily
>>> discovered when looking around the source tree is a lot better.
>>>
>>> I looked around the tree for suitable homes for this directory of
>>> links, and the least out-of-place I could find was under scripts/dtc.
>>> You even have a script for uprevving the imported dtc sources, so it's
>>> not like it's causing any problems from that point of view. But I do
>>> agree that it's not ideal -- it was just the least bad option I could
>>> find at the time. Better suggestions are welcome.
>>
>> Fair enough. Like I said, it was only a preference and certainly not
>> unprecedented. I'll just get less receptive with each addition. :)
>
> I'm familiar with that feeling. :)
>
>> When and by whom do you propose merging this?
>
> Given that it crosses architectures but fixes my mistaken recursive
> linking I was planning on either including it in arm-soc fixes or for
> full visibility just send it as a patch to Linus. Mind giving me an
> ack?

Given what it fixes, arm-soc probably makes the most sense.

Acked-by: Rob Herring <robh at kernel.org>

> Or, if you prefer to merge it that's fine with me too. I'd like to fix
> the tree for people who are seeing the problems soon though.
>
>> The only other comment I would have is at some point, we're going to
>> have overlays that aren't tied to any arch. Where are we going to put
>> those? Maybe they are tied to some vendor which tends to have most
>> stuff in $arch and we just continue this band-aid. Or we define some
>> common location. I bring this up now only because both could use that
>> location.
>
> Those are good questions. What kind of common overlays are you
> anticipating? Things like fragments describing connectors, etc?

Daughterboards on connectors is one. Another somewhat different case
is non-probeable buses hanging off of probeable devices where the host
system may not even be DT based. For example, GPIOs, I2C, UART, etc.
devices behind a USB serial chip and standard USB connector.

> Rule so far has been that the first arch to introduce something keeps
> it (that's between arm/arm64): Mostly it's been arm64 referencing arm
> contents so far.
>
> I guess we could introduce the concept of a common/ directory
> somewhere. As you say, finding a good home for it isn't 100% obvious
> today, and we should make sure ownership of the directory is clear
> since we've seen things go badly when patches get merged through too
> many paths on these files.

Agreed. I'm happy for you to own that. ;)

Rob