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

[Geert Uytterhoeven]

Hi Olof,

On Mon, May 15, 2017 at 6:09 PM, Olof Johansson  wrote:
>> 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?

I'm mostly using overlays to describe custom test hardware that
is connection to expansion connectors on standard development boards.
These fall into one of two classes:
  1. Overlays enabling an on-SoC device and configuring access to it from
 an expansion connector,
  2. Overlays describing hardware connected to a device from class1.

Class 1 overlays are SoC and board-specific, so they belong in e.g.
arch/arm/boot/dts/.
Class 2 overlays are more universal (depending on what they extend; Pantelis'
connectors work may help here), so they can be shared between architectures.

Other people may have other use cases.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Geert Uytterhoeven]

Hi Olof,

On Mon, May 15, 2017 at 6:09 PM, Olof Johansson  wrote:
>> 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?

I'm mostly using overlays to describe custom test hardware that
is connection to expansion connectors on standard development boards.
These fall into one of two classes:
  1. Overlays enabling an on-SoC device and configuring access to it from
 an expansion connector,
  2. Overlays describing hardware connected to a device from class1.

Class 1 overlays are SoC and board-specific, so they belong in e.g.
arch/arm/boot/dts/.
Class 2 overlays are more universal (depending on what they extend; Pantelis'
connectors work may help here), so they can be shared between architectures.

Other people may have other use cases.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[Masahiro Yamada]

