On Mon, May 15, 2017 at 11:09 AM, Olof Johansson [off-list ref] wrote:

On Mon, May 15, 2017 at 8:52 AM, Rob Herring [off-list ref] wrote:

quoted

On Mon, May 15, 2017 at 10:27 AM, Olof Johansson [off-list ref] wrote:

quoted

On Mon, May 15, 2017 at 7:47 AM, Rob Herring [off-list ref] wrote:

quoted

On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Mon, May 15, 2017 at 08:01:07AM -0500, Rob Herring wrote:

quoted

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?

[...]

quoted

quoted

quoted

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. :)

quoted

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@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.

quoted

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