[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Arnd Bergmann]

On Wednesday 27 January 2016 17:30:18 Fengguang Wu wrote:

> > Looks good, I'm just unsure about "multi_v8_defconfig", this does not
> > exist. Do you mean multi_v5_defconfig?

> Ah yes, multi_v8_defconfig does not exist actually.

Ok, can you include multi_v5_defconfig than?

I see you have one named "arm-arm5", which may be the same.

> > I also wonder if you include 'randconfig' builds for some architectures.
> > I have patches for all remaining errors and warnings that I see with
> > ARM randconfig builds today. Not all of them are merged yet, but I could
> > probably come up with a file to be used as input to KCONFIG_ALLCONFIG
> > to eliminate the known-broken configurations, if you are interested.
> 
> If the are mostly ready for upstream, it may be easier to wait until
> upstream randconfig works just fine for ARM.

I have around 130 patches for warnings that I'm submitting at the moment, but
there are a couple of really tricky ones that I don't currently have
a good plan for:

- in some configurations, you end up without any boards selected, hitting
  an #error in the final link
- ARMv3 support in gcc is rather broken and causes internal compiler errors
  among other things
- the old ELF format (OABI) doesn't work in some cases
- GCOV_PROFILE_ALL causes problems that need to be debugged
- XIP_KERNEL sometimes causes kallsyms to fail
- not all platforms implement the complete clk API, if they don't
  use CONFIG_COMMON_CLK (I have patch for that we can probably merge)
- CONFIG_PHYS_OFFSET needs to be entered manually to be a number
  in 'make config'
- same for DEBUG_LL

	Arnd

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Fengguang Wu]

On Wed, Jan 27, 2016 at 10:44:01AM +0100, Arnd Bergmann wrote:
> On Wednesday 27 January 2016 17:30:18 Fengguang Wu wrote:
> 
> > > Looks good, I'm just unsure about "multi_v8_defconfig", this does not
> > > exist. Do you mean multi_v5_defconfig?
> 
> > Ah yes, multi_v8_defconfig does not exist actually.
> 
> Ok, can you include multi_v5_defconfig than?
 
OK, done.

> I see you have one named "arm-arm5", which may be the same.

Yes, looks so -- it's provided by someone else long time ago.

> > > I also wonder if you include 'randconfig' builds for some architectures.
> > > I have patches for all remaining errors and warnings that I see with
> > > ARM randconfig builds today. Not all of them are merged yet, but I could
> > > probably come up with a file to be used as input to KCONFIG_ALLCONFIG
> > > to eliminate the known-broken configurations, if you are interested.
> > 
> > If the are mostly ready for upstream, it may be easier to wait until
> > upstream randconfig works just fine for ARM.
> 
> I have around 130 patches for warnings that I'm submitting at the moment, but
> there are a couple of really tricky ones that I don't currently have
> a good plan for:
> 
> - in some configurations, you end up without any boards selected, hitting
>   an #error in the final link
> - ARMv3 support in gcc is rather broken and causes internal compiler errors
>   among other things
> - the old ELF format (OABI) doesn't work in some cases
> - GCOV_PROFILE_ALL causes problems that need to be debugged
> - XIP_KERNEL sometimes causes kallsyms to fail
> - not all platforms implement the complete clk API, if they don't
>   use CONFIG_COMMON_CLK (I have patch for that we can probably merge)

The robot may explicitly enable/disable some CONFIG_* after randconfig
to workaround known problems.

> - CONFIG_PHYS_OFFSET needs to be entered manually to be a number
>   in 'make config'

That's a problem for auto tests.

> - same for DEBUG_LL

Thanks,
Fengguang

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Arnd Bergmann]

On Thursday 28 January 2016 11:14:35 Fengguang Wu wrote:

> > - CONFIG_PHYS_OFFSET needs to be entered manually to be a number
> >   in 'make config'
> 
> That's a problem for auto tests.

Ok, I'll try to revisit this one. Maybe I can turn it into a
'default 0xffffffff' with a compile-time warning, or make
'default 0' the fallback when it's not specified otherwise.

	Arnd

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Russell King - ARM Linux]

On Thu, Jan 28, 2016 at 11:14:35AM +0800, Fengguang Wu wrote:
> On Wed, Jan 27, 2016 at 10:44:01AM +0100, Arnd Bergmann wrote:
> > - CONFIG_PHYS_OFFSET needs to be entered manually to be a number
> >   in 'make config'
> 
> That's a problem for auto tests.

I'm really against the idea of providing some kind of "default" to it.
Not providing a default means that people _have_ to do some research
for their particular system in order to provide a value, and they're
more likely to get the right value.  Providing a default will lead to
the assumption that the value is okay, and then we'll end up with
people complaining that their kernel doesn't boot, and is totally
silent.

The only default I'd accept is one based on the rest of the config -
in other words, re-introducing all the physical address of RAM that
we used to have in the mach/memory.h files...

There's other ways around these kinds of things, the Kconfig system
does allow a Kconfig fragment which can be used to pre-set some
configuration options to particular values - and so which can be used
to set CONFIG_PHYS_OFFSET prior to an allrandconfig or similar.

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

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Geert Uytterhoeven]

Hi Arnd,

On Wed, Jan 27, 2016 at 10:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> - in some configurations, you end up without any boards selected, hitting
>   an #error in the final link

FWIW, I have a similar problem with m68k+MMU=y randconfig...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

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

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Arnd Bergmann]

On Thursday 28 January 2016 17:42:41 you wrote:
> On Thu, Jan 28, 2016 at 11:14:35AM +0800, Fengguang Wu wrote:
> > On Wed, Jan 27, 2016 at 10:44:01AM +0100, Arnd Bergmann wrote:
> > > - CONFIG_PHYS_OFFSET needs to be entered manually to be a number
> > >   in 'make config'
> > 
> > That's a problem for auto tests.
> 
> I'm really against the idea of providing some kind of "default" to it.
> Not providing a default means that people _have_ to do some research
> for their particular system in order to provide a value, and they're
> more likely to get the right value.  Providing a default will lead to
> the assumption that the value is okay, and then we'll end up with
> people complaining that their kernel doesn't boot, and is totally
> silent.
> 
> The only default I'd accept is one based on the rest of the config -
> in other words, re-introducing all the physical address of RAM that
> we used to have in the mach/memory.h files...

This doesn't sound too hard. I've picked the defaults out of the
git history in the patch below. The only tricky part was davinci,
which has two different addresses and requires a little rework
to avoid circular dependencies.

Most platforms these days hardcode ARCH_PATCH_PHS_VIRT anyway,
so we only need to list the bunch of remaining ones.

> There's other ways around these kinds of things, the Kconfig system
> does allow a Kconfig fragment which can be used to pre-set some
> configuration options to particular values - and so which can be used
> to set CONFIG_PHYS_OFFSET prior to an allrandconfig or similar.

I don't know what Fenguang's problem was with that approach, but
at least at the moment he's using a fixup after running randconfig.
In my own tests, I'm doing yet another approach by marking a
handful of symbols as 'depends on BROKEN' in my testing patches,
but clearly that does not work when building other people's trees.

The other related issue is the DEBUG_UART_{VIRT,PHYS} setting,
where there is no safe platform-specific default. I have two
ideas for working around that, maybe one of them sounds ok to
you:

a) find a way to warn and/or disable DEBUG_LL when no address
   is set, rather than failing the build

b) add 'default 0 if COMPILE_TEST' to make it harder to get this
   wrong by accident (hopefully nobody tries to run a COMPILE_TEST
   kernel). Also maybe add a #warning if DEBUG_UART_VIRT is
   outside of VMALLOC_START...PCI_IOBASE area, which would cover
   this case as well.

	Arnd

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2217ec9726c9..1d2b5e6cab14 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -273,15 +273,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.
@@ -627,6 +641,7 @@ config ARCH_DAVINCI
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKDEV_LOOKUP
+	select CPU_ARM926T
 	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_IRQ_CHIP
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 7a9f2b8c0a42..36c8f5324e43 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -9,7 +9,6 @@ config CP_INTC
 
 config ARCH_DAVINCI_DMx
 	bool
-	select CPU_ARM926T
 
 menu "TI DaVinci Implementations"
 
@@ -32,7 +31,7 @@ config ARCH_DAVINCI_DM646x
 
 config ARCH_DAVINCI_DA830
 	bool "DA830/OMAP-L137/AM17x based system"
-	depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
+	depends on !ARCH_DAVINCI_DMx || (AUTO_ZRELADDR && ARM_PATCH_PHYS_VIRT)
 	select ARCH_DAVINCI_DA8XX
 	# needed on silicon revs 1.0, 1.1:
 	select CPU_DCACHE_WRITETHROUGH if !CPU_DCACHE_DISABLE
@@ -40,13 +39,12 @@ config ARCH_DAVINCI_DA830
 
 config ARCH_DAVINCI_DA850
 	bool "DA850/OMAP-L138/AM18x based system"
-	depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
+	depends on !ARCH_DAVINCI_DMx || (AUTO_ZRELADDR && ARM_PATCH_PHYS_VIRT)
 	select ARCH_DAVINCI_DA8XX
 	select CP_INTC
 
 config ARCH_DAVINCI_DA8XX
 	bool
-	select CPU_ARM926T
 
 config ARCH_DAVINCI_DM365
 	bool "DaVinci 365 based system"

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Jan 29, 2016 at 12:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The other related issue is the DEBUG_UART_{VIRT,PHYS} setting,
> where there is no safe platform-specific default. I have two
> ideas for working around that, maybe one of them sounds ok to
> you:
>
> a) find a way to warn and/or disable DEBUG_LL when no address
>    is set, rather than failing the build
>
> b) add 'default 0 if COMPILE_TEST' to make it harder to get this
>    wrong by accident (hopefully nobody tries to run a COMPILE_TEST
>    kernel). Also maybe add a #warning if DEBUG_UART_VIRT is

Make sure to add it at the end of the list, so enabling COMPILE_TEST in a
working .config should give another working .config.

Perhaps you can use 0xdeadbeef instead of 0, and add

    #if DEBUG_UART_PHYS == 0xdeadbeed
    #warning Broken value of DEBUG_UART_PHYS.
    #endif

somewhere?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

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

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Arnd Bergmann]

On Friday 29 January 2016 09:01:31 Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Fri, Jan 29, 2016 at 12:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The other related issue is the DEBUG_UART_{VIRT,PHYS} setting,
> > where there is no safe platform-specific default. I have two
> > ideas for working around that, maybe one of them sounds ok to
> > you:
> >
> > a) find a way to warn and/or disable DEBUG_LL when no address
> >    is set, rather than failing the build
> >
> > b) add 'default 0 if COMPILE_TEST' to make it harder to get this
> >    wrong by accident (hopefully nobody tries to run a COMPILE_TEST
> >    kernel). Also maybe add a #warning if DEBUG_UART_VIRT is
> 
> Make sure to add it at the end of the list, so enabling COMPILE_TEST in a
> working .config should give another working .config.

Sure, I've just done a largish series of patches in 4.5 to fix that
bug where we had it already.

> Perhaps you can use 0xdeadbeef instead of 0, and add
> 
>     #if DEBUG_UART_PHYS == 0xdeadbeed
>     #warning Broken value of DEBUG_UART_PHYS.
>     #endif
> 
> somewhere?

I can do that, though I don't see much of an advantage, as zero
is no more likely to be a real address than 0xdeadbeed.

How about the version below?

	Arnd

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175d0203..6cc09cf8618f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1526,6 +1526,7 @@ config DEBUG_UART_PHYS
 	default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
 	default 0xfffe8600 if DEBUG_BCM63XX_UART
 	default 0xfffff700 if ARCH_IOP33X
+	default 0xdeadbeef if DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || DEBUG_LL_UART_EFM32
 	depends on ARCH_EP93XX || \
 	        DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
 		DEBUG_LL_UART_EFM32 || \
@@ -1628,6 +1629,7 @@ config DEBUG_UART_VIRT
 	default 0xff003000 if DEBUG_U300_UART
 	default 0xffd01000 if DEBUG_HIP01_UART
 	default DEBUG_UART_PHYS if !MMU
