[PATCH 0/9] ARM: randconfig testing fallout

Here are some new patches that I've collected as part of the randconfig
testing. I don't think any of these are urgent, but it would be nice
to get them merged to cut down on the noise in randconfig testing.

The NR_IPIS patch is the only one that I expect to matter to real
users, but I think it's been broken for several years without anyone
noticing.

	Arnd

When configuring the kernel for big-endian, we set either BE-8 or BE-32
based on the CPU architecture level. Until linux-4.4, we did not have
any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
is in that category, adn we get a build error because of this:

arch/arm/kernel/module-plts.c: In function 'get_module_plt':
arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]

This comes down to picking the wrong default, ARMv7-M uses BE8
like ARMv7-A does. Changing the default gets the kernel to compile
and presumably works.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 55347662e5ed..ff1637365494 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig

@@ -723,7 +723,7 @@ config CPU_BIG_ENDIAN
 config CPU_ENDIAN_BE8
 	bool
 	depends on CPU_BIG_ENDIAN
-	default CPU_V6 || CPU_V6K || CPU_V7
+	default CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
 	help
 	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
 

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

When configuring the kernel for big-endian, we set either BE-8 or BE-32
based on the CPU architecture level. Until linux-4.4, we did not have
any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
is in that category, adn we get a build error because of this:

arch/arm/kernel/module-plts.c: In function 'get_module_plt':
arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]

This comes down to picking the wrong default, ARMv7-M uses BE8
like ARMv7-A does. Changing the default gets the kernel to compile
and presumably works.

Was it tested without BE8 when it was submitted upstream? I don't think 
you can switch this freely on a given hardware platform and expect it to 
still work.

On Thursday 18 February 2016 11:06:08 Nicolas Pitre wrote:

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

quoted

When configuring the kernel for big-endian, we set either BE-8 or BE-32
based on the CPU architecture level. Until linux-4.4, we did not have
any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
is in that category, adn we get a build error because of this:

arch/arm/kernel/module-plts.c: In function 'get_module_plt':
arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]

This comes down to picking the wrong default, ARMv7-M uses BE8
like ARMv7-A does. Changing the default gets the kernel to compile
and presumably works.

Was it tested without BE8 when it was submitted upstream? I don't think 
you can switch this freely on a given hardware platform and expect it to 
still work.

mach-imx contains a number of different SoCs, and one SoC was recently
tested successfully after a number of endianess bugs got fixed. This was
an i.mx6 using a Cortex-A9 core, but we are now also able to build
vybrid vf610 big-endian based on that selection. This SoC supports
Linux running either on its Cortex-A5 or its Cortex-M3 (or M4?) cores.

I am rather sure nobody has ever run Linux in big-endian mode on the
Cortex-M platform, specifically because it was always wrong and could
not be enabled in Kconfig.

	Arnd

On 18/02/16 16:12, Arnd Bergmann wrote:

On Thursday 18 February 2016 11:06:08 Nicolas Pitre wrote:

quoted

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

quoted

When configuring the kernel for big-endian, we set either BE-8 or BE-32
based on the CPU architecture level. Until linux-4.4, we did not have
any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
is in that category, adn we get a build error because of this:

arch/arm/kernel/module-plts.c: In function 'get_module_plt':
arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]

This comes down to picking the wrong default, ARMv7-M uses BE8
like ARMv7-A does. Changing the default gets the kernel to compile
and presumably works.

Was it tested without BE8 when it was submitted upstream? I don't think 
you can switch this freely on a given hardware platform and expect it to 
still work.

mach-imx contains a number of different SoCs, and one SoC was recently
tested successfully after a number of endianess bugs got fixed. This was
an i.mx6 using a Cortex-A9 core, but we are now also able to build
vybrid vf610 big-endian based on that selection. This SoC supports
Linux running either on its Cortex-A5 or its Cortex-M3 (or M4?) cores.

I am rather sure nobody has ever run Linux in big-endian mode on the
Cortex-M platform, specifically because it was always wrong and could
not be enabled in Kconfig.

Ah, it explains why my quick attempt to enable BE for MPS2 (M-class
platform) failed. With this patch applied I'm able to see Linux booting
on MPS2 FVP model in BE, not complete boot but it might be due to other
reasons. So this patch definitely improves things for me, if it helps

Tested-by: Vladimir Murzin <redacted>

Cheers
Vladimir

	Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Friday 19 February 2016 08:47:47 Vladimir Murzin wrote:

Ah, it explains why my quick attempt to enable BE for MPS2 (M-class
platform) failed. With this patch applied I'm able to see Linux booting
on MPS2 FVP model in BE, not complete boot but it might be due to other
reasons. So this patch definitely improves things for me, if it helps

Tested-by: Vladimir Murzin <redacted>

Awesome, thanks for testing!

	Arnd

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.
To make the tracing work correctly, this extends the array by one
entry and increases NR_IPI accordingly.

This only works after patch e7273ff49acf ("ARM: 8488/1: Make
IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the number
assignment from '15' to '8'. If we decide to backport this patch
to stable kernels, we probably need to backport e7273ff49acf
as well.

As far as I can tell, the problem has existed since the tracepoints
were originally added, but it only triggered a gcc warning with the
later change to NR_IPIS.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
---
 arch/arm/include/asm/hardirq.h | 2 +-
 arch/arm/kernel/smp.c          | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 3d7351c844aa..fe3ea776dc34 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h

@@ -5,7 +5,7 @@
 #include <linux/threads.h>
 #include <asm/irq.h>
 
-#define NR_IPI	7
+#define NR_IPI	8
 
 typedef struct {
 	unsigned int __softirq_pending;

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4048e370730..d021566d71c2 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c

@@ -482,6 +482,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
 	S(IPI_CPU_STOP, "CPU stop interrupts"),
 	S(IPI_IRQ_WORK, "IRQ work interrupts"),
 	S(IPI_COMPLETION, "completion interrupts"),
+	S(IPI_CPU_BACKTRACE, "CPU backtrace"),
 };
 
 static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)

-- 
2.7.0

Hi Arnd,

On 18/02/16 14:01, Arnd Bergmann wrote:

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.
To make the tracing work correctly, this extends the array by one
entry and increases NR_IPI accordingly.

