Re: [PATCH] kernel.h: Skip single-eval logic on literals in min()/max()

[Ian Campbell]

On Thu, 2018-03-08 at 13:40 -0800, Kees Cook wrote:
> 
> +#define __min(t1, t2, x, y)  \
> + __builtin_choose_expr(__builtin_constant_p(x) &&\
> +   __builtin_constant_p(y) &&\
> +   __builtin_types_compatible_p(t1, t2), \
> +   (t1)(x) < (t2)(y) ? (t1)(x) : (t2)(y),\
> +   __single_eval_min(t1, t2, \
> + __UNIQUE_ID(max1_), \
> + __UNIQUE_ID(max2_), \

min1_ etc?

Ian.

Re: [PATCH] kernel.h: Skip single-eval logic on literals in min()/max()

[Ian Campbell]

On Thu, 2018-03-08 at 13:40 -0800, Kees Cook wrote:
> 
> +#define __min(t1, t2, x, y)  \
> + __builtin_choose_expr(__builtin_constant_p(x) &&\
> +   __builtin_constant_p(y) &&\
> +   __builtin_types_compatible_p(t1, t2), \
> +   (t1)(x) < (t2)(y) ? (t1)(x) : (t2)(y),\
> +   __single_eval_min(t1, t2, \
> + __UNIQUE_ID(max1_), \
> + __UNIQUE_ID(max2_), \

min1_ etc?

Ian.

Re: [kernel-hardening] Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

[Ian Campbell]

On Thu, 2017-11-30 at 15:39 +0100, Salvatore Mesoraca wrote:
> 2017-11-27 1:26 GMT+01:00 Solar Designer :
> > On Fri, Nov 24, 2017 at 12:43:47PM +0100, Salvatore Mesoraca wrote:
> > > 2017-11-24 11:53 GMT+01:00 David Laight 
> > > :
> > > > From: Alan Cox
> > > > > Sent: 22 November 2017 16:52
> > > > > 
> > > > > On Wed, 22 Nov 2017 09:01:46 +0100 Salvatore Mesoraca  > > > > rac...@gmail.com> wrote:
> > > > > 
> > > > > > Disallows O_CREAT open missing the O_EXCL flag, in world or
> > > > > > group writable directories, even if the file doesn't exist
> > > > > > yet.
> > > > > > With few exceptions (e.g. shared lock files based on
> > > > > > flock())
> > 
> > Why would "shared lock files based on flock()" need O_CREAT without
> > O_EXCL?  Where specifically are they currently used that way?
> 
> I don't think that they *need* to act like this, but this is how
> util-linux's flock(1) currently works.
> And it doesn't seem an unreasonable behavior from their perspective,

I thought that too, specifically I reasoned that using O_EXCL would
defeat the purpose of the _shared_ flock(), wouldn't it?

Ian.

Re: [kernel-hardening] Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

[Ian Campbell]

On Thu, 2017-11-30 at 15:39 +0100, Salvatore Mesoraca wrote:
> 2017-11-27 1:26 GMT+01:00 Solar Designer :
> > On Fri, Nov 24, 2017 at 12:43:47PM +0100, Salvatore Mesoraca wrote:
> > > 2017-11-24 11:53 GMT+01:00 David Laight 
> > > :
> > > > From: Alan Cox
> > > > > Sent: 22 November 2017 16:52
> > > > > 
> > > > > On Wed, 22 Nov 2017 09:01:46 +0100 Salvatore Mesoraca  > > > > rac...@gmail.com> wrote:
> > > > > 
> > > > > > Disallows O_CREAT open missing the O_EXCL flag, in world or
> > > > > > group writable directories, even if the file doesn't exist
> > > > > > yet.
> > > > > > With few exceptions (e.g. shared lock files based on
> > > > > > flock())
> > 
> > Why would "shared lock files based on flock()" need O_CREAT without
> > O_EXCL?  Where specifically are they currently used that way?
> 
> I don't think that they *need* to act like this, but this is how
> util-linux's flock(1) currently works.
> And it doesn't seem an unreasonable behavior from their perspective,

I thought that too, specifically I reasoned that using O_EXCL would
defeat the purpose of the _shared_ flock(), wouldn't it?

Ian.

Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

[Ian Campbell]

On Sun, 2017-10-01 at 11:06 +1100, Tobin C. Harding wrote:
> Suggestion by Ian Campbell to add comments on the threat model being mitigated
> by use of %pa vs %paP etc is not implemented because I do not know the threat
> model (I'm only the janitor). Happy to add them if someone writes them.

Thanks for the CC on this repost, but no need for it for V3 onwards.

Thanks,
Ian.

Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

[Ian Campbell]

On Sun, 2017-10-01 at 11:06 +1100, Tobin C. Harding wrote:
> Suggestion by Ian Campbell to add comments on the threat model being mitigated
> by use of %pa vs %paP etc is not implemented because I do not know the threat
> model (I'm only the janitor). Happy to add them if someone writes them.

Thanks for the CC on this repost, but no need for it for V3 onwards.

Thanks,
Ian.

Re: [PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

[Ian Campbell]

On Fri, 2017-07-21 at 15:54 +0300, Ivan Mikhaylov wrote:
> Hi Ian,
> > Building the split device-tree tree[0] highlighted that upstream commit
> > 9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced
> > this warning when building the device tree:
> > 
> > $ make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc fsp2.dtb
> >  CHK scripts/mod/devicetable-offsets.h
> >  DTC arch/powerpc/boot/fsp2.dtb
> > > > arch/powerpc/boot/fsp2.dtb: Warning (reg_format): "reg" property in 
> > > > /sdhci@020c has invalid length (8 bytes) (#address-cells == 2, 
> > > > #size-cells == 1)
> > 
> > This commit adds the second adress cell as zeroes to resolve the warning. 
> > Note:
> > I have no access to or information about this platform so this is purely a
> > guess as to the fix. An alternative would be to adjust #address-cells, but
> > whether that is correct or not depends on the platform.
> 
> Yes, this problem exists on this tag but it is already fixed and waiting for
> > review by this https://patchwork.kernel.org/patch/9819379/ . You can check 
> > it
> if you want, anyways it will go to powerpc next branch first.

Great, thanks for the info.

Re: [PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

[Ian Campbell]

On Fri, 2017-07-21 at 15:54 +0300, Ivan Mikhaylov wrote:
> Hi Ian,
> > Building the split device-tree tree[0] highlighted that upstream commit
> > 9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced
> > this warning when building the device tree:
> > 
> > $ make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc fsp2.dtb
> >  CHK scripts/mod/devicetable-offsets.h
> >  DTC arch/powerpc/boot/fsp2.dtb
> > > > arch/powerpc/boot/fsp2.dtb: Warning (reg_format): "reg" property in 
> > > > /sdhci@020c has invalid length (8 bytes) (#address-cells == 2, 
> > > > #size-cells == 1)
> > 
> > This commit adds the second adress cell as zeroes to resolve the warning. 
> > Note:
> > I have no access to or information about this platform so this is purely a
> > guess as to the fix. An alternative would be to adjust #address-cells, but
> > whether that is correct or not depends on the platform.
> 
> Yes, this problem exists on this tag but it is already fixed and waiting for
> > review by this https://patchwork.kernel.org/patch/9819379/ . You can check 
> > it
> if you want, anyways it will go to powerpc next branch first.

Great, thanks for the info.

[PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

[Ian Campbell]

Building the split device-tree tree[0] highlighted that upstream commit
9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced
this warning when building the device tree:

$ make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc fsp2.dtb
  CHK scripts/mod/devicetable-offsets.h
  DTC arch/powerpc/boot/fsp2.dtb
arch/powerpc/boot/fsp2.dtb: Warning (reg_format): "reg" property in 
/sdhci@020c has invalid length (8 bytes) (#address-cells == 2, #size-cells 
== 1)

This commit adds the second adress cell as zeroes to resolve the warning. Note:
I have no access to or information about this platform so this is purely a
guess as to the fix. An alternative would be to adjust #address-cells, but
whether that is correct or not depends on the platform.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Cc: Ivan Mikhaylov <i...@de.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: linuxppc-...@lists.ozlabs.org
Cc: Rob Herring <robh...@kernel.org>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/powerpc/boot/dts/fsp2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsp2.dts b/arch/powerpc/boot/dts/fsp2.dts
index 475953ada707..ab6d2346527f 100644
--- a/arch/powerpc/boot/dts/fsp2.dts
+++ b/arch/powerpc/boot/dts/fsp2.dts
@@ -362,7 +362,7 @@
mmc0: sdhci@020c {
compatible  = "st,sdhci-stih407", "st,sdhci";
status  = "disabled";
-   reg = <0x020c 0x2>;
+   reg = <0x 0x020c 0x2>;
reg-names   = "mmc";
interrupt-parent = <_3>;
interrupts  = <21 0x4 22 0x4>;
-- 
2.11.0

[PATCH] powerpc/44x/fsp2: correct dtb reg property for /sdhci@020c0000

[Ian Campbell]

Building the split device-tree tree[0] highlighted that upstream commit
9eec6cb142bd ("powerpc/44x/fsp2: Add device tree for FSP2 board") introduced
this warning when building the device tree:

$ make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc fsp2.dtb
  CHK scripts/mod/devicetable-offsets.h
  DTC arch/powerpc/boot/fsp2.dtb
arch/powerpc/boot/fsp2.dtb: Warning (reg_format): "reg" property in 
/sdhci@020c has invalid length (8 bytes) (#address-cells == 2, #size-cells 
== 1)

This commit adds the second adress cell as zeroes to resolve the warning. Note:
I have no access to or information about this platform so this is purely a
guess as to the fix. An alternative would be to adjust #address-cells, but
whether that is correct or not depends on the platform.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Ivan Mikhaylov 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-...@lists.ozlabs.org
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/powerpc/boot/dts/fsp2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsp2.dts b/arch/powerpc/boot/dts/fsp2.dts
index 475953ada707..ab6d2346527f 100644
--- a/arch/powerpc/boot/dts/fsp2.dts
+++ b/arch/powerpc/boot/dts/fsp2.dts
@@ -362,7 +362,7 @@
mmc0: sdhci@020c {
compatible  = "st,sdhci-stih407", "st,sdhci";
status  = "disabled";
-   reg = <0x020c 0x2>;
+   reg = <0x 0x020c 0x2>;
reg-names   = "mmc";
interrupt-parent = <_3>;
interrupts  = <21 0x4 22 0x4>;
-- 
2.11.0

Re: [PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

[Ian Campbell]

On Sat, 2017-05-13 at 17:43 +0200, Heiko Stuebner wrote:
> Hi Ian,
> 
> Am Samstag, 13. Mai 2017, 00:53:57 CEST schrieb Ian Campbell:
> > It not necessary and counter to how all the other files are done.
> > 
> > It also happens to break the build in the split device tree repo
> > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetr
> > ee-rebasing.git/
> > 
> > Signed-off-by: Ian Campbell <i...@hellion.org.uk>
> > Cc: Brian Norris <briannor...@chromium.org>
> > Cc: Heiko Stuebner <he...@sntech.de>
> > Cc: Rob Herring <robh...@kernel.org>
> > Cc: Mark Rutland <mark.rutl...@arm.com>
> > Cc: Catalin Marinas <catalin.mari...@arm.com>
> > Cc: Will Deacon <will.dea...@arm.com>
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-rockc...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> 
> that glitch also breaks Olof's patch [0] fixing a depmod symlink
> recursion in that it creates
> 
> ../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 
> 
> with only Olof's patch applied. So I guess both patches should go
> together with this one in front, so to be on the safe side, if some
> else
> is going to apply both:
> 
> Reviewed-by: Heiko Stuebner <he...@sntech.de>

Not sure who should/wil merge this, but it seems I neglected to Cc Arnd
and Olof so I'm doing so now.

Would be good to get this in soonish.

Ian

Re: [PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

[Ian Campbell]

On Sat, 2017-05-13 at 17:43 +0200, Heiko Stuebner wrote:
> Hi Ian,
> 
> Am Samstag, 13. Mai 2017, 00:53:57 CEST schrieb Ian Campbell:
> > It not necessary and counter to how all the other files are done.
> > 
> > It also happens to break the build in the split device tree repo
> > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetr
> > ee-rebasing.git/
> > 
> > Signed-off-by: Ian Campbell 
> > Cc: Brian Norris 
> > Cc: Heiko Stuebner 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-rockc...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> 
> that glitch also breaks Olof's patch [0] fixing a depmod symlink
> recursion in that it creates
> 
> ../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 
> 
> with only Olof's patch applied. So I guess both patches should go
> together with this one in front, so to be on the safe side, if some
> else
> is going to apply both:
> 
> Reviewed-by: Heiko Stuebner 

Not sure who should/wil merge this, but it seems I neglected to Cc Arnd
and Olof so I'm doing so now.

Would be good to get this in soonish.

Ian

[PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

[Ian Campbell]

It not necessary and counter to how all the other files are done.

It also happens to break the build in the split device tree repo
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Cc: Brian Norris <briannor...@chromium.org>
Cc: Heiko Stuebner <he...@sntech.de>
Cc: Rob Herring <robh...@kernel.org>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 658bb9dc9dfd..7bd31066399b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -44,7 +44,7 @@
 
 /dts-v1/;
 #include "rk3399-gru.dtsi"
-#include 
+#include 
 
 /*
  * Kevin-specific things
-- 
2.11.0

[PATCH] arm64: dts: rockchip: Drop explicit "include/" prefix from #include

[Ian Campbell]

It not necessary and counter to how all the other files are done.

It also happens to break the build in the split device tree repo
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Brian Norris 
Cc: Heiko Stuebner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 658bb9dc9dfd..7bd31066399b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -44,7 +44,7 @@
 
 /dts-v1/;
 #include "rk3399-gru.dtsi"
-#include 
+#include 
 
 /*
  * Kevin-specific things
-- 
2.11.0

Re: [kernel-hardening] [RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options

[Ian Campbell]

On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote:
> From: Dave Weinstein 
> 
> Add the kptr_restrict setting of 4 which results in %pa and
> %p[rR] values being replaced by zeros.

Given that '%pa' is:
 * - 'a[pd]' For address types [p] phys_addr_t, [d] dma_addr_t and derivatives
 *   (default assumed to be phys_addr_t, passed by reference)

what is the thread model which hiding physical addresses from attackers
protects against? I can see why virtual addresses would be obviously
dangerous but physical addresses seem less obvious and I didn't see it
spelled out in any of the commit messages or added comments in the
thread.

I think a comment somewhere would be useful for people who are trying
to decide if they should use %pa vs %paP etc.

Ian.

Re: [kernel-hardening] [RFC 3/6] lib: vsprintf: physical address kernel pointer filtering options

[Ian Campbell]

On Fri, 2017-05-05 at 21:07 -0700, Greg KH wrote:
> From: Dave Weinstein 
> 
> Add the kptr_restrict setting of 4 which results in %pa and
> %p[rR] values being replaced by zeros.

Given that '%pa' is:
 * - 'a[pd]' For address types [p] phys_addr_t, [d] dma_addr_t and derivatives
 *   (default assumed to be phys_addr_t, passed by reference)

what is the thread model which hiding physical addresses from attackers
protects against? I can see why virtual addresses would be obviously
dangerous but physical addresses seem less obvious and I didn't see it
spelled out in any of the commit messages or added comments in the
thread.

I think a comment somewhere would be useful for people who are trying
to decide if they should use %pa vs %paP etc.

Ian.

Re: [kernel-hardening] [PATCH v2 1/7] bug: Clarify help text for BUG_ON_DATA_CORRUPTION

[Ian Campbell]

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 77fadface4f9..5ac4d1148385 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1998,9 +1998,12 @@ config BUG_ON_DATA_CORRUPTION
> >     bool "Trigger a BUG when data corruption is detected"
> >     select DEBUG_LIST
> >     help
> > -     Select this option if the kernel should BUG when it encounters
> > -     data corruption in kernel memory structures when they get checked
> > -     for validity.
> > +     This option enables several inexpensive data corruption checks.
> > +     Most of these checks normally just WARN and try to further avoid
> +   the corruption. Selecting this option upgrades these to BUGs so

First it says it enables some checks, but here it says it upgrades them
to BUGs which seems inconsistent.

> +   that the offending process is killed. Additionally, the system
> +   owner can furhter configure the system for immediate reboots

   "further"

> +   (via panic_on_oops sysctl) or crash dumps.
>  
> >       If unsure, say N.
>  

Re: [kernel-hardening] [PATCH v2 1/7] bug: Clarify help text for BUG_ON_DATA_CORRUPTION

[Ian Campbell]

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 77fadface4f9..5ac4d1148385 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1998,9 +1998,12 @@ config BUG_ON_DATA_CORRUPTION
> >     bool "Trigger a BUG when data corruption is detected"
> >     select DEBUG_LIST
> >     help
> > -     Select this option if the kernel should BUG when it encounters
> > -     data corruption in kernel memory structures when they get checked
> > -     for validity.
> > +     This option enables several inexpensive data corruption checks.
> > +     Most of these checks normally just WARN and try to further avoid
> +   the corruption. Selecting this option upgrades these to BUGs so

First it says it enables some checks, but here it says it upgrades them
to BUGs which seems inconsistent.

> +   that the offending process is killed. Additionally, the system
> +   owner can furhter configure the system for immediate reboots

   "further"

> +   (via panic_on_oops sysctl) or crash dumps.
>  
> >       If unsure, say N.
>  

Re: [kernel-hardening] [RFC v2][PATCH 02/11] lkdtm: add test for rare_write() infrastructure

[Ian Campbell]

On Wed, 2017-03-29 at 11:15 -0700, Kees Cook wrote:
> diff --git a/drivers/misc/lkdtm_perms.c b/drivers/misc/lkdtm_perms.c
> index c7635a79341f..8fbadfa4cc34 100644
> --- a/drivers/misc/lkdtm_perms.c
> +++ b/drivers/misc/lkdtm_perms.c
> [...]
> +/* This is marked __wr_rare, so it should ultimately be .rodata. */
> +static unsigned long wr_rare __wr_rare = 0xAA66AA66;
> [...]
> +void lkdtm_WRITE_RARE_WRITE(void)
> +{
> + /* Explicitly cast away "const" for the test. */

wr_rare isn't actually declared const above though? I don't think
__wr_rare includes a const, apologies if I missed it.

OOI, if wr_rare _were_ const then can the compiler optimise the a pair
of reads spanning the rare_write? i.e. adding const to the declaration
above to get:

static const unsigned long wr_rare __wr_rare = 0xAA66AA66;
x = wr_read;
rare_write(x, 0xf000baaa);
y = wr_read;

Is it possible that x == y == 0xaa66aa66 because gcc realises the x and
y came from the same const location? Have I missed a clobber somewhere
(I can't actually find a definition of __arch_rare_write_memcpy in this
series so maybe it's there), or is such code expected to always cast
away the const first?

I suppose such constructs are rare in practice in the sorts of places
where rare_write is appropriate, but with aggressive inlining it could
occur as an unexpected trap for the unwary perhaps.

Ian.

Re: [kernel-hardening] [RFC v2][PATCH 02/11] lkdtm: add test for rare_write() infrastructure

[Ian Campbell]

On Wed, 2017-03-29 at 11:15 -0700, Kees Cook wrote:
> diff --git a/drivers/misc/lkdtm_perms.c b/drivers/misc/lkdtm_perms.c
> index c7635a79341f..8fbadfa4cc34 100644
> --- a/drivers/misc/lkdtm_perms.c
> +++ b/drivers/misc/lkdtm_perms.c
> [...]
> +/* This is marked __wr_rare, so it should ultimately be .rodata. */
> +static unsigned long wr_rare __wr_rare = 0xAA66AA66;
> [...]
> +void lkdtm_WRITE_RARE_WRITE(void)
> +{
> + /* Explicitly cast away "const" for the test. */

wr_rare isn't actually declared const above though? I don't think
__wr_rare includes a const, apologies if I missed it.

OOI, if wr_rare _were_ const then can the compiler optimise the a pair
of reads spanning the rare_write? i.e. adding const to the declaration
above to get:

static const unsigned long wr_rare __wr_rare = 0xAA66AA66;
x = wr_read;
rare_write(x, 0xf000baaa);
y = wr_read;

Is it possible that x == y == 0xaa66aa66 because gcc realises the x and
y came from the same const location? Have I missed a clobber somewhere
(I can't actually find a definition of __arch_rare_write_memcpy in this
series so maybe it's there), or is such code expected to always cast
away the const first?

I suppose such constructs are rare in practice in the sorts of places
where rare_write is appropriate, but with aggressive inlining it could
occur as an unexpected trap for the unwary perhaps.

Ian.

"sched/cpuacct: Show all possible CPUs in cpuacct output" broke Docker CPU usage accounting

[Ian Campbell]

Hello,

It seems that the changes to cpuacct.usage(_percpu) in 5ca3726af7f6
("sched/cpuacct: Show all possible CPUs in cpuacct output") have
broken CPU usage accounting in Docker
(https://github.com/docker/docker/issues/28941).

The issue is the code at
https://github.com/docker/docker/blob/master/cli/command/container/stats_helpers.go#L184
which multiplies by the length of the array on those files which has
gone from being the number of online cpus to the number of possible
cpus, hence inflating the numbers.

I'm not entirely sure what the answer is, mainly because I've not been
able to figure out what the units presented in the cpuacct files are
which would justify multiplying by any version of number of CPUs,
although it does appear to have been (AFAICT) producing the correct
numbers with the old code.

I'm more than happy to code up a fix on whichever side of the boundary
is appropriate given a hint in the correct direction to take...

Thanks,
Ian.

"sched/cpuacct: Show all possible CPUs in cpuacct output" broke Docker CPU usage accounting

[Ian Campbell]

Hello,

It seems that the changes to cpuacct.usage(_percpu) in 5ca3726af7f6
("sched/cpuacct: Show all possible CPUs in cpuacct output") have
broken CPU usage accounting in Docker
(https://github.com/docker/docker/issues/28941).

The issue is the code at
https://github.com/docker/docker/blob/master/cli/command/container/stats_helpers.go#L184
which multiplies by the length of the array on those files which has
gone from being the number of online cpus to the number of possible
cpus, hence inflating the numbers.

I'm not entirely sure what the answer is, mainly because I've not been
able to figure out what the units presented in the cpuacct files are
which would justify multiplying by any version of number of CPUs,
although it does appear to have been (AFAICT) producing the correct
numbers with the old code.

I'm more than happy to code up a fix on whichever side of the boundary
is appropriate given a hint in the correct direction to take...

Thanks,
Ian.

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ian Campbell]

On Sat, 2016-12-10 at 13:41 +0100, Greg Kroah-Hartman wrote:
> Now I don't work on a distro anymore, but I would think that something
> like this would be really useful, pointing out exactly what changed is
> very important for distro maintainers to determine what they want to do

The .symvers produced by the current scheme aren't completely useless
from this PoV, although they aren't ideal since you need both before an
d after trees and if the changes are large or far reaching the diff can
get a bit unwieldy, so better tooling which points directly to the
actual relevant change would be no bad thing.

Ian.

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ian Campbell]

On Sat, 2016-12-10 at 13:41 +0100, Greg Kroah-Hartman wrote:
> Now I don't work on a distro anymore, but I would think that something
> like this would be really useful, pointing out exactly what changed is
> very important for distro maintainers to determine what they want to do

The .symvers produced by the current scheme aren't completely useless
from this PoV, although they aren't ideal since you need both before an
d after trees and if the changes are large or far reaching the diff can
get a bit unwieldy, so better tooling which points directly to the
actual relevant change would be no bad thing.

Ian.

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ian Campbell]

On Fri, 2016-12-09 at 13:33 +1000, Nicholas Piggin wrote:
> 
> Well I simply tested the outcome. If you have:
> 
> struct blah {
>   int x;
> };
> int foo(struct blah *blah)
> {
>   return blah->x;
> }
> EXPORT(foo);
> 
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
> 
> Now change to
> 
> struct blah {
>   int y;
>   int x;
> };
> 
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
> 
> It just doesn't catch these things.

I found the same when I just added your snippet to init/main.c.

_But_ when I moved the struct into include/types.h (which happened to
be included by init/main.c) then, with just x in the struct:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { int x ; } 
foo int foo ( s#blah * ) 
0cd0312e A __crc_foo

but adding y:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { int x ; int y ; } 
foo int foo ( s#blah * ) 
eda220c6 A __crc_foo

So it does catch things in that case.

With struct blah inline in main.c it was:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { UNKNOWN } 
foo int foo ( s#blah * ) 
a0cf13a0 A __crc_foo

So I suppose it only cares about structs which are in headers, which I
guess makes sense. I think it is working in at least one of the
important cases.

Ian.

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Ian Campbell]

On Fri, 2016-12-09 at 13:33 +1000, Nicholas Piggin wrote:
> 
> Well I simply tested the outcome. If you have:
> 
> struct blah {
>   int x;
> };
> int foo(struct blah *blah)
> {
>   return blah->x;
> }
> EXPORT(foo);
> 
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
> 
> Now change to
> 
> struct blah {
>   int y;
>   int x;
> };
> 
> $ nm vmlinux | grep __crc_foo
> a0cf13a0 A __crc_foo
> 
> It just doesn't catch these things.

I found the same when I just added your snippet to init/main.c.

_But_ when I moved the struct into include/types.h (which happened to
be included by init/main.c) then, with just x in the struct:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { int x ; } 
foo int foo ( s#blah * ) 
0cd0312e A __crc_foo

but adding y:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { int x ; int y ; } 
foo int foo ( s#blah * ) 
eda220c6 A __crc_foo

So it does catch things in that case.

With struct blah inline in main.c it was:

$ make -s init/main.{o,symtypes} && grep -E foo\|blah init/main.symtypes && 
nm init/main.o  | grep __crc_foo
s#blah struct blah { UNKNOWN } 
foo int foo ( s#blah * ) 
a0cf13a0 A __crc_foo

So I suppose it only cares about structs which are in headers, which I
guess makes sense. I think it is working in at least one of the
important cases.

Ian.

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Fri, 2016-09-09 at 17:47 +0200, Arnd Bergmann wrote:
> On Friday, September 9, 2016 3:45:56 PM CEST Ian Campbell wrote:
> > 
> > On Tue, 2016-08-23 at 12:09 +0200, Arnd Bergmann wrote:
> > > 
> > > I had skipped the new message as well while sorting through 5000
> > > messages after my vacation, but I've now put it into my TODO
> > > folder
> > > and will get to it eventually.
> > 
> > Is it still on your TODO or should I do...
> > 
> > > 
> > > We sometimes miss stuff that is meant for arm-soc when it comes
> > > from people that don't normally send us patches. If you want to
> > > be sure to catch the attention, stick a 'GIT PULL' into the
> > > subject
> > > or send a ping on IRC.
> > 
> > ... one of these?
> > 
> > It'd be great to get this fixed in v4.8 so that the corresponding
> > device-tree.git tag will build.
> 
> Oh, it ended  up in my v4.9-todo folder, not 4.8, I misunderstood
> the urgency, sorry.

No worries.

> I've applied it to the fixes branch now.

Thank you!

Ian.

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Fri, 2016-09-09 at 17:47 +0200, Arnd Bergmann wrote:
> On Friday, September 9, 2016 3:45:56 PM CEST Ian Campbell wrote:
> > 
> > On Tue, 2016-08-23 at 12:09 +0200, Arnd Bergmann wrote:
> > > 
> > > I had skipped the new message as well while sorting through 5000
> > > messages after my vacation, but I've now put it into my TODO
> > > folder
> > > and will get to it eventually.
> > 
> > Is it still on your TODO or should I do...
> > 
> > > 
> > > We sometimes miss stuff that is meant for arm-soc when it comes
> > > from people that don't normally send us patches. If you want to
> > > be sure to catch the attention, stick a 'GIT PULL' into the
> > > subject
> > > or send a ping on IRC.
> > 
> > ... one of these?
> > 
> > It'd be great to get this fixed in v4.8 so that the corresponding
> > device-tree.git tag will build.
> 
> Oh, it ended  up in my v4.9-todo folder, not 4.8, I misunderstood
> the urgency, sorry.

No worries.

> I've applied it to the fixes branch now.

Thank you!

Ian.

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Tue, 2016-08-23 at 12:09 +0200, Arnd Bergmann wrote:
> I had skipped the new message as well while sorting through 5000
> messages after my vacation, but I've now put it into my TODO folder
> and will get to it eventually.

Is it still on your TODO or should I do...

> We sometimes miss stuff that is meant for arm-soc when it comes
> from people that don't normally send us patches. If you want to
> be sure to catch the attention, stick a 'GIT PULL' into the subject
> or send a ping on IRC.

... one of these?

It'd be great to get this fixed in v4.8 so that the corresponding
device-tree.git tag will build.

Thanks,
Ian.

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Tue, 2016-08-23 at 12:09 +0200, Arnd Bergmann wrote:
> I had skipped the new message as well while sorting through 5000
> messages after my vacation, but I've now put it into my TODO folder
> and will get to it eventually.

Is it still on your TODO or should I do...

> We sometimes miss stuff that is meant for arm-soc when it comes
> from people that don't normally send us patches. If you want to
> be sure to catch the attention, stick a 'GIT PULL' into the subject
> or send a ping on IRC.

... one of these?

It'd be great to get this fixed in v4.8 so that the corresponding
device-tree.git tag will build.

Thanks,
Ian.

Re: [PATCH v3 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Thu, 2016-08-18 at 10:59 -0700, Eric Anholt wrote:
> I'd lost track of these patches, sorry.  Both are:
> 
> Acked-by: Eric Anholt 

Thanks!

> They're going through the -soc tree, right?

I think so.

Ian.

Re: [PATCH v3 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Thu, 2016-08-18 at 10:59 -0700, Eric Anholt wrote:
> I'd lost track of these patches, sorry.  Both are:
> 
> Acked-by: Eric Anholt 

Thanks!

> They're going through the -soc tree, right?

I think so.

Ian.

[PATCH v3 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

The ../../../arm... style cross-references added by commit 9d56c22a7861
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Acked-by: Mark Rutland <mark.rutl...@arm.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Frank Rowand <frowand.l...@gmail.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Lee Jones <l...@kernel.org>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: No more need for skeleton.dtsi since this was cleaned up in the previous
patch
v3: Collected tags
---
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  | 1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   | 4 ++--
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi  | 2 +-
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi | 1 +
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  | 1 +
 5 files changed, 6 insertions(+), 3 deletions(-)
 create mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
new file mode 12
index 000..3937b77
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 6f47dd2..7841b72 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
-#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..8216bbb 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,4 +1,4 @@
-#include "../../../../arm/boot/dts/bcm283x.dtsi"
+#include "bcm283x.dtsi"
 
 / {
compatible = "brcm,bcm2836";
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..dca7c05
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
new file mode 12
index 000..5f54e4c
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
-- 
2.8.1

[PATCH v3 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

The ../../../arm... style cross-references added by commit 9d56c22a7861
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Acked-by: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Eric Anholt 
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Gerd Hoffmann 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: No more need for skeleton.dtsi since this was cleaned up in the previous
patch
v3: Collected tags
---
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  | 1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   | 4 ++--
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi  | 2 +-
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi | 1 +
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  | 1 +
 5 files changed, 6 insertions(+), 3 deletions(-)
 create mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
new file mode 12
index 000..3937b77
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 6f47dd2..7841b72 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
-#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..8216bbb 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,4 +1,4 @@
-#include "../../../../arm/boot/dts/bcm283x.dtsi"
+#include "bcm283x.dtsi"
 
 / {
compatible = "brcm,bcm2836";
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..dca7c05
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
new file mode 12
index 000..5f54e4c
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
-- 
2.8.1

[PATCH v3 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

This file is included from DTS files under arch/arm64 too (via
broadcom/bcm2837-rpi-3-b.dts and broadcom/bcm2837.dtsi). There is a desire
not to have skeleton.dtsi for ARM64. See commit 3ebee5a2e141 ("arm64: dts:
kill skeleton.dtsi") for rationale for its removal.

As well as the addition of #*-cells also requires adding the device_type to
the rpi memory node explicitly.

Note that this change results in the removal of an empty /aliases node from
bcm2835-rpi-a.dtb and bcm2835-rpi-a-plus.dtb. I have no hardware to check
if this is a problem or not.

It also results in some reordering of the nodes in the DTBs (the /aliases
and /memory nodes come later). This isn't supposed to matter but, again,
I've no hardware to check if it is true in this particular case.

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Acked-by: Mark Rutland <mark.rutl...@arm.com>
Tested-by: Stefan Wahren <stefan.wah...@i2se.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Frank Rowand <frowand.l...@gmail.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Lee Jones <l...@kernel.org>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: New patch to avoid needing to add skeleton.dtsi to arch/arm64
v3: Collected tags
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 1 +
 arch/arm/boot/dts/bcm283x.dtsi | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index caf2707..e9b47b2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -2,6 +2,7 @@
 
 / {
memory {
+   device_type = "memory";
reg = <0 0x1000>;
};
 
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index b982522..445624a 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -2,7 +2,6 @@
 #include 
 #include 
 #include 
-#include "skeleton.dtsi"
 
 /* This include file covers the common peripherals and configuration between
  * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
@@ -13,6 +12,8 @@
compatible = "brcm,bcm2835";
model = "BCM2835";
interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
chosen {
bootargs = "earlyprintk console=ttyAMA0";
-- 
2.8.1

[PATCH v3 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

This file is included from DTS files under arch/arm64 too (via
broadcom/bcm2837-rpi-3-b.dts and broadcom/bcm2837.dtsi). There is a desire
not to have skeleton.dtsi for ARM64. See commit 3ebee5a2e141 ("arm64: dts:
kill skeleton.dtsi") for rationale for its removal.

As well as the addition of #*-cells also requires adding the device_type to
the rpi memory node explicitly.

Note that this change results in the removal of an empty /aliases node from
bcm2835-rpi-a.dtb and bcm2835-rpi-a-plus.dtb. I have no hardware to check
if this is a problem or not.

It also results in some reordering of the nodes in the DTBs (the /aliases
and /memory nodes come later). This isn't supposed to matter but, again,
I've no hardware to check if it is true in this particular case.

Signed-off-by: Ian Campbell 
Acked-by: Mark Rutland 
Tested-by: Stefan Wahren 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Eric Anholt 
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Gerd Hoffmann 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: New patch to avoid needing to add skeleton.dtsi to arch/arm64
v3: Collected tags
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 1 +
 arch/arm/boot/dts/bcm283x.dtsi | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index caf2707..e9b47b2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -2,6 +2,7 @@
 
 / {
memory {
+   device_type = "memory";
reg = <0 0x1000>;
};
 
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index b982522..445624a 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -2,7 +2,6 @@
 #include 
 #include 
 #include 
-#include "skeleton.dtsi"
 
 /* This include file covers the common peripherals and configuration between
  * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
@@ -13,6 +12,8 @@
compatible = "brcm,bcm2835";
model = "BCM2835";
interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
chosen {
bootargs = "earlyprintk console=ttyAMA0";
-- 
2.8.1

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Tue, 2016-08-09 at 11:48 +0100, Ian Campbell wrote:
> On Wed, 2016-08-03 at 15:48 +0100, Mark Rutland wrote:
> > 
> > > [...]Signed-off-by: Ian Campbell <i...@hellion.org.uk>
> > 
> > I also don't have the relevant hardware to test with, but this
> looks
> > generally like the right thing. So FWIW:
> > 
> > Acked-by: Mark Rutland <mark.rutl...@arm.com>
> 
> Thanks (and Stefan too).
> 
> I think these things generally go via the arm-soc tree? Arnd & Olaf,
> would it be possible to get this fix in for rc2 please (or in any event
> for 4.8). Although it's an external tree I believe build breakage in
> the split-out DT git repo is worth addressing.

This change doesn't appear to be in either v4.8-rc2, Linus' tree nor in
the arm-soc tree that I can see. So, ping?

Or am I barking up the wrong tree pointing this patch towards arm-soc
(via arm@k.o)?

Ian

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Tue, 2016-08-09 at 11:48 +0100, Ian Campbell wrote:
> On Wed, 2016-08-03 at 15:48 +0100, Mark Rutland wrote:
> > 
> > > [...]Signed-off-by: Ian Campbell 
> > 
> > I also don't have the relevant hardware to test with, but this
> looks
> > generally like the right thing. So FWIW:
> > 
> > Acked-by: Mark Rutland 
> 
> Thanks (and Stefan too).
> 
> I think these things generally go via the arm-soc tree? Arnd & Olaf,
> would it be possible to get this fix in for rc2 please (or in any event
> for 4.8). Although it's an external tree I believe build breakage in
> the split-out DT git repo is worth addressing.

This change doesn't appear to be in either v4.8-rc2, Linus' tree nor in
the arm-soc tree that I can see. So, ping?

Or am I barking up the wrong tree pointing this patch towards arm-soc
(via arm@k.o)?

Ian

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Wed, 2016-08-03 at 15:48 +0100, Mark Rutland wrote:
> 
> > [...]Signed-off-by: Ian Campbell <i...@hellion.org.uk>
> 
> I also don't have the relevant hardware to test with, but this looks
> generally like the right thing. So FWIW:
> 
> Acked-by: Mark Rutland <mark.rutl...@arm.com>

Thanks (and Stefan too).

I think these things generally go via the arm-soc tree? Arnd & Olaf,
would it be possible to get this fix in for rc2 please (or in any event
for 4.8). Although it's an external tree I believe build breakage in
the split-out DT git repo is worth addressing.

Ian.

Re: [PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

On Wed, 2016-08-03 at 15:48 +0100, Mark Rutland wrote:
> 
> > [...]Signed-off-by: Ian Campbell 
> 
> I also don't have the relevant hardware to test with, but this looks
> generally like the right thing. So FWIW:
> 
> Acked-by: Mark Rutland 

Thanks (and Stefan too).

I think these things generally go via the arm-soc tree? Arnd & Olaf,
would it be possible to get this fix in for rc2 please (or in any event
for 4.8). Although it's an external tree I believe build breakage in
the split-out DT git repo is worth addressing.

Ian.

Re: [PATCH] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

On Wed, 2016-08-03 at 14:30 +0100, Mark Rutland wrote:
> On Wed, Aug 03, 2016 at 08:13:51AM -0500, Rob Herring wrote:
> > 
> > > > On Wed, Aug 3, 2016 at 3:40 AM, Ian Campbell <i...@hellion.org.uk> 
> > > > wrote:
> > > 
> > > These includes in turn require a skeleton.dtsi to be present, so add one 
> > > as
> > > a real file (with the same contents as arch/arm) rather than a symlink.
> > 
> > I don't follow why skeleton.dtsi is needed. The 32-bit RPi dts files
> > are including it?

Exactly.

> >  If so, can we just remove it. We decided
> > skeleton.dtsi was a bad idea.
> 
> Yup. I don't want to see skeleton.dtsi reappear, and the necessary
> fixups to source files are relatively simple.
> 
> Ian, see commit 3ebee5a2e141496b ("arm64: dts: kill skeleton.dtsi") for
> the rationale, and hints as to what needs to be fixed up (e.g. if empty
> > memory nodes are required, there should be a comment as to why).

Understood.

I can make the mechanical fix to arch/arm/boot/dts/bcm283x.dtsi (which
is linked here as arch/arm64/boot/dts/broadcom/bcm283x.dtsi which
causes the need for skeleton.dtsi) but I don't have any R-Pi hardware
with which to verify the need (or not) for empty memory nodes etc.

> Perhaps this is a good time to attack the remaining 32-bit skeleton.dtsi
> > users. I'll take another look come -rc1.

linux.git$ git grep skeleton.dtsi -- arch/arm  | wc -l
148
linux.git$

Good luck ;-)

Ian.

Re: [PATCH] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

On Wed, 2016-08-03 at 14:30 +0100, Mark Rutland wrote:
> On Wed, Aug 03, 2016 at 08:13:51AM -0500, Rob Herring wrote:
> > 
> > > > On Wed, Aug 3, 2016 at 3:40 AM, Ian Campbell  
> > > > wrote:
> > > 
> > > These includes in turn require a skeleton.dtsi to be present, so add one 
> > > as
> > > a real file (with the same contents as arch/arm) rather than a symlink.
> > 
> > I don't follow why skeleton.dtsi is needed. The 32-bit RPi dts files
> > are including it?

Exactly.

> >  If so, can we just remove it. We decided
> > skeleton.dtsi was a bad idea.
> 
> Yup. I don't want to see skeleton.dtsi reappear, and the necessary
> fixups to source files are relatively simple.
> 
> Ian, see commit 3ebee5a2e141496b ("arm64: dts: kill skeleton.dtsi") for
> the rationale, and hints as to what needs to be fixed up (e.g. if empty
> > memory nodes are required, there should be a comment as to why).

Understood.

I can make the mechanical fix to arch/arm/boot/dts/bcm283x.dtsi (which
is linked here as arch/arm64/boot/dts/broadcom/bcm283x.dtsi which
causes the need for skeleton.dtsi) but I don't have any R-Pi hardware
with which to verify the need (or not) for empty memory nodes etc.

> Perhaps this is a good time to attack the remaining 32-bit skeleton.dtsi
> > users. I'll take another look come -rc1.

linux.git$ git grep skeleton.dtsi -- arch/arm  | wc -l
148
linux.git$

Good luck ;-)

Ian.

[PATCH v2 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

The ../../../arm... style cross-references added by commit 9d56c22a7861
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Frank Rowand <frowand.l...@gmail.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Lee Jones <l...@kernel.org>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: No more need for skeleton.dtsi since this was cleaned up in the previous
patch
---
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  | 1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   | 4 ++--
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi  | 2 +-
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi | 1 +
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  | 1 +
 5 files changed, 6 insertions(+), 3 deletions(-)
 create mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
new file mode 12
index 000..3937b77
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 6f47dd2..7841b72 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
-#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..8216bbb 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,4 +1,4 @@
-#include "../../../../arm/boot/dts/bcm283x.dtsi"
+#include "bcm283x.dtsi"
 
 / {
compatible = "brcm,bcm2836";
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..dca7c05
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
new file mode 12
index 000..5f54e4c
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
-- 
2.8.1

[PATCH v2 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

The ../../../arm... style cross-references added by commit 9d56c22a7861
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Eric Anholt 
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Gerd Hoffmann 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: No more need for skeleton.dtsi since this was cleaned up in the previous
patch
---
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  | 1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   | 4 ++--
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi  | 2 +-
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi | 1 +
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  | 1 +
 5 files changed, 6 insertions(+), 3 deletions(-)
 create mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
new file mode 12
index 000..3937b77
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 6f47dd2..7841b72 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
-#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..8216bbb 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,4 +1,4 @@
-#include "../../../../arm/boot/dts/bcm283x.dtsi"
+#include "bcm283x.dtsi"
 
 / {
compatible = "brcm,bcm2836";
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..dca7c05
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
new file mode 12
index 000..5f54e4c
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
-- 
2.8.1

[PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

This file is included from DTS files under arch/arm64 too (via
broadcom/bcm2837-rpi-3-b.dts and broadcom/bcm2837.dtsi). There is a desire
not to have skeleton.dtsi for ARM64. See commit 3ebee5a2e141 ("arm64: dts:
kill skeleton.dtsi") for rationale for its removal.

As well as the addition of #*-cells also requires adding the device_type to
the rpi memory node explicitly.

Note that this change results in the removal of an empty /aliases node from
bcm2835-rpi-a.dtb and bcm2835-rpi-a-plus.dtb. I have no hardware to check
if this is a problem or not.

It also results in some reordering of the nodes in the DTBs (the /aliases
and /memory nodes come later). This isn't supposed to matter but, again,
I've no hardware to check if it is true in this particular case.

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Frank Rowand <frowand.l...@gmail.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Lee Jones <l...@kernel.org>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: New patch to avoid needing to add skeleton.dtsi to arch/arm64
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 1 +
 arch/arm/boot/dts/bcm283x.dtsi | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index caf2707..e9b47b2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -2,6 +2,7 @@
 
 / {
memory {
+   device_type = "memory";
reg = <0 0x1000>;
};
 
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index b982522..445624a 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -2,7 +2,6 @@
 #include 
 #include 
 #include 
-#include "skeleton.dtsi"
 
 /* This include file covers the common peripherals and configuration between
  * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
@@ -13,6 +12,8 @@
compatible = "brcm,bcm2835";
model = "BCM2835";
interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
chosen {
bootargs = "earlyprintk console=ttyAMA0";
-- 
2.8.1

[PATCH v2 1/2] ARM: dts: Remove use of skeleton.dtsi from bcm283x.dtsi

[Ian Campbell]

This file is included from DTS files under arch/arm64 too (via
broadcom/bcm2837-rpi-3-b.dts and broadcom/bcm2837.dtsi). There is a desire
not to have skeleton.dtsi for ARM64. See commit 3ebee5a2e141 ("arm64: dts:
kill skeleton.dtsi") for rationale for its removal.

As well as the addition of #*-cells also requires adding the device_type to
the rpi memory node explicitly.

Note that this change results in the removal of an empty /aliases node from
bcm2835-rpi-a.dtb and bcm2835-rpi-a-plus.dtb. I have no hardware to check
if this is a problem or not.

It also results in some reordering of the nodes in the DTBs (the /aliases
and /memory nodes come later). This isn't supposed to matter but, again,
I've no hardware to check if it is true in this particular case.

Signed-off-by: Ian Campbell 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Eric Anholt 
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Gerd Hoffmann 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
v2: New patch to avoid needing to add skeleton.dtsi to arch/arm64
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 1 +
 arch/arm/boot/dts/bcm283x.dtsi | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index caf2707..e9b47b2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -2,6 +2,7 @@
 
 / {
memory {
+   device_type = "memory";
reg = <0 0x1000>;
};
 
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index b982522..445624a 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -2,7 +2,6 @@
 #include 
 #include 
 #include 
-#include "skeleton.dtsi"
 
 /* This include file covers the common peripherals and configuration between
  * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
@@ -13,6 +12,8 @@
compatible = "brcm,bcm2835";
model = "BCM2835";
interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
 
chosen {
bootargs = "earlyprintk console=ttyAMA0";
-- 
2.8.1

[PATCH] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

The ../../../arm... style cross-references added by commit 9d56c22a7861
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.

These includes in turn require a skeleton.dtsi to be present, so add one as
a real file (with the same contents as arch/arm) rather than a symlink.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell <i...@hellion.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Frank Rowand <frowand.l...@gmail.com>
Cc: Eric Anholt <e...@anholt.net>
Cc: Stephen Warren <swar...@wwwdotorg.org>
Cc: Lee Jones <l...@kernel.org>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  |  1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   |  4 ++--
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi  |  2 +-
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi |  1 +
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  |  1 +
 arch/arm64/boot/dts/skeleton.dtsi  | 13 +
 6 files changed, 19 insertions(+), 3 deletions(-)
 create mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi
 create mode 100644 arch/arm64/boot/dts/skeleton.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
new file mode 12
index 000..3937b77
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 6f47dd2..7841b72 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
-#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..8216bbb 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,4 +1,4 @@
-#include "../../../../arm/boot/dts/bcm283x.dtsi"
+#include "bcm283x.dtsi"
 
 / {
compatible = "brcm,bcm2836";
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..dca7c05
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
new file mode 12
index 000..5f54e4c
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/skeleton.dtsi 
b/arch/arm64/boot/dts/skeleton.dtsi
new file mode 100644
index 000..b41d241
--- /dev/null
+++ b/arch/arm64/boot/dts/skeleton.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree; the bare minimum needed to boot; just include and
+ * add a compatible value.  The bootloader will typically populate the memory
+ * node.
+ */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   chosen { };
+   aliases { };
+   memory { device_type = "memory"; reg = <0 0>; };
+};
-- 
2.8.1

[PATCH] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

[Ian Campbell]

The ../../../arm... style cross-references added by commit 9d56c22a7861
("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the
context of the split device-tree repository[0] (where the directory
structure differs). As with commit 8ee57b8182c4 ("ARM64: dts: vexpress: Use
a symlink to vexpress-v2m-rs1.dtsi from arch=arm") use symlinks instead.

These includes in turn require a skeleton.dtsi to be present, so add one as
a real file (with the same contents as arch/arm) rather than a symlink.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Eric Anholt 
Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Gerd Hoffmann 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: a...@kernel.org
---
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  |  1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   |  4 ++--
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi  |  2 +-
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi |  1 +
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  |  1 +
 arch/arm64/boot/dts/skeleton.dtsi  | 13 +
 6 files changed, 19 insertions(+), 3 deletions(-)
 create mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi
 create mode 100644 arch/arm64/boot/dts/skeleton.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
new file mode 12
index 000..3937b77
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 6f47dd2..7841b72 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
-#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
index f2a31d0..8216bbb 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -1,4 +1,4 @@
-#include "../../../../arm/boot/dts/bcm283x.dtsi"
+#include "bcm283x.dtsi"
 
 / {
compatible = "brcm,bcm2836";
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..dca7c05
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
new file mode 12
index 000..5f54e4c
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/skeleton.dtsi 
b/arch/arm64/boot/dts/skeleton.dtsi
new file mode 100644
index 000..b41d241
--- /dev/null
+++ b/arch/arm64/boot/dts/skeleton.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree; the bare minimum needed to boot; just include and
+ * add a compatible value.  The bootloader will typically populate the memory
+ * node.
+ */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   chosen { };
+   aliases { };
+   memory { device_type = "memory"; reg = <0 0>; };
+};
-- 
2.8.1

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[Ian Campbell]

On Fri, 2016-01-22 at 13:49 +, Wei Liu wrote:
> On Fri, Jan 22, 2016 at 01:14:24PM +, David Vrabel wrote:
> > On 22/01/16 12:34, Wei Liu wrote:
> > > The comment at the beginning of the file is the canonical source of
> > > licenses for this module. Currently it contains GPL and MIT license.
> > > Fix
> > > the code to reflect the reality.
> > 
> > "The MIT license" isn't really a thing.  The closest is the X11
> > license[1], but this not applicable here either since the text in the
> > drivers does not refer to X11 trademarks etc.
> > 
> 
> That was referring to the license ident string in Linux.  If MIT license
> isn't a thing, why would Linux have it at all?

The fact what include/linux/license.h:license_is_gpl_compatible includes
"Dual MIT/GPL" as an option seems to suggest that it is enough of a thing
to be validly used as the contents of a MODULE_LICENSE() thing.

It's also in https://opensource.org/licenses/MIT , the fact that it might
be confused for other licenses used by MIT notwithstanding.

FWIW https://en.wikipedia.org/wiki/MIT_License seems to think that the
wording most commonly called the "MIT License" might be the "Expat
license", rather than the "X11 License" which is similar but different.

Ian.

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[Ian Campbell]

On Fri, 2016-01-22 at 13:49 +, Wei Liu wrote:
> On Fri, Jan 22, 2016 at 01:14:24PM +, David Vrabel wrote:
> > On 22/01/16 12:34, Wei Liu wrote:
> > > The comment at the beginning of the file is the canonical source of
> > > licenses for this module. Currently it contains GPL and MIT license.
> > > Fix
> > > the code to reflect the reality.
> > 
> > "The MIT license" isn't really a thing.  The closest is the X11
> > license[1], but this not applicable here either since the text in the
> > drivers does not refer to X11 trademarks etc.
> > 
> 
> That was referring to the license ident string in Linux.  If MIT license
> isn't a thing, why would Linux have it at all?

The fact what include/linux/license.h:license_is_gpl_compatible includes
"Dual MIT/GPL" as an option seems to suggest that it is enough of a thing
to be validly used as the contents of a MODULE_LICENSE() thing.

It's also in https://opensource.org/licenses/MIT , the fact that it might
be confused for other licenses used by MIT notwithstanding.

FWIW https://en.wikipedia.org/wiki/MIT_License seems to think that the
wording most commonly called the "MIT License" might be the "Expat
license", rather than the "X11 License" which is similar but different.

Ian.

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

[Ian Campbell]

On Tue, 2015-11-24 at 10:35 +, Andrew Cooper wrote:
> On 24/11/15 10:17, Petr Tesarik wrote:
> > On Tue, 24 Nov 2015 10:09:01 +
> > David Vrabel  wrote:
> > 
> > > On 24/11/15 09:55, Malcolm Crossley wrote:
> > > > On 24/11/15 08:59, Jan Beulich wrote:
> > > > > > > > On 24.11.15 at 07:55,  wrote:
> > > > > > What about:
> > > > > > 
> > > > > > 4) Instead of relying on the kernel maintained p2m list for m2p
> > > > > >    conversion use the hypervisor maintained m2p list which
> > > > > > should be
> > > > > >    available in the dump as well. This is the way the alive
> > > > > > kernel is
> > > > > >    working, so mimic it during crash dump analysis.
> > > > > I fully agree; I have to admit that looking at the p2m when doing
> > > > > page
> > > > > table walks for a PV Dom0 (having all machine addresses in page
> > > > > table
> > > > > entries) seems kind of backwards. (But I say this knowing nothing
> > > > > about the tool.)
> > > > > 
> > > > I don't think we can reliably use the m2p for PV domains because
> > > > PV domains don't always issue a m2p update hypercall when they
> > > > change
> > > > their p2m mapping.
> > > This only applies to foreign pages which won't be very interesting to
> > > a
> > > crash tool.
> > True. I think the main reason crash hasn't done this is that it cannot
> > find the hypervisor maintained m2p list. It should be sufficient to add
> > some more fields to XEN_VMCOREINFO, so that crash can locate the
> > mapping in the dump.
> 
> The M2P lives at an ABI-specified location in all virtual address spaces
> for PV guests.
> 
> Either 0xF580 or 0x8000 depending on bitness.

In theory it can actually be dynamic. XENMEM_machphys_mapping is the way to
get at it (for both bitnesses).

For 64-bit guests I think that is most an "in theory" thing and it never
has actually been so.

For a 32-bit guest case I don't recall if it is just a 32on32 vs 32on64
thing, or if something (either guest or toolstack) gets to pick more
dynamically or even if it is a dom0 vs domU thing.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list

[Ian Campbell]

On Tue, 2015-11-24 at 10:35 +, Andrew Cooper wrote:
> On 24/11/15 10:17, Petr Tesarik wrote:
> > On Tue, 24 Nov 2015 10:09:01 +
> > David Vrabel  wrote:
> > 
> > > On 24/11/15 09:55, Malcolm Crossley wrote:
> > > > On 24/11/15 08:59, Jan Beulich wrote:
> > > > > > > > On 24.11.15 at 07:55,  wrote:
> > > > > > What about:
> > > > > > 
> > > > > > 4) Instead of relying on the kernel maintained p2m list for m2p
> > > > > >    conversion use the hypervisor maintained m2p list which
> > > > > > should be
> > > > > >    available in the dump as well. This is the way the alive
> > > > > > kernel is
> > > > > >    working, so mimic it during crash dump analysis.
> > > > > I fully agree; I have to admit that looking at the p2m when doing
> > > > > page
> > > > > table walks for a PV Dom0 (having all machine addresses in page
> > > > > table
> > > > > entries) seems kind of backwards. (But I say this knowing nothing
> > > > > about the tool.)
> > > > > 
> > > > I don't think we can reliably use the m2p for PV domains because
> > > > PV domains don't always issue a m2p update hypercall when they
> > > > change
> > > > their p2m mapping.
> > > This only applies to foreign pages which won't be very interesting to
> > > a
> > > crash tool.
> > True. I think the main reason crash hasn't done this is that it cannot
> > find the hypervisor maintained m2p list. It should be sufficient to add
> > some more fields to XEN_VMCOREINFO, so that crash can locate the
> > mapping in the dump.
> 
> The M2P lives at an ABI-specified location in all virtual address spaces
> for PV guests.
> 
> Either 0xF580 or 0x8000 depending on bitness.

In theory it can actually be dynamic. XENMEM_machphys_mapping is the way to
get at it (for both bitnesses).

For 64-bit guests I think that is most an "in theory" thing and it never
has actually been so.

For a 32-bit guest case I don't recall if it is just a 32on32 vs 32on64
thing, or if something (either guest or toolstack) gets to pick more
dynamically or even if it is a dom0 vs domU thing.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH v4 2/7] xen/arm: introduce HYPERVISOR_platform_op on arm and arm64

[Ian Campbell]

On Fri, 2015-11-20 at 11:58 +, Stefano Stabellini wrote:
> On Mon, 16 Nov 2015, Ian Campbell wrote:
> > On Fri, 2015-11-13 at 18:10 +, Stefano Stabellini wrote:
> > > 
> > > I agree with your point (I thought about it myself) but the current
> > > assembly scheme for hypercalls doesn't work well with that. I would
> > > have
> > > to introduce, and maintain going forward, two special hypercall
> > > implementations in assembly, one for arm and another for arm64, just
> > > to
> > > set interface_version. I don't think it is worth it; I prefer to have
> > > to
> > > maintain the explicit interface_version setting at the call sites
> > > (that
> > > today is just one).
> > 
> > You could give the bare assembly stub a different name (append _core or
> > _raw or something) and make HYPERVISOR_platform_op a C wrapper for it
> > which
> > DTRT.
> 
> I had an idea. I just need to 
> 
> #define HYPERVISOR_platform_op_raw HYPERVISOR_platform_op

The need for this #define is a bit unfortunate, but the alternatives (e.g.
a suffix argument to the HYPERCALL*() macros or a RAWHYPERCALL variant)
would seem to suck more, so I say go for it.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH v4 2/7] xen/arm: introduce HYPERVISOR_platform_op on arm and arm64

[Ian Campbell]

On Fri, 2015-11-20 at 11:58 +, Stefano Stabellini wrote:
> On Mon, 16 Nov 2015, Ian Campbell wrote:
> > On Fri, 2015-11-13 at 18:10 +, Stefano Stabellini wrote:
> > > 
> > > I agree with your point (I thought about it myself) but the current
> > > assembly scheme for hypercalls doesn't work well with that. I would
> > > have
> > > to introduce, and maintain going forward, two special hypercall
> > > implementations in assembly, one for arm and another for arm64, just
> > > to
> > > set interface_version. I don't think it is worth it; I prefer to have
> > > to
> > > maintain the explicit interface_version setting at the call sites
> > > (that
> > > today is just one).
> > 
> > You could give the bare assembly stub a different name (append _core or
> > _raw or something) and make HYPERVISOR_platform_op a C wrapper for it
> > which
> > DTRT.
> 
> I had an idea. I just need to 
> 
> #define HYPERVISOR_platform_op_raw HYPERVISOR_platform_op

The need for this #define is a bit unfortunate, but the alternatives (e.g.
a suffix argument to the HYPERCALL*() macros or a RAWHYPERCALL variant)
would seem to suck more, so I say go for it.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH v4 2/7] xen/arm: introduce HYPERVISOR_platform_op on arm and arm64

[Ian Campbell]

On Fri, 2015-11-13 at 18:10 +, Stefano Stabellini wrote:
> 
> I agree with your point (I thought about it myself) but the current
> assembly scheme for hypercalls doesn't work well with that. I would have
> to introduce, and maintain going forward, two special hypercall
> implementations in assembly, one for arm and another for arm64, just to
> set interface_version. I don't think it is worth it; I prefer to have to
> maintain the explicit interface_version setting at the call sites (that
> today is just one).

You could give the bare assembly stub a different name (append _core or
_raw or something) and make HYPERVISOR_platform_op a C wrapper for it which
DTRT.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH v4 2/7] xen/arm: introduce HYPERVISOR_platform_op on arm and arm64

[Ian Campbell]

On Fri, 2015-11-13 at 18:10 +, Stefano Stabellini wrote:
> 
> I agree with your point (I thought about it myself) but the current
> assembly scheme for hypercalls doesn't work well with that. I would have
> to introduce, and maintain going forward, two special hypercall
> implementations in assembly, one for arm and another for arm64, just to
> set interface_version. I don't think it is worth it; I prefer to have to
> maintain the explicit interface_version setting at the call sites (that
> today is just one).

You could give the bare assembly stub a different name (append _core or
_raw or something) and make HYPERVISOR_platform_op a C wrapper for it which
DTRT.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen-netback: corretly check failed allocation

[Ian Campbell]

On Thu, 2015-10-15 at 12:26 -0400, Insu Yun wrote:
> Since vzalloc can be failed in memory pressure,
> return value should be checked and return ENOMEM.
> 
> Signed-off-by: Insu Yun 
> ---
>  drivers/net/xen-netback/xenbus.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen
> -netback/xenbus.c
> index 929a6e7..e288246 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -788,6 +788,11 @@ static void connect(struct backend_info *be)
>   /* Use the number of queues requested by the frontend */
>   be->vif->queues = vzalloc(requested_num_queues *
> sizeof(struct xenvif_queue));
> +  if (!be->vif->queues)  {
> +xenbus_dev_fatal(dev, -ENOMEM, "allocating queues");
> +return;
> +  }

Please fix the coding style, perhaps using checkpatch.pl or by observing
the surrounding code.

Ian.

> +
>   be->vif->num_queues = requested_num_queues;
>   be->vif->stalled_queues = requested_num_queues;
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen-netback: corretly check failed allocation

[Ian Campbell]

On Thu, 2015-10-15 at 12:26 -0400, Insu Yun wrote:
> Since vzalloc can be failed in memory pressure,
> return value should be checked and return ENOMEM.
> 
> Signed-off-by: Insu Yun 
> ---
>  drivers/net/xen-netback/xenbus.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen
> -netback/xenbus.c
> index 929a6e7..e288246 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -788,6 +788,11 @@ static void connect(struct backend_info *be)
>   /* Use the number of queues requested by the frontend */
>   be->vif->queues = vzalloc(requested_num_queues *
> sizeof(struct xenvif_queue));
> +  if (!be->vif->queues)  {
> +xenbus_dev_fatal(dev, -ENOMEM, "allocating queues");
> +return;
> +  }

Please fix the coding style, perhaps using checkpatch.pl or by observing
the surrounding code.

Ian.

> +
>   be->vif->num_queues = requested_num_queues;
>   be->vif->stalled_queues = requested_num_queues;
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Ian Campbell]

On Mon, 2015-10-05 at 12:53 +0100, Ian Campbell wrote:

Ping?

> Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> LogicTile Express 20MG" added a new dts file to arch/arm64 which
> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> .dtsi supplied by arch/arm.
> 
> Unfortunately this causes some issues for the split device tree
> repository[0], since things get moved around there. In that context
> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> 
> The sharing of the .dtsi is legitimate since the baseboard is the same
> for various vexpress systems whatever processor they use.
> 
> Previously I attempted to resolve this by creating a shared location
> for such things but we have been unable to come to a consensus on
> where that should be.
> 
> Instead this patch simply replaces the use of ../../ in the dts
> /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
> file arch/arm/boot/dts.
> 
> Since the split device tree repo will shortly be required to flatten
> symlinks for other reasons this will cause the dtsi file to appear in
> both src/arm and src/arm64 in the split repo, which is an improvement
> on not building for arm64 now.
> 
> [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-re
> basing.git/
> 
> Signed-off-by: Ian Campbell 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Kumar Gala 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Kristina Martsenko 
> Cc: Kevin Hilman 
> Cc: Frank Rowand 
> Cc: Olof Johansson 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: a...@kernel.org
> Cc: linux-kbu...@vger.kernel.org
> ---
> For more on flattening symlinks see
> http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742
> ---
>  arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
>  arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>  create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> 
> diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> index 5b1d018..bb3c26d 100644
> --- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> @@ -186,6 +186,6 @@
>   <0 0 41  GIC_SPI 41
> IRQ_TYPE_LEVEL_HIGH>,
>   <0 0 42  GIC_SPI 42
> IRQ_TYPE_LEVEL_HIGH>;
>  
> - /include/ "../../../../arm/boot/dts/vexpress-v2m
> -rs1.dtsi"
> + /include/ "vexpress-v2m-rs1.dtsi"
>   };
>  };
> diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> new file mode 12
> index 000..68fd0f8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> @@ -0,0 +1 @@
> +../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi
> \ No newline at end of file
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Ian Campbell]

On Mon, 2015-10-05 at 12:53 +0100, Ian Campbell wrote:

Ping?

> Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> LogicTile Express 20MG" added a new dts file to arch/arm64 which
> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> .dtsi supplied by arch/arm.
> 
> Unfortunately this causes some issues for the split device tree
> repository[0], since things get moved around there. In that context
> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> 
> The sharing of the .dtsi is legitimate since the baseboard is the same
> for various vexpress systems whatever processor they use.
> 
> Previously I attempted to resolve this by creating a shared location
> for such things but we have been unable to come to a consensus on
> where that should be.
> 
> Instead this patch simply replaces the use of ../../ in the dts
> /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
> file arch/arm/boot/dts.
> 
> Since the split device tree repo will shortly be required to flatten
> symlinks for other reasons this will cause the dtsi file to appear in
> both src/arm and src/arm64 in the split repo, which is an improvement
> on not building for arm64 now.
> 
> [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-re
> basing.git/
> 
> Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Pawel Moll <pawel.m...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: Kumar Gala <ga...@codeaurora.org>
> Cc: Liviu Dudau <liviu.du...@arm.com>
> Cc: Sudeep Holla <sudeep.ho...@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Cc: Russell King <li...@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: Kristina Martsenko <kristina.martse...@arm.com>
> Cc: Kevin Hilman <khil...@linaro.org>
> Cc: Frank Rowand <frank.row...@sonymobile.com>
> Cc: Olof Johansson <o...@lixom.net>
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: a...@kernel.org
> Cc: linux-kbu...@vger.kernel.org
> ---
> For more on flattening symlinks see
> http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742
> ---
>  arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
>  arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>  create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> 
> diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> index 5b1d018..bb3c26d 100644
> --- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
> @@ -186,6 +186,6 @@
>   <0 0 41  GIC_SPI 41
> IRQ_TYPE_LEVEL_HIGH>,
>   <0 0 42  GIC_SPI 42
> IRQ_TYPE_LEVEL_HIGH>;
>  
> - /include/ "../../../../arm/boot/dts/vexpress-v2m
> -rs1.dtsi"
> + /include/ "vexpress-v2m-rs1.dtsi"
>   };
>  };
> diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> new file mode 12
> index 000..68fd0f8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
> @@ -0,0 +1 @@
> +../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi
> \ No newline at end of file
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Ian Campbell]

On Tue, 2015-10-06 at 11:28 +0200, Roger Pau Monné wrote:
> El 22/09/15 a les 12.59, Ian Campbell ha escrit:
> > On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> > > I'm not saying that we shouldn't take those patches, I'm just saying
> > > that IMHO this is a workaround, and I would like to see a plan and
> > > somebody committed to have it fixed in a proper way, by introducing a
> > > 64KB PV block protocol.
> > 
> > In my view the basic unit of operation for all Xen interfaces (on x86
> > and
> > arm at least[0]) is 4K. The peer at either end of a PV protocol should
> > therefore be entitled to assume that at a minimum the other end
> > supports
> > operation in 4K mode (i.e. 4K is the baseline).
> > 
> > Operations in larger sizes (which would necessarily be multiples of 4K)
> > are
> > then an extension which is subject to a negotiation between the two
> > ends,
> > it doesn't really matter if those larger sizes arise because of the use
> > of
> > superpages or because the guest is internally using some larger basic
> > page
> > size (which ARM calls a "granule", and where 64K comes from here).
> > 
> > I think this line of reasoning applies just as strongly to the
> > hypercall
> > ABI as well BTW, they all use 4K as their basic unit, but might support
> > extensions to operation on multiples of that (negotiated either via a
> > specific error return and fallback or via the use of XENFEAT).
> 
> Yes, I completely agree that the current Xen interface is based on 4KB
> chunks. What I'm trying to say is that the approach taken, which is
> "let's not modify Xen" puts all the burden on the guest and it is going
> to hurt us in the long run.
> 
> Are we expecting all guests that want to use 64KB page to implement all
> the modifications that are needed? IMHO, those modifications are very
> far from trivial, and we are putting the bar for Xen guest support very
> high, and that is wrong. We are already struggling to have a decent set
> of PV drivers on guests different than Linux, and this is certainly not
> making things easier.

I think you are underestimating the impact/burden of not having a common
lowest common denominator interface which all front and backends should be
expected to provide in order to interact successfully with each other at a
basic level.

With your approach of requiring a 64KB guest to use native 64K interfaces
only you end up with guests containing front and backends which simply
cannot communicate at all because they do not have a common denominator or
a combinatorial explosion of guests supporting different sets of mutually
incompatible interfaces with no common ground.

I think that fragmentation is a far worse danger than of developers being
unwilling or unable to provide helpers which iterate over pages in whatever
size the guest happens to have (either larger granule or superpages) and
performing however many of whatever ops size has been negotiated with the
peer.

I'm also not convinced that Julien's patches are any less trivial than the
equivalent code to select the correct operations based on the kernels page
size without breaking them up, the developer still needs to be aware of the
4K vs large distinction if they want to support larger than 4K pages.

Developers can still choose to only support 4K pages in their OS, if they
feel this scheme of supporting larger pages is too intrusive or hard I
doubt they are going to want to implement a scheme based on an alternative
large-page protocol either.

> Do KVM guests also need such extensive set of modifications in order to
> run using 64KB pages? I know it's not fair to compare KVM and Xen in
> this regard, because the interfaces are very different, but that's what
> developers are going to look at.

I'm not sure that virtio cares about pages at all, just addresses which
have no particular alignment or granularity constraints, since they don't
have grant tables nor any requirement to mediate accesses to guest memory
by the host at any granularity at all.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Ian Campbell]

On Tue, 2015-10-06 at 11:28 +0200, Roger Pau Monné wrote:
> El 22/09/15 a les 12.59, Ian Campbell ha escrit:
> > On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> > > I'm not saying that we shouldn't take those patches, I'm just saying
> > > that IMHO this is a workaround, and I would like to see a plan and
> > > somebody committed to have it fixed in a proper way, by introducing a
> > > 64KB PV block protocol.
> > 
> > In my view the basic unit of operation for all Xen interfaces (on x86
> > and
> > arm at least[0]) is 4K. The peer at either end of a PV protocol should
> > therefore be entitled to assume that at a minimum the other end
> > supports
> > operation in 4K mode (i.e. 4K is the baseline).
> > 
> > Operations in larger sizes (which would necessarily be multiples of 4K)
> > are
> > then an extension which is subject to a negotiation between the two
> > ends,
> > it doesn't really matter if those larger sizes arise because of the use
> > of
> > superpages or because the guest is internally using some larger basic
> > page
> > size (which ARM calls a "granule", and where 64K comes from here).
> > 
> > I think this line of reasoning applies just as strongly to the
> > hypercall
> > ABI as well BTW, they all use 4K as their basic unit, but might support
> > extensions to operation on multiples of that (negotiated either via a
> > specific error return and fallback or via the use of XENFEAT).
> 
> Yes, I completely agree that the current Xen interface is based on 4KB
> chunks. What I'm trying to say is that the approach taken, which is
> "let's not modify Xen" puts all the burden on the guest and it is going
> to hurt us in the long run.
> 
> Are we expecting all guests that want to use 64KB page to implement all
> the modifications that are needed? IMHO, those modifications are very
> far from trivial, and we are putting the bar for Xen guest support very
> high, and that is wrong. We are already struggling to have a decent set
> of PV drivers on guests different than Linux, and this is certainly not
> making things easier.

I think you are underestimating the impact/burden of not having a common
lowest common denominator interface which all front and backends should be
expected to provide in order to interact successfully with each other at a
basic level.

With your approach of requiring a 64KB guest to use native 64K interfaces
only you end up with guests containing front and backends which simply
cannot communicate at all because they do not have a common denominator or
a combinatorial explosion of guests supporting different sets of mutually
incompatible interfaces with no common ground.

I think that fragmentation is a far worse danger than of developers being
unwilling or unable to provide helpers which iterate over pages in whatever
size the guest happens to have (either larger granule or superpages) and
performing however many of whatever ops size has been negotiated with the
peer.

I'm also not convinced that Julien's patches are any less trivial than the
equivalent code to select the correct operations based on the kernels page
size without breaking them up, the developer still needs to be aware of the
4K vs large distinction if they want to support larger than 4K pages.

Developers can still choose to only support 4K pages in their OS, if they
feel this scheme of supporting larger pages is too intrusive or hard I
doubt they are going to want to implement a scheme based on an alternative
large-page protocol either.

> Do KVM guests also need such extensive set of modifications in order to
> run using 64KB pages? I know it's not fair to compare KVM and Xen in
> this regard, because the interfaces are very different, but that's what
> developers are going to look at.

I'm not sure that virtio cares about pages at all, just addresses which
have no particular alignment or granularity constraints, since they don't
have grant tables nor any requirement to mediate accesses to guest memory
by the host at any granularity at all.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Ian Campbell]

Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Previously I attempted to resolve this by creating a shared location
for such things but we have been unable to come to a consensus on
where that should be.

Instead this patch simply replaces the use of ../../ in the dts
/include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
file arch/arm/boot/dts.

Since the split device tree repo will shortly be required to flatten
symlinks for other reasons this will cause the dtsi file to appear in
both src/arm and src/arm64 in the split repo, which is an improvement
on not building for arm64 now.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Kristina Martsenko 
Cc: Kevin Hilman 
Cc: Frank Rowand 
Cc: Olof Johansson 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: a...@kernel.org
Cc: linux-kbu...@vger.kernel.org
---
For more on flattening symlinks see
http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742
---
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi

diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts 
b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
index 5b1d018..bb3c26d 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
@@ -186,6 +186,6 @@
<0 0 41  GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42  GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 
-   /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi"
+   /include/ "vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi 
b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
new file mode 12
index 000..68fd0f8
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi
\ No newline at end of file
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Ian Campbell]

Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Previously I attempted to resolve this by creating a shared location
for such things but we have been unable to come to a consensus on
where that should be.

Instead this patch simply replaces the use of ../../ in the dts
/include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
file arch/arm/boot/dts.

Since the split device tree repo will shortly be required to flatten
symlinks for other reasons this will cause the dtsi file to appear in
both src/arm and src/arm64 in the split repo, which is an improvement
on not building for arm64 now.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Cc: Rob Herring <robh...@kernel.org>
Cc: Pawel Moll <pawel.m...@arm.com>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Kumar Gala <ga...@codeaurora.org>
Cc: Liviu Dudau <liviu.du...@arm.com>
Cc: Sudeep Holla <sudeep.ho...@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
Cc: Russell King <li...@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Will Deacon <will.dea...@arm.com>
Cc: Kristina Martsenko <kristina.martse...@arm.com>
Cc: Kevin Hilman <khil...@linaro.org>
Cc: Frank Rowand <frank.row...@sonymobile.com>
Cc: Olof Johansson <o...@lixom.net>
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: a...@kernel.org
Cc: linux-kbu...@vger.kernel.org
---
For more on flattening symlinks see
http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742
---
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi

diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts 
b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
index 5b1d018..bb3c26d 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
@@ -186,6 +186,6 @@
<0 0 41  GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42  GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 
-   /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi"
+   /include/ "vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi 
b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
new file mode 12
index 000..68fd0f8
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi
\ No newline at end of file
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Ian Campbell]

On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> I'm not saying that we shouldn't take those patches, I'm just saying
> that IMHO this is a workaround, and I would like to see a plan and
> somebody committed to have it fixed in a proper way, by introducing a
> 64KB PV block protocol.

In my view the basic unit of operation for all Xen interfaces (on x86 and
arm at least[0]) is 4K. The peer at either end of a PV protocol should
therefore be entitled to assume that at a minimum the other end supports
operation in 4K mode (i.e. 4K is the baseline).

Operations in larger sizes (which would necessarily be multiples of 4K) are
then an extension which is subject to a negotiation between the two ends,
it doesn't really matter if those larger sizes arise because of the use of
superpages or because the guest is internally using some larger basic page
size (which ARM calls a "granule", and where 64K comes from here).

I think this line of reasoning applies just as strongly to the hypercall
ABI as well BTW, they all use 4K as their basic unit, but might support
extensions to operation on multiples of that (negotiated either via a
specific error return and fallback or via the use of XENFEAT).

Ian.

[0] It's not implausible that some other architecture may exsit which
doesn't use 4K as the basic page szie)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Ian Campbell]

On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> I'm not saying that we shouldn't take those patches, I'm just saying
> that IMHO this is a workaround, and I would like to see a plan and
> somebody committed to have it fixed in a proper way, by introducing a
> 64KB PV block protocol.

In my view the basic unit of operation for all Xen interfaces (on x86 and
arm at least[0]) is 4K. The peer at either end of a PV protocol should
therefore be entitled to assume that at a minimum the other end supports
operation in 4K mode (i.e. 4K is the baseline).

Operations in larger sizes (which would necessarily be multiples of 4K) are
then an extension which is subject to a negotiation between the two ends,
it doesn't really matter if those larger sizes arise because of the use of
superpages or because the guest is internally using some larger basic page
size (which ARM calls a "granule", and where 64K comes from here).

I think this line of reasoning applies just as strongly to the hypercall
ABI as well BTW, they all use 4K as their basic unit, but might support
extensions to operation on multiples of that (negotiated either via a
specific error return and fallback or via the use of XENFEAT).

Ian.

[0] It's not implausible that some other architecture may exsit which
doesn't use 4K as the basic page szie)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Hi Olof,

On Mon, 2015-08-24 at 15:22 -0700, Olof Johansson wrote:

A little while ago you were trying to explain the scheme you would like to
see on IRC but my thick skull was getting in the way :-/ Then you had to
run...

So, ping?

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Hi Olof,

On Mon, 2015-08-24 at 15:22 -0700, Olof Johansson wrote:

A little while ago you were trying to explain the scheme you would like to
see on IRC but my thick skull was getting in the way :-/ Then you had to
run...

So, ping?

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Ian Campbell]

On Fri, 2015-09-11 at 15:45 +0100, Julien Grall wrote:
> On 11/09/15 15:29, Ian Campbell wrote:
> > On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
> > > When Xen is copyin data to/from the guest it will check if the kernel
> > 
> > "copying"
> > 
> > > has the right to do the access. If not, the hypercall will return an
> > > error.
> > > 
> > > After the commit a5e090acbf545c0a3b04080f8a488b17ec41fe02 "ARM:
> > > software-based priviledged-no-access support", the kernel can't
> > > access
> > 
> > "privileged"
> > 
> > > anymore the user space by default. This will result to fail on every
> > 
> > "any more" (or "any longer")
> > 
> > > hypercall made by the userspace (i.e via privcmd).
> > > 
> > > We have to enable the userspace access and then restore the correct
> > > permission everytime the privmcd is used to made an hypercall.
> > 
> > "every time" and "privcmd"
> > 
> > >  HYPERCALL1(tmem_op);
> > >  HYPERCALL2(multicall);
> > >  
> > > -ENTRY(privcmd_call)
> > > +ENTRY(__privcmd_call)
> > 
> > arch/arm/include/asm/assembler.h seems to contain uaccess_* macros
> > which
> > could be used right here directly I think? That would be preferable to
> > wrapping I think.
> 
> Looking to the uaccess_save macro:

I was thinking more about uaccess_enable/disable.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Ian Campbell]

On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
> When Xen is copyin data to/from the guest it will check if the kernel

"copying"

> has the right to do the access. If not, the hypercall will return an
> error.
> 
> After the commit a5e090acbf545c0a3b04080f8a488b17ec41fe02 "ARM:
> software-based priviledged-no-access support", the kernel can't access

"privileged"

> anymore the user space by default. This will result to fail on every

"any more" (or "any longer")

> hypercall made by the userspace (i.e via privcmd).
> 
> We have to enable the userspace access and then restore the correct
> permission everytime the privmcd is used to made an hypercall.

"every time" and "privcmd"

>  HYPERCALL1(tmem_op);
>  HYPERCALL2(multicall);
>  
> -ENTRY(privcmd_call)
> +ENTRY(__privcmd_call)

arch/arm/include/asm/assembler.h seems to contain uaccess_* macros which
could be used right here directly I think? That would be preferable to
wrapping I think.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ian Campbell]

On Thu, 2015-09-10 at 17:10 +0100, Stefano Stabellini wrote:

> > C) When you could go:
> > 
> >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI
> > discovery
> 
> I take you mean discovering Xen with the usual Xen hypervisor node on
> device tree.

There may be other options, such as ARM defining an architectural mechanism
to do early detection of hypervisors e.g. by defining some bit in some
hypervisor controllable register (MPIDR?) to say "a hypervisor is present"
and defining an hvc or smc call which can be used to ask which one it is.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Ian Campbell]

On Thu, 2015-09-10 at 17:23 +0100, Julien Grall wrote:
> I applied the two patches on top of linus/master and I'm able to boot
> correctly on X-gene. Thank you!

Perhaps we should replicate this approach in Xen and get rid of
 PLATFORM_QUIRK_GIC_64K_STRIDE?

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ian Campbell]

On Thu, 2015-09-10 at 17:10 +0100, Stefano Stabellini wrote:

> > C) When you could go:
> > 
> >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI
> > discovery
> 
> I take you mean discovering Xen with the usual Xen hypervisor node on
> device tree.

There may be other options, such as ARM defining an architectural mechanism
to do early detection of hypervisors e.g. by defining some bit in some
hypervisor controllable register (MPIDR?) to say "a hypervisor is present"
and defining an hvc or smc call which can be used to ask which one it is.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1

[Ian Campbell]

On Thu, 2015-09-10 at 17:23 +0100, Julien Grall wrote:
> I applied the two patches on top of linus/master and I'm able to boot
> correctly on X-gene. Thank you!

Perhaps we should replicate this approach in Xen and get rid of
 PLATFORM_QUIRK_GIC_64K_STRIDE?

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Ian Campbell]

On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
> When Xen is copyin data to/from the guest it will check if the kernel

"copying"

> has the right to do the access. If not, the hypercall will return an
> error.
> 
> After the commit a5e090acbf545c0a3b04080f8a488b17ec41fe02 "ARM:
> software-based priviledged-no-access support", the kernel can't access

"privileged"

> anymore the user space by default. This will result to fail on every

"any more" (or "any longer")

> hypercall made by the userspace (i.e via privcmd).
> 
> We have to enable the userspace access and then restore the correct
> permission everytime the privmcd is used to made an hypercall.

"every time" and "privcmd"

>  HYPERCALL1(tmem_op);
>  HYPERCALL2(multicall);
>  
> -ENTRY(privcmd_call)
> +ENTRY(__privcmd_call)

arch/arm/include/asm/assembler.h seems to contain uaccess_* macros which
could be used right here directly I think? That would be preferable to
wrapping I think.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm/xen: Enable user access to the kernel before issuing a privcmd call

[Ian Campbell]

On Fri, 2015-09-11 at 15:45 +0100, Julien Grall wrote:
> On 11/09/15 15:29, Ian Campbell wrote:
> > On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
> > > When Xen is copyin data to/from the guest it will check if the kernel
> > 
> > "copying"
> > 
> > > has the right to do the access. If not, the hypercall will return an
> > > error.
> > > 
> > > After the commit a5e090acbf545c0a3b04080f8a488b17ec41fe02 "ARM:
> > > software-based priviledged-no-access support", the kernel can't
> > > access
> > 
> > "privileged"
> > 
> > > anymore the user space by default. This will result to fail on every
> > 
> > "any more" (or "any longer")
> > 
> > > hypercall made by the userspace (i.e via privcmd).
> > > 
> > > We have to enable the userspace access and then restore the correct
> > > permission everytime the privmcd is used to made an hypercall.
> > 
> > "every time" and "privcmd"
> > 
> > >  HYPERCALL1(tmem_op);
> > >  HYPERCALL2(multicall);
> > >  
> > > -ENTRY(privcmd_call)
> > > +ENTRY(__privcmd_call)
> > 
> > arch/arm/include/asm/assembler.h seems to contain uaccess_* macros
> > which
> > could be used right here directly I think? That would be preferable to
> > wrapping I think.
> 
> Looking to the uaccess_save macro:

I was thinking more about uaccess_enable/disable.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ian Campbell]

On Thu, 2015-09-10 at 07:08 -0600, Jan Beulich wrote:
> > > > On 10.09.15 at 14:58,  wrote:
> > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:
> > 
> > > > In any case this should be separate from the shim ABI discussion.
> > > 
> > > I disagree; I think this is very much relevant to the ABI discussion.
> > > That's not to say that I insist on a particular approach, but I think
> > > that they need to be considered together.
> > 
> > Taking a step back, the reason for using the EFI stub parameters is
> > only
> > (AFAIK) in order to be able to locate the ACPI RDSP (the root table
> > pointer), which as it happens is normally passed via one of the EFI
> > firmware tables.
> > 
> > If there was a way to achieve that goal (i.e. another way to find the
> > RSDP)
> > without opening the can of UEFI worms then we could consider that
> > opiton
> > too.
> > 
> > a way != the legacy x86 thing of scanning low memory of the signature,
> > of
> > course.
> 
> But even x86 doesn't do that (other than as a fallback) on EFI.

Indeed, I was referring legacy (non-EFI) mode.

>  The
> configuration table is available to Dom0 (via XENPF_firmware_info:
> XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE).

Under ARM we find out we are running under Xen from the ACPI tables, so
there is a chicken and egg situation there.

Not insoluble I'm sure, if we want to go down this route.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ian Campbell]

On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:

> > In any case this should be separate from the shim ABI discussion.
> 
> I disagree; I think this is very much relevant to the ABI discussion.
> That's not to say that I insist on a particular approach, but I think
> that they need to be considered together.

Taking a step back, the reason for using the EFI stub parameters is only
(AFAIK) in order to be able to locate the ACPI RDSP (the root table
pointer), which as it happens is normally passed via one of the EFI
firmware tables.

If there was a way to achieve that goal (i.e. another way to find the RSDP)
without opening the can of UEFI worms then we could consider that opiton
too.

a way != the legacy x86 thing of scanning low memory of the signature, of
course.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ian Campbell]

On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:

> > In any case this should be separate from the shim ABI discussion.
> 
> I disagree; I think this is very much relevant to the ABI discussion.
> That's not to say that I insist on a particular approach, but I think
> that they need to be considered together.

Taking a step back, the reason for using the EFI stub parameters is only
(AFAIK) in order to be able to locate the ACPI RDSP (the root table
pointer), which as it happens is normally passed via one of the EFI
firmware tables.

If there was a way to achieve that goal (i.e. another way to find the RSDP)
without opening the can of UEFI worms then we could consider that opiton
too.

a way != the legacy x86 thing of scanning low memory of the signature, of
course.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

[Ian Campbell]

On Thu, 2015-09-10 at 07:08 -0600, Jan Beulich wrote:
> > > > On 10.09.15 at 14:58,  wrote:
> > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:
> > 
> > > > In any case this should be separate from the shim ABI discussion.
> > > 
> > > I disagree; I think this is very much relevant to the ABI discussion.
> > > That's not to say that I insist on a particular approach, but I think
> > > that they need to be considered together.
> > 
> > Taking a step back, the reason for using the EFI stub parameters is
> > only
> > (AFAIK) in order to be able to locate the ACPI RDSP (the root table
> > pointer), which as it happens is normally passed via one of the EFI
> > firmware tables.
> > 
> > If there was a way to achieve that goal (i.e. another way to find the
> > RSDP)
> > without opening the can of UEFI worms then we could consider that
> > opiton
> > too.
> > 
> > a way != the legacy x86 thing of scanning low memory of the signature,
> > of
> > course.
> 
> But even x86 doesn't do that (other than as a fallback) on EFI.

Indeed, I was referring legacy (non-EFI) mode.

>  The
> configuration table is available to Dom0 (via XENPF_firmware_info:
> XEN_FW_EFI_INFO:XEN_FW_EFI_CONFIG_TABLE).

Under ARM we find out we are running under Xen from the ACPI tables, so
there is a chicken and egg situation there.

Not insoluble I'm sure, if we want to go down this route.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Mon, 2015-08-24 at 15:22 -0700, Olof Johansson wrote:
> Hi,
> 
> On Mon, Aug 24, 2015 at 1:58 PM, Rob Herring  
> wrote:
> > On Sun, Aug 23, 2015 at 6:52 PM, Olof Johansson  wrote:
> > > On Sun, Aug 23, 2015 at 4:42 PM, Rob Herring  
> > > wrote:
> > > > On Sun, Aug 23, 2015 at 6:13 PM, Olof Johansson  
> > > > wrote:
> > > > > 
> > > Right now it's not possible to do even per-arch "all-dtbs" since only
> > > the currently configured platforms will get their dtbs compiled.
> > 
> > I know. It's been on my todo list for a while. Having that per arch at
> > least would be an improvement. Having it arch independent would mean I
> > don't even need a cross-compiler (probably).
> 
> Yeah, seems like something that should work quite well in the scope of
> Ian's tree if nothing else.

In the split tree "make all -k" will already build every dtb (and always
has done), in fact this is how I discovered the breakage which I'm trying
to address with this patch since the daily cronjob which does the
conversion runs this.

> Something like lib/ seems more appropriate. Or drivers/..., but I
> suspect that could cause further confusion on the expected separation
> of binding/hardware description and the consuming drivers.

I'm quite happy to rework the patch with whatever path is settled upon.

Or if someone has an alternative suggestion for how to fix the build in the
split devicetree git tree I'm happy to give that a go too.

> > > > We could also see sharing between PPC and ARM on FSL networking 
> > > > parts,
> > > > but I've not heard if they actually have that problem.
> > > 
> > > Yeah, there could potentially be some sharing between MIPS and
> > > ARM{,64} too, but I don't know if we'll actually see it done.
> > 
> > Yep, hard to say.
> > 
> > Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Mon, 2015-08-24 at 15:22 -0700, Olof Johansson wrote:
> Hi,
> 
> On Mon, Aug 24, 2015 at 1:58 PM, Rob Herring  
> wrote:
> > On Sun, Aug 23, 2015 at 6:52 PM, Olof Johansson  wrote:
> > > On Sun, Aug 23, 2015 at 4:42 PM, Rob Herring  
> > > wrote:
> > > > On Sun, Aug 23, 2015 at 6:13 PM, Olof Johansson  
> > > > wrote:
> > > > > 
> > > Right now it's not possible to do even per-arch "all-dtbs" since only
> > > the currently configured platforms will get their dtbs compiled.
> > 
> > I know. It's been on my todo list for a while. Having that per arch at
> > least would be an improvement. Having it arch independent would mean I
> > don't even need a cross-compiler (probably).
> 
> Yeah, seems like something that should work quite well in the scope of
> Ian's tree if nothing else.

In the split tree "make all -k" will already build every dtb (and always
has done), in fact this is how I discovered the breakage which I'm trying
to address with this patch since the daily cronjob which does the
conversion runs this.

> Something like lib/ seems more appropriate. Or drivers/..., but I
> suspect that could cause further confusion on the expected separation
> of binding/hardware description and the consuming drivers.

I'm quite happy to rework the patch with whatever path is settled upon.

Or if someone has an alternative suggestion for how to fix the build in the
split devicetree git tree I'm happy to give that a go too.

> > > > We could also see sharing between PPC and ARM on FSL networking 
> > > > parts,
> > > > but I've not heard if they actually have that problem.
> > > 
> > > Yeah, there could potentially be some sharing between MIPS and
> > > ARM{,64} too, but I don't know if we'll actually see it done.
> > 
> > Yep, hard to say.
> > 
> > Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Fri, 2015-08-14 at 16:21 -0500, Rob Herring wrote:
> +arm-soc

I could've sworn I did the same at one point. Obviously not.

> 
> On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell <
> ian.campb...@citrix.com> wrote:
> > On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
> > > Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM
> > > -A53x2 on
> > > LogicTile Express 20MG") added a new dts file to arch/arm64 which
> > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > > .dtsi supplied by arch/arm.
> > > 
> > > Unfortunately this causes some issues for the split device tree
> > > repository[0], since things get moved around there. In that 
> > > context
> > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7
> > > -ca53x2.dts
> > > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > 
> > Hi Grant,
> > 
> > Do you think there is any chance of getting this into 4.2-rc$NEXT 
> > or shall
> > we wait until 4.3? I'm assuming this should go via the DT tree, but 
> > maybe
> > it should go via an ARM tree?
> 
> I was assuming this would go thru the arm-soc tree which is why I
> acked it. It is getting a bit late for 4.2 at this point, but I guess
> the standalone tree remains broken for these platforms until this is
> done.

Correct.

>  Probably not such a big deal in grand scheme of things.

I guess not. FWIW I've not pushed since the breakage started happening,
so the split tree isn't broken, but it's also now however many weeks
behind. Once 4.3-rc1 arrives with this fixed I'll push all the 4.2-rcN
and 4.2 as well.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Fri, 2015-08-14 at 16:21 -0500, Rob Herring wrote:
 +arm-soc

I could've sworn I did the same at one point. Obviously not.

 
 On Tue, Aug 11, 2015 at 5:07 AM, Ian Campbell 
 ian.campb...@citrix.com wrote:
  On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
   Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM
   -A53x2 on
   LogicTile Express 20MG) added a new dts file to arch/arm64 which
   included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
   .dtsi supplied by arch/arm.
   
   Unfortunately this causes some issues for the split device tree
   repository[0], since things get moved around there. In that 
   context
   the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7
   -ca53x2.dts
   while the include is at src/arm/vexpress-v2m-rs1.dtsi.
  
  Hi Grant,
  
  Do you think there is any chance of getting this into 4.2-rc$NEXT 
  or shall
  we wait until 4.3? I'm assuming this should go via the DT tree, but 
  maybe
  it should go via an ARM tree?
 
 I was assuming this would go thru the arm-soc tree which is why I
 acked it. It is getting a bit late for 4.2 at this point, but I guess
 the standalone tree remains broken for these platforms until this is
 done.

Correct.

  Probably not such a big deal in grand scheme of things.

I guess not. FWIW I've not pushed since the breakage started happening,
so the split tree isn't broken, but it's also now however many weeks
behind. Once 4.3-rc1 arrives with this fixed I'll push all the 4.2-rcN
and 4.2 as well.

Ian.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
> Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
> LogicTile Express 20MG") added a new dts file to arch/arm64 which
> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> .dtsi supplied by arch/arm.
> 
> Unfortunately this causes some issues for the split device tree
> repository[0], since things get moved around there. In that context
> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> while the include is at src/arm/vexpress-v2m-rs1.dtsi.

Hi Grant,

Do you think there is any chance of getting this into 4.2-rc$NEXT or shall
we wait until 4.3? I'm assuming this should go via the DT tree, but maybe
it should go via an ARM tree?

Ian.

> 
> The sharing of the .dtsi is legitimate since the baseboard is the same
> for various vexpress systems whatever processor they use.
> 
> Rather than using ../../ tricks to pickup .dtsi files from another
> arch this patch creates a new directory kernel/dts as a home for such
> cross-arch .dtsi files and arranges for it to be in the include path
> for both dtc and cpp. The dtsi file itself is moved into a vendor
> subdir in this case "arm" (the vendor, not the ARCH=).
> 
> [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree
> -rebasing.git/
> 
> Signed-off-by: Ian Campbell 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Kumar Gala 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Kristina Martsenko 
> Cc: Kevin Hilman 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kbu...@vger.kernel.org
> Acked-by: Mark Rutland 
> Acked-by: Rob Herring 
> Acked-by: Liviu Dudau 
> Reviewed-by: Masahiro Yamada 
> ---
> v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
> 
> v3: Move to kernel/dts.
> Include new directory in DTC include path as well as cpp path, and
> therefore switch back to /include/.
> Update MAINTAINERS
> 
> v4: Change path in changelog too.
> Add ()s to title of 9ccd608070b6.
> 
> v5: Remove stale reference to switching from /include/ to #include.
> ---
>  Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
>  MAINTAINERS | 1 +
>  arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
>  arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
>  arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
>  arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
>  {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
>  scripts/Makefile.lib| 3 ++-
>  8 files changed, 8 insertions(+), 6 deletions(-)
>  rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi 
> (100%)
> 
> diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
> b/Documentation/devicetree/bindings/arm/vexpress.txt
> index 39844cd..b6031d9 100644
> --- a/Documentation/devicetree/bindings/arm/vexpress.txt
> +++ b/Documentation/devicetree/bindings/arm/vexpress.txt
> @@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
>   /* Active high IRQ 0 is connected to GIC's SPI0 */
>   interrupt-map = <0 0 0  0 0 4>;
>  
> - /include/ "vexpress-v2m-rs1.dtsi"
> + /include/ "arm/vexpress-v2m-rs1.dtsi"
>   };
>  };
>  
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a226416..1941078 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7537,6 +7537,7 @@ S:  Maintained
>  F:   Documentation/devicetree/
>  F:   arch/*/boot/dts/
>  F:   include/dt-bindings/
> +F:   kernel/dts/
>  
>  OPEN FIRMWARE AND DEVICE TREE OVERLAYS
>  M:   Pantelis Antoniou 
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
> b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> index 9420053..b144092 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
> @@ -278,6 +278,6 @@
>   <0 0 41  0 41 4>,
>   <0 0 42  0 42 4>;
>  
> - /include/ "vexpress-v2m-rs1.dtsi"
> + /include/ "arm/vexpress-v2m-rs1.dtsi"
>   };
>  };
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
> b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index 17f63f7..350f402 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
&g

Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Tue, 2015-08-11 at 13:00 +0900, Masahiro Yamada wrote:
> Hi
> 
> 2015-08-04 1:06 GMT+09:00 Ian Campbell :
> > Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG") added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> > 
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > 
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> > 
> > Rather than using ../../ tricks to pickup .dtsi files from another
> > arch this patch creates a new directory kernel/dts as a home for such
> > cross-arch .dtsi files and arranges for it to be in the include path
> > for both dtc and cpp. The dtsi file itself is moved into a vendor
> > subdir in this case "arm" (the vendor, not the ARCH=).
> 
> 
> Question:
> If this patch is applied, which directory will be created in
> device-tree-rebasing?
> src/kernel/, src/common/, or something else?
> Either will do, of course.

Below is the patch against the device-tree-rebasing.git, I went (pretty
much arbitrarily) with common at the top level.

commit 0524b00e5bd7b98a2a9ef85c1f5f2a8d93bcbeb6
Author: Ian Campbell 
Date:   Tue Jul 21 17:27:13 2015 +0100

Handle new kernel/dts subtree.

Rewrite its contents to common/ and include in the CPP and DTC include
paths.

Signed-off-by: Ian Campbell 

diff --git a/Makefile b/Makefile
index 5e8930c..b57107d 100644
--- a/Makefile
+++ b/Makefile
@@ -114,12 +114,13 @@ dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc  \
  -Iinclude -I$(src) -Itestcase-data\
+ -Icommon  \
  -undef -D__DTS__
 
 quiet_cmd_dtc = DTC $@
 cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
 $(DTC) -O dtb -o $@ -b 0 \
--i $(src) $(DTC_FLAGS) \
+-i $(src) -i common $(DTC_FLAGS) \
 -d $(depfile).dtc.tmp $(dtc-tmp) ; \
 cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
 
diff --git a/scripts/rewrite-paths.sed b/scripts/rewrite-paths.sed
index b73fbce..5269769 100644
--- a/scripts/rewrite-paths.sed
+++ b/scripts/rewrite-paths.sed
@@ -33,6 +33,7 @@ s,\tarch/\([^/]*\)/boot/dts/\(.*\.h\)$,\tsrc/\1/\2,gp
 # Also rewrite the DTS include paths for dtc+cpp support
 s,\tarch/\([^/]*\)/include/dts/,\tsrc/\1/include/,gp
 s,\tinclude/dt-bindings/,\tinclude/dt-bindings/,gp
+s,\tkernel/dts/,\tcommon/,gp
 
 # Rewrite the bindings subdirectory
 s,\tDocumentation/devicetree/bindings/,\tBindings/,gp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Mon, 2015-08-03 at 17:06 +0100, Ian Campbell wrote:
 Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
 LogicTile Express 20MG) added a new dts file to arch/arm64 which
 included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
 .dtsi supplied by arch/arm.
 
 Unfortunately this causes some issues for the split device tree
 repository[0], since things get moved around there. In that context
 the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
 while the include is at src/arm/vexpress-v2m-rs1.dtsi.

Hi Grant,

Do you think there is any chance of getting this into 4.2-rc$NEXT or shall
we wait until 4.3? I'm assuming this should go via the DT tree, but maybe
it should go via an ARM tree?

Ian.

 
 The sharing of the .dtsi is legitimate since the baseboard is the same
 for various vexpress systems whatever processor they use.
 
 Rather than using ../../ tricks to pickup .dtsi files from another
 arch this patch creates a new directory kernel/dts as a home for such
 cross-arch .dtsi files and arranges for it to be in the include path
 for both dtc and cpp. The dtsi file itself is moved into a vendor
 subdir in this case arm (the vendor, not the ARCH=).
 
 [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree
 -rebasing.git/
 
 Signed-off-by: Ian Campbell ian.campb...@citrix.com
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Kumar Gala ga...@codeaurora.org
 Cc: Liviu Dudau liviu.du...@arm.com
 Cc: Sudeep Holla sudeep.ho...@arm.com
 Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 Cc: Catalin Marinas catalin.mari...@arm.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Kristina Martsenko kristina.martse...@arm.com
 Cc: Kevin Hilman khil...@linaro.org
 Cc: devicet...@vger.kernel.org
 Cc: linux-kernel@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-kbu...@vger.kernel.org
 Acked-by: Mark Rutland mark.rutl...@arm.com
 Acked-by: Rob Herring r...@kernel.org
 Acked-by: Liviu Dudau liviu.du...@arm.com
 Reviewed-by: Masahiro Yamada yamada.masah...@socionext.com
 ---
 v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
 
 v3: Move to kernel/dts.
 Include new directory in DTC include path as well as cpp path, and
 therefore switch back to /include/.
 Update MAINTAINERS
 
 v4: Change path in changelog too.
 Add ()s to title of 9ccd608070b6.
 
 v5: Remove stale reference to switching from /include/ to #include.
 ---
  Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
  MAINTAINERS | 1 +
  arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
  arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
  arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
  arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
  {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
  scripts/Makefile.lib| 3 ++-
  8 files changed, 8 insertions(+), 6 deletions(-)
  rename {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi 
 (100%)
 
 diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
 b/Documentation/devicetree/bindings/arm/vexpress.txt
 index 39844cd..b6031d9 100644
 --- a/Documentation/devicetree/bindings/arm/vexpress.txt
 +++ b/Documentation/devicetree/bindings/arm/vexpress.txt
 @@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
   /* Active high IRQ 0 is connected to GIC's SPI0 */
   interrupt-map = 0 0 0 gic 0 0 4;
  
 - /include/ vexpress-v2m-rs1.dtsi
 + /include/ arm/vexpress-v2m-rs1.dtsi
   };
  };
  
 diff --git a/MAINTAINERS b/MAINTAINERS
 index a226416..1941078 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -7537,6 +7537,7 @@ S:  Maintained
  F:   Documentation/devicetree/
  F:   arch/*/boot/dts/
  F:   include/dt-bindings/
 +F:   kernel/dts/
  
  OPEN FIRMWARE AND DEVICE TREE OVERLAYS
  M:   Pantelis Antoniou pantelis.anton...@konsulko.com
 diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
 b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
 index 9420053..b144092 100644
 --- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
 +++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
 @@ -278,6 +278,6 @@
   0 0 41 gic 0 41 4,
   0 0 42 gic 0 42 4;
  
 - /include/ vexpress-v2m-rs1.dtsi
 + /include/ arm/vexpress-v2m-rs1.dtsi
   };
  };
 diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
 b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
 index 17f63f7..350f402 100644
 --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
 +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
 @@ -636,6 +636,6 @@
   0 0 41 gic 0 41 4,
   0 0 42 gic 0 42 4

Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Tue, 2015-08-11 at 13:00 +0900, Masahiro Yamada wrote:
 Hi
 
 2015-08-04 1:06 GMT+09:00 Ian Campbell ian.campb...@citrix.com:
  Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
  LogicTile Express 20MG) added a new dts file to arch/arm64 which
  included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
  .dtsi supplied by arch/arm.
  
  Unfortunately this causes some issues for the split device tree
  repository[0], since things get moved around there. In that context
  the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
  while the include is at src/arm/vexpress-v2m-rs1.dtsi.
  
  The sharing of the .dtsi is legitimate since the baseboard is the same
  for various vexpress systems whatever processor they use.
  
  Rather than using ../../ tricks to pickup .dtsi files from another
  arch this patch creates a new directory kernel/dts as a home for such
  cross-arch .dtsi files and arranges for it to be in the include path
  for both dtc and cpp. The dtsi file itself is moved into a vendor
  subdir in this case arm (the vendor, not the ARCH=).
 
 
 Question:
 If this patch is applied, which directory will be created in
 device-tree-rebasing?
 src/kernel/, src/common/, or something else?
 Either will do, of course.

Below is the patch against the device-tree-rebasing.git, I went (pretty
much arbitrarily) with common at the top level.

commit 0524b00e5bd7b98a2a9ef85c1f5f2a8d93bcbeb6
Author: Ian Campbell ian.campb...@citrix.com
Date:   Tue Jul 21 17:27:13 2015 +0100

Handle new kernel/dts subtree.

Rewrite its contents to common/ and include in the CPP and DTC include
paths.

Signed-off-by: Ian Campbell ian.campb...@citrix.com

diff --git a/Makefile b/Makefile
index 5e8930c..b57107d 100644
--- a/Makefile
+++ b/Makefile
@@ -114,12 +114,13 @@ dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc  \
  -Iinclude -I$(src) -Itestcase-data\
+ -Icommon  \
  -undef -D__DTS__
 
 quiet_cmd_dtc = DTC $@
 cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $ ; \
 $(DTC) -O dtb -o $@ -b 0 \
--i $(src) $(DTC_FLAGS) \
+-i $(src) -i common $(DTC_FLAGS) \
 -d $(depfile).dtc.tmp $(dtc-tmp) ; \
 cat $(depfile).pre.tmp $(depfile).dtc.tmp  $(depfile)
 
diff --git a/scripts/rewrite-paths.sed b/scripts/rewrite-paths.sed
index b73fbce..5269769 100644
--- a/scripts/rewrite-paths.sed
+++ b/scripts/rewrite-paths.sed
@@ -33,6 +33,7 @@ s,\tarch/\([^/]*\)/boot/dts/\(.*\.h\)$,\tsrc/\1/\2,gp
 # Also rewrite the DTS include paths for dtc+cpp support
 s,\tarch/\([^/]*\)/include/dts/,\tsrc/\1/include/,gp
 s,\tinclude/dt-bindings/,\tinclude/dt-bindings/,gp
+s,\tkernel/dts/,\tcommon/,gp
 
 # Rewrite the bindings subdirectory
 s,\tDocumentation/devicetree/bindings/,\tBindings/,gp

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] printk from softirq on xen: hard lockup

[Ian Campbell]

On Tue, 2015-08-04 at 18:12 +0100, David Vrabel wrote:
> On 04/08/15 17:41, Jason A. Donenfeld wrote:
> > Hi folks,
> > 
> > Paul McKenney and I had an offline discussion about some rcu questions
> > that eventually lead into me investigating a strange full lock-up I'm
> > experiencing as a consequence of a printk in softirq inside of an
> > rcu_read_lock, when using Xen PV. Relevant excerpts of the
> ^^  PV guest?
> 
> > (gdb) target remote localhost:
> > Remote debugging using localhost:
> > __xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56
> > 56  while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
>  ^^  => HVM guest
> 
> Which is it?

Aren't there still some code paths for PV guests which hit the native APIC
case (emulated in Xen even for PV these days, since pvops in the early days
didn't accept the hooks needed to make use of the hypercall versions of
apic read/write).

In particular I'm thinking of the IPI which is (or was) used by the sysrq
to trigger the backtrace on all CPUs.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Xen-devel] printk from softirq on xen: hard lockup

[Ian Campbell]

On Tue, 2015-08-04 at 18:12 +0100, David Vrabel wrote:
 On 04/08/15 17:41, Jason A. Donenfeld wrote:
  Hi folks,
  
  Paul McKenney and I had an offline discussion about some rcu questions
  that eventually lead into me investigating a strange full lock-up I'm
  experiencing as a consequence of a printk in softirq inside of an
  rcu_read_lock, when using Xen PV. Relevant excerpts of the
 ^^  PV guest?
 
  (gdb) target remote localhost:
  Remote debugging using localhost:
  __xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56
  56  while (native_apic_mem_read(APIC_ICR)  APIC_ICR_BUSY)
  ^^  = HVM guest
 
 Which is it?

Aren't there still some code paths for PV guests which hit the native APIC
case (emulated in Xen even for PV these days, since pvops in the early days
didn't accept the hooks needed to make use of the hypercall versions of
apic read/write).

In particular I'm thinking of the IPI which is (or was) used by the sysrq
to trigger the backtrace on all CPUs.

Ian.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net] net: thunderx: remove effective "default y" from Kconfig if ARCH_THUNDER=y

[Ian Campbell]

As well as for kernels built only for ThunderX ARCH_THUNDERX is also enabled
for kernels which support multiple platforms (such as distro kernels). Thus
"default ARCH_THUNDER" is inappropriate.

I believe default m is equally frowned upon, so remove the line completely
rather than "default m if ARCH_THUNDER".

Signed-off-by: Ian Campbell 
Cc: Sunil Goutham 
Cc: Robert Richter 
Cc: Derek Chickles 
Cc: Satanand Burla 
Cc: Felix Manlunas 
Cc: Raghu Vatsavayi 
Cc: Arnd Bergmann 
Cc: linux-arm-ker...@lists.infradead.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/cavium/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/Kconfig 
b/drivers/net/ethernet/cavium/Kconfig
index 3584420..9b35d14 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -16,7 +16,6 @@ if NET_VENDOR_CAVIUM
 config THUNDER_NIC_PF
tristate "Thunder Physical function driver"
depends on 64BIT
-   default ARCH_THUNDER
select THUNDER_NIC_BGX
---help---
  This driver supports Thunder's NIC physical function.
@@ -29,14 +28,12 @@ config THUNDER_NIC_PF
 config THUNDER_NIC_VF
tristate "Thunder Virtual function driver"
depends on 64BIT
-   default ARCH_THUNDER
---help---
  This driver supports Thunder's NIC virtual function
 
 config THUNDER_NIC_BGX
tristate "Thunder MAC interface driver (BGX)"
depends on 64BIT
-   default ARCH_THUNDER
select PHYLIB
select MDIO_OCTEON
---help---
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net] net: thunderx: remove effective default y from Kconfig if ARCH_THUNDER=y

[Ian Campbell]

As well as for kernels built only for ThunderX ARCH_THUNDERX is also enabled
for kernels which support multiple platforms (such as distro kernels). Thus
default ARCH_THUNDER is inappropriate.

I believe default m is equally frowned upon, so remove the line completely
rather than default m if ARCH_THUNDER.

Signed-off-by: Ian Campbell i...@hellion.org.uk
Cc: Sunil Goutham sgout...@cavium.com
Cc: Robert Richter r...@kernel.org
Cc: Derek Chickles derek.chick...@caviumnetworks.com
Cc: Satanand Burla satananda.bu...@caviumnetworks.com
Cc: Felix Manlunas felix.manlu...@caviumnetworks.com
Cc: Raghu Vatsavayi raghu.vatsav...@caviumnetworks.com
Cc: Arnd Bergmann a...@arndb.de
Cc: linux-arm-ker...@lists.infradead.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/net/ethernet/cavium/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/Kconfig 
b/drivers/net/ethernet/cavium/Kconfig
index 3584420..9b35d14 100644
--- a/drivers/net/ethernet/cavium/Kconfig
+++ b/drivers/net/ethernet/cavium/Kconfig
@@ -16,7 +16,6 @@ if NET_VENDOR_CAVIUM
 config THUNDER_NIC_PF
tristate Thunder Physical function driver
depends on 64BIT
-   default ARCH_THUNDER
select THUNDER_NIC_BGX
---help---
  This driver supports Thunder's NIC physical function.
@@ -29,14 +28,12 @@ config THUNDER_NIC_PF
 config THUNDER_NIC_VF
tristate Thunder Virtual function driver
depends on 64BIT
-   default ARCH_THUNDER
---help---
  This driver supports Thunder's NIC virtual function
 
 config THUNDER_NIC_BGX
tristate Thunder MAC interface driver (BGX)
depends on 64BIT
-   default ARCH_THUNDER
select PHYLIB
select MDIO_OCTEON
---help---
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG") added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case "arm" (the vendor, not the ARCH=).

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Kristina Martsenko 
Cc: Kevin Hilman 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland 
Acked-by: Rob Herring 
Acked-by: Liviu Dudau 
Reviewed-by: Masahiro Yamada 
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.

v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS

v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.

v5: Remove stale reference to switching from /include/ to #include.
---
 Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
 MAINTAINERS | 1 +
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
 {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib| 3 ++-
 8 files changed, 8 insertions(+), 6 deletions(-)
 rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0  0 0 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
 
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
 F: Documentation/devicetree/
 F: arch/*/boot/dts/
 F: include/dt-bindings/
+F: kernel/dts/
 
 OPEN FIRMWARE AND DEVICE TREE OVERLAYS
 M: Pantelis Antoniou 
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dts

[PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG") added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case "arm" (the vendor, not the ARCH=).

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Kristina Martsenko 
Cc: Kevin Hilman 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland 
Acked-by: Rob Herring 
Acked-by: Liviu Dudau 
Reviewed-by: Masahiro Yamada 
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.

v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS

v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.

v5: Remove stale reference to switching from /include/ to #include.
---
 Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
 MAINTAINERS | 1 +
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
 {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib| 3 ++-
 8 files changed, 8 insertions(+), 6 deletions(-)
 rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0  0 0 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
 
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
 F: Documentation/devicetree/
 F: arch/*/boot/dts/
 F: include/dt-bindings/
+F: kernel/dts/
 
 OPEN FIRMWARE AND DEVICE TREE OVERLAYS
 M: Pantelis Antoniou 
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dts

Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Mon, 2015-08-03 at 10:55 -0500, Rob Herring wrote:
> On Mon, Aug 3, 2015 at 3:55 AM, Ian Campbell  
> wrote:
> > Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG") added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> > 
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > 
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> > 
> > Rather than using ../../ tricks to pickup .dtsi files from another
> > arch this patch creates a new directory kernel/dts as a home for such
> > cross-arch .dtsi files, arranges for it to be in the include path when
> > the .dts files are processed by cpp and switches the .dts files to use
> > cpp #include instead of /include/. The dtsi file itself is moved into
> > a vendor subdir in this case "arm" (the vendor, not the ARCH=).
> 
> Sigh, it was not the include path I was referring to being wrong
> although that was too. It was the part about using #include instead of
> /include/.

Damn, how did I miss that!

v5 coming up, sorry :-/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Commit 9ccd608070b6 ("arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG") added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files, arranges for it to be in the include path when
the .dts files are processed by cpp and switches the .dts files to use
cpp #include instead of /include/. The dtsi file itself is moved into
a vendor subdir in this case "arm" (the vendor, not the ARCH=).

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Kristina Martsenko 
Cc: Kevin Hilman 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland 
Acked-by: Rob Herring 
Acked-by: Liviu Dudau 
Reviewed-by: Masahiro Yamada 
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.

v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS

v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
---
 Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
 MAINTAINERS | 1 +
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
 {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib| 3 ++-
 8 files changed, 8 insertions(+), 6 deletions(-)
 rename {arch/arm/boot/dts => kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0  0 0 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
 
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
 F: Documentation/devicetree/
 F: arch/*/boot/dts/
 F: include/dt-bindings/
+F: kernel/dts/
 
 OPEN FIRMWARE AND DEVICE TREE OVERLAYS
 M: Pantelis Antoniou 
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@ -248,6 +248,6 @@
<0 0 41  0 41 4>,
<0 0 42  0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   /include/ "arm/ve

Re: [PATCH v3] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Sat, 2015-08-01 at 15:43 +0900, Masahiro Yamada wrote:
> 2015-08-01 15:21 GMT+09:00 Masahiro Yamada  >:
> > 2015-07-31 23:31 GMT+09:00 Ian Campbell :
> > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> > > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > > .dtsi supplied by arch/arm.
> > > 
> > > Unfortunately this causes some issues for the split device tree
> > > repository[0], since things get moved around there. In that context
> > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > 
> > Typo?
> > 
> > src/arm64  ->  arch/arm64
> > src/arm->  arch/arm
> > 
> 
> 
> I retract this comment with my apology.
> (I was seeing the kernel tree, not devicetree-rebasing)

Right ;-)

I fixed the commit formatting and took your Reviewed-by. I shall post v4
shortly.

Thanks,
Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Mon, 2015-08-03 at 10:55 -0500, Rob Herring wrote:
 On Mon, Aug 3, 2015 at 3:55 AM, Ian Campbell ian.campb...@citrix.com 
 wrote:
  Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
  LogicTile Express 20MG) added a new dts file to arch/arm64 which
  included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
  .dtsi supplied by arch/arm.
  
  Unfortunately this causes some issues for the split device tree
  repository[0], since things get moved around there. In that context
  the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
  while the include is at src/arm/vexpress-v2m-rs1.dtsi.
  
  The sharing of the .dtsi is legitimate since the baseboard is the same
  for various vexpress systems whatever processor they use.
  
  Rather than using ../../ tricks to pickup .dtsi files from another
  arch this patch creates a new directory kernel/dts as a home for such
  cross-arch .dtsi files, arranges for it to be in the include path when
  the .dts files are processed by cpp and switches the .dts files to use
  cpp #include instead of /include/. The dtsi file itself is moved into
  a vendor subdir in this case arm (the vendor, not the ARCH=).
 
 Sigh, it was not the include path I was referring to being wrong
 although that was too. It was the part about using #include instead of
 /include/.

Damn, how did I miss that!

v5 coming up, sorry :-/

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG) added a new dts file to arch/arm64 which
included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case arm (the vendor, not the ARCH=).

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Kristina Martsenko kristina.martse...@arm.com
Cc: Kevin Hilman khil...@linaro.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Rob Herring r...@kernel.org
Acked-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Masahiro Yamada yamada.masah...@socionext.com
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.

v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS

v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.

v5: Remove stale reference to switching from /include/ to #include.
---
 Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
 MAINTAINERS | 1 +
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
 {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib| 3 ++-
 8 files changed, 8 insertions(+), 6 deletions(-)
 rename {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = 0 0 0 gic 0 0 4;
 
-   /include/ vexpress-v2m-rs1.dtsi
+   /include/ arm/vexpress-v2m-rs1.dtsi
};
 };
 
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
 F: Documentation/devicetree/
 F: arch/*/boot/dts/
 F: include/dt-bindings/
+F: kernel/dts/
 
 OPEN FIRMWARE AND DEVICE TREE OVERLAYS
 M: Pantelis Antoniou pantelis.anton...@konsulko.com
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
 
-   /include/ vexpress-v2m-rs1.dtsi
+   /include/ arm/vexpress-v2m-rs1.dtsi
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
 
-   /include/ vexpress-v2m-rs1.dtsi
+   /include/ arm/vexpress-v2m-rs1.dtsi
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts

[PATCH v5] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG) added a new dts file to arch/arm64 which
included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case arm (the vendor, not the ARCH=).

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Kristina Martsenko kristina.martse...@arm.com
Cc: Kevin Hilman khil...@linaro.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Rob Herring r...@kernel.org
Acked-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Masahiro Yamada yamada.masah...@socionext.com
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.

v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS

v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.

v5: Remove stale reference to switching from /include/ to #include.
---
 Documentation/devicetree/bindings/arm/vexpress.txt  | 2 +-
 MAINTAINERS | 1 +
 arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts  | 2 +-
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
 {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib| 3 ++-
 8 files changed, 8 insertions(+), 6 deletions(-)
 rename {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = 0 0 0 gic 0 0 4;
 
-   /include/ vexpress-v2m-rs1.dtsi
+   /include/ arm/vexpress-v2m-rs1.dtsi
};
 };
 
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
 F: Documentation/devicetree/
 F: arch/*/boot/dts/
 F: include/dt-bindings/
+F: kernel/dts/
 
 OPEN FIRMWARE AND DEVICE TREE OVERLAYS
 M: Pantelis Antoniou pantelis.anton...@konsulko.com
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
 
-   /include/ vexpress-v2m-rs1.dtsi
+   /include/ arm/vexpress-v2m-rs1.dtsi
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
 
-   /include/ vexpress-v2m-rs1.dtsi
+   /include/ arm/vexpress-v2m-rs1.dtsi
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts