Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 3/3] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-06 19:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-1-f.fainelli@gmail.com>

x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
virt_to_phys calls. The goal is to catch users who are calling
virt_to_phys on non-linear addresses immediately. This includes caller
using __virt_to_phys() on image addresses instead of __pa_symbol(). This
is a generally useful debug feature to spot bad code (particulary in
drivers).

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/Kconfig              |  1 +
 arch/arm/include/asm/memory.h | 16 ++++++++++++--
 arch/arm/mm/Makefile          |  1 +
 arch/arm/mm/physaddr.c        | 51 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 67 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mm/physaddr.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..5e66173c5787 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2,6 +2,7 @@ config ARM
 	bool
 	default y
 	select ARCH_CLOCKSOURCE_DATA
+	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index bee7511c5098..46f192218be7 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -213,7 +213,7 @@ extern const void *__pv_table_begin, *__pv_table_end;
 	: "r" (x), "I" (__PV_BITS_31_24)		\
 	: "cc")
 
-static inline phys_addr_t __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
 {
 	phys_addr_t t;
 
@@ -245,7 +245,7 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
 #define PHYS_OFFSET	PLAT_PHYS_OFFSET
 #define PHYS_PFN_OFFSET	((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
 
-static inline phys_addr_t __virt_to_phys(unsigned long x)
+static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
 {
 	return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
 }
@@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
 	((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
 	 PHYS_PFN_OFFSET)
 
+#define __pa_symbol_nodebug(x)	((x) - (unsigned long)KERNEL_START)
+
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __virt_to_phys(unsigned long x);
+extern phys_addr_t __phys_addr_symbol(unsigned long x);
+#else
+#define __virt_to_phys(x)	__virt_to_phys_nodebug(x)
+#define __phys_addr_symbol(x)	__pa_symbol_nodebug(x)
+#endif
+
 /*
  * These are *only* valid on the kernel direct mapped RAM memory.
  * Note: Drivers should NOT use these.  They are the wrong
@@ -283,9 +293,11 @@ static inline void *phys_to_virt(phys_addr_t x)
  * Drivers should NOT use these either.
  */
 #define __pa(x)			__virt_to_phys((unsigned long)(x))
+#define __pa_symbol(x)		__phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
 #define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)	__va((phys_addr_t)(pfn) << PAGE_SHIFT)
 
+
 extern long long arch_phys_to_idmap_offset;
 
 /*
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index e8698241ece9..b3dea80715b4 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -14,6 +14,7 @@ endif
 
 obj-$(CONFIG_ARM_PTDUMP)	+= dump.o
 obj-$(CONFIG_MODULES)		+= proc-syms.o
+obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
 
 obj-$(CONFIG_ALIGNMENT_TRAP)	+= alignment.o
 obj-$(CONFIG_HIGHMEM)		+= highmem.o
diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c
new file mode 100644
index 000000000000..00f6dcffab8b
--- /dev/null
+++ b/arch/arm/mm/physaddr.c
@@ -0,0 +1,51 @@
+#include <linux/bug.h>
+#include <linux/export.h>
+#include <linux/types.h>
+#include <linux/mmdebug.h>
+#include <linux/mm.h>
+
+#include <asm/sections.h>
+#include <asm/memory.h>
+#include <asm/fixmap.h>
+
+#include "mm.h"
+
+static inline bool __virt_addr_valid(unsigned long x)
+{
+	if (x < PAGE_OFFSET)
+		return false;
+	if (arm_lowmem_limit && is_vmalloc_or_module_addr((void *)x))
+		return false;
+	if (x >= FIXADDR_START && x < FIXADDR_END)
+		return false;
+	return true;
+}
+
+phys_addr_t __virt_to_phys(unsigned long x)
+{
+	WARN(!__virt_addr_valid(x),
+	     "virt_to_phys used for non-linear address :%pK\n", (void *)x);
+
+	return __virt_to_phys_nodebug(x);
+}
+EXPORT_SYMBOL(__virt_to_phys);
+
+static inline bool __phys_addr_valid(unsigned long x)
+{
+	/* This is bounds checking against the kernel image only.
+	 * __pa_symbol should only be used on kernel symbol addresses.
+	 */
+	if (x < (unsigned long)KERNEL_START ||
+	    x > (unsigned long)KERNEL_END)
+		return false;
+
+	return true;
+}
+
+phys_addr_t __phys_addr_symbol(unsigned long x)
+{
+	VIRTUAL_BUG_ON(!__phys_addr_valid(x));
+
+	return __pa_symbol_nodebug(x);
+}
+EXPORT_SYMBOL(__phys_addr_symbol);
-- 
2.9.3

^ permalink raw reply related

* [PATCH] arm/arm64: KVM: Check for properly initialized timer on init
From: Christoffer Dall @ 2016-12-06 19:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1ed187ba-965b-6087-f74f-68627f0d0504@arm.com>

On Tue, Dec 06, 2016 at 11:25:42AM +0000, Marc Zyngier wrote:
> On 05/12/16 09:32, Christoffer Dall wrote:
> > When the arch timer code fails to initialize (for example because the
> > memory mapped timer doesn't work, which is currently seen with the AEM
> > model), then KVM just continues happily with a final result that KVM
> > eventually does a NULL pointer dereference of the uninitialized cycle
> > counter.
> > 
> > Check directly for this in the init path and give the user a reasonable
> > error in this case.
> > 
> > Cc: Shih-Wei Li <shihwei@cs.columbia.edu>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> >  virt/kvm/arm/arch_timer.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 27a1f63..5c12f53 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -425,6 +425,11 @@ int kvm_timer_hyp_init(void)
> >  	info = arch_timer_get_kvm_info();
> >  	timecounter = &info->timecounter;
> >  
> > +	if (!timecounter->cc) {
> > +		kvm_err("arch_timer: uninitialized timecounter\n");
> 
> For consistency, I'll change the error message to say "kvm_arch_timer",
> just like the below case.
> 

No objections, only problem is that the patch you queued uses
kcm_arch_timer ;)

> > +		return -ENODEV;
> > +	}
> > +
> >  	if (info->virtual_irq <= 0) {
> >  		kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
> >  			info->virtual_irq);
> > 
> 
> Otherwise looks good to me. I'll queue it now.
> 

Thanks,
-Christoffer

^ permalink raw reply