This only works after patch e7273ff49acf ("ARM: 8488/1: Make
IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the number
assignment from '15' to '8'. If we decide to backport this patch
to stable kernels, we probably need to backport e7273ff49acf
as well.

I may actually have made the bug worse in 89d798b ("ARM: 8487/1: Remove
IPI_CALL_FUNC_SINGLE"), which changed NR_IPI from 8 to 7. It would need
to be backported as well (as otherwise we don't have a free non-secure
IP slot).

As far as I can tell, the problem has existed since the tracepoints
were originally added, but it only triggered a gcc warning with the
later change to NR_IPIS.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17

Acked-by: Marc Zyngier <redacted>

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

On Thu, Feb 18, 2016 at 03:01:54PM +0100, Arnd Bergmann wrote:

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

We really don't want to treat the backtrace IPI as a normal IPI at all -
we want it to invoke the least amount of code possible.  Hence this code
which avoids the issue:

        if ((unsigned)ipinr < NR_IPI) {
                trace_ipi_entry_rcuidle(ipi_types[ipinr]);
                __inc_irq_stat(cpu, ipi_irqs[ipinr]);
        }

However, what's missing is that the addition of tracing here missed
that CPU_BACKTRACE is not to be traced.  The call in raise_nmi()
should have been converted to __smp_cross_call() to avoid the
tracing code.

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

On Thursday 18 February 2016 14:37:09 Russell King - ARM Linux wrote:

On Thu, Feb 18, 2016 at 03:01:54PM +0100, Arnd Bergmann wrote:

quoted

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

We really don't want to treat the backtrace IPI as a normal IPI at all -
we want it to invoke the least amount of code possible.  Hence this code
which avoids the issue:

        if ((unsigned)ipinr < NR_IPI) {
                trace_ipi_entry_rcuidle(ipi_types[ipinr]);
                __inc_irq_stat(cpu, ipi_irqs[ipinr]);
        }

However, what's missing is that the addition of tracing here missed
that CPU_BACKTRACE is not to be traced.  The call in raise_nmi()
should have been converted to __smp_cross_call() to avoid the
tracing code.

I've replaced the patch locally with the version below now, and
will throw it into the randconfig build test infrastructure to
make sure I didn't screw up in an obvious way here.

	Arnd

From 7528c9b0558fdf4de785e62e61f0dd2ffe874110 Mon Sep 17 00:00:00 2001

From: Arnd Bergmann <arnd@arndb.de>
Date: Sun, 31 Jan 2016 22:26:21 +0100
Subject: [PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.

This patch raise_nmi() to call __smp_cross_call() instead of
smp_cross_call(), to avoid calling into ftrace. For clarification,
I'm also adding a two new code comments describing how this one
is special.

The warning appears to have shown up after patch e7273ff49acf
("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
changed the number assignment from '15' to '8', but as far as I can
tell has existed since the IPI tracepoints were first introduced.
If we decide to backport this patch to stable kernels, we probably
need to backport e7273ff49acf as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 3d7351c844aa..2fd0a2619b0b 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h

@@ -5,6 +5,7 @@
 #include <linux/threads.h>
 #include <asm/irq.h>
 
+/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
 #define NR_IPI	7
 
 typedef struct {

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4048e370730..9802a94260db 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c

@@ -72,6 +72,10 @@ enum ipi_msg_type {
 	IPI_CPU_STOP,
 	IPI_IRQ_WORK,
 	IPI_COMPLETION,
+	/*
+	 * CPU_BACKTRACE is special and not included in NR_IPI
+	 * or tracable with trace_ipi_*
+	 */
 	IPI_CPU_BACKTRACE,
 	/*
 	 * SGI8-15 can be reserved by secure firmware, and thus may

@@ -757,7 +761,7 @@ static void raise_nmi(cpumask_t *mask)
 	if (cpumask_test_cpu(smp_processor_id(), mask) && irqs_disabled())
 		nmi_cpu_backtrace(NULL);
 
-	smp_cross_call(mask, IPI_CPU_BACKTRACE);
+	__smp_cross_call(mask, IPI_CPU_BACKTRACE);
 }
 
 void arch_trigger_all_cpu_backtrace(bool include_self)

Hi,

Any conclusion on this patch? The coverity tool is still complaining
error on the issue which this patch can fix.

Thanks,
Chunyan

On 18 February 2016 at 23:18, Arnd Bergmann [off-list ref] wrote:

free_memmap is an inline function, but gcc may choose to ignore that
when CONFIG_OPTIMIZE_INLINING is set. In that case it is put in the
.text section, causing a kbuild warning:

WARNING: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in reference from the function free_memmap() to the function .init.text:__memblock_free_early()
The function free_memmap() references
the function __init __memblock_free_early().
This is often because free_memmap lacks a __init
annotation or the annotation of __memblock_free_early is wrong.

FATAL: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.

This marks the function both inline and __init, which is a
correct annotation and avoids the problem.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..a4db267c35b2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c

@@ -330,7 +330,7 @@ static inline void poison_init_mem(void *s, size_t count)
 		*p++ = 0xe7fddef0;
 }
 
-static inline void
+static inline void __init
 free_memmap(unsigned long start_pfn, unsigned long end_pfn)
 {
 	struct page *start_pg, *end_pg;

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

free_memmap is an inline function, but gcc may choose to ignore that
when CONFIG_OPTIMIZE_INLINING is set. In that case it is put in the
.text section, causing a kbuild warning:

WARNING: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in reference from the function free_memmap() to the function .init.text:__memblock_free_early()
The function free_memmap() references
the function __init __memblock_free_early().
This is often because free_memmap lacks a __init
annotation or the annotation of __memblock_free_early is wrong.

FATAL: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.

This marks the function both inline and __init, which is a
correct annotation and avoids the problem.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Nicolas Pitre <redacted>

For platforms that are not yet converted to ARCH_MULTIPLATFORM,
we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires
setting a correct address here.

As we actualy know what all the values are supposed to be based
on the old mach/memory.h header file contents (from git history),
we can just add them here.

This also solves a problem in Kconfig where 'make randconfig'
fails to continue if no number is selected for a 'hex' option.
Users can still override the number at configuration time, e.g.
when the memory visible to the kernel starts at a nonstandard
address on some machine, but it should no longer be required
now.

To make this foolproof, another patch is required in mach-davinci
to prevent a configuration with both DMx and DA8xx enabled but
ARM_PATCH_PHYS_VIRT disabled. The two patches however can be
merged independently as there is no direct dependency between
them.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/Kconfig | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index be00b53f399b..7839c9923709 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig

@@ -271,15 +271,29 @@ config PHYS_OFFSET
 	depends on !ARM_PATCH_PHYS_VIRT
 	default DRAM_BASE if !MMU
 	default 0x00000000 if ARCH_EBSA110 || \
+			ARCH_DOVE || \
 			ARCH_FOOTBRIDGE || \
+			(ARCH_GEMINI && GEMINI_MEM_SWAP) || \
 			ARCH_INTEGRATOR || \
+			ARCH_IOP33X || \
 			ARCH_IOP13XX || \
+			ARCH_IXP4XX || \
 			ARCH_KS8695 || \
-			(ARCH_REALVIEW && !REALVIEW_HIGH_PHYS_OFFSET)
-	default 0x10000000 if ARCH_OMAP1 || ARCH_RPC
+			(ARCH_REALVIEW && !REALVIEW_HIGH_PHYS_OFFSET) || \
+			ARCH_W90X900
+	default 0x10000000 if (ARCH_GEMINI && !GEMINI_MEM_SWAP) || \
+			ARCH_OMAP1 || \
+			ARCH_RPC
 	default 0x20000000 if ARCH_S5PV210
+	default 0x30000000 if ARCH_S3C24XX
 	default 0x70000000 if REALVIEW_HIGH_PHYS_OFFSET
-	default 0xc0000000 if ARCH_SA1100
+	default 0x80000000 if (ARCH_DAVINCI_DMx && !ARCH_DAVINCI_DA8XX) || \
+			ARCH_NETX || \
+			ARCH_LPC32XX
+	default 0xa0000000 if ARCH_IOP32X || ARCH_PXA
+	default 0xc0000000 if (ARCH_DAVINCI_DA8XX && !ARCH_DAVINCI_DMx) || \
+			ARCH_CLPS711X || \
+			ARCH_SA1100
 	help
 	  Please provide the physical address corresponding to the
 	  location of main memory in your system.

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

For platforms that are not yet converted to ARCH_MULTIPLATFORM,
we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires
setting a correct address here.

As we actualy know what all the values are supposed to be based
on the old mach/memory.h header file contents (from git history),
we can just add them here.

This also solves a problem in Kconfig where 'make randconfig'
fails to continue if no number is selected for a 'hex' option.
Users can still override the number at configuration time, e.g.
when the memory visible to the kernel starts at a nonstandard
address on some machine, but it should no longer be required
now.

To make this foolproof, another patch is required in mach-davinci
to prevent a configuration with both DMx and DA8xx enabled but
ARM_PATCH_PHYS_VIRT disabled. The two patches however can be
merged independently as there is no direct dependency between
them.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

We could have something like

config PHYS_OFFSET_0
	bool

config PHYS_OFFSET_1
	bool

config PHYS_OFFSET_2
	bool

... (we need 8 of the 16 possible addresses)


config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	default DRAM_BASE if !MMU
	default 0x00000000 if PHYS_OFFSET_0
	default 0x10000000 if PHYS_OFFSET_1
	default 0x20000000 if PHYS_OFFSET_2
	default 0x30000000 if PHYS_OFFSET_3
	default 0x70000000 if PHYS_OFFSET_7
	default 0x80000000 if PHYS_OFFSET_8
	default 0xa0000000 if PHYS_OFFSET_A
	default 0xc0000000 if PHYS_OFFSET_C


and then select one of the bool symbols from each platform.
Would that address your question?

FWIW, that would also let us do:

config XIP_KERNEL
	bool "Kernel Execute-In-Place from ROM"
	depends on PHYS_OFFSET_0 || PHYS_OFFSET_1 || PHYS_OFFSET_2 ||
		   PHYS_OFFSET_3 || PHYS_OFFSET_7 || PHYS_OFFSET_8 ||
		   PHYS_OFFSET_A || PHYS_OFFSET_C

We can probably come up with a more elaborate way to prevent configurations
that have more than one of these set.

	Arnd

On 19 Feb 2016, Arnd Bergmann wrote:

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

quoted

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

We could have something like

config PHYS_OFFSET_0
	bool

config PHYS_OFFSET_1
	bool

config PHYS_OFFSET_2
	bool

... (we need 8 of the 16 possible addresses)


config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	default DRAM_BASE if !MMU
	default 0x00000000 if PHYS_OFFSET_0
	default 0x10000000 if PHYS_OFFSET_1
	default 0x20000000 if PHYS_OFFSET_2
	default 0x30000000 if PHYS_OFFSET_3
	default 0x70000000 if PHYS_OFFSET_7
	default 0x80000000 if PHYS_OFFSET_8
	default 0xa0000000 if PHYS_OFFSET_A
	default 0xc0000000 if PHYS_OFFSET_C


and then select one of the bool symbols from each platform.
Would that address your question?

Here's a question:

Can we just get rid of PHYS_OFFSET???

If it's only used at boot for XIP systems, we could:

A) pass it in via an unused register like atags and DT
 or
B) just assume that atags or DT is in RAM, so round down to the nearest section and assume that is the start of your RAM

If it is needed after initial boot, then on first boot we save what was passed in from the boot loader for later use.


Chris

On Friday 19 February 2016 14:29:00 Chris Brandt wrote:

On 19 Feb 2016, Arnd Bergmann wrote:

quoted

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

quoted

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

We could have something like

config PHYS_OFFSET_0
	bool

config PHYS_OFFSET_1
	bool

config PHYS_OFFSET_2
	bool

... (we need 8 of the 16 possible addresses)


config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	default DRAM_BASE if !MMU
	default 0x00000000 if PHYS_OFFSET_0
	default 0x10000000 if PHYS_OFFSET_1
	default 0x20000000 if PHYS_OFFSET_2
	default 0x30000000 if PHYS_OFFSET_3
	default 0x70000000 if PHYS_OFFSET_7
	default 0x80000000 if PHYS_OFFSET_8
	default 0xa0000000 if PHYS_OFFSET_A
	default 0xc0000000 if PHYS_OFFSET_C


and then select one of the bool symbols from each platform.
Would that address your question?

Here's a question:

Can we just get rid of PHYS_OFFSET???

If it's only used at boot for XIP systems, we could:

A) pass it in via an unused register like atags and DT
 or
B) just assume that atags or DT is in RAM, so round down to the nearest section and assume that is the start of your RAM

If it is needed after initial boot, then on first boot we save what was passed in from the boot loader for later use.

Hmm, you mean making phys_offset a runtime variable instead
of patching it at early boot time in the instructions?

I have no idea if that works, how much effort it would be,
or how much it would enlarge the kernel image size, but
you can definitely try.

Of course we must not break existing platforms using XIP_KERNEL
already, but the installed base among systems that are upgrading
to modern kernels is very small now, given how all modern platforms
don't support XIP_KERNEL today, or have no MMU to start with.

	Arnd

On Fri, Feb 19, 2016 at 04:34:51PM +0100, Arnd Bergmann wrote:

On Friday 19 February 2016 14:29:00 Chris Brandt wrote:

quoted

On 19 Feb 2016, Arnd Bergmann wrote:

quoted

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

quoted

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

We could have something like

config PHYS_OFFSET_0
	bool

config PHYS_OFFSET_1
	bool

config PHYS_OFFSET_2
	bool

... (we need 8 of the 16 possible addresses)


config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	default DRAM_BASE if !MMU
	default 0x00000000 if PHYS_OFFSET_0
	default 0x10000000 if PHYS_OFFSET_1
	default 0x20000000 if PHYS_OFFSET_2
	default 0x30000000 if PHYS_OFFSET_3
	default 0x70000000 if PHYS_OFFSET_7
	default 0x80000000 if PHYS_OFFSET_8
	default 0xa0000000 if PHYS_OFFSET_A
	default 0xc0000000 if PHYS_OFFSET_C


and then select one of the bool symbols from each platform.
Would that address your question?

Here's a question:

Can we just get rid of PHYS_OFFSET???

If it's only used at boot for XIP systems, we could:

A) pass it in via an unused register like atags and DT
 or
B) just assume that atags or DT is in RAM, so round down to the nearest section and assume that is the start of your RAM

If it is needed after initial boot, then on first boot we save what was passed in from the boot loader for later use.

Hmm, you mean making phys_offset a runtime variable instead
of patching it at early boot time in the instructions?

I have no idea if that works, how much effort it would be,
or how much it would enlarge the kernel image size, but
you can definitely try.

Of course we must not break existing platforms using XIP_KERNEL
already, but the installed base among systems that are upgrading
to modern kernels is very small now, given how all modern platforms
don't support XIP_KERNEL today, or have no MMU to start with.

You're all barking up the wrong tree, because you don't understand
why it exists.

ARM_PATCH_PHYS_VIRT exists to support an init-time decided phys offset,
and it supports this by modifying each location that the phys offset
is used.  It determines this by looking at the location that the early
init code is executing, and masking the PC with a value that has been
carefully crafted to fit 99% of the existing platforms.

One of the side effects of ARM_PATCH_PHYS_VIRT is that we hide the
translation from the compiler, so the compiler is unable to optimise
things like virt_to_phys(phys_to_virt(x)) to just 'x' (and yes, such
things do happen.)

PHYS_OFFSET exists to cater for the case where ARM_PATCH_PHYS_VIRT is
disabled, because either ARM_PATCH_PHYS_VIRT does not work for the
platform, or the platform has special requirements and/or requires
better performance.  It switches back to the pre-ARM_PATCH_PHYS_VIRT
situation where the PHYS_OFFSET is a compile time constant.

Obviously, making PHYS_OFFSET a runtime variable is basically what
ARM_PATCH_PHYS_VIRT is doing.  That does not help these cases though,
because the problem cases are not whether it's a runtime variable or
not, it's how to arrive at the value for it in the first place.

Using the DTB location on XIP platforms is a no-goer - the flattened
DTB information can be fixed, so on an XIP platform it makes sense
for this to also be in flash, not in RAM (the whole point of XIP is
to remove constant data from RAM after all, so why would you want to
copy the FDT to RAM?)

Passing it in a register to the kernel image is also not possible:
we've been out of spare registers for some time now for passing
additional information into the kernel.  It wouldn't be a problem
had folk not had this "eww, I don't like ATAGs, lets get rid of them
and use DT instead" attitude: had we kept ATAGs, then we'd have an
in-memory format to pass this kind of information to the kernel.
That would solve soo many problems today it's untrue: stuff like
where a debugging UART is located and the type of it...

When DT was being proposed, my opinion was that's how it should've
been done, but I assumed that the DT folk knew better, and Grant was
very much of the opinion that ATAGs should be completely dropped (I
did touch on it with Grant.)  I regret now not having a discussion
about it and pressing strongly for it.

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

On 19 Feb 2016, Russell King wrote:

Using the DTB location on XIP platforms is a no-goer - the flattened
DTB information can be fixed, so on an XIP platform it makes sense
for this to also be in flash, not in RAM (the whole point of XIP is
to remove constant data from RAM after all, so why would you want to
copy the FDT to RAM?)

I was under the impression that the DTB had a limited life span, and once booted, it could be clobbered. Hence, RAM would not really be wasted (post boot that is).

For an XIP system (with MMU), if you have your DTB in ROM someplace, you run the risk of getting it cut off after the MMU setup is done because it would fall someplace after the _exiprom marker.

Passing it in a register to the kernel image is also not possible:
we've been out of spare registers for some time now for passing
additional information into the kernel.  It wouldn't be a problem
had folk not had this "eww, I don't like ATAGs, lets get rid of them
and use DT instead" attitude: had we kept ATAGs, then we'd have an
in-memory format to pass this kind of information to the kernel.
That would solve soo many problems today it's untrue: stuff like
where a debugging UART is located and the type of it...

Too bad we just couldn't have added an ATAG to point to a DTB. Sigh.


Chris

On Fri, 19 Feb 2016, Russell King - ARM Linux wrote:

ARM_PATCH_PHYS_VIRT exists to support an init-time decided phys offset,
and it supports this by modifying each location that the phys offset
is used.  It determines this by looking at the location that the early
init code is executing, and masking the PC with a value that has been
carefully crafted to fit 99% of the existing platforms.

One of the side effects of ARM_PATCH_PHYS_VIRT is that we hide the
translation from the compiler, so the compiler is unable to optimise
things like virt_to_phys(phys_to_virt(x)) to just 'x' (and yes, such
things do happen.)

PHYS_OFFSET exists to cater for the case where ARM_PATCH_PHYS_VIRT is
disabled, because either ARM_PATCH_PHYS_VIRT does not work for the
platform, or the platform has special requirements and/or requires
better performance.  It switches back to the pre-ARM_PATCH_PHYS_VIRT
situation where the PHYS_OFFSET is a compile time constant.

Obviously, making PHYS_OFFSET a runtime variable is basically what
ARM_PATCH_PHYS_VIRT is doing.  That does not help these cases though,
because the problem cases are not whether it's a runtime variable or
not, it's how to arrive at the value for it in the first place.

I think what Chris was suggesting is to have the same functionality as 
PATCH_PHYS_VIRT i.e. determining phys offset at run time while being 
XIP.  In theory that could mean that the kernel binary becomes 
independent of the physical location in flash where it executes from.

Arriving at the value for phys offset could be done based on sp instead 
of pc.  That's assuming the bootloader did not clobber sp before calling 
into the kernel.

But this is rather fragile. And normally if you are interested in XIP, 
you certainly have a highly customized kernel config already anyway. And 
having a build-time constant PHYS_OFFSET is of course what performs 
best.


Nicolas

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

quoted

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

We could have something like

config PHYS_OFFSET_0
	bool

config PHYS_OFFSET_1
	bool

config PHYS_OFFSET_2
	bool

... (we need 8 of the 16 possible addresses)


config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	default DRAM_BASE if !MMU
	default 0x00000000 if PHYS_OFFSET_0
	default 0x10000000 if PHYS_OFFSET_1
	default 0x20000000 if PHYS_OFFSET_2
	default 0x30000000 if PHYS_OFFSET_3
	default 0x70000000 if PHYS_OFFSET_7
	default 0x80000000 if PHYS_OFFSET_8
	default 0xa0000000 if PHYS_OFFSET_A
	default 0xc0000000 if PHYS_OFFSET_C


and then select one of the bool symbols from each platform.
Would that address your question?

Yes, but the ugliness factor isn't worth it IMHO.

I was wondering if something like this was possible:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        default DRAM_BASE if !MMU
        default 0x10000000 if FOO
        default 0x20000000 if BAR
        default 0x30000000 if BAZ
        default 0x00000000


Nicolas

On Friday 19 February 2016 11:10:22 Nicolas Pitre wrote:

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

quoted

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

quoted

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

...

quoted

and then select one of the bool symbols from each platform.
Would that address your question?

Yes, but the ugliness factor isn't worth it IMHO.

I was wondering if something like this was possible:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        default DRAM_BASE if !MMU
        default 0x10000000 if FOO
        default 0x20000000 if BAR
        default 0x30000000 if BAZ
        default 0x00000000

Ah, that was my previous approach, but Russell didn't like
how it makes it easier to fall back to an incorrect address
instead of forcing a build error when the address is not
configured.

	Arnd

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

On Friday 19 February 2016 11:10:22 Nicolas Pitre wrote:

quoted

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

quoted

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:

quoted

Acked-by: Nicolas Pitre <redacted>

Is there a way to provide a default for defaults?

...

quoted

quoted

and then select one of the bool symbols from each platform.
Would that address your question?

Yes, but the ugliness factor isn't worth it IMHO.

I was wondering if something like this was possible:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        default DRAM_BASE if !MMU
        default 0x10000000 if FOO
        default 0x20000000 if BAR
        default 0x30000000 if BAZ
        default 0x00000000

Ah, that was my previous approach, but Russell didn't like
how it makes it easier to fall back to an incorrect address
instead of forcing a build error when the address is not
configured.

Makes sense.

Yet, the only reason for a default here is to accommodate automatic 
build tests like randconfig, right?

If so then this should be "fixed" by having the config system provide 
built-in symbols that can be tested from kconfig files.  This way you 
could terminate the above list with:

	default 0x00000000 if RANDCONFIG || ALLYESCONFIG

or the like.


Nicolas

On Fri, Feb 19, 2016 at 12:31:02PM -0500, Nicolas Pitre wrote:

Yet, the only reason for a default here is to accommodate automatic 
build tests like randconfig, right?

If so then this should be "fixed" by having the config system provide 
built-in symbols that can be tested from kconfig files.  This way you 
could terminate the above list with:

	default 0x00000000 if RANDCONFIG || ALLYESCONFIG

or the like.

I've suggested in the past that we have kconf read a seed file for
these configurations.  kconf already has most of the required support
for this, we just need to teach it where to read it from.  Maybe
something like this.

 arch/arm/allrandom.config |  1 +
 scripts/kconfig/conf.c    | 61 ++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/arch/arm/allrandom.config b/arch/arm/allrandom.config
index e69de29bb2d1..5a70ef5926f5 100644
--- a/arch/arm/allrandom.config
+++ b/arch/arm/allrandom.config

@@ -0,0 +1 @@
+CONFIG_PHYS_OFFSET=0

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 866369f10ff8..5a4b2d8bbf9a 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c

@@ -12,6 +12,7 @@
 #include <time.h>
 #include <unistd.h>
 #include <getopt.h>
+#include <sys/fcntl.h>
 #include <sys/stat.h>
 #include <sys/time.h>
 #include <errno.h>

@@ -489,10 +490,53 @@ static void conf_usage(const char *progname)
 	printf("  --randconfig            New config with random answer to all options\n");
 }
 
+static int try_allconfig(int try_arch, int input_mode)
+{
+	const char *name = NULL;
+	int fd = -1, ret;
+
+	if (try_arch) {
+		const char *srctree = getenv("srctree");
+		const char *arch = getenv("ARCH");
+		
+		fd = open(".", O_DIRECTORY);
+		if (fd == -1) {
+			perror("opening .");
+			return -1;
+		}
+		if (chdir(srctree) == -1 ||
+		    chdir("arch") == -1 ||
+		    chdir(arch) == -1) {
+			perror("chdir");
+			return -1;
+		}
+	}
+
+	switch (input_mode) {
+	case allnoconfig:	name = "allno.config"; break;
+	case allyesconfig:	name = "allyes.config"; break;
+	case allmodconfig:	name = "allmod.config"; break;
+	case alldefconfig:	name = "alldef.config"; break;
+	case randconfig:	name = "allrandom.config"; break;
+	default: break;
+	}
+
+	ret = name ? conf_read_simple(name, S_DEF_USER) : 1;
+	if (ret)
+		ret = conf_read_simple("all.config", S_DEF_USER);
+
+	if (fd >= 0) {
+		fchdir(fd);
+		close(fd);
+	}
+
+	return ret;
+}
+
 int main(int ac, char **av)
 {
 	const char *progname = av[0];
-	int opt;
+	int opt, ret;
 	const char *name, *defconfig_file = NULL /* gcc uninit */;
 	struct stat tmpstat;
 

@@ -601,6 +645,9 @@ int main(int ac, char **av)
 	case allmodconfig:
 	case alldefconfig:
 	case randconfig:
+		ret = try_allconfig(1, input_mode);
+		if (ret < 0)
+			exit(1);
 		name = getenv("KCONFIG_ALLCONFIG");
 		if (!name)
 			break;

@@ -613,16 +660,8 @@ int main(int ac, char **av)
 			}
 			break;
 		}
-		switch (input_mode) {
-		case allnoconfig:	name = "allno.config"; break;
-		case allyesconfig:	name = "allyes.config"; break;
-		case allmodconfig:	name = "allmod.config"; break;
-		case alldefconfig:	name = "alldef.config"; break;
-		case randconfig:	name = "allrandom.config"; break;
-		default: break;
-		}
-		if (conf_read_simple(name, S_DEF_USER) &&
-		    conf_read_simple("all.config", S_DEF_USER)) {
+		ret = try_allconfig(0, input_mode);
+		if (ret) {
 			fprintf(stderr,
 				_("*** KCONFIG_ALLCONFIG set, but no \"%s\" or \"all.config\" file found\n"),
 				name);

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

On Friday 19 February 2016 18:07:25 Russell King - ARM Linux wrote:

On Fri, Feb 19, 2016 at 12:31:02PM -0500, Nicolas Pitre wrote:

quoted

Yet, the only reason for a default here is to accommodate automatic 
build tests like randconfig, right?

If so then this should be "fixed" by having the config system provide 
built-in symbols that can be tested from kconfig files.  This way you 
could terminate the above list with:

	default 0x00000000 if RANDCONFIG || ALLYESCONFIG

or the like.

I've suggested in the past that we have kconf read a seed file for
these configurations.  kconf already has most of the required support
for this, we just need to teach it where to read it from.  Maybe
something like this.

 arch/arm/allrandom.config |  1 +
 scripts/kconfig/conf.c    | 61 ++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 51 insertions(+), 11 deletions(-)

Interesting, I had never noticed that we had the infrastructure to have
separate presets for allno/allmod/allyes/...config by file name,
aside from the ${KCONFIG_ALLCONFIG}, I think your extension to make
it architecture specific is a very good idea, and it can solve a
couple of other problems as well, such as new toolchains barfing
on -march=armv3 and OABI support.

There is a bit of overlap with the Kconfig fragments, which are
defined in a similar way:

With the recently added Kconfig fragments support, you could do
(almost) the same thing by specifying

make randconfig allrandom.config

"almost", because

- The fragments use a search path including kernel/config/*.config
  and arch/*/configs/*.config, rather than arch/*/*.config
  I would prefer using the search path we have for the fragments now.

- The current implementation does not start out with the symbols
  from the fragment but instead applies the fragments one by one
  after the initial config, so the example above is the same as

	make randconfig
	make allrandom.config

  which does not have the same results. For this, I think starting
  with the fragment makes more sense, but that unfortunately requires
  changing the command line interface if we want to generalize it.

	Arnd

The merge_fdt_bootargs() function by definition consumes more than 1024
bytes of stack because it has a 1024 byte command line on the stack,
meaning that we always get a warning when building this file:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

However, as this is the decompressor and we know that it has a very shallow
call chain, and we do not actually risk overflowing the kernel stack
at runtime here.

This just shuts up the warning by disabling the warning flag for this
file.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/boot/compressed/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7a6a58ef8aaf..b5db4c868640 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile

@@ -85,6 +85,8 @@ $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/
 $(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
 	$(addprefix $(obj)/,$(libfdt_hdrs))
 
+CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
+
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

The merge_fdt_bootargs() function by definition consumes more than 1024
bytes of stack because it has a 1024 byte command line on the stack,
meaning that we always get a warning when building this file:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

However, as this is the decompressor and we know that it has a very shallow
call chain, and we do not actually risk overflowing the kernel stack
at runtime here.

This just shuts up the warning by disabling the warning flag for this
file.

What about setting the warning to 2048 instead?

The merge_fdt_bootargs() function by definition consumes more than 1024
bytes of stack because it has a 1024 byte command line on the stack,
meaning that we always get a warning when building this file:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

However, as this is the decompressor and we know that it has a very shallow
call chain, and we do not actually risk overflowing the kernel stack
at runtime here.

This just shuts up the warning by slightly increasing the limit for this
file.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
On Thursday 18 February 2016 11:13:52 Nicolas Pitre wrote:

What about setting the warning to 2048 instead?

Sure, actually 1280 is more than enough I think.

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7a6a58ef8aaf..2cc63038d6c8 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile

@@ -85,6 +85,8 @@ $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/
 $(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
 	$(addprefix $(obj)/,$(libfdt_hdrs))
 
+CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
+
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

The merge_fdt_bootargs() function by definition consumes more than 1024
bytes of stack because it has a 1024 byte command line on the stack,
meaning that we always get a warning when building this file:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

However, as this is the decompressor and we know that it has a very shallow
call chain, and we do not actually risk overflowing the kernel stack
at runtime here.

This just shuts up the warning by slightly increasing the limit for this
file.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Nicolas Pitre <redacted>

On Thursday 18 February 2016 17:26:56 Arnd Bergmann wrote:

On Thursday 18 February 2016 11:13:52 Nicolas Pitre wrote:

quoted

What about setting the warning to 2048 instead?

Sure, actually 1280 is more than enough I think.

It turns out that doesn't fix the problem though, as the new
argument gets prepended and the existing flag overrides it.

I have modified the patch now to do both:

CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280

	Arnd

When CONFIG_MMU is disabled, the access_ok() and __range_ok()
macros always return success, and there is a cast to void
to ensure the compiler does not warn about an unused address
variable. However, at least one driver has a variable for
the size argument as well and does warn about that one:

drivers/vhost/vhost.c: In function 'vq_access_ok':
drivers/vhost/vhost.c:633:9: warning: unused variable 's' [-Wunused-variable]

This changes the macro to also ignore the size argument
explicitly to shut up that warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/uaccess.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 35c9db857ebe..9c74c84a10d2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h

@@ -290,7 +290,7 @@ extern int __put_user_8(void *, unsigned long long);
 
 #define segment_eq(a, b)		(1)
 #define __addr_ok(addr)		((void)(addr), 1)
-#define __range_ok(addr, size)	((void)(addr), 0)
+#define __range_ok(addr, size)	((void)(addr), (void)(size), 0)
 #define get_fs()		(KERNEL_DS)
 
 static inline void set_fs(mm_segment_t fs)

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

When CONFIG_MMU is disabled, the access_ok() and __range_ok()
macros always return success, and there is a cast to void
to ensure the compiler does not warn about an unused address
variable. However, at least one driver has a variable for
the size argument as well and does warn about that one:

drivers/vhost/vhost.c: In function 'vq_access_ok':
drivers/vhost/vhost.c:633:9: warning: unused variable 's' [-Wunused-variable]

This changes the macro to also ignore the size argument
explicitly to shut up that warning.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Nicolas Pitre <redacted>

The NO_DMA macro is only used on the RiscPC ecard bus, and conflicts
with a couple of driver specific macros with the same name:

drivers/scsi/eata.c:571:0: warning: "NO_DMA" redefined
 #define NO_DMA  0xff
In file included from ../drivers/scsi/eata.c:495:0:
arch/arm/include/asm/dma.h:140:0: note: this is the location of the previous definition
 #define NO_DMA 255

This moves the definition out of the asm/dma.h header that is used
by all ISA DMA API users and into the ecard header.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/dma.h   | 4 ----
 arch/arm/include/asm/ecard.h | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index bb4fa67da541..573128481fc4 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h

@@ -136,10 +136,6 @@ extern void set_dma_speed(unsigned int chan, int cycle_ns);
  */
 extern int  get_dma_residue(unsigned int chan);
 
-#ifndef NO_DMA
-#define NO_DMA	255
-#endif
-
 #endif /* CONFIG_ISA_DMA_API */
 
 #ifdef CONFIG_PCI

diff --git a/arch/arm/include/asm/ecard.h b/arch/arm/include/asm/ecard.h
index eaea14676d57..d3e16628c792 100644
--- a/arch/arm/include/asm/ecard.h
+++ b/arch/arm/include/asm/ecard.h

@@ -83,6 +83,10 @@
 #define CONST const
 #endif
 
+#ifndef NO_DMA
+#define NO_DMA	255
+#endif
+
 #define MAX_ECARDS	9
 
 struct ecard_id {			/* Card ID structure		*/

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

The NO_DMA macro is only used on the RiscPC ecard bus, and conflicts
with a couple of driver specific macros with the same name:

drivers/scsi/eata.c:571:0: warning: "NO_DMA" redefined
 #define NO_DMA  0xff
In file included from ../drivers/scsi/eata.c:495:0:
arch/arm/include/asm/dma.h:140:0: note: this is the location of the previous definition
 #define NO_DMA 255

This moves the definition out of the asm/dma.h header that is used
by all ISA DMA API users and into the ecard header.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Nicolas Pitre <redacted>

The gcc-4.9 optimization goes wrong while building target_core_iblock.c
for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
output:

ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!

I could not find anyone who is interested in fixing it in gcc,
so as a workaround this disables the do_div magic, just like
we do for old compilers and for OABI.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/include/asm/div64.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index 7d919a9b32e5..958fdc2363f5 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h

@@ -58,6 +58,14 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
  */
 #define do_div(n, base) __div64_32(&(n), base)
 
+#elif defined(CONFIG_CPU_32v3)
+
+/*
+ * modern compiler versions (>= gcc-4.9) tend to misoptimize
+ * the code for ARMv3, and this is not getting fixed any more.
+ */
+#define do_div(n, base) __div64_32(&(n), base)
+
 #else
 
 /*

-- 
2.7.0

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

The gcc-4.9 optimization goes wrong while building target_core_iblock.c
for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
output:

ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!

I could not find anyone who is interested in fixing it in gcc,
so as a workaround this disables the do_div magic, just like
we do for old compilers and for OABI.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

I suppose this is good enough for the purpose of keeping RiscPC 
buildable. Whether or not it is still used is another question.  If it 
is then its user probably expects it to be slow already.

Acked-by: Nicolas Pitre <redacted>

Still unfortunate having to use a big hammer such as -march=armv3 just 
to avoid halfword memory accesses.

On Thursday 18 February 2016 12:20:51 Nicolas Pitre wrote:

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

quoted

The gcc-4.9 optimization goes wrong while building target_core_iblock.c
for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
output:

ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!

I could not find anyone who is interested in fixing it in gcc,
so as a workaround this disables the do_div magic, just like
we do for old compilers and for OABI.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

I suppose this is good enough for the purpose of keeping RiscPC 
buildable. Whether or not it is still used is another question.  If it 
is then its user probably expects it to be slow already.

Acked-by: Nicolas Pitre <redacted>

Thanks.

Still unfortunate having to use a big hammer such as -march=armv3 just 
to avoid halfword memory accesses.

I brought this up with the gcc developers before. They would really want
to deprecated ARMv3 support, but nobody seems interested in implementing
halfword memory access as a replacement.

FWIW, I am currently still allowing ARMv3 in randconfig builds, but
have run into 12 internal compiler errors with that, on gcc-4.9 or higher.
It's probably all the same bug, but I don't see this getting fixed
unless the RiscOS people update to a newer toolchain and run into the
same problem.

The patch below disables optimization so I am able to build this, but
I see no way to fix this upstream.

	Arnd

 arch/arm/boot/compressed/Makefile            |    3 +++
 drivers/block/aoe/Makefile                   |    3 +++
 drivers/block/paride/Makefile                |    3 +++
 drivers/net/Makefile                         |    7 +++++++
 drivers/net/ethernet/apm/xgene/Makefile      |    4 ++++
 drivers/staging/lustre/lustre/llite/Makefile |    4 ++++
 fs/fat/Makefile                              |    4 ++++
 kernel/Makefile                              |    3 +++
 lib/zlib_inflate/Makefile                    |    4 ++++
 net/decnet/Makefile                          |    4 ++++
 net/irda/Makefile                            |    4 ++++
 11 files changed, 43 insertions(+)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index b5db4c868640..f000efa55003 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile

@@ -9,6 +9,9 @@ OBJS		=
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
 HEAD	= head.o
 OBJS	+= misc.o decompress.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_decompress.o += -O0
+endif
 ifeq ($(CONFIG_DEBUG_UNCOMPRESS),y)
 OBJS	+= debug.o
 endif

diff --git a/drivers/block/aoe/Makefile b/drivers/block/aoe/Makefile
index 06ea82cdf27d..7007fe7a14ce 100644
--- a/drivers/block/aoe/Makefile
+++ b/drivers/block/aoe/Makefile

@@ -4,3 +4,6 @@
 
 obj-$(CONFIG_ATA_OVER_ETH)	+= aoe.o
 aoe-y := aoeblk.o aoechr.o aoecmd.o aoedev.o aoemain.o aoenet.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_aoechr.o += -O0
+endif

diff --git a/drivers/block/paride/Makefile b/drivers/block/paride/Makefile
index a539e004bb7a..26ac7c329e4b 100644
--- a/drivers/block/paride/Makefile
+++ b/drivers/block/paride/Makefile

@@ -11,6 +11,9 @@ obj-$(CONFIG_PARIDE_BPCK)	+= bpck.o
 obj-$(CONFIG_PARIDE_COMM)	+= comm.o
 obj-$(CONFIG_PARIDE_DSTR)	+= dstr.o
 obj-$(CONFIG_PARIDE_KBIC)	+= kbic.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_kbic.o += -O0
+endif
 obj-$(CONFIG_PARIDE_EPAT)	+= epat.o
 obj-$(CONFIG_PARIDE_EPIA)	+= epia.o
 obj-$(CONFIG_PARIDE_FRPW)	+= frpw.o

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 900b0c5320bb..a249ae2a5c9b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile

@@ -12,6 +12,10 @@ obj-$(CONFIG_EQUALIZER) += eql.o
 obj-$(CONFIG_IFB) += ifb.o
 obj-$(CONFIG_MACVLAN) += macvlan.o
 obj-$(CONFIG_MACVTAP) += macvtap.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_macvtap.o += -O1
+endif
+
 obj-$(CONFIG_MII) += mii.o
 obj-$(CONFIG_MDIO) += mdio.o
 obj-$(CONFIG_NET) += Space.o loopback.o

@@ -70,3 +74,6 @@ obj-$(CONFIG_HYPERV_NET) += hyperv/
 obj-$(CONFIG_NTB_NETDEV) += ntb_netdev.o
 
 obj-$(CONFIG_FUJITSU_ES) += fjes/
+ifdef CONFIG_CPU_32v3
+CFLAGS_tun.o += -O1
+endif

diff --git a/drivers/net/ethernet/apm/xgene/Makefile b/drivers/net/ethernet/apm/xgene/Makefile
index 700b5abe5de5..b357127e77ed 100644
--- a/drivers/net/ethernet/apm/xgene/Makefile
+++ b/drivers/net/ethernet/apm/xgene/Makefile

@@ -5,3 +5,7 @@
 xgene-enet-objs := xgene_enet_hw.o xgene_enet_sgmac.o xgene_enet_xgmac.o \
 		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o
 obj-$(CONFIG_NET_XGENE) += xgene-enet.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_xgene_enet_main.o += -O1
+endif

diff --git a/drivers/staging/lustre/lustre/llite/Makefile b/drivers/staging/lustre/lustre/llite/Makefile
index 9ac29e718da3..7ebe6c751448 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile

@@ -8,3 +8,7 @@ lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
 	    vvp_dev.o vvp_page.o vvp_lock.o vvp_io.o vvp_object.o lproc_llite.o
 
 llite_lloop-y := lloop.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_file.o += -O1
+endif

diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 964b634f6667..b33feac5df36 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile

@@ -9,3 +9,7 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
 fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
 vfat-y := namei_vfat.o
 msdos-y := namei_msdos.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_dir.o += -O0
+endif

diff --git a/kernel/Makefile b/kernel/Makefile
index f0c40bf49d9f..d0c818182fd8 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile

@@ -55,6 +55,9 @@ ifneq ($(CONFIG_SMP),y)
 obj-y += up.o
 endif
 obj-$(CONFIG_UID16) += uid16.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_uid16.o += -O0
+endif
 obj-$(CONFIG_MODULES) += module.o
 obj-$(CONFIG_MODULE_SIG) += module_signing.o
 obj-$(CONFIG_KALLSYMS) += kallsyms.o

diff --git a/lib/zlib_inflate/Makefile b/lib/zlib_inflate/Makefile
index 49f8ce5774d2..d99fd57d0d34 100644
--- a/lib/zlib_inflate/Makefile
+++ b/lib/zlib_inflate/Makefile

@@ -17,3 +17,7 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate.o
 
 zlib_inflate-objs := inffast.o inflate.o infutil.o \
 		     inftrees.o inflate_syms.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_inffast.o += -O0
+endif

diff --git a/net/decnet/Makefile b/net/decnet/Makefile
index e44003af71f6..a99608c9bd93 100644
--- a/net/decnet/Makefile
+++ b/net/decnet/Makefile

@@ -8,3 +8,7 @@ decnet-y += sysctl_net_decnet.o
 
 obj-$(CONFIG_NETFILTER) += netfilter/
 
+ifdef CONFIG_CPU_32v3
+CFLAGS_dn_table.o += -O1
+endif
+

diff --git a/net/irda/Makefile b/net/irda/Makefile
index 187f6c563a4b..d1801fda7865 100644
--- a/net/irda/Makefile
+++ b/net/irda/Makefile

@@ -13,3 +13,7 @@ irda-y := iriap.o iriap_event.o irlmp.o irlmp_event.o irlmp_frame.o \
 	  discovery.o parameters.o irnetlink.o irmod.o
 irda-$(CONFIG_PROC_FS) += irproc.o
 irda-$(CONFIG_SYSCTL) += irsysctl.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_wrapper.o += -O0
+endif

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

On Thursday 18 February 2016 12:20:51 Nicolas Pitre wrote:

quoted

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

quoted

The gcc-4.9 optimization goes wrong while building target_core_iblock.c
for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
output:

ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!

I could not find anyone who is interested in fixing it in gcc,
so as a workaround this disables the do_div magic, just like
we do for old compilers and for OABI.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

I suppose this is good enough for the purpose of keeping RiscPC 
buildable. Whether or not it is still used is another question.  If it 
is then its user probably expects it to be slow already.

Acked-by: Nicolas Pitre <redacted>

Thanks.

quoted

Still unfortunate having to use a big hammer such as -march=armv3 just 
to avoid halfword memory accesses.

I brought this up with the gcc developers before. They would really want
to deprecated ARMv3 support, but nobody seems interested in implementing
halfword memory access as a replacement.

Actually, the only thing needed as far as Linux on RiscPC is concerned 
is a compiler switch that prevents the use of STRH, LDRH and LDRSH 
instructions when -march=armv4 is used.

FWIW, I am currently still allowing ARMv3 in randconfig builds, but
have run into 12 internal compiler errors with that, on gcc-4.9 or higher.
It's probably all the same bug, but I don't see this getting fixed
unless the RiscOS people update to a newer toolchain and run into the
same problem.

Hmmm I suppose the ability to use halfword accesses is assumed by new 
optimization patterns and that's why gcc fails when they're not 
available.

The patch below disables optimization so I am able to build this, but
I see no way to fix this upstream.

That begs the question again: is anyone using mainline Linux on RiscPC?
If I remember correctly, the ability to boot Linux on an i386 was 
removed a while ago and nobody complained.


Nicolas

ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
so building the kprobe test code fails with lots of warnings about
these:

/tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode `umull r0,r1,r2,r3'
/tmp/ccI4SKHx.s:19617: Error: selected processor does not support ARM mode `umullls r7,r8,r9,r10'
/tmp/ccI4SKHx.s:19645: Error: selected processor does not support ARM mode `umull lr,r12,r11,r13'
/tmp/ccI4SKHx.s:19727: Error: selected processor does not support ARM mode `umulls r0,r1,r2,r3'
...
/tmp/ccI4SKHx.s:21273: Error: selected processor does not support ARM mode `strh r0,[r1,-r2]'
/tmp/ccI4SKHx.s:21309: Error: selected processor does not support ARM mode `streqh r14,[r11,r12]'
/tmp/ccI4SKHx.s:21333: Error: selected processor does not support ARM mode `streqh r14,[r13,r12]'

This puts all the affected instructions inside an #ifdef section,
like we do for the other architecture levels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/probes/kprobes/test-arm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/probes/kprobes/test-arm.c b/arch/arm/probes/kprobes/test-arm.c
index 8866aedfdea2..4e8511f0582d 100644
--- a/arch/arm/probes/kprobes/test-arm.c
+++ b/arch/arm/probes/kprobes/test-arm.c

@@ -391,6 +391,7 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(__inst_arm(0xe0700090) " @ undef")
 	TEST_UNSUPPORTED(__inst_arm(0xe07fff9f) " @ undef")
 
+#if __LINUX_ARM_ARCH__ >= 4
 	TEST_RR(  "umull	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "umullls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "umull	lr, r12, r",11,VAL3,", r13")

@@ -436,6 +437,7 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(__inst_arm(0xe0f0f392) " @ smlals r0, pc, r2, r3")
 	TEST_UNSUPPORTED(__inst_arm(0xe0f0139f) " @ smlals r0, r1, pc, r3")
 	TEST_UNSUPPORTED(__inst_arm(0xe0f01f92) " @ smlals r0, r1, r2, pc")
+#endif
 
 	TEST_GROUP("Synchronization primitives")
 

@@ -478,7 +480,7 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED("ldrexh	r2, [sp]")
 #endif
 	TEST_GROUP("Extra load/store instructions")
-
+#if __LINUX_ARM_ARCH__ >= 4
 	TEST_RPR(  "strh	r",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
 	TEST_RPR(  "streqh	r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
 	TEST_UNSUPPORTED(  "streqh	r14, [r13, r12]")

@@ -560,6 +562,7 @@ void kprobe_arm_test_cases(void)
 	TEST(      "ldrsh	r0, [pc, #0]")
 	TEST_UNSUPPORTED(__inst_arm(0xe1ffc3f0) "	@ ldrsh r12, [pc, #48]!")
 	TEST_UNSUPPORTED(__inst_arm(0xe0d9f3f0) "	@ ldrsh pc, [r9], #48")
+#endif
 
 #if __LINUX_ARM_ARCH__ >= 7
 	TEST_UNSUPPORTED("strht	r1, [r2], r3")

-- 
2.7.0

On Thu, 2016-02-18 at 15:02 +0100, Arnd Bergmann wrote:

ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
so building the kprobe test code fails with lots of warnings about
these:

/tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode `umull r0,r1,r2,r3'
/tmp/ccI4SKHx.s:19617: Error: selected processor does not support ARM mode `umullls r7,r8,r9,r10'
/tmp/ccI4SKHx.s:19645: Error: selected processor does not support ARM mode `umull lr,r12,r11,r13'
/tmp/ccI4SKHx.s:19727: Error: selected processor does not support ARM mode `umulls r0,r1,r2,r3'
...
/tmp/ccI4SKHx.s:21273: Error: selected processor does not support ARM mode `strh r0,[r1,-r2]'
/tmp/ccI4SKHx.s:21309: Error: selected processor does not support ARM mode `streqh r14,[r11,r12]'
/tmp/ccI4SKHx.s:21333: Error: selected processor does not support ARM mode `streqh r14,[r13,r12]'

This puts all the affected instructions inside an #ifdef section,
like we do for the other architecture levels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---

I was about to say that I didn't know that we supported ARMv3 then got a
feeling of deja vu :-) [1]

Acked-by: Jon Medhurst <redacted>

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/242997.html

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
so building the kprobe test code fails with lots of warnings about
these:

/tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode `umull r0,r1,r2,r3'
/tmp/ccI4SKHx.s:19617: Error: selected processor does not support ARM mode `umullls r7,r8,r9,r10'
/tmp/ccI4SKHx.s:19645: Error: selected processor does not support ARM mode `umull lr,r12,r11,r13'
/tmp/ccI4SKHx.s:19727: Error: selected processor does not support ARM mode `umulls r0,r1,r2,r3'
...
/tmp/ccI4SKHx.s:21273: Error: selected processor does not support ARM mode `strh r0,[r1,-r2]'
/tmp/ccI4SKHx.s:21309: Error: selected processor does not support ARM mode `streqh r14,[r11,r12]'
/tmp/ccI4SKHx.s:21333: Error: selected processor does not support ARM mode `streqh r14,[r13,r12]'

This puts all the affected instructions inside an #ifdef section,
like we do for the other architecture levels.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Nicolas Pitre <redacted>