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

[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 = <&UIC1_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 
> > 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 
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] [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.

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

[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 
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 = <&intc>;
+   #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 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 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  
> > > > 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 
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 
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 = <&intc>;
+   #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 
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] 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-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] 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 GIC_SPI 41
> IRQ_TYPE_LEVEL_HIGH>,
>   <0 0 42 &gic 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/

[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 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42 &gic 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 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: [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: [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 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 &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 
> 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/d

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: [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 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 &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 
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
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi

[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 &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 
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
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi

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 &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 
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
@@ -248,6 +248,6 @@
<0 0 41 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
 
-   /include/ "vexp

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/

[PATCH v2] regulator: axp20x: Add module alias

[Ian Campbell]

This allows the module to be autoloaded.

Together with 07949bf9c63c ("cpufreq: dt: allow driver to boot
automatically") this is sufficient to allow a modular kernel (such
as Debian's) to enable cpufreq on a Cubietruck.

Signed-off-by: Ian Campbell 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Chen-Yu Tsai 
Cc: Maxime Ripard 
Cc: linux-su...@googlegroups.com
---
v2: Submit properly.
---
 drivers/regulator/axp20x-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index e4331f5..2c82131 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -264,3 +264,4 @@ module_platform_driver(axp20x_regulator_driver);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Carlo Caione ");
 MODULE_DESCRIPTION("Regulator Driver for AXP20X PMIC");
+MODULE_ALIAS("platform:axp20x-regulator");
-- 
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 v3] 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 include/dt-dtsi 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
---
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
---
 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 
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
@@ -248,6 +248,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/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts 

Re: [PATCH 1/8] arm/xen: Remove helpers which are PV specific

[Ian Campbell]

On Fri, 2015-07-31 at 11:44 +0100, Stefano Stabellini wrote:
> On Tue, 28 Jul 2015, Julien Grall wrote:
> > ARM guests are assimilated to HVM guest on ARM. The current
> > implementation is assuming a 1:1 mapping which is only true for DOM0 
> > and
> > may not be at all in the future.
> > 
> > Furthermore, all the helpers but arbitrary_virt_to_machine are used in
> > x86 specific code (or only compiled for).
> > 
> > The helper arbitrary_virt_to_machine is only used in PV specific code.
> > Therefore we should never call the function.
> > 
> > Add a BUG() in this helper and drop all the others.
> > 
> > Signed-off-by: Julien Grall 
> > Cc: Stefano Stabellini 
> > Cc: Russell King 
> > Cc: linux-arm-ker...@lists.infradead.org
> > ---
> >  arch/arm/include/asm/xen/page.h | 16 ++--
> >  1 file changed, 2 insertions(+), 14 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/xen/page.h 
> > b/arch/arm/include/asm/xen/page.h
> > index 1bee8ca..c2e9dcd 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -54,26 +54,14 @@ static inline unsigned long mfn_to_pfn(unsigned 
> > long mfn)
> >  
> >  #define mfn_to_local_pfn(mfn) mfn_to_pfn(mfn)
> >  
> > -static inline xmaddr_t phys_to_machine(xpaddr_t phys)
> > -{
> > -   unsigned offset = phys.paddr & ~PAGE_MASK;
> > -   return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | 
> > offset);
> > -}
> > -
> > -static inline xpaddr_t machine_to_phys(xmaddr_t machine)
> > -{
> > -   unsigned offset = machine.maddr & ~PAGE_MASK;
> > -   return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | 
> > offset);
> > -}
> >  /* VIRT <-> MACHINE conversion */
> > -#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
> >  #define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> >  #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> >  
> > +/* Only used in PV code. However ARM guest is always assimilated as 
> > HVM. */
>^ "However" doesn't make sense here from an
>english grammer point of view.

"English grammar" :-P

Sorry. What I really meant to say was that "assimilated" doesn't make sense
in this context either. I think maybe what was meant is "ARM guests are
always HVM".

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 v2] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Wed, 2015-07-29 at 14:27 +0100, Mark Rutland wrote:
> On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote:
> > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> > > Hi Ian,
> > > 
> > > 
> > > 2015-07-27 19:35 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 include/dt-dtsi 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
> > > 
> > > 
> > > "include/dt-dtsi/"  can be referenced from normal C sources.
> > > 
> > > I think another possible home for cross-arch DTSI is "kernel/dts/".
> > > This directory can be hidden from C sources.
> > 
> > I suppose, I don't really mind and will follow the direction of the 
> > other
> > DTB maintainers. It doesn't seem like a big deal to me.
> 
> I don't really have a preference either way.

I'm inclined to leave it, "visible to C sources" doesn't seem like that
much of an issue and IMHO the cure (kernel/dts/...) is worse than the
disease.

@@ -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 
> > > > };
> > > >  };
> > > 
> > > 
> > > 
> > > You do not have to replace /include/ with #include,
> > > if you add the include path for DTC.
> > 
> > Ah, I looked for this but -i is not documented in the man page.
> > 
> > Is there any reason to prefer one over the other?
> 
> #include allows you to use CPP in the file you're including, /include/
> does not.
> 
> I would imagine we have to use #include in case the dtsi itself has
> #include statements...

If it did, yes. I don't think vexpress-v2m-rs1.dtsi does, since it is using
/include/ today. I'm inclined to switch back to /include/ unless someone
objects.

> > > Please add include path for DTC too
> > > so that both /include/ and #include are available.
> 
> ... though that does not preclude adding it to the path for /include/.

Indeed, I've done that locally already.

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 v2] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> Hi Ian,
> 
> 
> 2015-07-27 19:35 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 include/dt-dtsi 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
> 
> 
> "include/dt-dtsi/"  can be referenced from normal C sources.
> 
> I think another possible home for cross-arch DTSI is "kernel/dts/".
> This directory can be hidden from C sources.

I suppose, I don't really mind and will follow the direction of the other
DTB maintainers. It doesn't seem like a big deal to me.

> >@@ -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 
> > };
> >  };
> 
> 
> 
> You do not have to replace /include/ with #include,
> if you add the include path for DTC.

Ah, I looked for this but -i is not documented in the man page.

Is there any reason to prefer one over the other?

> Please add include path for DTC too
> so that both /include/ and #include are available.

OK.

I shall await further feedback on what path to use before spinning a v3.

Ian.

> 
> 
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 79e8661..fc6c06c 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -285,7 +285,7 @@ quiet_cmd_dtc = DTC $@
>  cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; 
> \
> $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
> -   -i $(dir $<) $(DTC_FLAGS) \
> +   -i $(dir $<) -i $(srctree)/kernel/dts $(DTC_FLAGS) \
> -d $(depfile).dtc.tmp $(dtc-tmp) ; \
> cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
> 
> 
> 
> 
--
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 v2] 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 include/dt-dtsi 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
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
---
 Documentation/devicetree/bindings/arm/vexpress.txt   | 4 ++--
 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 => include/dt-dtsi/arm}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib | 1 +
 7 files changed, 7 insertions(+), 6 deletions(-)
 rename {arch/arm/boot/dts => include/dt-dtsi/arm}/vexpress-v2m-rs1.dtsi (100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..dccf570 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -7,7 +7,7 @@ peripherals. Processor and RAM "live" on the tiles.
 
 The motherboard and each core tile should be described by a separate
 Device Tree source file, with the tile's description including
-the motherboard file using a /include/ directive. As the motherboard
+the motherboard file using a #include directive. As the motherboard
 can be initialized in one of two different configurations ("memory
 maps"), care must be taken to include the correct one.
 
@@ -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 
};
 };
 
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..7ea7054 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 
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..afe997a4 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 
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..498181c 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 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   #include 
};
 };
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..b86c5a8 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts

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

[Ian Campbell]

On Fri, 2015-07-24 at 12:31 +0100, Mark Rutland wrote:
> On Wed, Jul 22, 2015 at 10:47:18AM +0100, Ian Campbell wrote:
> > On Wed, 2015-07-22 at 09:47 +0100, Liviu Dudau wrote:
> > > 
> > > Acked-by: Liviu Dudau 
> > 
> > Thanks.
> > 
> > > Picking your brains here: would it be worth to have some vendor 
> > > directories in
> > > this shared area or we can hope that there will be very few files 
> > > living here?
> > 
> > I'm honestly not sure.
> > 
> > I don't expect there will be very many files under here, and I 
> > would
> > expect the norm would be that common .dtsi files used by multiple
> > arches would be things from the same vendor, but I don't think we 
> > can
> > guarantee that.
> 
> I'm not so sure that this area will remain small. I suspect we'll see
> a reasonable amount of sharing for arm/arm64 where two SoCs differ 
> sith
> s/Cortex-A7/Cortex-A53/, for example.
> 
> Perhaps we could wait until the that starts to happen; we managed to
> survive for a while before moving arm64's dts into subdirs.

If we think it is inevitable we may as well bite the bullet, plus I've
already done "git commit --amend" to move it to include/dt-dtsi/arm ;-)

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 v2 01/20] xen: Add Xen specific page definition

[Ian Campbell]

On Fri, 2015-07-24 at 11:34 +0100, David Vrabel wrote:
> it would be better to think that:
> 
> PFNs index guest-sized pages (which may be 64 KiB).
> 
> GFNs index Xen-sized pages (which is always 4 KiB).

This concept could be usefully added to the comment in
xen/include/xen/mm.h IMHO.


> 
> David
--
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] dtb: Create a common home for cross-architecture dtsi files.

[Ian Campbell]

On Wed, 2015-07-22 at 09:47 +0100, Liviu Dudau wrote:
> 
> Acked-by: Liviu Dudau 

Thanks.

> Picking your brains here: would it be worth to have some vendor directories in
> this shared area or we can hope that there will be very few files living here?

I'm honestly not sure.

I don't expect there will be very many files under here, and I would
expect the norm would be that common .dtsi files used by multiple
arches would be things from the same vendor, but I don't think we can
guarantee that.

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] 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 include/dt-bindings/dtsi 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/.

[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
---
 Documentation/devicetree/bindings/arm/vexpress.txt| 2 +-
 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 => include/dt-bindings/dtsi}/vexpress-v2m-rs1.dtsi | 0
 scripts/Makefile.lib  | 1 +
 7 files changed, 6 insertions(+), 5 deletions(-)
 rename {arch/arm/boot/dts => include/dt-bindings/dtsi}/vexpress-v2m-rs1.dtsi 
(100%)

diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt 
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..46c6b04 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 
};
 };
 
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..85b201e 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 
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..fe5091d 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 
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts 
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..a028d59 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 &gic 0 41 4>,
<0 0 42 &gic 0 42 4>;
 
-   /include/ "vexpress-v2m-rs1.dtsi"
+   #include 
};
 };
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..b4257ee 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 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42 &gic GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 
-   /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi"
+   #include 
};
 };
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi 
b/include/dt-bindings/dtsi/vexpress-v2m-rs1.dtsi
similarity index 100%
rename from arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
rename to include/dt-bindings/dtsi/vexpress-v2m-rs1.dtsi
diff --git a/scripts/Makefile.lib

Re: 3.18.17 Xen regression

[Ian Campbell]

On Tue, 2015-07-07 at 15:54 -0400, Boris Ostrovsky wrote:
> Commit 63753fac67e1 ("x86: Store a per-cpu shadow copy of CR4") in 
> 3.18.y branch introduced a regression on PVH Xen guests.
> 
> Please apply 5054daa285be ("x86/xen: Initialize cr4 shadow for 64-bit 
> PV(H) guests") from mainline to fix this. 3.18.y appears to be the only 
> affected branch.

Any news on this? Our automated tests of 3.18 are continuing to fail.

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 3.4 000/172] 3.4.108-rc1 review

[Ian Campbell]

On Thu, 2015-06-18 at 11:19 +0800, Zefan Li wrote:
> On 2015/6/16 23:13, Ian Campbell wrote:
> > On Tue, 2015-06-16 at 16:33 +0800, l...@kernel.org wrote:
> >> From: Zefan Li 
> >>
> >> This is the start of the stable review cycle for the 3.4.108 release.
> >> There are 172 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Thu Jun 18 08:30:58 UTC 2015.
> >> Anything received after that time might be too late.
> > 
> > Would it be possible to also include 31a418986a58 "xen: netback: read
> > hotplug script once at start of day." which has started trickling into
> > other stable branches already, please.
> > 
> > If not now then for 109.
> > 
> 
> Queued up for 3.4.108. :)

Smashing, thank you.

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/3] net/xen-netback: Don't mix hexa and decimal with 0x in the printf format

[Ian Campbell]

On Wed, 2015-06-17 at 10:30 +0100, Julien Grall wrote:
> I see different opinion on whether using 0x% or %#. As I plan to resend 
> a version with the commit message update, shall I use %#?

I think it's mostly pointless bike-shedding over a saving measured in
single digit bytes, use whichever you like.

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/3] net/xen-netback: Don't mix hexa and decimal with 0x in the printf format

[Ian Campbell]

On Tue, 2015-06-16 at 20:10 +0100, Julien Grall wrote:
> Append 0x to all %x in order to avoid while reading when there is other
> decimal value in the log.
> 
> Also replace some of the hexadecimal print to decimal to uniformize the
> format with netfront.
> 
> Signed-off-by: Julien Grall 
> Cc: Wei Liu 
> Cc: Ian Campbell 
> Cc: net...@vger.kernel.org

You meant s/Append/Prepend/, nonetheless:

Acked-by: Ian Campbell 


--
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/3] net/xen-netback: Don't mix hexa and decimal with 0x in the printf format

[Ian Campbell]

On Tue, 2015-06-16 at 16:55 -0700, Joe Perches wrote:
> 0x%x is easier and simpler to visualize than %#x.

They also don't produce the same output if the value is 0 (0x%x=>0x0, %
#x=>0), which can matter if you are trying to line up a column or
whatever.

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 3.4 000/172] 3.4.108-rc1 review

[Ian Campbell]

On Tue, 2015-06-16 at 16:33 +0800, l...@kernel.org wrote:
> From: Zefan Li 
> 
> This is the start of the stable review cycle for the 3.4.108 release.
> There are 172 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Jun 18 08:30:58 UTC 2015.
> Anything received after that time might be too late.

Would it be possible to also include 31a418986a58 "xen: netback: read
hotplug script once at start of day." which has started trickling into
other stable branches already, please.

If not now then for 109.

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 07/12] x86/virt/guest/xen: Remove use of pgd_list from the Xen guest code

[Ian Campbell]

On Sat, 2015-06-13 at 11:49 +0200, Ingo Molnar wrote:
> xen_mm_pin_all()/unpin_all() are used to implement full guest instance
> suspend/restore. It's a stop-all method that needs to iterate through
> all allocated pgds in the system to fix them up for Xen's use.
> 
> This code uses pgd_list, probably because it was an easy interface.
> 
> But we want to remove the pgd_list, so convert the code over to walk
> all tasks in the system. This is an equivalent method.
> 
> (As I don't use Xen this is was only build tested.)

In which case it seems extra important to copy the appropriate
maintainers, which I've done here.

Ian.

> 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Linus Torvalds 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: Waiman Long 
> Cc: linux...@kvack.org
> Signed-off-by: Ingo Molnar 
> ---
>  arch/x86/xen/mmu.c | 51 ++-
>  1 file changed, 38 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index dd151b2045b0..70a3df5b0b54 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -853,15 +853,27 @@ static void xen_pgd_pin(struct mm_struct *mm)
>   */
>  void xen_mm_pin_all(void)
>  {
> - struct page *page;
> + struct task_struct *g, *p;
>  
> - spin_lock(&pgd_lock);
> + spin_lock(&pgd_lock); /* Implies rcu_read_lock() for the task list 
> iteration: */
>  
> - list_for_each_entry(page, &pgd_list, lru) {
> - if (!PagePinned(page)) {
> - __xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
> - SetPageSavePinned(page);
> + for_each_process_thread(g, p) {
> + struct mm_struct *mm;
> + struct page *page;
> + pgd_t *pgd;
> +
> + task_lock(p);
> + mm = p->mm;
> + if (mm) {
> + pgd = mm->pgd;
> + page = virt_to_page(pgd);
> +
> + if (!PagePinned(page)) {
> + __xen_pgd_pin(&init_mm, pgd);
> + SetPageSavePinned(page);
> + }
>   }
> + task_unlock(p);
>   }
>  
>   spin_unlock(&pgd_lock);
> @@ -967,19 +979,32 @@ static void xen_pgd_unpin(struct mm_struct *mm)
>   */
>  void xen_mm_unpin_all(void)
>  {
> - struct page *page;
> + struct task_struct *g, *p;
>  
> - spin_lock(&pgd_lock);
> + spin_lock(&pgd_lock); /* Implies rcu_read_lock() for the task list 
> iteration: */
>  
> - list_for_each_entry(page, &pgd_list, lru) {
> - if (PageSavePinned(page)) {
> - BUG_ON(!PagePinned(page));
> - __xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
> - ClearPageSavePinned(page);
> + for_each_process_thread(g, p) {
> + struct mm_struct *mm;
> + struct page *page;
> + pgd_t *pgd;
> +
> + task_lock(p);
> + mm = p->mm;
> + if (mm) {
> + pgd = mm->pgd;
> + page = virt_to_page(pgd);
> +
> + if (PageSavePinned(page)) {
> + BUG_ON(!PagePinned(page));
> + __xen_pgd_unpin(&init_mm, pgd);
> + ClearPageSavePinned(page);
> + }
>   }
> + task_unlock(p);
>   }
>  
>   spin_unlock(&pgd_lock);
> + rcu_read_unlock();
>  }
>  
>  static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)


--
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 1/1] PCI: X-Gene: Disable Configuration Request Retry Status for X-Gene v1 PCIe

[Ian Campbell]

On Thu, 2015-06-11 at 13:08 -0700, Duc Dang wrote:
> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
> Status (CRS) logic:
>   When CPU tries to read Vendor ID and Device ID of not-existed
>   remote device, the controller returns 0x0001 instead of
>   0x; this will add significant delay in boot time as
>   pci_bus_read_dev_vendor_id will wait for 60 seconds before
>   giving up.
> 
> So for X-Gene v1 PCIe controllers, disable CRS capability
> advertisement by clearing CRS Software Visibility bit before
> returning the Root Capability value to the callers. This is done
> by implementing X-Gene PCIe specific xgene_pcie_config_read32 for
> CFG read accesses to replace the generic default pci_generic_config_read32
> function.
> 
> Signed-off-by: Duc Dang 

Applied onto v4.1-rc7 and:
Tested-by: Ian Campbell 

Thanks!


--
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: [linux-sunxi] [RFC 0/7] ARM: sun9i: SMP support with Multi-Cluster Power Management

[Ian Campbell]

On Thu, 2015-05-14 at 14:10 +0800, Chen-Yu Tsai wrote:
> This is my attempt to support SMP and CPU hot plugging on the Allwinner
> A80 SoC. The A80 is a big.Little processor with 2 clusters of 4x Cortex-A7
> and 4x Cortex-A15 cores.

I thought there was a preference these days to support this sort of
thing via support PSCI in the firmware, which allows for other things
such as non-secure-world etc.

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] [RFC 21/23] net/xen-netback: Make it running on 64KB page granularity

[Ian Campbell]

On Fri, 2015-05-15 at 16:31 +0100, Wei Liu wrote:
> On Fri, May 15, 2015 at 01:35:42PM +0100, Julien Grall wrote:
> > Hi Wei,
> > 
> > Thanks you for the review.
> > 
> > On 15/05/15 03:35, Wei Liu wrote:
> > > On Thu, May 14, 2015 at 06:01:01PM +0100, Julien Grall wrote:
> > >> The PV network protocol is using 4KB page granularity. The goal of this
> > >> patch is to allow a Linux using 64KB page granularity working as a
> > >> network backend on a non-modified Xen.
> > >>
> > >> It's only necessary to adapt the ring size and break skb data in small
> > >> chunk of 4KB. The rest of the code is relying on the grant table code.
> > >>
> > >> Although only simple workload is working (dhcp request, ping). If I try
> > >> to use wget in the guest, it will stall until a tcpdump is started on
> > >> the vif interface in DOM0. I wasn't able to find why.
> > >>
> > > 
> > > I think in wget workload you're more likely to break down 64K pages to
> > > 4K pages. Some of your calculation of mfn, offset might be wrong.
> > 
> > If so, why tcpdump on the vif interface would make wget suddenly
> > working? Does it make netback use a different path?
> 
> No, but if might make core network component behave differently, this is
> only my suspicion.

Traffic being delivered to dom0 (as opposed to passing through a bridge
and going elsewhere) will get skb_orphan_frags called on it, since
tcpdump ends up cloning the skb to go to two places it's not out of the
question that this might have some impact (deliberate or otherwise) on
the other skb which isn't going to dom0.

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] xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages.

[Ian Campbell]

On Tue, 2015-04-21 at 11:36 +0100, Stefano Stabellini wrote:
> On Tue, 21 Apr 2015, Ian Campbell wrote:
> > On Mon, 2015-04-20 at 18:54 +0100, Stefano Stabellini wrote:
> > > This should definitely be done only on ARM and ARM64, as on x86 PVH
> > > assumes the presence of an IOMMU. We need an ifdef.
> > > 
> > > Also we need to figure out a way to try without GFP_DMA in case no ram
> > > under 4g is available at all, as some arm64 platforms don't have any. Of
> > > course in those cases we don't need to worry about devices and their dma
> > > masks.  Maybe we could use memblock for that?
> > 
> > It's pretty ugly, but I've not got any better ideas.
> > 
> > It would perhaps be less ugly as a an arch-specific
> > get_me_a_swiotlb_region type function, with the bare __get_free_pages as
> > the generic fallback.
> 
> We could do that, but even open code like this isn't too bad: it might
> be ugly but at least is very obvious.
> 
> 
> > >  Something like:
> > > 
> > > struct memblock_region *reg;
> > > gfp_t flags = __GFP_NOWARN;
> > > 
> > > #if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> > >   for_each_memblock(memory, reg) {
> > >   unsigned long start = memblock_region_memory_base_pfn(reg);
> > > 
> > > if (start < 4G) {
> > > flags |= __GFP_DMA;
> > > break;
> > > }
> > > }
> > > #endif
> > > 
> > > [...]
> > > 
> > > xen_io_tlb_start = (void *)__get_free_pages(flags, order);
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > This is also conceptually wrong since it doesn't matter where the pages
> > > > are in PFN space,  but where they are in bus address (MFN) space (which
> > > > is what the subsequent hypercall is required to sort out).
> > > 
> > > Actually on ARM dom0 is mapped 1:1, so it is the same thing.
> > 
> > On a system with a fully functional SMMU dom0 may not be 1:1 mapped, but
> > I think that dom0 can still treat that as 1:1 mapped for these purposes,
> > since the SMMU will provide that illusion.
> > 
> > Dumb question, and this might affect PVH too, if you have an IOMMU and a
> > device with a limited DMA range, I suppose you need to provide DMA
> > addresses in the <4G for the input to the IOMMU (i.e. PFN) and not the
> > output (i.e. MFN) space (since the device only sees PFNs).
> 
> I think you mean "for the input to the device (PFN)", but I presume the
> same.

Yes, either the numbers the driver programs into the device, or the ones
the device itself puts on the bus (i.e. inputs to the IOMMU). They are
in the same address space.

> > So even for x86 PVH isn't something required here to ensure that the
> > swiotlb has suitable pages under 4GB in PFN space too?
> > 
> > (On ARM PFN==IPA and MFN==PA)
> 
> I guess that is true. PVH people, any thoughts?
> 
> 
> > Second dumb question, on x86 PVH or ARM with an SMMU, would we even hit
> > the Xen swiotlb code, or would we want to arrange to go via the native
> > swiotlb paths? I initially thought the latter, but does e.g. grant
> > mappings still need some special handling?
> 
> In both cases I think it would be simpler to just go through the normal
> swiotlb.

No special grant table magic in this case == great!

> FYI at the moment there is no knowledge about SMMUs availability on ARM.
> The code is still missing.

Right, I just want to avoid painting ourselves into a corner before that
stuff lands.

--
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] xen: Add __GFP_DMA flag when xen_swiotlb_init gets free pages.

[Ian Campbell]

On Mon, 2015-04-20 at 18:54 +0100, Stefano Stabellini wrote:
> This should definitely be done only on ARM and ARM64, as on x86 PVH
> assumes the presence of an IOMMU. We need an ifdef.
> 
> Also we need to figure out a way to try without GFP_DMA in case no ram
> under 4g is available at all, as some arm64 platforms don't have any. Of
> course in those cases we don't need to worry about devices and their dma
> masks.  Maybe we could use memblock for that?

It's pretty ugly, but I've not got any better ideas.

It would perhaps be less ugly as a an arch-specific
get_me_a_swiotlb_region type function, with the bare __get_free_pages as
the generic fallback.

>  Something like:
> 
> struct memblock_region *reg;
> gfp_t flags = __GFP_NOWARN;
> 
> #if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
>   for_each_memblock(memory, reg) {
>   unsigned long start = memblock_region_memory_base_pfn(reg);
> 
> if (start < 4G) {
> flags |= __GFP_DMA;
> break;
> }
> }
> #endif
> 
> [...]
> 
> xen_io_tlb_start = (void *)__get_free_pages(flags, order);
> 
> 
> 
> 
> 
> > This is also conceptually wrong since it doesn't matter where the pages
> > are in PFN space,  but where they are in bus address (MFN) space (which
> > is what the subsequent hypercall is required to sort out).
> 
> Actually on ARM dom0 is mapped 1:1, so it is the same thing.

On a system with a fully functional SMMU dom0 may not be 1:1 mapped, but
I think that dom0 can still treat that as 1:1 mapped for these purposes,
since the SMMU will provide that illusion.

Dumb question, and this might affect PVH too, if you have an IOMMU and a
device with a limited DMA range, I suppose you need to provide DMA
addresses in the <4G for the input to the IOMMU (i.e. PFN) and not the
output (i.e. MFN) space (since the device only sees PFNs).

So even for x86 PVH isn't something required here to ensure that the
swiotlb has suitable pages under 4GB in PFN space too?

(On ARM PFN==IPA and MFN==PA)

Second dumb question, on x86 PVH or ARM with an SMMU, would we even hit
the Xen swiotlb code, or would we want to arrange to go via the native
swiotlb paths? I initially thought the latter, but does e.g. grant
mappings still need some special handling?

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 v6 07/30] PCI: Pass PCI domain number combined with root bus number

[Ian Campbell]

On Tue, 2015-03-17 at 10:45 +0530, Manish Jaggi wrote:
> On Monday 09 March 2015 08:04 AM, Yijing Wang wrote:
> > Now we could pass PCI domain combined with bus number
> > in u32 argu. Because in arm/arm64, PCI domain number
> > is assigned by pci_bus_assign_domain_nr(). So we leave
> > pci_scan_root_bus() and pci_create_root_bus() in arm/arm64
> > unchanged. A new function pci_host_assign_domain_nr()
> > will be introduced for arm/arm64 to assign domain number
> > in later patch.
> Hi,
> I think these changes might not be required. We have made very few 
> changes in the xen-pcifront to support PCI passthrough in arm64.
> As per xen architecture for a domU only a single pci virtual bus is 
> created and all passthrough devices are attached to it.

I guess you are only talking about the changes to xen-pcifront.c?
Otherwise you are ignoring the dom0 case which is exposed to the real
set of PCI root complexes and anyway I'm not sure how "not needed for
Xen domU" translates into not required, since it is clearly required for
other systems.

Strictly speaking the Xen pciif protocol does support multiple buses,
it's just that the tools, and perhaps kernels, have not yet felt any
need to actually make use of that.

There doesn't seem to be any harm in updating pcifront to follow this
generic API change.

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: [RFC PATCH] xen-netback: making the bandwidth limiter runtime settable

[Ian Campbell]

On Fri, 2015-03-13 at 13:51 +0100, Imre Palik wrote:
[...]
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index 3aa8648..34d8038 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -463,6 +463,7 @@ int xenvif_init_queue(struct xenvif_queue *queue)
>   queue->credit_bytes = queue->remaining_credit = ~0UL;
>   queue->credit_usec  = 0UL;
>   init_timer(&queue->credit_timeout);
> + queue->credit_timeout.function = xenvif_tx_credit_callback;
>   queue->credit_window_start = get_jiffies_64();
>  
>   queue->rx_queue_max = XENVIF_RX_QUEUE_BYTES;
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index cab9f52..bcc1880 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
[...]
> @@ -1170,7 +1170,7 @@ static bool tx_credit_exceeded(struct xenvif_queue 
> *queue, unsigned size)
>   queue->credit_timeout.data =
>   (unsigned long)queue;
>   queue->credit_timeout.function =
> - tx_credit_callback;
> + xenvif_tx_credit_callback;

Are this init and the one in xenvif_init_queue really both needed?

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 3/4] usb: Introduce Xen pvUSB backend

[Ian Campbell]

On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote:
> On 03/04/2015 03:29 PM, Ian Campbell wrote:
> > On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
> >> On 04/03/15 14:09, Juergen Gross wrote:
> >>>
> >>> The main question whether it is worth to consider this alternative is
> >>> the performance aspect. Does anyone have an idea which USB devices would
> >>> typically be used via pvusb? I'd suspect memory sticks and USB disks
> >>> and perhaps webcams being the most performance relevant ones. Is an
> >>> additional copy operation of user data acceptable here?
> >>
> >> I have no idea.  We (XenServer) have no use cases at all for USB device
> >> passthrough.
> >
> > My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough
> > that anyone would care. qdisk has acceptable for disks, so it's probably
> > ok for usb too.
> 
> While I can accept the bus speed reasoning, I doubt qdisk is copying
> data between user and kernel space under normal circumstances. I think
> disk I/Os are done using DMA to/from the user buffer directly.

I thought there was at least one copy on the datapath with qdisk,
wherever it is. But I don't know for sure.

> > For usb 3 onwards, well, maybe when we care about those we'll decide
> > that a kernel space driver is needed, but for now it seems like
> > userspace would be ok.
> 
> Do you have another feeling about the probability of a need to do usb 3?
> If it is already on the horizon I wouldn't want to do the user space
> backend now and the kernel one next year. :-)

Well, what is *your* use case for USB passthru? I don't actually have
one myself.

I'd speculate that people are more interested in passing in
low/medium/high speed devices rather than the superfast usb3 disks etc.
But I have no reason to back that up.

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 3/4] usb: Introduce Xen pvUSB backend

[Ian Campbell]

On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
> On 04/03/15 14:09, Juergen Gross wrote:
> > 
> > The main question whether it is worth to consider this alternative is
> > the performance aspect. Does anyone have an idea which USB devices would
> > typically be used via pvusb? I'd suspect memory sticks and USB disks
> > and perhaps webcams being the most performance relevant ones. Is an
> > additional copy operation of user data acceptable here?
> 
> I have no idea.  We (XenServer) have no use cases at all for USB device
> passthrough.

My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough
that anyone would care. qdisk has acceptable for disks, so it's probably
ok for usb too.

For usb 3 onwards, well, maybe when we care about those we'll decide
that a kernel space driver is needed, but for now it seems like
userspace would be ok.

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 3/4] usb: Introduce Xen pvUSB backend

[Ian Campbell]

On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:
> >> - move module to appropriate location in kernel tree
> >
> > drivers/xen/ is the correct location for this driver.
> 
> Hmm, so you regard placement of xen-netback under drivers/net and
> xen-blkback under drivers/block as wrong? I've just followed these
> examples.

At least in the case of netback it really is just a normal Ethernet
driver as far as the kernel is concerned. The fact it happens to talk to
a virtual device doesn't matter.

I don't know about other device types.

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 net-next 06/14] xen: Use eth__addr instead of memset

[Ian Campbell]

On Mon, 2015-03-02 at 19:54 -0800, Joe Perches wrote:
> Use the built-in function instead of memset.
> 
> Signed-off-by: Joe Perches 

Acked-by: Ian Campbell 


--
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 2/2] swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single

[Ian Campbell]

On Fri, 2014-11-21 at 17:00 +, Stefano Stabellini wrote:
> Need to pass the pointer within the swiotlb internal buffer to the
> swiotlb library, that in the case of xen_unmap_single is dev_addr, not
> paddr.
> 
> Signed-off-by: Stefano Stabellini 
> CC: konrad.w...@oracle.com
> CC: sta...@vger.kernel.org

This went into mainline as 2c3fc8d26dd0 "swiotlb-xen: pass dev_addr to
swiotlb_tbl_unmap_single" but was reverted in dbdd74763f1f.

However it seems that 2c3fc8d26dd0 has made it into at least some stable
kernel trees:
v3.18.3 as 2129c43d41e9
v3.16.7-ckt4 as 94ab279b0c9a
v3.14.29 as 3394691d34fc
v3.10.65 as 81cb80b578c5
so it should be reverted there too. This is causing issues in the field
such as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776237.

v3.17, v3.15, v3.13.11-ckt14, v3.12.x, v3.11.x appear clean, I stopped
going backwards at v3.10.

Cheers,
Ian.

> ---
>  drivers/xen/swiotlb-xen.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 810ad41..5ea1e3c 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -451,7 +451,7 @@ static void xen_unmap_single(struct device *hwdev, 
> dma_addr_t dev_addr,
>  
>   /* NOTE: We use dev_addr here, not paddr! */
>   if (is_xen_swiotlb_buffer(dev_addr)) {
> - swiotlb_tbl_unmap_single(hwdev, paddr, size, dir);
> + swiotlb_tbl_unmap_single(hwdev, dev_addr, size, dir);
>   return;
>   }
>  


--
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 RFC] xen-time: decreasing the rating of the xen clocksource below that of the tsc clocksource for dom0's

[Ian Campbell]

On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
> From: "Palik, Imre" 
> 
> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
> be used) instead of the Xen clocksource should not cause any issues, as
> Dom0 VMs never live-migrated.

Is this still true given that dom0's vcpus are migrated amongst pcpus on
the host? The tsc are not synchronised on some generations of hardware
so the result there would be the TSC appearing to do very odd things
under dom0's feet. Does Linux cope with that or does it not matter for
some other reason?

> 
> Cc: Anthony Liguori 
> Signed-off-by: Imre Palik 
> ---
>  arch/x86/xen/time.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index f473d26..c768726 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -487,6 +487,10 @@ static void __init xen_time_init(void)
>   int cpu = smp_processor_id();
>   struct timespec tp;
>  
> + /* As Dom0 is never moved, no penalty on using TSC there */
> + if (xen_initial_domain())
> + xen_clocksource.rating = 275;
> +
>   clocksource_register_hz(&xen_clocksource, NSEC_PER_SEC);
>  
>   if (HYPERVISOR_vcpu_op(VCPUOP_stop_periodic_timer, cpu, NULL) == 0) {


--
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: fixing the propagation of the transmit shaper timeout

[Ian Campbell]

On Tue, 2015-01-06 at 16:44 +0100, Imre Palik wrote:
> From: "Palik, Imre" 
> 
> Since e9ce7cb6b107 ("xen-netback: Factor queue-specific data into queue 
> struct"),
> the transimt shaper timeout is always set to 0.  The value the user sets via
> xenbus is never propagated to the transmit shaper.
> 
> This patch fixes the issue.
> 
> Cc: Anthony Liguori 
> Signed-off-by: Imre Palik 

Acked-by: Ian Campbell 


--
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] Regression in netfilter code under Xen

[Ian Campbell]

On Tue, 2014-11-25 at 15:23 -0500, Boris Ostrovsky wrote:
> We have a regression due to (5195c14c8: netfilter: conntrack: fix race 
> in __nf_conntrack_confirm against get_next_corpse). I have not been able 
> to reproduce this on baremetal but dom0 crashes reliably after a few 
> seconds of idle time.

Are guests running when this happens? (IOW is netback possibly
involved).

>  This doesn't appear to be dependent on Xen version 
> --- I saw it on at least a 4.2 and unstable).
> 
> I don't know much about networking (and will be out for most of the rest 
> of the week) so I wonder whether anyone has any ideas. The stack is below.
> 
> 
> Thanks.
> -boris
> 
> # 
> [ 
> 54.901368] general protection fault:  [#1] SMP
> [   54.919324] Modules linked in: dm_multipath dm_mod xen_evtchn 
> iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport 
> libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod i915 fbcon 
> tileblit font bitblit softcursor tpm_tis ahci libahci libata 
> drm_kms_helper video scsi_mod e1000e wmi xen_blkfront xen_netfront 
> fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd
> [   54.996767] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 3.18.0-rc5upstream-00179-g8a84e01 #1
> [   55.016730] Hardware name: LENOVO ThinkServer TS130/, BIOS 
> 9HKT47AUS 01/10/2012
> [   55.036873] task: 880037e48a10 ti: 880037e54000 task.ti: 
> 880037e54000
> [   55.057338] RIP: e030:[] [] 
> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
> [   55.[   55.099069] RAX: dead00200200 RBX: e8c89108 RCX: 
> 81cc5820
> [   55.119918] RDX: 8001 RSI: 0011 RDI: 
> e8c89108
> [   55.140768] RBP: 88003e283908 R08: c5f889ff R09: 
> a1a10f28
> [   55.161785] R10: 880037e5f1b8 R11: 0001 R12: 
> 880037e5f148
> [   55.183005] R13: 815e6a6b R14: 88002bed8400 R15: 
> 88002bb3
> [   55.204214] FS:  7f668f694700() GS[   55.225733] CS: e033 
> DS: 002b ES: 002b CR0: 80050033
> [   55.247220] CR2: 7f66c0a598eb CR3: 2bc39000 CR4: 
> 00042660
> [   55.268863] Stack:
> [   55.290200]  880037e5f148 81c98080 88003e283928 
> 815eb59d
> [   55.312068]  88002bed8400 88002bed8400 88003e283938 
> 815e689a
> [   55.333849]  88003e283958 815a37a5 88003e283968 
> 88002bed8400
> [   55.355449] Call Trace:
> [   55.376552]  
> [   55.376728]  [] destroy_conntrack+0x5d/0xc0
> [   55.418187]  [] nf_conntrack_destroy+0x1a/0x40
> [   55.439349]  [] skb_release_head_state+0x85/0xd0
> [   55.460468]  [] skb_release_all+0x11/0x30
> [   55.481440]  [] __kfree_skb+0x11/0xc0
> [   55.502239]  [] kfree_skb+0x38/0xa0
> [   55.522661]  [] ? ip_rcv+0x3a0/0x3a0
> [   55.542811]  [] ? ip_rcv+0x3a0/0x3a0
> [   55.562543]  [] nf_hook_slow+0x10b/0x120
> [   55.582100]  [] ? ip_rcv+0x3a0/0x3a0
> [   55.601470]  [] ? _raw_spin_unlock_irqrestore+0[   
> 55.620900] [] ip_local_deliver+0x73/0x80
> [   55.640154]  [] ip_rcv_finish+0x109/0x310
> [   55.659244]  [] ip_rcv+0x28c/0x3a0
> [   55.678287]  [] 
> __netif_receive_skb_core+0x58e/0x[   55.697287] [] 
> __netif_receive_skb+0x1d/0x70
> [   55.715820]  [] netif_receive_skb_internal+0x1e/0xb0
> [   55.734442]  [] netif_receive_skb+0x17/0x70
> [   55.752898]  [] br_handle_frame_finish+0x192/0x360
> [   55.771709]  [] br_handle_frame+0
> [   55.790274]  [] ? br_handle_local_finish+0x40/0x40
> [   55.808760]  [] __netif_receive_skb_core+0x1d7/0x710
> [   55.827302]  [] __netif_receive_skb+0x1d/0x70
> [   55.845594]  [] netif_receive_skb_internal+0x1e/0xb0
> [   55.863836]  [] napi_gro_receive+0x118/0x1a0
> [   55.881549]  [] tg3_poll_work+0xe1f/0x1[   
> 55.898629]  [] tg3_poll+0x69/0x3c0
> [   55.915010]  [] net_rx_action+0x103/0x290
> [   55.930840]  [] __do_softirq+0xf3/0x2e0
> [   55.946310]  [] irq_exit+0xcd/0xe0
> [   55.961399]  [] xen_evtchn_do_upcall+0x37/0x50
> 766]  [] xen_do_hypervisor_callback+0x1e/0x30
> [   55.990802]  
> [   55.990977]  [] ? xen_hypercall_sched_op+0xa/0x20
> [   56.018897]  [] ? xen_hypercall_sched_op+0xa/0x20
> [   56.032815]  [] ? xen_safe_halt+0x10/0x20
> [   56.046583]  [] ? default_idle+0x1a/0xd0
> [   56.060307]  [] ? arch_cpu_idle+0xa/0x10
> [   56.073920]  [] ? cpu_startup_entry+0x2d3/0[   
> 56.100421]  [] ? cpu_bringup_and_idle+0x25/0x40
> [   56.113427] Code: 98 08 08 00 00 0f b7 47 08 48 03 1c c5 a0 42 cc 81 
> 48 89 df e8 94 fc 11 00 49 8b 44 24 18 48 85 c0 74 2d 49[   
> 56.141507] RIP  [] 
> nf_ct_del_from_dying_or_unconfirmed_list+0x3e/0x70
> [   56.155425]  RSP 
> [   56.169234] ---[ end trace 4c64578e4c629cc4 ]---
> [   56.182913] Kernel panic - not syncing: Fatal exception in interrupt
> [   56.197026] Kernel Offset: 0x0 from 0x81000k  text console
> (XEN) [2014-

Re: [PATCH] of: support passing console options with stdout-path

[Ian Campbell]

On Tue, 2014-11-25 at 15:39 +, Grant Likely wrote:
> On Tue, Nov 25, 2014 at 3:24 PM, Ian Campbell  wrote:
> >> sed s/of_find_node_by_path\((.*)\)/of_find_node_by_path\(\1, NULL\)
> >
> > Coccinelle rules for this sort of transformation...
> 
> /me still hasn't gotten his head around how to use Coccinelle properly. :-(

Me neither, but for the "add an extra NULL parameter" case I can
generally find something to cargo cult from ;-) (it's been ages since I
had a need though)

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] of: support passing console options with stdout-path

[Ian Campbell]

On Tue, 2014-11-25 at 15:20 +, Grant Likely wrote:
> On Tue, Nov 25, 2014 at 3:15 PM, Leif Lindholm  
> wrote:
> > On Tue, Nov 25, 2014 at 02:58:54PM +, Grant Likely wrote:
> >> > +   len = strchrnul(path, ':') - path;
> >> > +
> >> > for_each_property_of_node(of_aliases, pp) {
> >> > if (strlen(pp->name) == len && !strncmp(pp->name, 
> >> > path, len)) {
> >> > np = of_find_node_by_path(pp->value);
> >>
> >> Can you add a testcase to drivers/of/unittests.c for this new path
> >> parsing? Then we know it's correct!
> >
> > Will do.
> >
> >> > @@ -1830,8 +1835,12 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, 
> >> > u64 align))
> >> > name = of_get_property(of_chosen, 
> >> > "linux,stdout-path", NULL);
> >> > if (IS_ENABLED(CONFIG_PPC) && !name)
> >> > name = of_get_property(of_aliases, "stdout", NULL);
> >> > -   if (name)
> >> > +   if (name) {
> >> > of_stdout = of_find_node_by_path(name);
> >> > +   of_stdout_options = strchr(name, ':');
> >> > +   if (of_stdout_options != NULL)
> >> > +   of_stdout_options++;
> >> > +   }
> >>
> >> Not so good. The ':' should actually be a generic part of
> >> of_find_node_by_path(), it doesn't have to be limited to stdout parsing.
> >> There are other places that would use it. I would add a second,
> >> optional, argument to of_find_node_by_path() that will update a pointer
> >> to the arguments after the ':'.
> >
> > So, I agree this would be nicer...
> >
> > However, I'm counting 157 callers of this function outside of
> > drivers/of and 43 inside. Any chance you'd let me get away with a
> > separate of_find_extra_options_by_path()?
> 
> I'd rather not. It is a trivial change and can be pretty much done
> mechanically. Something like (I think; I always have to look up the
> sed syntax):
> 
> sed s/of_find_node_by_path\((.*)\)/of_find_node_by_path\(\1, NULL\)

Coccinelle rules for this sort of transformation...

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] of: support passing console options with stdout-path

[Ian Campbell]

On Tue, 2014-11-25 at 11:17 +, Leif Lindholm wrote:
> On Tue, Nov 25, 2014 at 10:35:04AM +, Mark Rutland wrote:
> > On Mon, Nov 24, 2014 at 10:23:58PM +, Leif Lindholm wrote:
> > > Support specifying console options (like with console=ttyXN,)
> > > by appending them to the stdout-path property after a separating ':'.
> > > 
> > > Example:
> > >   stdout-path = "uart0:115200";
> > 
> > I would very much like to be able to use this -- it will allow
> > distributions to boot on a board without having to know _anything_ about
> > the console UART until userspace is up, which would make it possible to
> > have a completely generic installer image, without requiring the
> > platform to provide bootargs.
> > 
> > My only concern is that this conflates the set of kernel command line
> > options for the UART wit the DT binding for it. I don't know how good
> > people are at keeping those options stable, and I know they are
> > currently not documented -- we would need to add a stdout-path options
> > section to relevant UART bindings.
> 
> I don't disagree.
> 
> Current options are fairly well defined and stable, at least for any
> driver that uses uart_parse_options() (documented in
> Documentation/serial/driver).

My concern is that this is Linux specific, other OSes may have different
ideas about how stdout options should be formatted within this property.
(At least I don't know of any standardisation of the 115200n8 thing --
I'd love to be corrected!)

If I were a firmware author I'd be wary of specifying a stdout-path with
a Linux specific suffix.

Search ePAPR for baud it seems that the generic serial binding includes
a current-speed property in 6.2.1.2. It then goes on a bit ambiguously
to talk about the NS16550 in 6.2.2 but I think 6.2.1.2 was intended to
be generic. No mention of stop-bits/parity etc though, they are assumed
to be set already I think

One thought I had was to define a dt-stdout "pseudo-console" so that
console=dt-stdout,115200n8 or something could be used.

Anyway I applied your patch to v3.18-rc5 and ran it on a Mustang and it
didn't work for some reason. I'm using:

fdt set /chosen stdout-path "/soc/serial@1c02:115200"
setenv bootargs "earlycon=uart8250,mmio32,0x1c02 root=/dev/sda3 rw 
debug"

So I get earlycon but then no proper console. Removing earlycon just
makes that stop working.

With:

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 89c6b33..5dc1718 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1840,6 +1840,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 
align))
of_stdout_options = strchr(name, ':');
if (of_stdout_options != NULL)
of_stdout_options++;
+   printk(KERN_CRIT "%s: name=%s of_stdout=%p 
options=%s\n",
+  __func__, name, of_stdout, of_stdout_options);
}
}
 

I can see in dmesg:
[0.00] of_alias_scan: name=/soc/serial@1c02:115200 of_stdout=   
   (null) options=115200

So it seems like of_find_node_by_path() is confused by the ":".

I've not tried it but I'd have expected something more like:
if (name) {
of_stdout_options = strchr(name, ':');
if (of_stdout_options != NULL) {
*of_stdout_options = '0';
of_stdout_options++;
}
of_stdout = of_find_node_by_path(name);
}

i.e. strip the options then do the patch lookup. name is const so this
won't actually work, but something like 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: [RFC PATCH 1/1] arm64: Fix up /proc/cpuinfo

[Ian Campbell]

On Thu, 2014-10-30 at 17:15 +, Will Deacon wrote:
> Hi Mark,
> 
> On Fri, Oct 24, 2014 at 02:56:40PM +0100, Mark Rutland wrote:
> > Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
> > attempted to clean up /proc/cpuinfo, but due to concerns regarding
> > further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
> > cpuinfo: print info for all CPUs").
> 
> I've applied this on our devel branch, with a view to queuing it for -next
> in a week or two. I think we should also CC stable on this, so could you
> see how far back it applies please? (note that I already had to resolve
> a conflict with a patch we've got queued from Ard).



Since we'll be shipping 3.16 in our next release I'd love to see it go
back at least as far as that ;-)

(I'd likely apply it myself even if it doesn't appear via stable).

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 0/2] xen: Switch to virtual mapped linear p2m list

[Ian Campbell]

On Tue, 2014-10-28 at 06:00 +0100, Juergen Gross wrote:
> On 10/27/2014 04:16 PM, David Vrabel wrote:
> > On 27/10/14 14:52, Juergen Gross wrote:
> >> Paravirtualized kernels running on Xen use a three level tree for
> >> translation of guest specific physical addresses to machine global
> >> addresses. This p2m tree is used for construction of page table
> >> entries, so the p2m tree walk is performance critical.
> >>
> >> By using a linear virtual mapped p2m list accesses to p2m elements
> >> can be sped up while even simplifying code. To achieve this goal
> >> some p2m related initializations have to be performed later in the
> >> boot process, as the final p2m list can be set up only after basic
> >> memory management functions are available.
> >
> > What impact does this have on 32-bit guests which don't have huge amount
> > of virtual address space?
> >
> > I think a 32-bit guest could have up to 64 GiB of PFNs, which would
> > require a 128 MiB p2m array, which is too large?
> 
> It is 64 MB (one entry on 32 bit is 32 bits :-) ).
> 
> With a m2p array of only 16 MB size I doubt a 32 bit guest can be larger
> than 16 GB, or am I wrong here?

I think they can be bigger, the compat r/o m2p is 168MB, since Xen
doesn't need to be in the hole as well (like it was with a real 32-bit
Xen). There is also some scope for dynamic sizing of the hole (queried
via XENMEM_machphys_mapping), I'm not sure if pvops makes use of that
though.

In practice a 32-bit kernel starts to get pretty unhappy somewhere
between 32 and 64GB because it runs out of low memory for various
structures which are sized according to the amount of RAM. Or it did,
it's been years since I've tried, maybe things are more able to use
highmem now. In any case if you have such large amounts of RAM using a
64-bit kernel would be advisable.

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/7] [RFC] arm/arm64: introduce is_dma_coherent

[Ian Campbell]

On Sat, 2014-10-25 at 14:29 +0100, Stefano Stabellini wrote:
>  
> Your suggestions and looking more at the code gave me another idea, that
> I think is clean and at the same time suitable for 3.18.
> What do you think of the following? It is simple, self-contained and
> doesn't need a new flag in struct device.

of_dma_is_coherent looks to be quite expensive though (walks up the
Device Tree doing strcmps on each property of each node until it finds
the one it is looking for.

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 5/6] xen/arm/arm64: introduce xen_arch_need_swiotlb

[Ian Campbell]

On Thu, 2014-10-23 at 18:27 +0100, Stefano Stabellini wrote:
> Introduce an arch specific function to find out whether a particular dma
> mapping operation needs to bounce on the swiotlb buffer.
> 
> On ARM and ARM64, if the page involved is a foreign page and the device
> is not coherent, we need to bounce because at unmap time we cannot
> execute any required cache maintenance operations (we don't know how to
> find the pfn from the mfn).
> 
> No change of behaviour for x86.
> 
> Signed-off-by: Stefano Stabellini 

Your tab stops are messed up on almost every new line you added. Looks 
like you have ts=4 or something.

The actual changes look ok though, so with the coding style fixed you
can add:
Acked-by: Ian Campbell 

> 
> ---
> 
> Changes in v5:
> - fix indentation.
> ---
>  arch/arm/include/asm/xen/page.h |4 
>  arch/arm/xen/mm.c   |7 +++
>  arch/x86/include/asm/xen/page.h |7 +++
>  drivers/xen/swiotlb-xen.c   |5 -
>  4 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 135c24a..fb7839d 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -107,4 +107,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, 
> unsigned long mfn)
>  #define xen_remap(cookie, size) ioremap_cache((cookie), (size))
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +unsigned long pfn,
> +unsigned long mfn);
> +
>  #endif /* _ASM_ARM_XEN_PAGE_H */
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index 659e1c3..728c245 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -140,6 +140,13 @@ void xen_dma_sync_single_for_device(struct device *hwdev,
>   __xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }
>  
> +bool xen_arch_need_swiotlb(struct device *dev,
> +unsigned long pfn,
> +unsigned long mfn)
> +{
> + return ((pfn != mfn) && !xen_is_dma_coherent(dev));
> +}
> +
>  int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
>unsigned int address_bits,
>dma_addr_t *dma_handle)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index c949923..800b6a9 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -236,4 +236,11 @@ void make_lowmem_page_readwrite(void *vaddr);
>  #define xen_remap(cookie, size) ioremap((cookie), (size));
>  #define xen_unmap(cookie) iounmap((cookie))
>  
> +static inline bool xen_arch_need_swiotlb(struct device *dev,
> +  unsigned long pfn,
> +  unsigned long mfn)
> +{
> + return false;
> +}
> +
>  #endif /* _ASM_X86_XEN_PAGE_H */
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ebd8f21..ac0bd60 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -399,7 +399,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, 
> struct page *page,
>* buffering it.
>*/
>   if (dma_capable(dev, dev_addr, size) &&
> - !range_straddles_page_boundary(phys, size) && !swiotlb_force) {
> + !range_straddles_page_boundary(phys, size) &&
> + !xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) 
> &&
> + !swiotlb_force) {
>   /* we are not interested in the dma_addr returned by
>* xen_dma_map_page, only in the potential cache flushes 
> executed
>* by the function. */
> @@ -557,6 +559,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct 
> scatterlist *sgl,
>   dma_addr_t dev_addr = xen_phys_to_bus(paddr);
>  
>   if (swiotlb_force ||
> + xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), 
> PFN_DOWN(dev_addr)) ||
>   !dma_capable(hwdev, dev_addr, sg->length) ||
>   range_straddles_page_boundary(paddr, sg->length)) {
>   phys_addr_t map = swiotlb_tbl_map_single(hwdev,


--
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 4/6] xen/arm/arm64: merge xen/mm32.c into xen/mm.c

[Ian Campbell]

On Thu, 2014-10-23 at 18:27 +0100, Stefano Stabellini wrote:
> Merge xen/mm32.c into xen/mm.c.
> As a consequence the code gets compiled on arm64 too: introduce a few
> compat functions to actually be able to compile it.
> Introduce xen_is_dma_coherent on arm64 and call into the dma_ops
> functions from the xen_dma wrappers in page-coherent.h to handle
> non-coherent devices.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 


--
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 3/6] xen/arm: introduce xen_is_dma_coherent

[Ian Campbell]

On Thu, 2014-10-23 at 18:27 +0100, Stefano Stabellini wrote:
> Introduce a utility function to check whether a device is dma coherent.
> The current implementation is suboptimal. Let's rework it later in
> common arch/arm code.
> 
> Use it to figure out whether we need to issue cache maintenance
> operations instead of checking on the existence of a particular dma_ops
> function for the device.
> 
> Signed-off-by: Stefano Stabellini 

As well as refactoring this also changes the nature of the test, making
it tighter AFAICT. Perhaps it is the same because you happen to know
that arm_coherent_dma_ops is the only possible one which doesn't set the
hooks you were checking before.

Either way this should be mentioned in the commit log. With that done:

Acked-by: Ian Campbell 

> 
> ---
> 
> Changes in v5:
> - introduce xen_is_dma_coherent as a xen specific function;
> - call xen_is_dma_coherent instead of is_dma_coherent.
> ---
>  arch/arm/include/asm/xen/page-coherent.h |5 +
>  arch/arm/xen/mm32.c  |6 +++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h 
> b/arch/arm/include/asm/xen/page-coherent.h
> index e8275ea..6f0f882 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -5,6 +5,11 @@
>  #include 
>  #include 
>  
> +static inline bool xen_is_dma_coherent(struct device *dev)
> +{
> +return (__generic_dma_ops(dev) == &arm_coherent_dma_ops);
> +}
> + 
>  static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t 
> size,
>   dma_addr_t *dma_handle, gfp_t flags,
>   struct dma_attrs *attrs)
> diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
> index 6153d61..6c0224e 100644
> --- a/arch/arm/xen/mm32.c
> +++ b/arch/arm/xen/mm32.c
> @@ -76,7 +76,7 @@ void xen_dma_unmap_page(struct device *hwdev, dma_addr_t 
> handle,
>   struct dma_attrs *attrs)
>  
>  {
> - if (!__generic_dma_ops(hwdev)->unmap_page)
> + if (xen_is_dma_coherent(hwdev))
>   return;
>   if (dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
>   return;
> @@ -87,7 +87,7 @@ void xen_dma_unmap_page(struct device *hwdev, dma_addr_t 
> handle,
>  void xen_dma_sync_single_for_cpu(struct device *hwdev,
>   dma_addr_t handle, size_t size, enum dma_data_direction dir)
>  {
> - if (!__generic_dma_ops(hwdev)->sync_single_for_cpu)
> + if (xen_is_dma_coherent(hwdev))
>   return;
>   __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
>  }
> @@ -95,7 +95,7 @@ void xen_dma_sync_single_for_cpu(struct device *hwdev,
>  void xen_dma_sync_single_for_device(struct device *hwdev,
>   dma_addr_t handle, size_t size, enum dma_data_direction dir)
>  {
> - if (!__generic_dma_ops(hwdev)->sync_single_for_device)
> + if (xen_is_dma_coherent(hwdev))
>   return;
>   __xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
>  }


--
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 2/6] xen/arm: remove outer_*_range call

[Ian Campbell]

On Thu, 2014-10-23 at 18:27 +0100, Stefano Stabellini wrote:
> Dom0 is not actually capable of issuing outer_inv_range or
> outer_clean_range calls.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 


--
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 7/7] xen/arm: introduce GNTTABOP_cache_flush

[Ian Campbell]

On Fri, 2014-10-10 at 12:51 +0100, Stefano Stabellini wrote:
> Introduce support for new hypercall GNTTABOP_cache_flush.
> Use it to perform cache flashing on pages used for dma when necessary.
> 
> If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to
> bounce dma map operations that involve foreign grants and non-coherent
> devices.
> 
> Signed-off-by: Stefano Stabellini 
> 
> ---
> 
> Changes in v4:
> - add comment;
> - avoid bouncing dma map operations that involve foreign grants and
> non-coherent devices if GNTTABOP_cache_flush is provided by Xen.
> 
> Changes in v3:
> - fix the cache maintenance op call to match what Linux does natively;
> - update the hypercall interface to match Xen.
> 
> Changes in v2:
> - update the hypercall interface to match Xen;
> - call the interface on a single page at a time.
> ---
>  arch/arm/xen/mm.c   |   41 
> ++-
>  include/xen/interface/grant_table.h |   19 
>  2 files changed, 54 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index 0c2a75a..21db123 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -11,6 +11,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -44,6 +45,8 @@ static inline void *kmap_high_get(struct page *page)
>  static inline void kunmap_high(struct page *page) {}
>  #endif
>  
> +static bool hypercall_flush = false;

Would be nice to include the word "cache" (or at least cflush) in this.

> -arch_initcall(xen_mm_init);
> +arch_initcall(xen_mm_init)

I think this is stray?

Acked-by: Ian Campbell 

--
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 5/7] xen/arm/arm64: merge xen/mm32.c into xen/mm.c

[Ian Campbell]

On Fri, 2014-10-10 at 12:51 +0100, Stefano Stabellini wrote:
> Merge xen/mm32.c into xen/mm.c.
> As a consequence the code gets compiled on arm64 too: introduce a few
> compat functions to actually be able to compile it.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 


--
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 4/7] xen/arm: use is_dma_coherent