* [PATCH 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Jon Mason @ 2016-12-06 19:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-3-zajec5@gmail.com>

On Tue, Dec 06, 2016 at 06:17:12PM +0100, Rafa? Mi?ecki wrote:
> There is one GPIO controlling power for both USB ports.
> 
> Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>

Was the double Signed-off-by intentional?

> ---
>  arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 0225d82..7ab1176 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -100,3 +100,11 @@
>  		};
>  	};
>  };
> +
> +&usb2 {
> +	vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb3 {
> +	vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> +};
> -- 
> 2.10.1
> 

^ permalink raw reply

* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Jon Mason @ 2016-12-06 20:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206171714.22738-4-zajec5@gmail.com>

On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
> 
> So far we were specifying only the first block which is always limited
> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.

Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
ways to access the first 128M of RAM, a proxy starting at address 0
and the real address.  I think you are splitting RAM by accessing it
both ways, when you really should just be accessing it at the real
address.

Thanks,
Jon

> 
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> ---
>  arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts        | 3 ++-
>  arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts        | 3 ++-
>  arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts  | 3 ++-
>  arch/arm/boot/dts/bcm4708-netgear-r6250.dts        | 3 ++-
>  arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts     | 3 ++-
>  arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts      | 3 ++-
>  arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts        | 3 ++-
>  arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
>  arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts  | 3 ++-
>  arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts        | 3 ++-
>  arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts  | 3 ++-
>  arch/arm/boot/dts/bcm4709-netgear-r7000.dts        | 3 ++-
>  arch/arm/boot/dts/bcm4709-netgear-r8000.dts        | 3 ++-
>  arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts      | 3 ++-
>  arch/arm/boot/dts/bcm47094-netgear-r8500.dts       | 3 ++-
>  15 files changed, 30 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 112a5a8..d241cee 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 3600f56..b0e6204 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index d49afec0..c9ba6b9 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x18000000>;
>  	};
>  
>  	spi {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8519548..b9f66c0 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> index 6229ef2..ae0199f 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 74cfcd3..36b628b1 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> index 71b98cf..db8608b 100644
> --- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> +++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index 2922536..d51586d 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	spi {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> index 184fd92..de041b8 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	gpio-keys {
> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> index eac0f52..eaca687 100644
> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> index aab39c9..b32957c 100644
> --- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> +++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x18000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 7ab1176..f459a98 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 56d38a3..cd13534 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 7fb9270..64ded76 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -21,7 +21,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x08000000>;
>  	};
>  
>  	nand: nand at 18028000 {
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 7ecd57c..600795e 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -18,7 +18,8 @@
>  	};
>  
>  	memory {
> -		reg = <0x00000000 0x08000000>;
> +		reg = <0x00000000 0x08000000
> +		       0x88000000 0x18000000>;
>  	};
>  
>  	leds {
> -- 
> 2.10.1
> 

^ permalink raw reply

* [PATCHv4 09/10] mm/usercopy: Switch to using lm_alias
From: Kees Cook @ 2016-12-06 20:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206181859.GH24177@leverpostej>

On Tue, Dec 6, 2016 at 10:18 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Nov 29, 2016 at 11:39:44AM -0800, Kees Cook wrote:
>> On Tue, Nov 29, 2016 at 10:55 AM, Laura Abbott <labbott@redhat.com> wrote:
>> >
>> > The usercopy checking code currently calls __va(__pa(...)) to check for
>> > aliases on symbols. Switch to using lm_alias instead.
>> >
>> > Signed-off-by: Laura Abbott <labbott@redhat.com>
>>
>> Acked-by: Kees Cook <keescook@chromium.org>
>>
>> I should probably add a corresponding alias test to lkdtm...
>>
>> -Kees
>
> Something like the below?
>
> It uses lm_alias(), so it depends on Laura's patches. We seem to do the
> right thing, anyhow:

Cool, this looks good. What happens on systems without an alias?

Laura, feel free to add this to your series:

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

>
> root at ribbensteg:/home/nanook# echo USERCOPY_KERNEL_ALIAS > /sys/kernel/debug/provoke-crash/DIRECT
> [   44.493400] usercopy: kernel memory exposure attempt detected from ffff80000031a730 (<linear kernel text>) (4096 bytes)
> [   44.504263] kernel BUG at mm/usercopy.c:75!
>
> Thanks,
> Mark.
>
> ---->8----
> diff --git a/drivers/misc/lkdtm.h b/drivers/misc/lkdtm.h
> index fdf954c..96d8d76 100644
> --- a/drivers/misc/lkdtm.h
> +++ b/drivers/misc/lkdtm.h
> @@ -56,5 +56,6 @@
>  void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
>  void lkdtm_USERCOPY_STACK_BEYOND(void);
>  void lkdtm_USERCOPY_KERNEL(void);
> +void lkdtm_USERCOPY_KERNEL_ALIAS(void);
>
>  #endif
> diff --git a/drivers/misc/lkdtm_core.c b/drivers/misc/lkdtm_core.c
> index f9154b8..f6bc6d6 100644
> --- a/drivers/misc/lkdtm_core.c
> +++ b/drivers/misc/lkdtm_core.c
> @@ -228,6 +228,7 @@ struct crashtype crashtypes[] = {
>         CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
>         CRASHTYPE(USERCOPY_STACK_BEYOND),
>         CRASHTYPE(USERCOPY_KERNEL),
> +       CRASHTYPE(USERCOPY_KERNEL_ALIAS),
>  };
>
>
> diff --git a/drivers/misc/lkdtm_usercopy.c b/drivers/misc/lkdtm_usercopy.c
> index 1dd6114..955f2dc 100644
> --- a/drivers/misc/lkdtm_usercopy.c
> +++ b/drivers/misc/lkdtm_usercopy.c
> @@ -279,9 +279,16 @@ void lkdtm_USERCOPY_STACK_BEYOND(void)
>         do_usercopy_stack(true, false);
>  }
>
> -void lkdtm_USERCOPY_KERNEL(void)
> +static void do_usercopy_kernel(bool use_alias)
>  {
>         unsigned long user_addr;
> +       const void *rodata = test_text;
> +       void *text = vm_mmap;
> +
> +       if (use_alias) {
> +               rodata = lm_alias(rodata);
> +               text = lm_alias(text);
> +       }
>
>         user_addr = vm_mmap(NULL, 0, PAGE_SIZE,
>                             PROT_READ | PROT_WRITE | PROT_EXEC,
> @@ -292,14 +299,14 @@ void lkdtm_USERCOPY_KERNEL(void)
>         }
>
>         pr_info("attempting good copy_to_user from kernel rodata\n");
> -       if (copy_to_user((void __user *)user_addr, test_text,
> +       if (copy_to_user((void __user *)user_addr, rodata,
>                          unconst + sizeof(test_text))) {
>                 pr_warn("copy_to_user failed unexpectedly?!\n");
>                 goto free_user;
>         }
>
>         pr_info("attempting bad copy_to_user from kernel text\n");
> -       if (copy_to_user((void __user *)user_addr, vm_mmap,
> +       if (copy_to_user((void __user *)user_addr, text,
>                          unconst + PAGE_SIZE)) {
>                 pr_warn("copy_to_user failed, but lacked Oops\n");
>                 goto free_user;
> @@ -309,6 +316,16 @@ void lkdtm_USERCOPY_KERNEL(void)
>         vm_munmap(user_addr, PAGE_SIZE);
>  }
>
> +void lkdtm_USERCOPY_KERNEL(void)
> +{
> +       do_usercopy_kernel(false);
> +}
> +
> +void lkdtm_USERCOPY_KERNEL_ALIAS(void)
> +{
> +       do_usercopy_kernel(true);
> +}
> +
>  void __init lkdtm_usercopy_init(void)
>  {
>         /* Prepare cache that lacks SLAB_USERCOPY flag. */



-- 
Kees Cook
Nexus Security

^ permalink raw reply

* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-06 20:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <aac9391d-8803-f5e8-f4e4-d7e56d54c05c@redhat.com>

On Tue, Dec 06, 2016 at 02:46:00PM -0500, Jon Masters wrote:
> On 12/05/2016 04:21 PM, Bjorn Helgaas wrote:
> > On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote:
> 
> >>> Even without this patch, I don't think it's a show-stopper to have
> >>> Linux mistakenly thinking this region is routed to PCI, because the
> >>> driver does reserve it and the PCI core will never try to use it.
> >>
> >> Ok. So are you happy with pulling in Duc's v4 patch and retaining
> >> status quo on the bridge resources for 4.10?
> > 
> > Yes, I think it looks good.  I'll finish packaging things up and
> > repost the current series.
> 
> Ok, great. So you're still pretty confident we'll have "out of the box"
> booting on these machines for 4.10? :)

I just merged pci/ecam into my "next" branch, so as long as tomorrow's
linux-next boots out of the box, we should be set.  I made the following
changes compared to v11:

  - dropped the x86 change to use acpi_resource_consumer()
  - added parens around macro args used in arithmetic expressions
  - renamed "seg" to "node" in THUNDER_PEM_RES and THUNDER_PEM_QUIRK
  - incorporated (u64) cast and dropped "UL" postfix for THUNDER_PEM_QUIRK

Let me know if you see any issues.

Bjorn

^ permalink raw reply

* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-06 20:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206201835.GA19700@bhelgaas-glaptop.roam.corp.google.com>

On 12/06/2016 03:18 PM, Bjorn Helgaas wrote:
> On Tue, Dec 06, 2016 at 02:46:00PM -0500, Jon Masters wrote:
>> On 12/05/2016 04:21 PM, Bjorn Helgaas wrote:
>>> On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote:
>>
>>>>> Even without this patch, I don't think it's a show-stopper to have
>>>>> Linux mistakenly thinking this region is routed to PCI, because the
>>>>> driver does reserve it and the PCI core will never try to use it.
>>>>
>>>> Ok. So are you happy with pulling in Duc's v4 patch and retaining
>>>> status quo on the bridge resources for 4.10?
>>>
>>> Yes, I think it looks good.  I'll finish packaging things up and
>>> repost the current series.
>>
>> Ok, great. So you're still pretty confident we'll have "out of the box"
>> booting on these machines for 4.10? :)
> 
> I just merged pci/ecam into my "next" branch, so as long as tomorrow's
> linux-next boots out of the box, we should be set.  I made the following
> changes compared to v11:
> 
>   - dropped the x86 change to use acpi_resource_consumer()
>   - added parens around macro args used in arithmetic expressions
>   - renamed "seg" to "node" in THUNDER_PEM_RES and THUNDER_PEM_QUIRK
>   - incorporated (u64) cast and dropped "UL" postfix for THUNDER_PEM_QUIRK
> 
> Let me know if you see any issues.

Thanks - I'll test linux-next tomorrow.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

^ permalink raw reply

* [stable:PATCH 0/3] PAN fixes backport for v4.8.12
From: Greg KH @ 2016-12-06 20:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206190454.19083-1-james.morse@arm.com>

On Tue, Dec 06, 2016 at 07:04:51PM +0000, James Morse wrote:
> Hi Greg, linux-stable,
> 
> This is the backport of the recent PAN fixes series for v4.8.
> Original series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
> 
> Next time I will remember to work backwards through stable versions.
> Sorry for the confusion!

Not a problem, many thanks for these, all now queued up.

greg k-h

^ permalink raw reply

* [stable:PATCH 0/3] PAN fixes backport for v4.4.35
From: Greg KH @ 2016-12-06 20:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161202164247.19496-1-james.morse@arm.com>

On Fri, Dec 02, 2016 at 04:42:44PM +0000, James Morse wrote:
> Hi linux-stable,
> 
> This is the backport of the recent PAN fixes series for v4.4.35.
> Original series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
> 
> Patch 1 changes the prototype of all the feature/errata enable calls, so
> is fiddly to backport, hence doing it later as a separate series.
> 
> Patch 3 has had the UAO desription removed from its commit message as
> v4.4 doesn't support this feature.

Thanks, now all queued up.

greg k-h

^ permalink raw reply

* [PATCH 3/3] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-06 20:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-4-f.fainelli@gmail.com>

On 12/06/2016 11:53 AM, Florian Fainelli wrote:
> x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
> virt_to_phys calls. The goal is to catch users who are calling
> virt_to_phys on non-linear addresses immediately. This includes caller
> using __virt_to_phys() on image addresses instead of __pa_symbol(). This
> is a generally useful debug feature to spot bad code (particulary in
> drivers).
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---

> @@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>  	((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
>  	 PHYS_PFN_OFFSET)
>  
> +#define __pa_symbol_nodebug(x)	((x) - (unsigned long)KERNEL_START)

I don't think I got this one quite right, but I also assume that won't
be the only problem with this patch series.
-- 
Florian

^ permalink raw reply

* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Rafał Miłecki @ 2016-12-06 20:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206200621.GB2768@broadcom.com>

On 6 December 2016 at 21:06, Jon Mason <jon.mason@broadcom.com> wrote:
> On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>
>> So far we were specifying only the first block which is always limited
>> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
>
> Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
> ways to access the first 128M of RAM, a proxy starting at address 0
> and the real address.  I think you are splitting RAM by accessing it
> both ways, when you really should just be accessing it at the real
> address.

I need some more help, please.

This patch (quite well tested) confirms that 0x88000000 can be used to
access RAM at offset 128 MiB. If this is a real address and whole
space is contiguous, it means the base real address should be
0x80000000. So using 0x0 and 0x80000000 should allow accessing
beginning of the RAM. I took a device that was working just fine with:
reg = <0x00000000 0x08000000>;
and I replaced it with:
reg = <0x80000000 0x08000000>;
but it broke things, kernel didn't boot with the last message being:
[    0.000000] Memory policy: Data cache writealloc

I can see that bcm958525er.dts, bcm958525xmc.dts, bcm958623hr.dts,
bcm958625k.dts bcm988312hr.dts are using 0x60000000 as base address.
It seems to be different from Northstar but I tried following entry
anyway:
reg = <0x60000000 0x08000000>;
and I got kernel hang just like in the previous try.

Did I miss something? Or does Northstar seem to be actually different than NSP?

^ permalink raw reply

* [Question] New mmap64 syscall?
From: Arnd Bergmann @ 2016-12-06 21:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206185440.GA4654@yury-N73SV>

On Wednesday, December 7, 2016 12:24:40 AM CET Yury Norov wrote:

> I see 3 solutions for my problem:
> 1. Reuse aarch64/lp64 mmap code for ilp32 in glibc, but wrap offset with
> SYSCALL_LL64() macro - which converts offset to the pair for 32-bit
> ports. This is simple but local solution. And most probably it's enough.

I wouldn't want arm64 to be different from all other architectures
here for the 32-bit API. The mmap() API used to be done entirely
in architecture specific code, while nowadays at least new architectures
use something resembling sys_mmap_pgoff(). I think that was originally
introduced to be the default API for 32-bit architectures, but it
failed to address architectures with variable page sizes.

> 2. Add new flag to mmap, like MAP_OFFSET_IN_PAIR. This will also work.
> The problem here is that there are too much arches that implement
> their custom sys_mmap2(). And, of course, this type of flags is
> looking ugly.

Right, better not touch make complicate it further. The other problem
is that mmap2() already has six argument and on most architectures
that is the limit for the number of syscall arguments, so you
cannot add another argument for the upper half.

> 3. Introduce new mmap64() syscall like this:
> sys_mmap64(void *addr, size_t len, int prot, int flags, int fd, struct off_pair *off);
> (The pointer here because otherwise we have 7 args, if simply pass off_hi and
> off_lo in registers.)

This wouldn't have to be a pair, just a pointer to a 64-bit number.

> With new 64-bit interface we can deprecate mmap2(), and generalize all
> implementations in kernel.
> 
> I think we can discuss it because 64-bit is the default size for off_t 
> in all new 32-bit architectures. So generic solution may take place.
> 
> The last question here is how important to support offsets bigger than
> 2^44 on 32-bit machines in practice? It may be a case for ARM64 servers,
> which are looking like main aarch64/ilp32 users. If no, we can leave
> things as is, and just do nothing.

If there is a use case for larger than 16TB offsets, we should add
the call on all architectures, probably using your approach 3. I don't
think that we should treat it as anything special for arm64 though.

	Arnd

^ permalink raw reply

* [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Alexey Kardashevskiy @ 2016-12-06 21:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206104343.hb8GsYcB@smtp2j.mail.yandex.net>

On 06/12/16 18:43, Icenowy Zheng wrote:
> 
> 2016?12?6? 09:51? Alexey Kardashevskiy <aik@ozlabs.ru>???
>>
>> On 03/12/16 02:05, Icenowy Zheng wrote: 
>>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a 
>>> SDIO Wi-Fi chip by Allwinner (XR819). 
>>>
>>> Add a device tree file for it. 
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> 
>>> --- 
>>> Changes since v2: 
>>> - Merged SDIO Wi-Fi patch into it. 
>>> - SDIO Wi-Fi: add a ethernet1 alias to it, as it has no internal NVRAM. 
>>> - SDIO Wi-Fi: changed pinctrl binding to generic pinconf 
>>> - removed all gpio pinctrl nodes 
>>> - changed h2plus to h2-plus 
>>> Changes since v1: 
>>> - Convert to generic pinconf bindings. 
>>> - SDIO Wi-Fi: add patch. 
>>>
>>> Some notes: 
>>> - The uart1 and uart2 is available on the unsoldered gpio header. 
>>> - The onboard USB connector has its Vbus directly connected to DCIN-5V (the 
>>>    power jack) 
>>>
>>>   arch/arm/boot/dts/Makefile                        |   1 + 
>>>   arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 159 ++++++++++++++++++++++ 
>>>   2 files changed, 160 insertions(+) 
>>>   create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>>> index 6447abc..59f6e86 100644 
>>> --- a/arch/arm/boot/dts/Makefile 
>>> +++ b/arch/arm/boot/dts/Makefile 
>>> @@ -844,6 +844,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \ 
>>>   sun8i-a33-sinlinx-sina33.dtb \ 
>>>   sun8i-a83t-allwinner-h8homlet-v2.dtb \ 
>>>   sun8i-a83t-cubietruck-plus.dtb \ 
>>> + sun8i-h2-plus-orangepi-zero.dtb \ 
>>>   sun8i-h3-bananapi-m2-plus.dtb \ 
>>>   sun8i-h3-nanopi-neo.dtb \ 
>>>   sun8i-h3-orangepi-2.dtb \ 
>>> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
>>> new file mode 100644 
>>> index 0000000..d18807f 
>>> --- /dev/null 
>>> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
>>> @@ -0,0 +1,159 @@ 
>>> +/* 
>>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz> 
>>> + * 
>>> + * Based on sun8i-h3-orangepi-one.dts, which is: 
>>> + *   Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com> 
>>> + * 
>>> + * This file is dual-licensed: you can use it either under the terms 
>>> + * of the GPL or the X11 license, at your option. Note that this dual 
>>> + * licensing only applies to this file, and not this project as a 
>>> + * whole. 
>>> + * 
>>> + *  a) This file is free software; you can redistribute it and/or 
>>> + *     modify it under the terms of the GNU General Public License as 
>>> + *     published by the Free Software Foundation; either version 2 of the 
>>> + *     License, or (at your option) any later version. 
>>> + * 
>>> + *     This file is distributed in the hope that it will be useful, 
>>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of 
>>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
>>> + *     GNU General Public License for more details. 
>>> + * 
>>> + * Or, alternatively, 
>>> + * 
>>> + *  b) Permission is hereby granted, free of charge, to any person 
>>> + *     obtaining a copy of this software and associated documentation 
>>> + *     files (the "Software"), to deal in the Software without 
>>> + *     restriction, including without limitation the rights to use, 
>>> + *     copy, modify, merge, publish, distribute, sublicense, and/or 
>>> + *     sell copies of the Software, and to permit persons to whom the 
>>> + *     Software is furnished to do so, subject to the following 
>>> + *     conditions: 
>>> + * 
>>> + *     The above copyright notice and this permission notice shall be 
>>> + *     included in all copies or substantial portions of the Software. 
>>> + * 
>>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
>>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES 
>>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 
>>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 
>>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
>>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
>>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 
>>> + *     OTHER DEALINGS IN THE SOFTWARE. 
>>> + */ 
>>> + 
>>> +/dts-v1/; 
>>> +#include "sun8i-h3.dtsi" 
>>> +#include "sunxi-common-regulators.dtsi" 
>>> + 
>>> +#include <dt-bindings/gpio/gpio.h> 
>>> +#include <dt-bindings/input/input.h> 
>>> +#include <dt-bindings/pinctrl/sun4i-a10.h> 
>>> + 
>>> +/ { 
>>> + model = "Xunlong Orange Pi Zero"; 
>>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus"; 
>>> + 
>>> + aliases { 
>>> + serial0 = &uart0; 
>>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */ 
>>
>>
>> It is not defined there as for: 
>>
>> cef87e9 (tag: next-20161205) 20 hours ago Stephen Rothwell Add linux-next 
>> specific files for 20161205 
> 
> The driver of H3's obfuscated DesignWare MAC is not yet mainlined, so there won't be one ethernet0 now.
> 
> But it's reserved for the onboard Ethernet.


Could you please elaborate how you tested this patch (ideally some tree
somewhere on github)? This patch added RX819, it assumes EMAC support is
there, neither is there nor there is a way to test this... Thanks.


> 
>>
>>
>>
>>
>>
>>> + ethernet1 = &xr819; 
>>> + }; 
>>> + 
>>> + chosen { 
>>> + stdout-path = "serial0:115200n8"; 
>>> + }; 
>>> + 
>>> + leds { 
>>> + compatible = "gpio-leds"; 
>>> + 
>>> + pwr_led { 
>>> + label = "orangepi:green:pwr"; 
>>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; 
>>> + default-state = "on"; 
>>> + }; 
>>> + 
>>> + status_led { 
>>> + label = "orangepi:red:status"; 
>>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>; 
>>> + }; 
>>> + }; 
>>> + 
>>> + reg_vcc_wifi: reg_vcc_wifi { 
>>> + compatible = "regulator-fixed"; 
>>> + regulator-min-microvolt = <3300000>; 
>>> + regulator-max-microvolt = <3300000>; 
>>> + regulator-name = "vcc-wifi"; 
>>> + enable-active-high; 
>>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>; 
>>> + }; 
>>> + 
>>> + wifi_pwrseq: wifi_pwrseq { 
>>> + compatible = "mmc-pwrseq-simple"; 
>>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; 
>>> + }; 
>>> +}; 
>>> + 
>>> +&ehci1 { 
>>> + status = "okay"; 
>>> +}; 
>>> + 
>>> +&mmc0 { 
>>> + pinctrl-names = "default"; 
>>> + pinctrl-0 = <&mmc0_pins_a>; 
>>> + vmmc-supply = <&reg_vcc3v3>; 
>>> + bus-width = <4>; 
>>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */ 
>>> + cd-inverted; 
>>> + status = "okay"; 
>>> +}; 
>>> + 
>>> +&mmc1 { 
>>> + pinctrl-names = "default"; 
>>> + pinctrl-0 = <&mmc1_pins_a>; 
>>> + vmmc-supply = <&reg_vcc_wifi>; 
>>> + mmc-pwrseq = <&wifi_pwrseq>; 
>>> + bus-width = <4>; 
>>> + non-removable; 
>>> + status = "okay"; 
>>> + 
>>> + /* 
>>> + * Explicitly define the sdio device, so that we can add an ethernet 
>>> + * alias for it (which e.g. makes u-boot set a mac-address). 
>>> + */ 
>>> + xr819: sdio_wifi at 1 { 
>>> + reg = <1>; 
>>> + }; 
>>> +}; 
>>> + 
>>> +&mmc1_pins_a { 
>>> + bias-pull-up; 
>>> +}; 
>>> + 
>>> +&ohci1 { 
>>> + status = "okay"; 
>>> +}; 
>>> + 
>>> +&uart0 { 
>>> + pinctrl-names = "default"; 
>>> + pinctrl-0 = <&uart0_pins_a>; 
>>> + status = "okay"; 
>>> +}; 
>>> + 
>>> +&uart1 { 
>>> + pinctrl-names = "default"; 
>>> + pinctrl-0 = <&uart1_pins>; 
>>> + status = "disabled"; 
>>> +}; 
>>> + 
>>> +&uart2 { 
>>> + pinctrl-names = "default"; 
>>> + pinctrl-0 = <&uart2_pins>; 
>>> + status = "disabled"; 
>>> +}; 
>>> + 
>>> +&usbphy { 
>>> + /* USB VBUS is always on */ 
>>> + status = "okay"; 
>>> +}; 
>>>
>>
>>
>> -- 
>> Alexey 


-- 
Alexey

^ permalink raw reply

* [PATCH] usb: gadget: udc: atmel: Fix check in usba_ep_enable()
From: Boris Brezillon @ 2016-12-06 21:59 UTC (permalink / raw)
  To: linux-arm-kernel

desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK is not necessarily
equal to ep->index and that's perfectly fine. The usba endpoint index is
just an internal identifier used by the driver to know which registers
to use for a USB endpoint.

Enforcing this constraint is not only useless, but can also lead to
errors since nothing guarantees that the endpoint number and index are
matching when an endpoint is selected for a specific descriptor, thus
leading to errors at ->enable() time when it's already too late to choose
another endpoint.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Hi,

I intentionally didn't add the Cc stable and Fixes tags because this
bug dates back to the drivers creation, and I fear the index <->
epnum constraint was actually required at that time.

Note that I discovered this bug thanks to the WARN_ON_ONCE() in
usb_ep_queue() [1] which was introduced in 4.5.
It might appear that this problem was silently ignored before that
(with part of the usba_ep_enable() code being skipped without any
notice).

Regards,

Boris

[1]http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/core.c#L264
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index bb1f6c8f0f01..981d2639d413 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -531,11 +531,8 @@ usba_ep_enable(struct usb_ep *_ep, const struct usb_endpoint_descriptor *desc)
 
 	maxpacket = usb_endpoint_maxp(desc) & 0x7ff;
 
-	if (((desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) != ep->index)
-			|| ep->index == 0
-			|| desc->bDescriptorType != USB_DT_ENDPOINT
-			|| maxpacket == 0
-			|| maxpacket > ep->fifo_size) {
+	if (ep->index == 0 || desc->bDescriptorType != USB_DT_ENDPOINT ||
+	    maxpacket == 0 || maxpacket > ep->fifo_size) {
 		DBG(DBG_ERR, "ep_enable: Invalid argument");
 		return -EINVAL;
 	}
-- 
2.7.4

^ permalink raw reply related

* [PATCH] usb: gadget: udc: atmel: Fix check in usba_ep_enable()
From: Boris Brezillon @ 2016-12-06 22:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1481061583-4727-1-git-send-email-boris.brezillon@free-electrons.com>

Hi Felipe,

I realize I sent this patch to your old @ti.com email address. Do you
want me to resend it?

Regards,

Boris

On Tue,  6 Dec 2016 22:59:43 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK is not necessarily
> equal to ep->index and that's perfectly fine. The usba endpoint index is
> just an internal identifier used by the driver to know which registers
> to use for a USB endpoint.
> 
> Enforcing this constraint is not only useless, but can also lead to
> errors since nothing guarantees that the endpoint number and index are
> matching when an endpoint is selected for a specific descriptor, thus
> leading to errors at ->enable() time when it's already too late to choose
> another endpoint.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Hi,
> 
> I intentionally didn't add the Cc stable and Fixes tags because this
> bug dates back to the drivers creation, and I fear the index <->
> epnum constraint was actually required at that time.
> 
> Note that I discovered this bug thanks to the WARN_ON_ONCE() in
> usb_ep_queue() [1] which was introduced in 4.5.
> It might appear that this problem was silently ignored before that
> (with part of the usba_ep_enable() code being skipped without any
> notice).
> 
> Regards,
> 
> Boris
> 
> [1]http://lxr.free-electrons.com/source/drivers/usb/gadget/udc/core.c#L264
> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index bb1f6c8f0f01..981d2639d413 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -531,11 +531,8 @@ usba_ep_enable(struct usb_ep *_ep, const struct usb_endpoint_descriptor *desc)
>  
>  	maxpacket = usb_endpoint_maxp(desc) & 0x7ff;
>  
> -	if (((desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK) != ep->index)
> -			|| ep->index == 0
> -			|| desc->bDescriptorType != USB_DT_ENDPOINT
> -			|| maxpacket == 0
> -			|| maxpacket > ep->fifo_size) {
> +	if (ep->index == 0 || desc->bDescriptorType != USB_DT_ENDPOINT ||
> +	    maxpacket == 0 || maxpacket > ep->fifo_size) {
>  		DBG(DBG_ERR, "ep_enable: Invalid argument");
>  		return -EINVAL;
>  	}

^ permalink raw reply

* [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Jon Mason @ 2016-12-06 22:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACna6rwdKHtgp+g58B3HrDnkYZoGGZUdSqVFAGXZbf8tNTBZPg@mail.gmail.com>

On Tue, Dec 06, 2016 at 09:57:31PM +0100, Rafa? Mi?ecki wrote:
> On 6 December 2016 at 21:06, Jon Mason <jon.mason@broadcom.com> wrote:
> > On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafa? Mi?ecki wrote:
> >> From: Rafa? Mi?ecki <rafal@milecki.pl>
> >>
> >> So far we were specifying only the first block which is always limited
> >> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
> >
> > Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
> > ways to access the first 128M of RAM, a proxy starting at address 0
> > and the real address.  I think you are splitting RAM by accessing it
> > both ways, when you really should just be accessing it at the real
> > address.
> 
> I need some more help, please.
> 
> This patch (quite well tested) confirms that 0x88000000 can be used to
> access RAM at offset 128 MiB. If this is a real address and whole
> space is contiguous, it means the base real address should be
> 0x80000000. So using 0x0 and 0x80000000 should allow accessing
> beginning of the RAM. I took a device that was working just fine with:
> reg = <0x00000000 0x08000000>;
> and I replaced it with:
> reg = <0x80000000 0x08000000>;
> but it broke things, kernel didn't boot with the last message being:
> [    0.000000] Memory policy: Data cache writealloc
> 
> I can see that bcm958525er.dts, bcm958525xmc.dts, bcm958623hr.dts,
> bcm958625k.dts bcm988312hr.dts are using 0x60000000 as base address.
> It seems to be different from Northstar but I tried following entry
> anyway:
> reg = <0x60000000 0x08000000>;
> and I got kernel hang just like in the previous try.
> 
> Did I miss something? Or does Northstar seem to be actually different than NSP?

Per the BCM5301X Preliminary Programmer's Register Reference guide
(page 394), under the second titled "System Address Mapping".
There is a table listing the System Address Mapping.  The parts that
are of interest in this converstation are (and forgive my
approxmiation, but I cannot cut'n'paste from it):

Address Range                Size            Description
---------------------------------------------------
0x0000_0000-0x07FF_FFFF    128 MB       DDR2/3 SDRAM Memory Region*
0x8000_0000-0xBFFF_FFFF    1 G          DDR2/3 SDRAM Large Region

* The DDR2/3 SDRAM Memory Region (128MB) is a subset of the DDR2/3
SDRAM Large Region (1GB).  Additionally, 0x0000_0000-0x07FF_FFFF is
aliased to 0x8000_0000-0x87FF_FFFF

However, since you say it isn't working for you, then there must be
some other missing peice.  I'll retract my comment for now, and
hopefully we can double back and get it working in the future.

Thanks,
Jon

^ permalink raw reply

* [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END
From: Chris Brandt @ 2016-12-06 22:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-2-f.fainelli@gmail.com>

On 12/6/2016, Florian Fainelli wrote:
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 4001dd15818d..18ef688a796e 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1437,12 +1437,8 @@ static void __init kmap_init(void)
>  static void __init map_lowmem(void)
>  {
>  	struct memblock_region *reg;
> -#ifdef CONFIG_XIP_KERNEL
> -	phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
> -#else
> -	phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
> -#endif
> -	phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
> +	phys_addr_t kernel_x_start = round_down(__pa(KERNEL_START),
> SECTION_SIZE);
> +	phys_addr_t kernel_x_end = round_down(__pa(_end), SECTION_SIZE);

Why are you changing the end of executable kernel (hence the 'x' in
kernel_x_end) from __init_end to _end which basically maps the entire
kernel image including text and data?

Doing so would then change data from MT_MEMORY_RW into MT_MEMORY_RWX.

I would think it would create some type of security risk to allow
data to be executable.

^ permalink raw reply

* [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END
From: Florian Fainelli @ 2016-12-06 22:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <SG2PR06MB116569D2A9756BE11131CB4B8A820@SG2PR06MB1165.apcprd06.prod.outlook.com>

On 12/06/2016 02:43 PM, Chris Brandt wrote:
> On 12/6/2016, Florian Fainelli wrote:
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index 4001dd15818d..18ef688a796e 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -1437,12 +1437,8 @@ static void __init kmap_init(void)
>>  static void __init map_lowmem(void)
>>  {
>>  	struct memblock_region *reg;
>> -#ifdef CONFIG_XIP_KERNEL
>> -	phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
>> -#else
>> -	phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
>> -#endif
>> -	phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
>> +	phys_addr_t kernel_x_start = round_down(__pa(KERNEL_START),
>> SECTION_SIZE);
>> +	phys_addr_t kernel_x_end = round_down(__pa(_end), SECTION_SIZE);
> 
> Why are you changing the end of executable kernel (hence the 'x' in
> kernel_x_end) from __init_end to _end which basically maps the entire
> kernel image including text and data?

That's a typo, was not intentional thanks for spotting it.
-- 
Florian

^ permalink raw reply

* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-12-06 22:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <yw1xshq12hr9.fsf@unicorn.mansr.com>

On 06/12/2016 16:34, M?ns Rullg?rd wrote:

> Mason writes:
> 
>> Meh. The two controller blocks share the I/O pins to the outside
>> world, so it's not possible to have two concurrent accesses.
> 
> OK, you failed to mention that part.  Why are there two controllers at
> all if only one or the other can be used?

I'd have to ask the HW designer what types of use-cases he had
in mind. Perhaps looking at what is *not* shared provides clues.
Configuration registers are duplicated, meaning it is possible
to decide "channel A for chip0, channel B for chip1" if there
are two NAND chips in the system (as is the case on dev boards).
In that case, it is unnecessary to rewrite the chip parameters
every time the driver switches chips. (I don't think the perf
impact is even measurable.)

The ECC engines are duplicated, but I don't know how long it
takes to run the BCH algorithm in HW vs performing I/O over
a slow 8-bit bus.


>> The callback is called from vchan_complete() right?
>> Is that running from interrupt context?
> 
> It runs from a tasklet which is almost the same thing.

I'll read up on tasklets tomorrow.


>> I can give that a shot (if you're busy with real work).
> 
> I have an idea I'd like to try out over the weekend.  If I don't come
> back with something by next week, go for it.

I do have my plate full this week, with XHCI and AHCI :-)


>> Why can't we queue channel requests the same way we queue
>> transfer requests?
> 
> That's in effect what we're doing.  Calling it by another name doesn't
> really solve anything.

Hmmm... the difference is that "tear down" would be explicit
in the release function.

Current implementation for single transfer:

dmaengine_prep_slave_sg()
dmaengine_submit()
dma_async_issue_pending()	/* A */
wait for read channel IRQ	/* B */
spin until NFC idle		/* C */

Setup SBOX route and program MBUS transfer happen in A.
The SBOX route is torn down a little before B (thus before C).


With the proposed implementation, where request_chan
sets up the route and release_chan tears it down:

request_chan()			/* X */
dmaengine_prep_slave_sg()
dmaengine_submit()
dma_async_issue_pending()	/* A */
wait for read channel IRQ	/* B */
spin until NFC idle		/* C */
release_chan()			/* Y */

Now, the SBOX route is setup in X.
(If no MBUS channel are available, thread is put to sleep
until one becomes available.)
Program MBUS transfer in A.
When IRQ falls, cannot start new transfer yet.
vchan_complete() will at some point run the client callback.
The client driver can now spin however long until NFC idle.
In Y, we release the channel, thus calling back into the
DMA driver, at which point a new transfer can be started.

What did I get wrong in this pseudo-code?


I do see one problem with the approach:
It's no big deal for me to convert the NFC driver to
do it that way, but the Synopsys (I think) SATA driver
in tango3 and tango4 is shared across multiple SoCs,
and they probably call request_chan() only in the
probe function, as you mentioned at some point.

http://lxr.free-electrons.com/source/drivers/ata/sata_dwc_460ex.c#L366

BTW, can someone explain what the DMA_CTRL_ACK flag means?


Regards.

^ permalink raw reply

* [PATCH 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
From: Rob Herring @ 2016-12-06 23:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <054a65d8-8606-eeb0-e028-1b85dbf1c8ba@samsung.com>

On Fri, Dec 02, 2016 at 09:48:45AM +0900, Jaehoon Chung wrote:
> On 12/02/2016 09:14 AM, Sergio Prado wrote:
> > Adds the device tree bindings description for Samsung S3C24XX
> > MMC/SD/SDIO controller, used as a connectivity interface with external
> > MMC, SD and SDIO storage mediums.
> > 
> > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> > ---
> >  .../devicetree/bindings/mmc/samsung,s3cmci.txt     | 38 ++++++++++++++++++++++
> >  1 file changed, 38 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> > new file mode 100644
> > index 000000000000..3f044076e69a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> > @@ -0,0 +1,38 @@
> > +* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
> > +
> > +Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
> > +with external MMC, SD and SDIO storage mediums.
> > +
> > +This file documents differences between the core mmc properties described by
> > +mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
> > +implementation.
> > +
> > +Required SoC Specific Properties:
> > +- compatible: should be one of the following
> > +  - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
> > +  - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
> > +  - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
> > +- clocks: Should reference the controller clock
> > +- clock-names: Should contain "sdi"
> > +
> > +Required Board Specific Properties:
> > +- pinctrl-0: Should specify pin control groups used for this controller.
> > +- pinctrl-names: Should contain only one value - "default".
> 
> I'm not sure but i think this description doesn't need at here.
> 
> > +
> > +Example:
> > +	sdi: sdi at 5a000000 {
> 
> I think it needs to use "mmc0: sdi at 5a000000" instead of "sdi: sdi at 5a000000"
> Because mmc is more clear than sdi.

The label doesn't matter much as it is not part of the dtb. The unit 
name should be 'mmc' though.

With that,

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [PATCH] clk: uniphier: Fix build with gcc-4.4.
From: Stephen Boyd @ 2016-12-06 23:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAK7LNATeswNhoFsA90k=qF4Jock0ytNT-pPT6j+0b9MJFJwu9Q@mail.gmail.com>

On 12/03, Masahiro Yamada wrote:
> Hi Vinson,
> 
> 2016-12-03 9:37 GMT+09:00 Vinson Lee <vlee@freedesktop.org>:
> > gcc-4.4 has issues with anonymous unions in initializers.
> >
> >   CC      drivers/clk/uniphier/clk-uniphier-sys.o
> > drivers/clk/uniphier/clk-uniphier-sys.c:45: error: unknown field ?factor? specified in initializer
> >
> > Fixes: 1574d5722636 ("clk: uniphier: remove unneeded member name for union")
> > Signed-off-by: Vinson Lee <vlee@freedesktop.org>
> 
> 
> This driver has COMPILE_TEST option, but kbuild test robot
> did not mention about this.
> 
> 
> 
> This is a bad way of fixing, I think.
> (what if a new member is inserted before the union in the future?)
> 
> Rather, please revert the bad commit.
> 

Reverting on top of clk-next will cause build failures though.
Can you resend the patch series without this first patch please?
I'll apply them then.

I'll go drop all three patches and wreck Andrew's merge of this
patch to -mm.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [PATCH 3/4] iommu/arm-smmu: Disable stalling faults for all endpoints
From: Rob Clark @ 2016-12-06 23:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1471525542-14969-4-git-send-email-will.deacon@arm.com>

On Thu, Aug 18, 2016 at 9:05 AM, Will Deacon <will.deacon@arm.com> wrote:
> Enabling stalling faults can result in hardware deadlock on poorly
> designed systems, particularly those with a PCI root complex upstream of
> the SMMU.
>
> Although it's not really Linux's job to save hardware integrators from
> their own misfortune, it *is* our job to stop userspace (e.g. VFIO
> clients) from hosing the system for everybody else, even if they might
> already be required to have elevated privileges.
>
> Given that the fault handling code currently executes entirely in IRQ
> context, there is nothing that can sensibly be done to recover from
> things like page faults anyway, so let's rip this code out for now and
> avoid the potential for deadlock.

Hi Will,

so, I'd like to re-introduce this feature, I *guess* as some sort of
opt-in quirk (ie. disabled by default unless something in DT tells you
otherwise??  But I'm open to suggestions.  I'm not entirely sure what
hw was having problems due to this feature.)

On newer snapdragon devices we are using arm-smmu for the GPU, and
halting the GPU so the driver's fault handler can dump some GPU state
on faults is enormously helpful for debugging and tracking down where
in the gpu cmdstream the fault was triggered.  In addition, we will
eventually want the ability to update pagetables from fault handler
and resuming the faulting transition.

Some additional comments below..

> Cc: <stable@vger.kernel.org>
> Reported-by: Matt Evans <matt.evans@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  drivers/iommu/arm-smmu.c | 34 +++++++---------------------------
>  1 file changed, 7 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 4f49fe29f202..2db74ebc3240 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -686,8 +686,7 @@ static struct iommu_gather_ops arm_smmu_gather_ops = {
>
>  static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>  {
> -       int flags, ret;
> -       u32 fsr, fsynr, resume;
> +       u32 fsr, fsynr;
>         unsigned long iova;
>         struct iommu_domain *domain = dev;
>         struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> @@ -701,34 +700,15 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>         if (!(fsr & FSR_FAULT))
>                 return IRQ_NONE;
>
> -       if (fsr & FSR_IGN)
> -               dev_err_ratelimited(smmu->dev,
> -                                   "Unexpected context fault (fsr 0x%x)\n",
> -                                   fsr);
> -
>         fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
> -       flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
> -
>         iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
> -       if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
> -               ret = IRQ_HANDLED;
> -               resume = RESUME_RETRY;
> -       } else {
> -               dev_err_ratelimited(smmu->dev,
> -                   "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
> -                   iova, fsynr, cfg->cbndx);

I would like to decouple this dev_err_ratelimit() print from the
RESUME_RETRY vs RESUME_TERMINATE behaviour.  I need the ability to
indicate by return from my fault handler whether to resume or
terminate.  But I already have my own ratelimted prints and would
prefer not to spam dmesg twice.

I'm thinking about report_iommu_fault() returning:

  0 => RESUME_RETRY
  -EFAULT => RESUME_TERMINATE but don't print
  anything else (or specifically -ENOSYS?) => RESUME_TERMINATE and print

thoughts?

> -               ret = IRQ_NONE;
> -               resume = RESUME_TERMINATE;
> -       }
> -
> -       /* Clear the faulting FSR */
> -       writel(fsr, cb_base + ARM_SMMU_CB_FSR);
>
> -       /* Retry or terminate any stalled transactions */
> -       if (fsr & FSR_SS)
> -               writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);

This might be a bug in qcom's implementation of the smmu spec, but
seems like we don't have SS bit set, yet we still require RESUME reg
to be written, otherwise gpu is perma-wedged.  Maybe topic for a
separate quirk?  I'm not sure if writing RESUME reg on other hw when
SS bit is not set is likely to cause problems?  If not I suppose we
could just unconditionally write it.

Anyways, I'm not super-familiar w/ arm-smmu so suggestions welcome..
in between debugging freedreno I'll try to put together some patches.

BR,
-R

> +       dev_err_ratelimited(smmu->dev,
> +       "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cb=%d\n",
> +                           fsr, iova, fsynr, cfg->cbndx);
>
> -       return ret;
> +       writel(fsr, cb_base + ARM_SMMU_CB_FSR);
> +       return IRQ_HANDLED;
>  }
>
>  static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> @@ -837,7 +817,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>         }
>
>         /* SCTLR */
> -       reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
> +       reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP;
>         if (stage1)
>                 reg |= SCTLR_S1_ASIDPNE;
>  #ifdef __BIG_ENDIAN
> --
> 2.1.4
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply

* [PATCHv5 00/11] CONFIG_DEBUG_VIRTUAL for arm64
From: Laura Abbott @ 2016-12-06 23:50 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

This is v5 of the series to add CONFIG_DEBUG_VIRTUAL for arm64. This mostly
contains minor fixups including adding a few extra headers around and splitting
things out into a few more sub-patches.

With a few more acks I think this should be ready to go. More testing is
always appreciated though.

Thanks,
Laura

Laura Abbott (11):
  lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
  mm/cma: Cleanup highmem check
  arm64: Move some macros under #ifndef __ASSEMBLY__
  arm64: Add cast for virt_to_pfn
  mm: Introduce lm_alias
  arm64: Use __pa_symbol for kernel symbols
  drivers: firmware: psci: Use __pa_symbol for kernel symbol
  kexec: Switch to __pa_symbol
  mm/kasan: Switch to using __pa_symbol and lm_alias
  mm/usercopy: Switch to using lm_alias
  arm64: Add support for CONFIG_DEBUG_VIRTUAL

 arch/arm64/Kconfig                        |  1 +
 arch/arm64/include/asm/kvm_mmu.h          |  4 +-
 arch/arm64/include/asm/memory.h           | 66 +++++++++++++++++++++----------
 arch/arm64/include/asm/mmu_context.h      |  6 +--
 arch/arm64/include/asm/pgtable.h          |  2 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  3 +-
 arch/arm64/kernel/cpu-reset.h             |  2 +-
 arch/arm64/kernel/cpufeature.c            |  3 +-
 arch/arm64/kernel/hibernate.c             | 20 +++-------
 arch/arm64/kernel/insn.c                  |  2 +-
 arch/arm64/kernel/psci.c                  |  3 +-
 arch/arm64/kernel/setup.c                 |  9 +++--
 arch/arm64/kernel/smp_spin_table.c        |  3 +-
 arch/arm64/kernel/vdso.c                  |  8 +++-
 arch/arm64/mm/Makefile                    |  2 +
 arch/arm64/mm/init.c                      | 12 +++---
 arch/arm64/mm/kasan_init.c                | 22 +++++++----
 arch/arm64/mm/mmu.c                       | 33 ++++++++++------
 arch/arm64/mm/physaddr.c                  | 30 ++++++++++++++
 arch/x86/Kconfig                          |  1 +
 drivers/firmware/psci.c                   |  2 +-
 include/linux/mm.h                        |  4 ++
 kernel/kexec_core.c                       |  2 +-
 lib/Kconfig.debug                         |  5 ++-
 mm/cma.c                                  | 15 +++----
 mm/kasan/kasan_init.c                     | 15 +++----
 mm/usercopy.c                             |  4 +-
 27 files changed, 180 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm64/mm/physaddr.c

-- 
2.7.4

^ permalink raw reply

* [PATCHv5 01/11] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-12-06 23:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1481068257-6367-1-git-send-email-labbott@redhat.com>


DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting
the same support. Rather than add a list of architectures, switch this
to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as
appropriate.

Acked-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v5: No changes
---
 arch/x86/Kconfig  | 1 +
 lib/Kconfig.debug | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..f533321 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
 	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_DISCARD_MEMBLOCK
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a6c8db1..be65e04 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -603,9 +603,12 @@ config DEBUG_VM_PGFLAGS
 
 	  If unsure, say N.
 
+config ARCH_HAS_DEBUG_VIRTUAL
+	bool
+
 config DEBUG_VIRTUAL
 	bool "Debug VM translations"
-	depends on DEBUG_KERNEL && X86
+	depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
 	help
 	  Enable some costly sanity checks in virtual to page code. This can
 	  catch mistakes with virt_to_page() and friends.
-- 
2.7.4

^ permalink raw reply related

* [PATCHv5 02/11] mm/cma: Cleanup highmem check
From: Laura Abbott @ 2016-12-06 23:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1481068257-6367-1-git-send-email-labbott@redhat.com>


6b101e2a3ce4 ("mm/CMA: fix boot regression due to physical address of
high_memory") added checks to use __pa_nodebug on x86 since
CONFIG_DEBUG_VIRTUAL complains about high_memory not being linearlly
mapped. arm64 is now getting support for CONFIG_DEBUG_VIRTUAL as well.
Rather than add an explosion of arches to the #ifdef, switch to an
alternate method to calculate the physical start of highmem using
the page before highmem starts. This avoids the need for the #ifdef and
extra __pa_nodebug calls.

Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v5: No changes
---
 mm/cma.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/mm/cma.c b/mm/cma.c
index c960459..94b3460 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -235,18 +235,13 @@ int __init cma_declare_contiguous(phys_addr_t base,
 	phys_addr_t highmem_start;
 	int ret = 0;
 
-#ifdef CONFIG_X86
 	/*
-	 * high_memory isn't direct mapped memory so retrieving its physical
-	 * address isn't appropriate.  But it would be useful to check the
-	 * physical address of the highmem boundary so it's justifiable to get
-	 * the physical address from it.  On x86 there is a validation check for
-	 * this case, so the following workaround is needed to avoid it.
+	 * We can't use __pa(high_memory) directly, since high_memory
+	 * isn't a valid direct map VA, and DEBUG_VIRTUAL will (validly)
+	 * complain. Find the boundary by adding one to the last valid
+	 * address.
 	 */
-	highmem_start = __pa_nodebug(high_memory);
-#else
-	highmem_start = __pa(high_memory);
-#endif
+	highmem_start = __pa(high_memory - 1) + 1;
 	pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n",
 		__func__, &size, &base, &limit, &alignment);
 
-- 
2.7.4

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox