[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL_nwRn-8L5bdcQ=0_HEiSRqF7yfonrq1GsYdcvtykRyQ@mail.gmail.com>
Date: Mon, 15 May 2017 11:40:09 -0500
From: Rob Herring <robh+dt@...nel.org>
To: Olof Johansson <olof@...om.net>
Cc: Russell King - ARM Linux <linux@...linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Heiko Stuebner <heiko@...ech.de>,
Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Mikael Starvik <starvik@...s.com>,
Jesper Nilsson <jesper.nilsson@...s.com>,
James Hogan <james.hogan@...tec.com>,
Ralf Baechle <ralf@...ux-mips.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>,
Frank Rowand <frowand.list@...il.com>,
linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] devicetree: Move include prefixes from arch to separate directory
On Mon, May 15, 2017 at 11:09 AM, Olof Johansson <olof@...om.net> wrote:
> On Mon, May 15, 2017 at 8:52 AM, Rob Herring <robh+dt@...nel.org> wrote:
>> On Mon, May 15, 2017 at 10:27 AM, Olof Johansson <olof@...om.net> wrote:
>>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring <robh+dt@...nel.org> wrote:
>>>> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>>> <linux@...linux.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@...nel.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
Powered by blists - more mailing lists