+	default 0xdeadbeef if DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || DEBUG_LL_UART_EFM32
 	depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
 		DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_MESON_UARTAO || \
 		DEBUG_NETX_UART || \
diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
index 7f7446f6f806..1191b1458586 100644
--- a/arch/arm/include/debug/8250.S
+++ b/arch/arm/include/debug/8250.S
@@ -9,6 +9,9 @@
  */
 #include <linux/serial_reg.h>
 
+#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xe0000000
+#include "none.S"
+#else
 		.macro	addruart, rp, rv, tmp
 		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
 		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
@@ -55,3 +58,5 @@
 		beq	1001b
 #endif
 		.endm
+
+#endif
diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S
index 660fa1e4b77b..537021761e4a 100644
--- a/arch/arm/include/debug/efm32.S
+++ b/arch/arm/include/debug/efm32.S
@@ -6,6 +6,9 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xf0000000
+#include "none.S"
+#else
 
 #define UARTn_CMD		0x000c
 #define UARTn_CMD_TXEN			0x0004
@@ -43,3 +46,5 @@
 		tst	\rd, #UARTn_STATUS_TXC
 		bne	1001b
 		.endm
+
+#endif
diff --git a/arch/arm/include/debug/none.S b/arch/arm/include/debug/none.S
new file mode 100644
index 000000000000..75cd1bbee5c4
--- /dev/null
+++ b/arch/arm/include/debug/none.S
@@ -0,0 +1,16 @@
+
+#warning DEBUG_LL not configured, disabling
+
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =0
+		ldr	\rv, =0
+		.endm
+
+		.macro	senduart,rd,rx
+		.endm
+
+		.macro	busyuart,rd,rx
+		.endm
+
+		.macro	waituart,rd,rx
+		.endm
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index f7d8323cefcc..fbe0cad32be0 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -10,6 +10,9 @@
  * published by the Free Software Foundation.
  *
 */
+#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xf0000000
+#include "none.S"
+#else
 #include <linux/amba/serial.h>
 
 #ifdef CONFIG_DEBUG_ZTE_ZX
@@ -43,3 +46,4 @@
 		tst	\rd, #UART01x_FR_BUSY
 		bne	1001b
 		.endm
+#endif

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Jan 29, 2016 at 9:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index c6b6175d0203..6cc09cf8618f 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1526,6 +1526,7 @@ config DEBUG_UART_PHYS
>         default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
>         default 0xfffe8600 if DEBUG_BCM63XX_UART
>         default 0xfffff700 if ARCH_IOP33X
> +       default 0xdeadbeef if DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || DEBUG_LL_UART_EFM32
>         depends on ARCH_EP93XX || \
>                 DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
>                 DEBUG_LL_UART_EFM32 || \
> @@ -1628,6 +1629,7 @@ config DEBUG_UART_VIRT
>         default 0xff003000 if DEBUG_U300_UART
>         default 0xffd01000 if DEBUG_HIP01_UART
>         default DEBUG_UART_PHYS if !MMU
> +       default 0xdeadbeef if DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || DEBUG_LL_UART_EFM32
>         depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
>                 DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_MESON_UARTAO || \
>                 DEBUG_NETX_UART || \
> diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
> index 7f7446f6f806..1191b1458586 100644
> --- a/arch/arm/include/debug/8250.S
> +++ b/arch/arm/include/debug/8250.S
> @@ -9,6 +9,9 @@
>   */
>  #include <linux/serial_reg.h>
>
> +#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xe0000000

Any special reason for 0xe0000000 vs ...

> --- a/arch/arm/include/debug/efm32.S
> +++ b/arch/arm/include/debug/efm32.S
> @@ -6,6 +6,9 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> +#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xf0000000

0xf0000000?

> --- a/arch/arm/include/debug/pl01x.S
> +++ b/arch/arm/include/debug/pl01x.S
> @@ -10,6 +10,9 @@
>   * published by the Free Software Foundation.
>   *
>  */
> +#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xf0000000

Likewise.

Gr{oetje,eeting}s,

                        Geert

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

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

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Russell King - ARM Linux]

On Fri, Jan 29, 2016 at 12:07:21AM +0100, Arnd Bergmann wrote:
> This doesn't sound too hard. I've picked the defaults out of the
> git history in the patch below. The only tricky part was davinci,
> which has two different addresses and requires a little rework
> to avoid circular dependencies.

I think there's a much better way to solve this.

How about we have an architecture-defined way to provide all*config
with a set of settings to be used with Kconfig to define these
integer settings, rather than papering over the problem making up
random addresses (like you're doing for the debug stuff.)  Eg,
a default architecture-provided setting for KCONFIG_ALLCONFIG
that defines things such as the physical offset and the debug
addresses to be used for all*config targets?

Surely that's better than hacking around with the Kconfig files
trying to frig something into working, which can potentially confuse
people.

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

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Arnd Bergmann]

On Friday 29 January 2016 22:24:31 Geert Uytterhoeven wrote:
> > diff --git a/arch/arm/include/debug/8250.S b/arch/arm/include/debug/8250.S
> > index 7f7446f6f806..1191b1458586 100644
> > --- a/arch/arm/include/debug/8250.S
> > +++ b/arch/arm/include/debug/8250.S
> > @@ -9,6 +9,9 @@
> >   */
> >  #include <linux/serial_reg.h>
> >
> > +#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xe0000000
> 
> Any special reason for 0xe0000000 vs ...
> 
> > --- a/arch/arm/include/debug/efm32.S
> > +++ b/arch/arm/include/debug/efm32.S
> > @@ -6,6 +6,9 @@
> >   * it under the terms of the GNU General Public License version 2 as
> >   * published by the Free Software Foundation.
> >   */
> > +#if CONFIG_DEBUG_UART_PHYS == 0xdeadbeef || CONFIG_DEBUG_UART_VIRT < 0xf0000000
> 
> 0xf0000000?

We have one platform that uses a 8250 at address 0xe0010fe0, and one using
the netx UART at virtual address 0xe0000a00, everything else uses 0xf0000000
or higher.

The 0xf0000000 address seems like a better default cutoff, because that
is close to the VMALLOC_START value for systems with 768MB of RAM or more.
Picking a lower number can easily get you in trouble here.

Now that I think about it, I guess platforms that use values above
0xfee00000 can also easily get into trouble as that conflicts with the
PCI I/O space, the fixmap or other special areas documented in
Documentation/arm/memory.txt. We have a bunch of those:

        default 0xfee003f8 if DEBUG_FOOTBRIDGE_COM1
        default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
        default 0xfee82340 if ARCH_IOP13XX
        default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
        default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
        default 0xfef36000 if DEBUG_HIGHBANK_UART
        default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
        default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
        default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
        default 0xfefff700 if ARCH_IOP33X
        default 0xff003000 if DEBUG_U300_UART
        default 0xffd01000 if DEBUG_HIP01_UART

The HIP01 is the only one that looks actively dangerous here (clashes with
fixmap), the others are probably all fine but it would be nice to stay out
of that area completely.

	Arnd

[linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

[Russell King - ARM Linux]

On Fri, Jan 29, 2016 at 10:54:02PM +0100, Arnd Bergmann wrote:
> Now that I think about it, I guess platforms that use values above
> 0xfee00000 can also easily get into trouble as that conflicts with the
> PCI I/O space, the fixmap or other special areas documented in
> Documentation/arm/memory.txt. We have a bunch of those:
> 
>         default 0xfee003f8 if DEBUG_FOOTBRIDGE_COM1
>         default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
>         default 0xfee82340 if ARCH_IOP13XX
>         default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
>         default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
>         default 0xfef36000 if DEBUG_HIGHBANK_UART
>         default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
>         default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2
>         default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3
>         default 0xfefff700 if ARCH_IOP33X
>         default 0xff003000 if DEBUG_U300_UART
>         default 0xffd01000 if DEBUG_HIP01_UART
> 
> The HIP01 is the only one that looks actively dangerous here (clashes with
> fixmap), the others are probably all fine but it would be nice to stay out
> of that area completely.

That's wrong.  Given it's PCI bus architecture and it's IO space, at least
one of those above is perfectly valid.  0x3f8 into IO space might ring a
bell... if not the COM1 certainly should. :)

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