2017-05-16 2:04 GMT+09:00 Olof Johansson :
> On Mon, May 15, 2017 at 8:48 AM, Russell King - ARM Linux
>  wrote:
>> On Mon, May 15, 2017 at 08:27:54AM -0700, Olof Johansson wrote:
>>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>>> > On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>> >  wrote:
>>> >> Maybe what we should do is:
>>> >>
>>> >> mkdir include/dt
>>> >> git mv include/dt-bindings include/dt
>>> >> for arch in arch/*; do
>>> >>   dts=$arch/boot/dts
>>> >>   if [ -d $dts ]; then
>>> >>  a=include/dt/$(basename $arch)
>>> >>  ln -s $dts $a
>>> >>  git add $a
>>> >>   fi
>>> >> done
>>> >> ... fixup scripts/Makefile.lib ...
>>> >> git commit
>>> >
>>> > That would just break every existing include in dts files.
>>>
>>> It doesn't break dts includes if done together with a change in -I,
>>> but it might break includes from the driver side (or needs another -I
>>> there).
>>
>> Good point.
>>
>> We could leave include/dt-bindings where it is, and just do the rest of
>> it for the cross-arch includes.  Slightly less tidy but should have a
>> lower impact.
>
> I think you're proposing this?
> include/dt-bindings
> include/dt/$arch -> ../../arch/$arch/boot/dts/
>
> And then having -I$(srctree)include/dt as argument to dtc?
>
> That'd work but have the same drawback as I mentioned to Rob about
> having several -I statements at different levels of the include
> hierarchy, the same file could be reached through  and
> <$arch/>. Not a showstopper but since Rob seems to be OK with the link
> hierarchy living under scripts/dtc, I'd prefer to just stick to that.
>
> This is all pretty isolated, and if we want to move it somewhere else
> later for some reason, we should be able to do so without impacting
> DTS and drivers.
>




As I pointed out in
https://patchwork.kernel.org/patch/9726699/

/include/ "arm/foo.dtsi"
will make sense, so I'd like to to improve it some time later.


Anyway, this patch fixes the circular symlinks.

Reviewed-by: Masahiro Yamada 


-- 
Best Regards
Masahiro Yamada

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

[Masahiro Yamada]

2017-05-16 2:04 GMT+09:00 Olof Johansson :
> On Mon, May 15, 2017 at 8:48 AM, Russell King - ARM Linux
>  wrote:
>> On Mon, May 15, 2017 at 08:27:54AM -0700, Olof Johansson wrote:
>>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>>> > On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>> >  wrote:
>>> >> Maybe what we should do is:
>>> >>
>>> >> mkdir include/dt
>>> >> git mv include/dt-bindings include/dt
>>> >> for arch in arch/*; do
>>> >>   dts=$arch/boot/dts
>>> >>   if [ -d $dts ]; then
>>> >>  a=include/dt/$(basename $arch)
>>> >>  ln -s $dts $a
>>> >>  git add $a
>>> >>   fi
>>> >> done
>>> >> ... fixup scripts/Makefile.lib ...
>>> >> git commit
>>> >
>>> > That would just break every existing include in dts files.
>>>
>>> It doesn't break dts includes if done together with a change in -I,
>>> but it might break includes from the driver side (or needs another -I
>>> there).
>>
>> Good point.
>>
>> We could leave include/dt-bindings where it is, and just do the rest of
>> it for the cross-arch includes.  Slightly less tidy but should have a
>> lower impact.
>
> I think you're proposing this?
> include/dt-bindings
> include/dt/$arch -> ../../arch/$arch/boot/dts/
>
> And then having -I$(srctree)include/dt as argument to dtc?
>
> That'd work but have the same drawback as I mentioned to Rob about
> having several -I statements at different levels of the include
> hierarchy, the same file could be reached through  and
> <$arch/>. Not a showstopper but since Rob seems to be OK with the link
> hierarchy living under scripts/dtc, I'd prefer to just stick to that.
>
> This is all pretty isolated, and if we want to move it somewhere else
> later for some reason, we should be able to do so without impacting
> DTS and drivers.
>




As I pointed out in
https://patchwork.kernel.org/patch/9726699/

/include/ "arm/foo.dtsi"
will make sense, so I'd like to to improve it some time later.


Anyway, this patch fixes the circular symlinks.

Reviewed-by: Masahiro Yamada 


-- 
Best Regards
Masahiro Yamada

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

[Olof Johansson]

On Mon, May 15, 2017 at 8:48 AM, Russell King - ARM Linux
 wrote:
> On Mon, May 15, 2017 at 08:27:54AM -0700, Olof Johansson wrote:
>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>> > On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>> >  wrote:
>> >> Maybe what we should do is:
>> >>
>> >> mkdir include/dt
>> >> git mv include/dt-bindings include/dt
>> >> for arch in arch/*; do
>> >>   dts=$arch/boot/dts
>> >>   if [ -d $dts ]; then
>> >>  a=include/dt/$(basename $arch)
>> >>  ln -s $dts $a
>> >>  git add $a
>> >>   fi
>> >> done
>> >> ... fixup scripts/Makefile.lib ...
>> >> git commit
>> >
>> > That would just break every existing include in dts files.
>>
>> It doesn't break dts includes if done together with a change in -I,
>> but it might break includes from the driver side (or needs another -I
>> there).
>
> Good point.
>
> We could leave include/dt-bindings where it is, and just do the rest of
> it for the cross-arch includes.  Slightly less tidy but should have a
> lower impact.

I think you're proposing this?
include/dt-bindings
include/dt/$arch -> ../../arch/$arch/boot/dts/

And then having -I$(srctree)include/dt as argument to dtc?

That'd work but have the same drawback as I mentioned to Rob about
having several -I statements at different levels of the include
hierarchy, the same file could be reached through  and
<$arch/>. Not a showstopper but since Rob seems to be OK with the link
hierarchy living under scripts/dtc, I'd prefer to just stick to that.

This is all pretty isolated, and if we want to move it somewhere else
later for some reason, we should be able to do so without impacting
DTS and drivers.


-Olof

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

[Olof Johansson]

On Mon, May 15, 2017 at 8:48 AM, Russell King - ARM Linux
 wrote:
> On Mon, May 15, 2017 at 08:27:54AM -0700, Olof Johansson wrote:
>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>> > On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>> >  wrote:
>> >> Maybe what we should do is:
>> >>
>> >> mkdir include/dt
>> >> git mv include/dt-bindings include/dt
>> >> for arch in arch/*; do
>> >>   dts=$arch/boot/dts
>> >>   if [ -d $dts ]; then
>> >>  a=include/dt/$(basename $arch)
>> >>  ln -s $dts $a
>> >>  git add $a
>> >>   fi
>> >> done
>> >> ... fixup scripts/Makefile.lib ...
>> >> git commit
>> >
>> > That would just break every existing include in dts files.
>>
>> It doesn't break dts includes if done together with a change in -I,
>> but it might break includes from the driver side (or needs another -I
>> there).
>
> Good point.
>
> We could leave include/dt-bindings where it is, and just do the rest of
> it for the cross-arch includes.  Slightly less tidy but should have a
> lower impact.

I think you're proposing this?
include/dt-bindings
include/dt/$arch -> ../../arch/$arch/boot/dts/

And then having -I$(srctree)include/dt as argument to dtc?

That'd work but have the same drawback as I mentioned to Rob about
having several -I statements at different levels of the include
hierarchy, the same file could be reached through  and
<$arch/>. Not a showstopper but since Rob seems to be OK with the link
hierarchy living under scripts/dtc, I'd prefer to just stick to that.

This is all pretty isolated, and if we want to move it somewhere else
later for some reason, we should be able to do so without impacting
DTS and drivers.


-Olof

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

[Rob Herring]

On Mon, May 15, 2017 at 11:09 AM, Olof Johansson  wrote:
> On Mon, May 15, 2017 at 8:52 AM, Rob Herring  wrote:
>> On Mon, May 15, 2017 at 10:27 AM, Olof Johansson  wrote:
>>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
 On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
  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 

> 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

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

[Rob Herring]

On Mon, May 15, 2017 at 11:09 AM, Olof Johansson  wrote:
> On Mon, May 15, 2017 at 8:52 AM, Rob Herring  wrote:
>> On Mon, May 15, 2017 at 10:27 AM, Olof Johansson  wrote:
>>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
 On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
  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 

> 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

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

[Olof Johansson]

On Mon, May 15, 2017 at 8:52 AM, Rob Herring  wrote:
> On Mon, May 15, 2017 at 10:27 AM, Olof Johansson  wrote:
>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>>> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>>  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?

 I don't think that works.

 The include path used is "include", which means that we force people
 to use:

 #include 
>>>
>>> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
>>> the include path instead of scripts/dtc/include-prefix/. The only
>>> downside I can see is people could mistakenly do:
>>>
>>> #include 
>>
>> I considered that but thought it was a worse solution than the one I
>> ended up with. It's just confusing to have -I paths that enter an
>> include hierarchy at different levels like that.
>>
>> Just see what already happened with the mistake on rockchip, where
>> Heiko accidentally included  instead -- it'd
>> be nice to catch that when it happens through tools
>>

 in their DT files.  This means that we'd need to populate $topdir/include
 with per-architecture symlinks on top of the 26 or so directories already
 there, so that:

 #include 

 would work.  That's quite horrible, since $topdir/include is the main
 include path for C headers.

 I guess we could have symlinks inside include/dt-bindings, but that
 makes the includes:

 #include 

 but that's rather absurd because these _aren't_ dt-binding definitions.
>>>
>>> True, but the same can be said that "scripts/dtc" is not includes nor
>>> kernel build infrastructure.
>>>
 Maybe what we should do is:

 mkdir include/dt
 git mv include/dt-bindings include/dt
 for arch in arch/*; do
   dts=$arch/boot/dts
   if [ -d $dts ]; then
  a=include/dt/$(basename $arch)
  ln -s $dts $a
  git add $a
   fi
 done
 ... fixup scripts/Makefile.lib ...
 git commit
>>>
>>> That would just break every existing include in dts files.
>>
>> It doesn't break dts includes if done together with a change in -I,
>> but it might break includes from the driver side (or needs another -I
>> there).
>
> Ah yes, I should have paid attention to the mkdir.
>
>>> 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?

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?

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.


-Olof

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

[Olof Johansson]

On Mon, May 15, 2017 at 8:52 AM, Rob Herring  wrote:
> On Mon, May 15, 2017 at 10:27 AM, Olof Johansson  wrote:
>> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>>> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>>  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?

 I don't think that works.

 The include path used is "include", which means that we force people
 to use:

 #include 
>>>
>>> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
>>> the include path instead of scripts/dtc/include-prefix/. The only
>>> downside I can see is people could mistakenly do:
>>>
>>> #include 
>>
>> I considered that but thought it was a worse solution than the one I
>> ended up with. It's just confusing to have -I paths that enter an
>> include hierarchy at different levels like that.
>>
>> Just see what already happened with the mistake on rockchip, where
>> Heiko accidentally included  instead -- it'd
>> be nice to catch that when it happens through tools
>>

 in their DT files.  This means that we'd need to populate $topdir/include
 with per-architecture symlinks on top of the 26 or so directories already
 there, so that:

 #include 

 would work.  That's quite horrible, since $topdir/include is the main
 include path for C headers.

 I guess we could have symlinks inside include/dt-bindings, but that
 makes the includes:

 #include 

 but that's rather absurd because these _aren't_ dt-binding definitions.
>>>
>>> True, but the same can be said that "scripts/dtc" is not includes nor
>>> kernel build infrastructure.
>>>
 Maybe what we should do is:

 mkdir include/dt
 git mv include/dt-bindings include/dt
 for arch in arch/*; do
   dts=$arch/boot/dts
   if [ -d $dts ]; then
  a=include/dt/$(basename $arch)
  ln -s $dts $a
  git add $a
   fi
 done
 ... fixup scripts/Makefile.lib ...
 git commit
>>>
>>> That would just break every existing include in dts files.
>>
>> It doesn't break dts includes if done together with a change in -I,
>> but it might break includes from the driver side (or needs another -I
>> there).
>
> Ah yes, I should have paid attention to the mkdir.
>
>>> 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?

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?

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.


-Olof

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

[Rob Herring]

On Mon, May 15, 2017 at 10:27 AM, Olof Johansson  wrote:
> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>  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?
>>>
>>> I don't think that works.
>>>
>>> The include path used is "include", which means that we force people
>>> to use:
>>>
>>> #include 
>>
>> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
>> the include path instead of scripts/dtc/include-prefix/. The only
>> downside I can see is people could mistakenly do:
>>
>> #include 
>
> I considered that but thought it was a worse solution than the one I
> ended up with. It's just confusing to have -I paths that enter an
> include hierarchy at different levels like that.
>
> Just see what already happened with the mistake on rockchip, where
> Heiko accidentally included  instead -- it'd
> be nice to catch that when it happens through tools
>
>>>
>>> in their DT files.  This means that we'd need to populate $topdir/include
>>> with per-architecture symlinks on top of the 26 or so directories already
>>> there, so that:
>>>
>>> #include 
>>>
>>> would work.  That's quite horrible, since $topdir/include is the main
>>> include path for C headers.
>>>
>>> I guess we could have symlinks inside include/dt-bindings, but that
>>> makes the includes:
>>>
>>> #include 
>>>
>>> but that's rather absurd because these _aren't_ dt-binding definitions.
>>
>> True, but the same can be said that "scripts/dtc" is not includes nor
>> kernel build infrastructure.
>>
>>> Maybe what we should do is:
>>>
>>> mkdir include/dt
>>> git mv include/dt-bindings include/dt
>>> for arch in arch/*; do
>>>   dts=$arch/boot/dts
>>>   if [ -d $dts ]; then
>>>  a=include/dt/$(basename $arch)
>>>  ln -s $dts $a
>>>  git add $a
>>>   fi
>>> done
>>> ... fixup scripts/Makefile.lib ...
>>> git commit
>>
>> That would just break every existing include in dts files.
>
> It doesn't break dts includes if done together with a change in -I,
> but it might break includes from the driver side (or needs another -I
> there).

Ah yes, I should have paid attention to the mkdir.

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

When and by whom do you propose merging this?

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.

Rob

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

[Rob Herring]

On Mon, May 15, 2017 at 10:27 AM, Olof Johansson  wrote:
> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
>> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>>  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?
>>>
>>> I don't think that works.
>>>
>>> The include path used is "include", which means that we force people
>>> to use:
>>>
>>> #include 
>>
>> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
>> the include path instead of scripts/dtc/include-prefix/. The only
>> downside I can see is people could mistakenly do:
>>
>> #include 
>
> I considered that but thought it was a worse solution than the one I
> ended up with. It's just confusing to have -I paths that enter an
> include hierarchy at different levels like that.
>
> Just see what already happened with the mistake on rockchip, where
> Heiko accidentally included  instead -- it'd
> be nice to catch that when it happens through tools
>
>>>
>>> in their DT files.  This means that we'd need to populate $topdir/include
>>> with per-architecture symlinks on top of the 26 or so directories already
>>> there, so that:
>>>
>>> #include 
>>>
>>> would work.  That's quite horrible, since $topdir/include is the main
>>> include path for C headers.
>>>
>>> I guess we could have symlinks inside include/dt-bindings, but that
>>> makes the includes:
>>>
>>> #include 
>>>
>>> but that's rather absurd because these _aren't_ dt-binding definitions.
>>
>> True, but the same can be said that "scripts/dtc" is not includes nor
>> kernel build infrastructure.
>>
>>> Maybe what we should do is:
>>>
>>> mkdir include/dt
>>> git mv include/dt-bindings include/dt
>>> for arch in arch/*; do
>>>   dts=$arch/boot/dts
>>>   if [ -d $dts ]; then
>>>  a=include/dt/$(basename $arch)
>>>  ln -s $dts $a
>>>  git add $a
>>>   fi
>>> done
>>> ... fixup scripts/Makefile.lib ...
>>> git commit
>>
>> That would just break every existing include in dts files.
>
> It doesn't break dts includes if done together with a change in -I,
> but it might break includes from the driver side (or needs another -I
> there).

Ah yes, I should have paid attention to the mkdir.

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

When and by whom do you propose merging this?

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.

Rob

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

[Russell King - ARM Linux]

On Mon, May 15, 2017 at 08:27:54AM -0700, Olof Johansson wrote:
> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
> > On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
> >  wrote:
> >> Maybe what we should do is:
> >>
> >> mkdir include/dt
> >> git mv include/dt-bindings include/dt
> >> for arch in arch/*; do
> >>   dts=$arch/boot/dts
> >>   if [ -d $dts ]; then
> >>  a=include/dt/$(basename $arch)
> >>  ln -s $dts $a
> >>  git add $a
> >>   fi
> >> done
> >> ... fixup scripts/Makefile.lib ...
> >> git commit
> >
> > That would just break every existing include in dts files.
> 
> It doesn't break dts includes if done together with a change in -I,
> but it might break includes from the driver side (or needs another -I
> there).

Good point.

We could leave include/dt-bindings where it is, and just do the rest of
it for the cross-arch includes.  Slightly less tidy but should have a
lower impact.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Russell King - ARM Linux]

On Mon, May 15, 2017 at 08:27:54AM -0700, Olof Johansson wrote:
> On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
> > On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
> >  wrote:
> >> Maybe what we should do is:
> >>
> >> mkdir include/dt
> >> git mv include/dt-bindings include/dt
> >> for arch in arch/*; do
> >>   dts=$arch/boot/dts
> >>   if [ -d $dts ]; then
> >>  a=include/dt/$(basename $arch)
> >>  ln -s $dts $a
> >>  git add $a
> >>   fi
> >> done
> >> ... fixup scripts/Makefile.lib ...
> >> git commit
> >
> > That would just break every existing include in dts files.
> 
> It doesn't break dts includes if done together with a change in -I,
> but it might break includes from the driver side (or needs another -I
> there).

Good point.

We could leave include/dt-bindings where it is, and just do the rest of
it for the cross-arch includes.  Slightly less tidy but should have a
lower impact.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Olof Johansson]

On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>  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?
>>
>> I don't think that works.
>>
>> The include path used is "include", which means that we force people
>> to use:
>>
>> #include 
>
> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
> the include path instead of scripts/dtc/include-prefix/. The only
> downside I can see is people could mistakenly do:
>
> #include 

I considered that but thought it was a worse solution than the one I
ended up with. It's just confusing to have -I paths that enter an
include hierarchy at different levels like that.

Just see what already happened with the mistake on rockchip, where
Heiko accidentally included  instead -- it'd
be nice to catch that when it happens through tools

>>
>> in their DT files.  This means that we'd need to populate $topdir/include
>> with per-architecture symlinks on top of the 26 or so directories already
>> there, so that:
>>
>> #include 
>>
>> would work.  That's quite horrible, since $topdir/include is the main
>> include path for C headers.
>>
>> I guess we could have symlinks inside include/dt-bindings, but that
>> makes the includes:
>>
>> #include 
>>
>> but that's rather absurd because these _aren't_ dt-binding definitions.
>
> True, but the same can be said that "scripts/dtc" is not includes nor
> kernel build infrastructure.
>
>> Maybe what we should do is:
>>
>> mkdir include/dt
>> git mv include/dt-bindings include/dt
>> for arch in arch/*; do
>>   dts=$arch/boot/dts
>>   if [ -d $dts ]; then
>>  a=include/dt/$(basename $arch)
>>  ln -s $dts $a
>>  git add $a
>>   fi
>> done
>> ... fixup scripts/Makefile.lib ...
>> git commit
>
> That would just break every existing include in dts files.

It doesn't break dts includes if done together with a change in -I,
but it might break includes from the driver side (or needs another -I
there).

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

-Olof

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

[Olof Johansson]

On Mon, May 15, 2017 at 7:47 AM, Rob Herring  wrote:
> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>  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?
>>
>> I don't think that works.
>>
>> The include path used is "include", which means that we force people
>> to use:
>>
>> #include 
>
> No, I was thinking you'd add include/dt-bindings/include-prefix/ to
> the include path instead of scripts/dtc/include-prefix/. The only
> downside I can see is people could mistakenly do:
>
> #include 

I considered that but thought it was a worse solution than the one I
ended up with. It's just confusing to have -I paths that enter an
include hierarchy at different levels like that.

Just see what already happened with the mistake on rockchip, where
Heiko accidentally included  instead -- it'd
be nice to catch that when it happens through tools

>>
>> in their DT files.  This means that we'd need to populate $topdir/include
>> with per-architecture symlinks on top of the 26 or so directories already
>> there, so that:
>>
>> #include 
>>
>> would work.  That's quite horrible, since $topdir/include is the main
>> include path for C headers.
>>
>> I guess we could have symlinks inside include/dt-bindings, but that
>> makes the includes:
>>
>> #include 
>>
>> but that's rather absurd because these _aren't_ dt-binding definitions.
>
> True, but the same can be said that "scripts/dtc" is not includes nor
> kernel build infrastructure.
>
>> Maybe what we should do is:
>>
>> mkdir include/dt
>> git mv include/dt-bindings include/dt
>> for arch in arch/*; do
>>   dts=$arch/boot/dts
>>   if [ -d $dts ]; then
>>  a=include/dt/$(basename $arch)
>>  ln -s $dts $a
>>  git add $a
>>   fi
>> done
>> ... fixup scripts/Makefile.lib ...
>> git commit
>
> That would just break every existing include in dts files.

It doesn't break dts includes if done together with a change in -I,
but it might break includes from the driver side (or needs another -I
there).

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

-Olof

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

[Russell King - ARM Linux]

On Mon, May 15, 2017 at 09:47:40AM -0500, Rob Herring wrote:
> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>  wrote:
> > Maybe what we should do is:
> >
> > mkdir include/dt
> > git mv include/dt-bindings include/dt
> > for arch in arch/*; do
> >   dts=$arch/boot/dts
> >   if [ -d $dts ]; then
> >  a=include/dt/$(basename $arch)
> >  ln -s $dts $a
> >  git add $a
> >   fi
> > done
> > ... fixup scripts/Makefile.lib ...
> > git commit
> 
> That would just break every existing include in dts files.

Are you sure about that - the existing:

#include 

would still work.  Maybe you haven't parsed the shell code properly...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Russell King - ARM Linux]

On Mon, May 15, 2017 at 09:47:40AM -0500, Rob Herring wrote:
> On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
>  wrote:
> > Maybe what we should do is:
> >
> > mkdir include/dt
> > git mv include/dt-bindings include/dt
> > for arch in arch/*; do
> >   dts=$arch/boot/dts
> >   if [ -d $dts ]; then
> >  a=include/dt/$(basename $arch)
> >  ln -s $dts $a
> >  git add $a
> >   fi
> > done
> > ... fixup scripts/Makefile.lib ...
> > git commit
> 
> That would just break every existing include in dts files.

Are you sure about that - the existing:

#include 

would still work.  Maybe you haven't parsed the shell code properly...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Rob Herring]

On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
 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?
>
> I don't think that works.
>
> The include path used is "include", which means that we force people
> to use:
>
> #include 

No, I was thinking you'd add include/dt-bindings/include-prefix/ to
the include path instead of scripts/dtc/include-prefix/. The only
downside I can see is people could mistakenly do:

#include 

>
> in their DT files.  This means that we'd need to populate $topdir/include
> with per-architecture symlinks on top of the 26 or so directories already
> there, so that:
>
> #include 
>
> would work.  That's quite horrible, since $topdir/include is the main
> include path for C headers.
>
> I guess we could have symlinks inside include/dt-bindings, but that
> makes the includes:
>
> #include 
>
> but that's rather absurd because these _aren't_ dt-binding definitions.

True, but the same can be said that "scripts/dtc" is not includes nor
kernel build infrastructure.

> Maybe what we should do is:
>
> mkdir include/dt
> git mv include/dt-bindings include/dt
> for arch in arch/*; do
>   dts=$arch/boot/dts
>   if [ -d $dts ]; then
>  a=include/dt/$(basename $arch)
>  ln -s $dts $a
>  git add $a
>   fi
> done
> ... fixup scripts/Makefile.lib ...
> git commit

That would just break every existing include in dts files.

Another idea. Could kbuild create all the symlinks at build time instead?

Rob

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

[Rob Herring]

On Mon, May 15, 2017 at 9:26 AM, Russell King - ARM Linux
 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?
>
> I don't think that works.
>
> The include path used is "include", which means that we force people
> to use:
>
> #include 

No, I was thinking you'd add include/dt-bindings/include-prefix/ to
the include path instead of scripts/dtc/include-prefix/. The only
downside I can see is people could mistakenly do:

#include 

>
> in their DT files.  This means that we'd need to populate $topdir/include
> with per-architecture symlinks on top of the 26 or so directories already
> there, so that:
>
> #include 
>
> would work.  That's quite horrible, since $topdir/include is the main
> include path for C headers.
>
> I guess we could have symlinks inside include/dt-bindings, but that
> makes the includes:
>
> #include 
>
> but that's rather absurd because these _aren't_ dt-binding definitions.

True, but the same can be said that "scripts/dtc" is not includes nor
kernel build infrastructure.

> Maybe what we should do is:
>
> mkdir include/dt
> git mv include/dt-bindings include/dt
> for arch in arch/*; do
>   dts=$arch/boot/dts
>   if [ -d $dts ]; then
>  a=include/dt/$(basename $arch)
>  ln -s $dts $a
>  git add $a
>   fi
> done
> ... fixup scripts/Makefile.lib ...
> git commit

That would just break every existing include in dts files.

Another idea. Could kbuild create all the symlinks at build time instead?

Rob

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

[Russell King - ARM Linux]

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?

I don't think that works.

The include path used is "include", which means that we force people
to use:

#include 

in their DT files.  This means that we'd need to populate $topdir/include
with per-architecture symlinks on top of the 26 or so directories already
there, so that:

#include 

would work.  That's quite horrible, since $topdir/include is the main
include path for C headers.

I guess we could have symlinks inside include/dt-bindings, but that
makes the includes:

#include 

but that's rather absurd because these _aren't_ dt-binding definitions.

Maybe what we should do is:

mkdir include/dt
git mv include/dt-bindings include/dt
for arch in arch/*; do
  dts=$arch/boot/dts
  if [ -d $dts ]; then
 a=include/dt/$(basename $arch)
 ln -s $dts $a
 git add $a
  fi
done
... fixup scripts/Makefile.lib ...
git commit

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Russell King - ARM Linux]

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?

I don't think that works.

The include path used is "include", which means that we force people
to use:

#include 

in their DT files.  This means that we'd need to populate $topdir/include
with per-architecture symlinks on top of the 26 or so directories already
there, so that:

#include 

would work.  That's quite horrible, since $topdir/include is the main
include path for C headers.

I guess we could have symlinks inside include/dt-bindings, but that
makes the includes:

#include 

but that's rather absurd because these _aren't_ dt-binding definitions.

Maybe what we should do is:

mkdir include/dt
git mv include/dt-bindings include/dt
for arch in arch/*; do
  dts=$arch/boot/dts
  if [ -d $dts ]; then
 a=include/dt/$(basename $arch)
 ln -s $dts $a
 git add $a
  fi
done
... fixup scripts/Makefile.lib ...
git commit

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

[Rob Herring]

On Fri, May 12, 2017 at 10:34 PM, Olof Johansson  wrote:
> We use a directory under arch/$ARCH/boot/dts as an include path
> that has links outside of the subtree to find dt-bindings from under
> include/dt-bindings. That's been working well, but new DT architectures
> haven't been adding them by default.
>
> Recently there's been a desire to share some of the DT material between
> arm and arm64, which originally caused developers to create symlinks or
> relative includes between the subtrees. This isn't ideal -- it breaks
> if the DT files aren't stored in the exact same hierarchy as the kernel
> tree, and generally it's just icky.
>
> As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
> once, and allow DTS files to reference dtsi (and dts) files in other
> architectures that way.
>
> Original approach was to create these links under each architecture,
> but it lead to the problem of recursive symlinks.
>
> As a remedy, move the include link directories out of the architecture
> trees into a common location. At the same time, they can now share one
> directory and one dt-bindings/ link as well.
>
> Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
> Reported-by: Russell King 
> Reported-by: Omar Sandoval 
> Cc: Heiko Stuebner 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Mikael Starvik 
> Cc: Jesper Nilsson 
> Cc: James Hogan 
> Cc: Ralf Baechle 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Frank Rowand 
> Cc: linux-arch 
> Signed-off-by: Olof Johansson 
> ---
>  arch/arm/boot/dts/include/arm | 1 -
>  arch/arm/boot/dts/include/arm64   | 1 -
>  arch/arm/boot/dts/include/dt-bindings | 1 -
>  arch/arm64/boot/dts/include/arm   | 1 -
>  arch/arm64/boot/dts/include/arm64 | 1 -
>  arch/arm64/boot/dts/include/dt-bindings   | 1 -
>  arch/cris/boot/dts/include/dt-bindings| 1 -
>  arch/metag/boot/dts/include/dt-bindings   | 1 -
>  arch/mips/boot/dts/include/dt-bindings| 1 -
>  arch/powerpc/boot/dts/include/dt-bindings | 1 -
>  scripts/Makefile.lib  | 2 +-
>  scripts/dtc/include-prefixes/arc  | 1 +
>  scripts/dtc/include-prefixes/arm  | 1 +
>  scripts/dtc/include-prefixes/arm64| 1 +
>  scripts/dtc/include-prefixes/c6x  | 1 +
>  scripts/dtc/include-prefixes/cris | 1 +
>  scripts/dtc/include-prefixes/dt-bindings  | 1 +
>  scripts/dtc/include-prefixes/h8300| 1 +
>  scripts/dtc/include-prefixes/metag| 1 +
>  scripts/dtc/include-prefixes/microblaze   | 1 +
>  scripts/dtc/include-prefixes/mips | 1 +
>  scripts/dtc/include-prefixes/nios2| 1 +
>  scripts/dtc/include-prefixes/openrisc | 1 +
>  scripts/dtc/include-prefixes/powerpc  | 1 +
>  scripts/dtc/include-prefixes/sh   | 1 +
>  scripts/dtc/include-prefixes/xtensa   | 1 +

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?

Rob

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

[Rob Herring]

On Fri, May 12, 2017 at 10:34 PM, Olof Johansson  wrote:
> We use a directory under arch/$ARCH/boot/dts as an include path
> that has links outside of the subtree to find dt-bindings from under
> include/dt-bindings. That's been working well, but new DT architectures
> haven't been adding them by default.
>
> Recently there's been a desire to share some of the DT material between
> arm and arm64, which originally caused developers to create symlinks or
> relative includes between the subtrees. This isn't ideal -- it breaks
> if the DT files aren't stored in the exact same hierarchy as the kernel
> tree, and generally it's just icky.
>
> As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
> once, and allow DTS files to reference dtsi (and dts) files in other
> architectures that way.
>
> Original approach was to create these links under each architecture,
> but it lead to the problem of recursive symlinks.
>
> As a remedy, move the include link directories out of the architecture
> trees into a common location. At the same time, they can now share one
> directory and one dt-bindings/ link as well.
>
> Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
> Reported-by: Russell King 
> Reported-by: Omar Sandoval 
> Cc: Heiko Stuebner 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Mikael Starvik 
> Cc: Jesper Nilsson 
> Cc: James Hogan 
> Cc: Ralf Baechle 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Frank Rowand 
> Cc: linux-arch 
> Signed-off-by: Olof Johansson 
> ---
>  arch/arm/boot/dts/include/arm | 1 -
>  arch/arm/boot/dts/include/arm64   | 1 -
>  arch/arm/boot/dts/include/dt-bindings | 1 -
>  arch/arm64/boot/dts/include/arm   | 1 -
>  arch/arm64/boot/dts/include/arm64 | 1 -
>  arch/arm64/boot/dts/include/dt-bindings   | 1 -
>  arch/cris/boot/dts/include/dt-bindings| 1 -
>  arch/metag/boot/dts/include/dt-bindings   | 1 -
>  arch/mips/boot/dts/include/dt-bindings| 1 -
>  arch/powerpc/boot/dts/include/dt-bindings | 1 -
>  scripts/Makefile.lib  | 2 +-
>  scripts/dtc/include-prefixes/arc  | 1 +
>  scripts/dtc/include-prefixes/arm  | 1 +
>  scripts/dtc/include-prefixes/arm64| 1 +
>  scripts/dtc/include-prefixes/c6x  | 1 +
>  scripts/dtc/include-prefixes/cris | 1 +
>  scripts/dtc/include-prefixes/dt-bindings  | 1 +
>  scripts/dtc/include-prefixes/h8300| 1 +
>  scripts/dtc/include-prefixes/metag| 1 +
>  scripts/dtc/include-prefixes/microblaze   | 1 +
>  scripts/dtc/include-prefixes/mips | 1 +
>  scripts/dtc/include-prefixes/nios2| 1 +
>  scripts/dtc/include-prefixes/openrisc | 1 +
>  scripts/dtc/include-prefixes/powerpc  | 1 +
>  scripts/dtc/include-prefixes/sh   | 1 +
>  scripts/dtc/include-prefixes/xtensa   | 1 +

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?

Rob

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

[Heiko Stuebner]

Hi Olof,

Am Freitag, 12. Mai 2017, 20:34:31 CEST schrieb Olof Johansson:
> We use a directory under arch/$ARCH/boot/dts as an include path
> that has links outside of the subtree to find dt-bindings from under
> include/dt-bindings. That's been working well, but new DT architectures
> haven't been adding them by default.
> 
> Recently there's been a desire to share some of the DT material between
> arm and arm64, which originally caused developers to create symlinks or
> relative includes between the subtrees. This isn't ideal -- it breaks
> if the DT files aren't stored in the exact same hierarchy as the kernel
> tree, and generally it's just icky.
> 
> As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
> once, and allow DTS files to reference dtsi (and dts) files in other
> architectures that way.
> 
> Original approach was to create these links under each architecture,
> but it lead to the problem of recursive symlinks.
> 
> As a remedy, move the include link directories out of the architecture
> trees into a common location. At the same time, they can now share one
> directory and one dt-bindings/ link as well.
> 
> Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
> Reported-by: Russell King 
> Reported-by: Omar Sandoval 
> Cc: Heiko Stuebner 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Mikael Starvik 
> Cc: Jesper Nilsson 
> Cc: James Hogan 
> Cc: Ralf Baechle 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Frank Rowand 
> Cc: linux-arch 
> Signed-off-by: Olof Johansson 

change itself looks good to me and also works, so

Reviewed-by: Heiko Stuebner 
Tested-by: Heiko Stuebner 

But we also have an overlooked glitch in the new rk3399-gru devicetrees
that surfaces with this patch applied.

../arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts:47:57: fatal error: 
include/dt-bindings/input/linux-event-codes.h: File or directory not found
 #include 

so need the patch from Ian Campbell 
"arm64: dts: rockchip: Drop explicit "include/" prefix from #include" [0]
in front to not cause other build breakage.

So if applicable, both patches should go in together, with the gru patch
in front and I've added my Reviewed-by there if someone else is doing it.


Heiko

[0] https://www.spinics.net/lists/arm-kernel/msg580835.html

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

[Heiko Stuebner]

Hi Olof,

Am Freitag, 12. Mai 2017, 20:34:31 CEST schrieb Olof Johansson:
> We use a directory under arch/$ARCH/boot/dts as an include path
> that has links outside of the subtree to find dt-bindings from under
> include/dt-bindings. That's been working well, but new DT architectures
> haven't been adding them by default.
> 
> Recently there's been a desire to share some of the DT material between
> arm and arm64, which originally caused developers to create symlinks or
> relative includes between the subtrees. This isn't ideal -- it breaks
> if the DT files aren't stored in the exact same hierarchy as the kernel
> tree, and generally it's just icky.
> 
> As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
> once, and allow DTS files to reference dtsi (and dts) files in other
> architectures that way.
> 
> Original approach was to create these links under each architecture,
> but it lead to the problem of recursive symlinks.
> 
> As a remedy, move the include link directories out of the architecture
> trees into a common location. At the same time, they can now share one
> directory and one dt-bindings/ link as well.
> 
> Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
> Reported-by: Russell King 
> Reported-by: Omar Sandoval 
> Cc: Heiko Stuebner 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Mikael Starvik 
> Cc: Jesper Nilsson 
> Cc: James Hogan 
> Cc: Ralf Baechle 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Frank Rowand 
> Cc: linux-arch 
> Signed-off-by: Olof Johansson 

change itself looks good to me and also works, so

Reviewed-by: Heiko Stuebner 
Tested-by: Heiko Stuebner 

But we also have an overlooked glitch in the new rk3399-gru devicetrees
that surfaces with this patch applied.

../arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts:47:57: fatal error: 
include/dt-bindings/input/linux-event-codes.h: File or directory not found
 #include 

so need the patch from Ian Campbell 
"arm64: dts: rockchip: Drop explicit "include/" prefix from #include" [0]
in front to not cause other build breakage.

So if applicable, both patches should go in together, with the gru patch
in front and I've added my Reviewed-by there if someone else is doing it.


Heiko

[0] https://www.spinics.net/lists/arm-kernel/msg580835.html

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

[Olof Johansson]

We use a directory under arch/$ARCH/boot/dts as an include path
that has links outside of the subtree to find dt-bindings from under
include/dt-bindings. That's been working well, but new DT architectures
haven't been adding them by default.

Recently there's been a desire to share some of the DT material between
arm and arm64, which originally caused developers to create symlinks or
relative includes between the subtrees. This isn't ideal -- it breaks
if the DT files aren't stored in the exact same hierarchy as the kernel
tree, and generally it's just icky.

As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
once, and allow DTS files to reference dtsi (and dts) files in other
architectures that way.

Original approach was to create these links under each architecture,
but it lead to the problem of recursive symlinks.

As a remedy, move the include link directories out of the architecture
trees into a common location. At the same time, they can now share one
directory and one dt-bindings/ link as well.

Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
Reported-by: Russell King 
Reported-by: Omar Sandoval 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Frank Rowand 
Cc: linux-arch 
Signed-off-by: Olof Johansson 
---
 arch/arm/boot/dts/include/arm | 1 -
 arch/arm/boot/dts/include/arm64   | 1 -
 arch/arm/boot/dts/include/dt-bindings | 1 -
 arch/arm64/boot/dts/include/arm   | 1 -
 arch/arm64/boot/dts/include/arm64 | 1 -
 arch/arm64/boot/dts/include/dt-bindings   | 1 -
 arch/cris/boot/dts/include/dt-bindings| 1 -
 arch/metag/boot/dts/include/dt-bindings   | 1 -
 arch/mips/boot/dts/include/dt-bindings| 1 -
 arch/powerpc/boot/dts/include/dt-bindings | 1 -
 scripts/Makefile.lib  | 2 +-
 scripts/dtc/include-prefixes/arc  | 1 +
 scripts/dtc/include-prefixes/arm  | 1 +
 scripts/dtc/include-prefixes/arm64| 1 +
 scripts/dtc/include-prefixes/c6x  | 1 +
 scripts/dtc/include-prefixes/cris | 1 +
 scripts/dtc/include-prefixes/dt-bindings  | 1 +
 scripts/dtc/include-prefixes/h8300| 1 +
 scripts/dtc/include-prefixes/metag| 1 +
 scripts/dtc/include-prefixes/microblaze   | 1 +
 scripts/dtc/include-prefixes/mips | 1 +
 scripts/dtc/include-prefixes/nios2| 1 +
 scripts/dtc/include-prefixes/openrisc | 1 +
 scripts/dtc/include-prefixes/powerpc  | 1 +
 scripts/dtc/include-prefixes/sh   | 1 +
 scripts/dtc/include-prefixes/xtensa   | 1 +
 26 files changed, 16 insertions(+), 11 deletions(-)
 delete mode 12 arch/arm/boot/dts/include/arm
 delete mode 12 arch/arm/boot/dts/include/arm64
 delete mode 12 arch/arm/boot/dts/include/dt-bindings
 delete mode 12 arch/arm64/boot/dts/include/arm
 delete mode 12 arch/arm64/boot/dts/include/arm64
 delete mode 12 arch/arm64/boot/dts/include/dt-bindings
 delete mode 12 arch/cris/boot/dts/include/dt-bindings
 delete mode 12 arch/metag/boot/dts/include/dt-bindings
 delete mode 12 arch/mips/boot/dts/include/dt-bindings
 delete mode 12 arch/powerpc/boot/dts/include/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/arc
 create mode 12 scripts/dtc/include-prefixes/arm
 create mode 12 scripts/dtc/include-prefixes/arm64
 create mode 12 scripts/dtc/include-prefixes/c6x
 create mode 12 scripts/dtc/include-prefixes/cris
 create mode 12 scripts/dtc/include-prefixes/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/h8300
 create mode 12 scripts/dtc/include-prefixes/metag
 create mode 12 scripts/dtc/include-prefixes/microblaze
 create mode 12 scripts/dtc/include-prefixes/mips
 create mode 12 scripts/dtc/include-prefixes/nios2
 create mode 12 scripts/dtc/include-prefixes/openrisc
 create mode 12 scripts/dtc/include-prefixes/powerpc
 create mode 12 scripts/dtc/include-prefixes/sh
 create mode 12 scripts/dtc/include-prefixes/xtensa

diff --git a/arch/arm/boot/dts/include/arm b/arch/arm/boot/dts/include/arm
deleted file mode 12
index a96aa0e..000
--- a/arch/arm/boot/dts/include/arm
+++ /dev/null
@@ -1 +0,0 @@
-..
\ No newline at end of file
diff --git a/arch/arm/boot/dts/include/arm64 b/arch/arm/boot/dts/include/arm64
deleted file mode 12
index 074a835..000
--- a/arch/arm/boot/dts/include/arm64
+++ 

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

[Olof Johansson]

We use a directory under arch/$ARCH/boot/dts as an include path
that has links outside of the subtree to find dt-bindings from under
include/dt-bindings. That's been working well, but new DT architectures
haven't been adding them by default.

Recently there's been a desire to share some of the DT material between
arm and arm64, which originally caused developers to create symlinks or
relative includes between the subtrees. This isn't ideal -- it breaks
if the DT files aren't stored in the exact same hierarchy as the kernel
tree, and generally it's just icky.

As a somewhat cleaner solution we decided to add a $ARCH/ prefix link
once, and allow DTS files to reference dtsi (and dts) files in other
architectures that way.

Original approach was to create these links under each architecture,
but it lead to the problem of recursive symlinks.

As a remedy, move the include link directories out of the architecture
trees into a common location. At the same time, they can now share one
directory and one dt-bindings/ link as well.

Fixes: 4027494ae6e3 ('ARM: dts: add arm/arm64 include symlinks')
Reported-by: Russell King 
Reported-by: Omar Sandoval 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Frank Rowand 
Cc: linux-arch 
Signed-off-by: Olof Johansson 
---
 arch/arm/boot/dts/include/arm | 1 -
 arch/arm/boot/dts/include/arm64   | 1 -
 arch/arm/boot/dts/include/dt-bindings | 1 -
 arch/arm64/boot/dts/include/arm   | 1 -
 arch/arm64/boot/dts/include/arm64 | 1 -
 arch/arm64/boot/dts/include/dt-bindings   | 1 -
 arch/cris/boot/dts/include/dt-bindings| 1 -
 arch/metag/boot/dts/include/dt-bindings   | 1 -
 arch/mips/boot/dts/include/dt-bindings| 1 -
 arch/powerpc/boot/dts/include/dt-bindings | 1 -
 scripts/Makefile.lib  | 2 +-
 scripts/dtc/include-prefixes/arc  | 1 +
 scripts/dtc/include-prefixes/arm  | 1 +
 scripts/dtc/include-prefixes/arm64| 1 +
 scripts/dtc/include-prefixes/c6x  | 1 +
 scripts/dtc/include-prefixes/cris | 1 +
 scripts/dtc/include-prefixes/dt-bindings  | 1 +
 scripts/dtc/include-prefixes/h8300| 1 +
 scripts/dtc/include-prefixes/metag| 1 +
 scripts/dtc/include-prefixes/microblaze   | 1 +
 scripts/dtc/include-prefixes/mips | 1 +
 scripts/dtc/include-prefixes/nios2| 1 +
 scripts/dtc/include-prefixes/openrisc | 1 +
 scripts/dtc/include-prefixes/powerpc  | 1 +
 scripts/dtc/include-prefixes/sh   | 1 +
 scripts/dtc/include-prefixes/xtensa   | 1 +
 26 files changed, 16 insertions(+), 11 deletions(-)
 delete mode 12 arch/arm/boot/dts/include/arm
 delete mode 12 arch/arm/boot/dts/include/arm64
 delete mode 12 arch/arm/boot/dts/include/dt-bindings
 delete mode 12 arch/arm64/boot/dts/include/arm
 delete mode 12 arch/arm64/boot/dts/include/arm64
 delete mode 12 arch/arm64/boot/dts/include/dt-bindings
 delete mode 12 arch/cris/boot/dts/include/dt-bindings
 delete mode 12 arch/metag/boot/dts/include/dt-bindings
 delete mode 12 arch/mips/boot/dts/include/dt-bindings
 delete mode 12 arch/powerpc/boot/dts/include/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/arc
 create mode 12 scripts/dtc/include-prefixes/arm
 create mode 12 scripts/dtc/include-prefixes/arm64
 create mode 12 scripts/dtc/include-prefixes/c6x
 create mode 12 scripts/dtc/include-prefixes/cris
 create mode 12 scripts/dtc/include-prefixes/dt-bindings
 create mode 12 scripts/dtc/include-prefixes/h8300
 create mode 12 scripts/dtc/include-prefixes/metag
 create mode 12 scripts/dtc/include-prefixes/microblaze
 create mode 12 scripts/dtc/include-prefixes/mips
 create mode 12 scripts/dtc/include-prefixes/nios2
 create mode 12 scripts/dtc/include-prefixes/openrisc
 create mode 12 scripts/dtc/include-prefixes/powerpc
 create mode 12 scripts/dtc/include-prefixes/sh
 create mode 12 scripts/dtc/include-prefixes/xtensa

diff --git a/arch/arm/boot/dts/include/arm b/arch/arm/boot/dts/include/arm
deleted file mode 12
index a96aa0e..000
--- a/arch/arm/boot/dts/include/arm
+++ /dev/null
@@ -1 +0,0 @@
-..
\ No newline at end of file
diff --git a/arch/arm/boot/dts/include/arm64 b/arch/arm/boot/dts/include/arm64
deleted file mode 12
index 074a835..000
--- a/arch/arm/boot/dts/include/arm64
+++ /dev/null
@@ -1 +0,0 @@
-../../../../arm64/boot/dts
\ No newline at end of file
diff --git a/arch/arm/boot/dts/include/dt-bindings 
b/arch/arm/boot/dts/include/dt-bindings
deleted file mode 12
index 08c00e4..000
--- a/arch/arm/boot/dts/include/dt-bindings
+++ /dev/null
@@ -1 +0,0 @@
-../../../../../include/dt-bindings
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/include/arm