[Ian Campbell]

On Fri, 2014-10-10 at 12:51 +0100, Stefano Stabellini wrote:
> Use is_dma_coherent to check whether we need to issue cache maintenance
> operations rather than checking on the existence of a particular
> dma_ops function for the device.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Ian Campbell 


--
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 1/7] xen/arm: remove handling of XENFEAT_grant_map_identity

[Ian Campbell]

On Fri, 2014-10-10 at 12:51 +0100, Stefano Stabellini wrote:
> The feature has been removed from Xen. Also Linux cannot use it on ARM32
> without CONFIG_ARM_LPAE.
> 
> Signed-off-by: Stefano Stabellini 
> Reviewed-by: David Vrabel 

Acked-by: Ian Campbell 


--
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 v2 2/2] xen/arm: introduce GNTTABOP_cache_flush

[Ian Campbell]

On Fri, 2014-10-03 at 17:20 +0100, Stefano Stabellini wrote:
> On Fri, 3 Oct 2014, David Vrabel wrote:
> > On 03/10/14 15:53, Stefano Stabellini wrote:
> > > Introduce support for new hypercall GNTTABOP_cache_flush.
> > > Use it to perform cache flashing on pages used for dma when necessary.
> > [..]
> > >  /* functions called by SWIOTLB */
> > > @@ -22,16 +25,31 @@ static void dma_cache_maint(dma_addr_t handle, 
> > > unsigned long offset,
> > >   size_t len = left;
> > >   void *vaddr;
> > >   
> > > + if (len + offset > PAGE_SIZE)
> > > + len = PAGE_SIZE - offset;
> > > +
> > >   if (!pfn_valid(pfn))
> > >   {
> > > - /* TODO: cache flush */
> > > + struct gnttab_cache_flush cflush;
> > > +
> > > + cflush.op = 0;
> > > + cflush.a.dev_bus_addr = pfn << PAGE_SHIFT;
> > > + cflush.offset = offset;
> > > + cflush.size = len;
> > > +
> > > + if (op == dmac_unmap_area && dir != DMA_TO_DEVICE)
> > > + cflush.op = GNTTAB_CACHE_INVAL;
> > > + if (op == dmac_map_area) {
> > > + cflush.op = GNTTAB_CACHE_CLEAN;
> > > + if (dir == DMA_FROM_DEVICE)
> > > + cflush.op |= GNTTAB_CACHE_INVAL;
> > > + }
> > 
> > Are all these cache operations needed?  You do a clean on map regardless
> > of the direction and INVAL on map seems unnecessary.

Isn't the inval on map so that the processor doesn't decide to
evict/clean the cache line all over your newly DMA'd data?

> > I would have thought it would be:
> > 
> > map && (TO_DEVICE || BOTH)
> >op = CLEAN
> > 
> > unmap && (FROM_DEVICE || BOTH)
> >op = INVAL
> 
> I was trying to do the same thing Linux is already doing on native to
> stay on the safe side.
> 
> See arch/arm/mm/cache-v7.S:v7_dma_map_area and
> arch/arm/mm/cache-v7.S:v7_dma_unmap_area.
> 
> Unless I misread the assembly they should match.

I think you have, beq doesn't set lr, so the called function will return
to its "grandparent". i.e. the caller of v7_dma_map_area in this case
(which will have used bl), so:
ENTRY(v7_dma_map_area)
add r1, r1, r0
teq r2, #DMA_FROM_DEVICE
beq v7_dma_inv_range
b   v7_dma_clean_range
ENDPROC(v7_dma_map_area)

Is actually
if (dir == from device)
inv
else
clean

which makes much more sense I think.


> 
> 
> > > --- a/include/xen/interface/grant_table.h
> > > +++ b/include/xen/interface/grant_table.h
> > > @@ -479,6 +479,24 @@ struct gnttab_get_version {
> > >  DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
> > >  
> > >  /*
> > > + * Issue one or more cache maintenance operations on a portion of a
> > > + * page granted to the calling domain by a foreign domain.
> > > + */
> > > +#define GNTTABOP_cache_flush  12
> > > +struct gnttab_cache_flush {
> > > +union {
> > > +uint64_t dev_bus_addr;
> > > +grant_ref_t ref;
> > > +} a;
> > > +uint32_t offset; /* offset from start of grant */
> > > +uint32_t size;   /* size within the grant */
> > > +#define GNTTAB_CACHE_CLEAN  (1<<0)
> > > +#define GNTTAB_CACHE_INVAL  (1<<1)
> > > +uint32_t op;
> > > +};
> > > +DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
> > > +
> > > +/*
> > >   * Bitfield values for update_pin_status.flags.
> > >   */
> > >   /* Map the grant entry for access by I/O devices. */
> > 
> > If the ARM bits are correct, have a
> > 
> > Reviewed-by: David Vrabel 
> > 
> > for the common header.
> > 
> > David
> > 


--
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] xen-pciback: Add MODULE_ALIAS for pciback.

[Ian Campbell]

On Wed, 2014-08-20 at 13:20 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 20, 2014 at 06:18:52PM +0100, Ian Campbell wrote:
> > On Wed, 2014-08-20 at 12:40 -0400, Konrad Rzeszutek Wilk wrote:
> > > The rest of the Xen device drivers use an module alias
> > > to load devices when they shop up in XenBus.
> > 
> > "show".
> > >  
> > >  MODULE_LICENSE("Dual BSD/GPL");
> > >  MODULE_ALIAS("xen-backend:pci");
> > > +MODULE_ALIAS("xen:pci");
> > 
> > Isn't that xen-backend:pci already the right thing for a backend device?
> > xen: is for frontends, I thought.
> 
> Oh, you are right. Cool! Thanks!

The patch turned out to be even more trivial than expected ;-)

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] xen-pciback: Add MODULE_ALIAS for pciback.

[Ian Campbell]

On Wed, 2014-08-20 at 12:40 -0400, Konrad Rzeszutek Wilk wrote:
> The rest of the Xen device drivers use an module alias
> to load devices when they shop up in XenBus.

"show".
>  
>  MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_ALIAS("xen-backend:pci");
> +MODULE_ALIAS("xen:pci");

Isn't that xen-backend:pci already the right thing for a backend device?
xen: is for frontends, I thought.

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/