bcm53xx: initial support for the BCM5301/BCM470X SoC with ARM CPU

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

A bootlog can be found here:
http://pastebin.com/0MYYC7Fx

 MAINTAINERS                                  |    7 +++
 arch/arm/Kconfig                             |    2 +
 arch/arm/Kconfig.debug                       |    5 ++
 arch/arm/Makefile                            |    1 +
 arch/arm/boot/dts/Makefile                   |    1 +
 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
 arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
 arch/arm/include/debug/bcm53xx.S             |   19 +++++++
 arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
 arch/arm/mach-bcm53xx/Makefile               |    1 +
 arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
 11 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
 create mode 100644 arch/arm/include/debug/bcm53xx.S
 create mode 100644 arch/arm/mach-bcm53xx/Kconfig
 create mode 100644 arch/arm/mach-bcm53xx/Makefile
 create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c

MAINTAINERS +7 -0

index bf61e04..b72ba65 100644
@@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM53XX ARM ARCHICTURE
+M:	Hauke Mehrtens <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm53xx/
+F:	arch/arm/boot/dts/bcm53*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <[email protected]>
 M:	Michael Chan <[email protected]>

arch/arm/Kconfig +2 -0

index ba412e0..ee7362e 100644
@@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-bcm53xx/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"

arch/arm/Kconfig.debug +5 -0

index e401a76..74e32f6 100644
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X

@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART

arch/arm/Makefile +1 -0

index c0ac0f5..4a69cd5 100644
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
+machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci

arch/arm/boot/dts/Makefile +1 -0

index 641b3c9..480a68e 100644
@@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb
+dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
 
 targets += dtbs
 targets += $(dtb-y)

arch/arm/boot/dts/bcm5301x-netgear-r6250.dts new file +20 -0

new file mode 100644
index 0000000..d1b97aa
@@ -0,0 +1,20 @@
+/*
+ * Broadcom BCM47XX / BCM53XX arm platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/dts-v1/;
+
+/include/ "bcm5301x.dtsi"
+
+/ {
+	model = "Netgear R6250 V1 (BCM4708)";
+	compatible = "netgear,r6250v1", "brcm,bcm5301x";
+
+	memory {
+		reg = <0x00000000 0x08000000>;
+	};
+};

arch/arm/boot/dts/bcm5301x.dtsi new file +2 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.

arch/arm/boot/dts/bcm5301x.dtsi new file +23 -0

+	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk debug";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {

arch/arm/boot/dts/bcm5301x.dtsi new file +27 -0

+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <0 85 4>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <1 11 0xf04>;
+		clocks = <&clk_periph>;
+		#clock-cells = <0>;
+	};
+};

arch/arm/include/debug/bcm53xx.S new file +19 -0

new file mode 100644
index 0000000..98c836b
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>

arch/arm/mach-bcm53xx/Kconfig new file +10 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.

arch/arm/mach-bcm53xx/Makefile new file +1 -0

new file mode 100644
index 0000000..88da84d
@@ -0,0 +1 @@
+obj-y += bcm53xx.o

arch/arm/mach-bcm53xx/bcm53xx.c new file +68 -0

new file mode 100644
index 0000000..aa5bd397
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",
+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END

Signature · 1 line

1.7.10.4

Hi Hauke,

Quoted 145 lines · Hauke Mehrtens

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

A bootlog can be found here:
http://pastebin.com/0MYYC7Fx

 MAINTAINERS                                  |    7 +++
 arch/arm/Kconfig                             |    2 +
 arch/arm/Kconfig.debug                       |    5 ++
 arch/arm/Makefile                            |    1 +
 arch/arm/boot/dts/Makefile                   |    1 +
 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
 arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
 arch/arm/include/debug/bcm53xx.S             |   19 +++++++
 arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
 arch/arm/mach-bcm53xx/Makefile               |    1 +
 arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
 11 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
 create mode 100644 arch/arm/include/debug/bcm53xx.S
 create mode 100644 arch/arm/mach-bcm53xx/Kconfig
 create mode 100644 arch/arm/mach-bcm53xx/Makefile
 create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c

MAINTAINERS +7 -0

index bf61e04..b72ba65 100644
@@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM53XX ARM ARCHICTURE
+M:	Hauke Mehrtens <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm53xx/
+F:	arch/arm/boot/dts/bcm53*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <[email protected]>
 M:	Michael Chan <[email protected]>

arch/arm/Kconfig +2 -0

index ba412e0..ee7362e 100644
@@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-bcm53xx/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"

arch/arm/Kconfig.debug +5 -0

index e401a76..74e32f6 100644
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X

@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART

arch/arm/Makefile +1 -0

index c0ac0f5..4a69cd5 100644
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
+machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci

arch/arm/boot/dts/Makefile +1 -0

index 641b3c9..480a68e 100644
@@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb
+dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
 
 targets += dtbs
 targets += $(dtb-y)

arch/arm/boot/dts/bcm5301x-netgear-r6250.dts new file +20 -0

new file mode 100644
index 0000000..d1b97aa
@@ -0,0 +1,20 @@
+/*
+ * Broadcom BCM47XX / BCM53XX arm platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/dts-v1/;
+
+/include/ "bcm5301x.dtsi"
+
+/ {
+	model = "Netgear R6250 V1 (BCM4708)";
+	compatible = "netgear,r6250v1", "brcm,bcm5301x";
+
+	memory {
+		reg = <0x00000000 0x08000000>;
+	};
+};

arch/arm/boot/dts/bcm5301x.dtsi new file +2 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 10 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +10 -0

+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Arnd, any thoughts here?

Another thing is that this is missing a binding definition for this compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt for an example. You should split this patch out separately as the DT maintainers generally want to see bindings as a separate patch for easy independent review.

Last thing, compatible strings are not to have wildcards in them. See
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
and note the Warning at the bottom. Also see how bcm2835.txt and bcm11351.txt use a specific model.

Quoted 30 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +30 -0

+	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk debug";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <400000000>;
+		};
+	};
+
+	uart at 18000300 {

arch/arm/boot/dts/bcm5301x.dtsi line 45

Quoted 3 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +3 -0

+		compatible = "ns16550";
+		reg = <0x18000300 0x100>;
+		interrupts = <0 85 4>;

The DT files should be switched to use the C preprocessor like several other machines have already done (see bcm11351.dtsi, for example), you can use the existing GIC includes and have human-redable defines for the edge/level values here and throughout all interrupt properties.

Quoted 152 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +27 -0

+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <0 85 4>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <1 11 0xf04>;
+		clocks = <&clk_periph>;
+		#clock-cells = <0>;
+	};
+};

arch/arm/include/debug/bcm53xx.S new file +19 -0

new file mode 100644
index 0000000..98c836b
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>

arch/arm/mach-bcm53xx/Kconfig new file +10 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.

arch/arm/mach-bcm53xx/Makefile new file +1 -0

new file mode 100644
index 0000000..88da84d
@@ -0,0 +1 @@
+obj-y += bcm53xx.o

arch/arm/mach-bcm53xx/bcm53xx.c new file +68 -0

new file mode 100644
index 0000000..aa5bd397
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",
+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END

Signature · 1 line

1.7.10.4

Quoted 13 lines · Matt Porter

Hi Hauke,

Quoted 10 lines · Hauke Mehrtens

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

Quoted 29 lines

Quoted 8 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +2 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 10 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +10 -0

+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 1 line

Arnd, any thoughts here?

I have no problem with bcm or with brcm. This is a Broadcom Chip and their names are starting with bcm.

Quoted 5 lines

Another thing is that this is missing a binding definition for this compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt for an example. You should split this patch out separately as the DT maintainers generally want to see bindings as a separate patch for easy independent review.

Ok I will do that. This will then be merged by Linus in the 3.12 merge window into a working version or how does this work?

Currently I have based this patch on top of 3.11-rc1 on which tree should I base my changes?

Quoted 4 lines

Last thing, compatible strings are not to have wildcards in them. See
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
and note the Warning at the bottom. Also see how bcm2835.txt and bcm11351.txt use a specific model.

Ok will do that.

Quoted 31 lines

Quoted 31 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +30 -0

+	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk debug";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <400000000>;
+		};
+	};
+
+	uart at 18000300 {

Quoted 8 lines

arch/arm/boot/dts/bcm5301x.dtsi line 45

Quoted 3 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +3 -0

+		compatible = "ns16550";
+		reg = <0x18000300 0x100>;
+		interrupts = <0 85 4>;

The DT files should be switched to use the C preprocessor like several other machines have already done (see bcm11351.dtsi, for example), you can use the existing GIC includes and have human-redable defines for the edge/level values here and throughout all interrupt properties.

Ok I will read that and change it.

Quoted 152 lines

Quoted 152 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +27 -0

+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <0 85 4>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <1 11 0xf04>;
+		clocks = <&clk_periph>;
+		#clock-cells = <0>;
+	};
+};

arch/arm/include/debug/bcm53xx.S new file +19 -0

new file mode 100644
index 0000000..98c836b
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>

arch/arm/mach-bcm53xx/Kconfig new file +10 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.

arch/arm/mach-bcm53xx/Makefile new file +1 -0

new file mode 100644
index 0000000..88da84d
@@ -0,0 +1 @@
+obj-y += bcm53xx.o

arch/arm/mach-bcm53xx/bcm53xx.c new file +68 -0

new file mode 100644
index 0000000..aa5bd397
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",
+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END

Signature · 1 line

1.7.10.4

Quoted 14 lines · Hauke Mehrtens

Quoted 13 lines · Matt Porter

Hi Hauke,

Quoted 10 lines · Hauke Mehrtens

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

....

Quoted 40 lines

Quoted 29 lines

Quoted 8 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +2 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 10 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +10 -0

+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 1 line

Arnd, any thoughts here?

I have no problem with bcm or with brcm. This is a Broadcom Chip and their names are starting with bcm.

Quoted 5 lines

Another thing is that this is missing a binding definition for this compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt for an example. You should split this patch out separately as the DT maintainers generally want to see bindings as a separate patch for easy independent review.

Quoted 5 lines

Ok I will do that. This will then be merged by Linus in the 3.12 merge window into a working version or how does this work?

Currently I have based this patch on top of 3.11-rc1 on which tree should I base my changes?

Should I split out the *.dts files in arch/arm/boot/dts/ and the documentation for brcm,bcm4708 into an other patch?

Quoted 6 lines

Quoted 4 lines

Last thing, compatible strings are not to have wildcards in them. See
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
and note the Warning at the bottom. Also see how bcm2835.txt and bcm11351.txt use a specific model.

Ok will do that.

Do I understand this right that I should currently name it exactly like the SoC I know and when a new SoC pops up I should make it compatible to this SoC?

I would change this to:
compatible = "brcm,bcm4708";

If I find a BCM4709 SoC I will add this like to its dts file, assuming they are mostly the same?
compatible = "brcm,bcm4709", "brcm,bcm4708";

Quoted 169 lines · Matt Porter

Hi Hauke,

Quoted 145 lines · Hauke Mehrtens

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

A bootlog can be found here:
http://pastebin.com/0MYYC7Fx

 MAINTAINERS                                  |    7 +++
 arch/arm/Kconfig                             |    2 +
 arch/arm/Kconfig.debug                       |    5 ++
 arch/arm/Makefile                            |    1 +
 arch/arm/boot/dts/Makefile                   |    1 +
 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts |   20 +++++++
 arch/arm/boot/dts/bcm5301x.dtsi              |   72 ++++++++++++++++++++++++++
 arch/arm/include/debug/bcm53xx.S             |   19 +++++++
 arch/arm/mach-bcm53xx/Kconfig                |   10 ++++
 arch/arm/mach-bcm53xx/Makefile               |    1 +
 arch/arm/mach-bcm53xx/bcm53xx.c              |   68 ++++++++++++++++++++++++
 11 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm5301x-netgear-r6250.dts
 create mode 100644 arch/arm/boot/dts/bcm5301x.dtsi
 create mode 100644 arch/arm/include/debug/bcm53xx.S
 create mode 100644 arch/arm/mach-bcm53xx/Kconfig
 create mode 100644 arch/arm/mach-bcm53xx/Makefile
 create mode 100644 arch/arm/mach-bcm53xx/bcm53xx.c

MAINTAINERS +7 -0

index bf61e04..b72ba65 100644
@@ -1795,6 +1795,13 @@ F:	arch/arm/boot/dts/bcm2835*
 F:	arch/arm/configs/bcm2835_defconfig
 F:	drivers/*/*bcm2835*
 
+BROADCOM BCM53XX ARM ARCHICTURE
+M:	Hauke Mehrtens <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org
+S:	Maintained
+F:	arch/arm/mach-bcm53xx/
+F:	arch/arm/boot/dts/bcm53*
+
 BROADCOM TG3 GIGABIT ETHERNET DRIVER
 M:	Nithin Nayak Sujir <[email protected]>
 M:	Michael Chan <[email protected]>

arch/arm/Kconfig +2 -0

index ba412e0..ee7362e 100644
@@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-bcm53xx/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"

arch/arm/Kconfig.debug +5 -0

index e401a76..74e32f6 100644
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X

@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART

arch/arm/Makefile +1 -0

index c0ac0f5..4a69cd5 100644
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
+machine-$(CONFIG_ARCH_BCM53XX)		+= bcm53xx
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci

arch/arm/boot/dts/Makefile +1 -0

index 641b3c9..480a68e 100644
@@ -242,6 +242,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
 dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb
+dtb-$(CONFIG_ARCH_BCM53XX) += bcm5301x-netgear-r6250.dtb
 
 targets += dtbs
 targets += $(dtb-y)

arch/arm/boot/dts/bcm5301x-netgear-r6250.dts new file +20 -0

new file mode 100644
index 0000000..d1b97aa
@@ -0,0 +1,20 @@
+/*
+ * Broadcom BCM47XX / BCM53XX arm platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/dts-v1/;
+
+/include/ "bcm5301x.dtsi"
+
+/ {
+	model = "Netgear R6250 V1 (BCM4708)";
+	compatible = "netgear,r6250v1", "brcm,bcm5301x";
+
+	memory {
+		reg = <0x00000000 0x08000000>;
+	};
+};

arch/arm/boot/dts/bcm5301x.dtsi new file +2 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 10 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +10 -0

+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 1 line

Arnd, any thoughts here?

I have no problem with bcm or with brcm. This is a Broadcom Chip and their names are starting with bcm.

Quoted 6 lines

Another thing is that this is missing a binding definition for this compatible string. See Documentation/devicetree/bindings/arm/bcm2835.txt for an example. You should split this patch out separately as the DT maintainers generally want to see bindings as a separate patch for easy independent review.

Ok I will do that. This will then be merged by Linus in the 3.12 merge window into a working version or how does this work?

Currently I have based this patch on top of 3.11-rc1 on which tree should I base my changes?

Quoted 4 lines

Last thing, compatible strings are not to have wildcards in them. See
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
and note the Warning at the bottom. Also see how bcm2835.txt and bcm11351.txt use a specific model.

Ok will do that.

Quoted 30 lines

Quoted 30 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +30 -0

+	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk debug";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+		};
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk_periph: periph {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <400000000>;
+		};
+	};
+
+	uart at 18000300 {

Quoted 8 lines

arch/arm/boot/dts/bcm5301x.dtsi line 45

Quoted 3 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +3 -0

+		compatible = "ns16550";
+		reg = <0x18000300 0x100>;
+		interrupts = <0 85 4>;

The DT files should be switched to use the C preprocessor like several other machines have already done (see bcm11351.dtsi, for example), you can use the existing GIC includes and have human-redable defines for the edge/level values here and throughout all interrupt properties.

Ok I will read that and change it.

Quoted 152 lines

Quoted 152 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +27 -0

+		clock-frequency = <100000000>;
+	};
+
+	uart at 18000400 {
+		compatible = "ns16550";
+		reg = <0x18000400 0x100>;
+		interrupts = <0 85 4>;
+		clock-frequency = <100000000>;
+	};
+
+	gic: interrupt-controller at 19021000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x19021000 0x1000>,
+		      <0x19020100 0x100>;
+	};
+
+	timer at 19020200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0x19020200 0x100>;
+		interrupts = <1 11 0xf04>;
+		clocks = <&clk_periph>;
+		#clock-cells = <0>;
+	};
+};

arch/arm/include/debug/bcm53xx.S new file +19 -0

new file mode 100644
index 0000000..98c836b
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual
+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>

arch/arm/mach-bcm53xx/Kconfig new file +10 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"
+	select CPU_V7
+	select ARM_GIC
+	select HAVE_CLK
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_TIME
+	select ARM_GLOBAL_TIMER
+	help
+	  Support for Broadcom BCM47XX and BCM53XX SoCs with ARM CPU cores.

arch/arm/mach-bcm53xx/Makefile new file +1 -0

new file mode 100644
index 0000000..88da84d
@@ -0,0 +1 @@
+obj-y += bcm53xx.o

arch/arm/mach-bcm53xx/bcm53xx.c new file +68 -0

new file mode 100644
index 0000000..aa5bd397
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",
+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END

Signature · 1 line

1.7.10.4

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 1 line

arch/arm/boot/dts/bcm5301x.dtsi new file +1 -0

+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 1 line

arch/arm/boot/dts/bcm5301x.dtsi new file +1 -0

+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

(as of Linux 3.11-rc1)

So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 1 line

arch/arm/boot/dts/bcm5301x.dtsi new file +1 -0

+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

Quoted 15 lines · Florian Fainelli

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 1 line

arch/arm/boot/dts/bcm5301x.dtsi new file +1 -0

+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 3 lines

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

brcm is the stock ticker. As far as I can search, this is the convention for the vendor prefixes.

I'm theb not that surprised that it's common within broadcom ;)

Quoted 20 lines · Florian Fainelli

Quoted 18 lines

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

Quoted 1 line

+ compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

Quoted 2 lines

brcm is the stock ticker. As far as I can search, this is the convention for the vendor prefixes.

No, correlation does not equal causation. The fact that some vendor prefixes in DT match the stock symbol is by chance of 3-4 character name being the same...nothing more.

It's pretty easy to see that the "ti" vendor prefix has no relation at all to their TXN symbol so that blows that convention out of the water. Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

2013/7/23 Matt Porter <[email protected]>:

Quoted 24 lines · Domenico Andreoli

Quoted 22 lines · Florian Fainelli

Quoted 15 lines

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

Quoted 1 line

+ compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 3 lines

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

brcm is the stock ticker. As far as I can search, this is the convention for the vendor prefixes.

Quoted 3 lines

No, correlation does not equal causation. The fact that some vendor prefixes in DT match the stock symbol is by chance of 3-4 character name being the same...nothing more.

That was a bad argument as was later explained to me, I won't use that reason again.

Quoted 7 lines

It's pretty easy to see that the "ti" vendor prefix has no relation at all to their TXN symbol so that blows that convention out of the water. Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

2013/7/25 Domenico Andreoli <[email protected]>:

Quoted 10 lines · Florian Fainelli

Quoted 9 lines

2013/7/23 Matt Porter <[email protected]>:

Quoted 8 lines · Domenico Andreoli

Quoted 7 lines · Florian Fainelli

Quoted 6 lines

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 3 lines

Quoted 1 line

+ compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long

vacation. I see

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

the "brcm" vendor prefix as a real consistency problem. I noticed

on the

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

bcm281xx/kona family, we have been using "bcm" which is not

logged in

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx

support

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

came in. Ideally, the vendor prefix should change to "bcm" since

every

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

reference in the family names is BCM. However, if others want the

least

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

amount of churn in making this consistent, we might have to go

with

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

"brcm" across the board.

I would like to keep "brcm" here because that is what has been

defined as a

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

vendor prefix, and is used beyond the scope of the ARM Linux kernel

support

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

even within Broadcom. Maybe it was an oversight, or rather a

mistake to let

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

brcm is the stock ticker. As far as I can search, this is the

convention

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

for the vendor prefixes.

No, correlation does not equal causation. The fact that some vendor prefixes in DT match the stock symbol is by chance of 3-4 character

name

Quoted 24 lines

Quoted 4 lines

Quoted 1 line

being the same...nothing more.

That was a bad argument as was later explained to me, I won't use that reason again.

I cited the stock ticker only because IIRC it's the reason my initial proposal for bcm has been ditched in favour of brcm when bcm2835 was initially proposed.

Quoted 11 lines

Quoted 7 lines

It's pretty easy to see that the "ti" vendor prefix has no relation at all to their TXN symbol so that blows that convention out of the water. Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term.

Quoted 2 lines

So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better.

If we are to fix it in stone, once and for all, let's go for the full name which would avoid any kind of future confusion (this also seems to be the tendency with new vendor prefixes these days). That way we could make everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

Quoted 19 lines · Florian Fainelli

2013/7/25 Domenico Andreoli <[email protected]>:

Quoted 18 lines · Florian Fainelli

Quoted 8 lines

2013/7/23 Matt Porter <[email protected]>:

Quoted 7 lines · Domenico Andreoli

It's pretty easy to see that the "ti" vendor prefix has no relation at all to their TXN symbol so that blows that convention out of the water. Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

Quoted 4 lines

Quoted 1 line

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term.

So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better.

Quoted 4 lines

If we are to fix it in stone, once and for all, let's go for the full name which would avoid any kind of future confusion (this also seems to be the tendency with new vendor prefixes these days). That way we could make everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

I really like that.

-Matt

Quoted 24 lines · Matt Porter

Quoted 23 lines · Florian Fainelli

2013/7/25 Domenico Andreoli <[email protected]>:

Quoted 10 lines · Florian Fainelli

Quoted 9 lines

2013/7/23 Matt Porter <[email protected]>:

Quoted 8 lines · Domenico Andreoli

It's pretty easy to see that the "ti" vendor prefix has no relation at all to their TXN symbol so that blows that convention out of the water. Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

Quoted 8 lines

Quoted 3 lines

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term.

So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better.

If we are to fix it in stone, once and for all, let's go for the full name which would avoid any kind of future confusion (this also seems to be the tendency with new vendor prefixes these days). That way we could make everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

Quoted 4 lines

I really like that.

-Matt

broadcom works for me also.
thanks,
csd

Quoted 29 lines · Matt Porter

Quoted 28 lines · Florian Fainelli

2013/7/25 Domenico Andreoli <[email protected]>:

Quoted 12 lines · Florian Fainelli

Quoted 11 lines

2013/7/23 Matt Porter <[email protected]>:

Quoted 10 lines · Domenico Andreoli

It's pretty easy to see that the "ti" vendor prefix has no relation at
all to their TXN symbol so that blows that convention out of the water.
Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

Quoted 8 lines

Quoted 3 lines

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term.

So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better.

If we are to fix it in stone, once and for all, let's go for the full name
which would avoid any kind of future confusion (this also seems to be the
tendency with new vendor prefixes these days). That way we could make everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

Quoted 4 lines

I really like that.

-Matt

broadcom works for me also.
thanks,
csd

I'm CC'ing in the DT bindings maintainers in case they have any comment.

Quoted 34 lines · Christian Daudt

Quoted 33 lines · Matt Porter

Quoted 21 lines · Florian Fainelli

2013/7/25 Domenico Andreoli <[email protected]>:

Quoted 12 lines · Florian Fainelli

Quoted 11 lines

2013/7/23 Matt Porter <[email protected]>:

Quoted 10 lines · Domenico Andreoli

It's pretty easy to see that the "ti" vendor prefix has no relation at
all to their TXN symbol so that blows that convention out of the water.
Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

Quoted 8 lines

Quoted 3 lines

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term.

So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better.

Quoted 7 lines

If we are to fix it in stone, once and for all, let's go for the full name
which would avoid any kind of future confusion (this also seems to be the
tendency with new vendor prefixes these days). That way we could make everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

I really like that.

-Matt

Quoted 3 lines

broadcom works for me also.
thanks,
csd

I have no strong objection at this point in principle to renaming the vendor prefix used by the RPi support, although it will cause a bunch of pointless churn in the drivers to match the new compatible values, and in the pinctrl bindings for the custom properties there...

Quoted 37 lines · Stephen Warren

I'm CC'ing in the DT bindings maintainers in case they have any comment.

Quoted 34 lines · Christian Daudt

Quoted 33 lines · Matt Porter

Quoted 21 lines · Florian Fainelli

2013/7/25 Domenico Andreoli <[email protected]>:

Quoted 12 lines · Florian Fainelli

Quoted 11 lines

2013/7/23 Matt Porter <[email protected]>:

Quoted 10 lines · Domenico Andreoli

It's pretty easy to see that the "ti" vendor prefix has no relation at
all to their TXN symbol so that blows that convention out of the water.
Rather, the prefix is based on somebody's notion of how that vendor's part are normally referred to. In TI-land, it's TI AM335x or TI OMAP, never TXN OMAP. :)

For Broadcom, every part is BCMxxxxx so "bcm" is appropriate.

Quoted 8 lines

Quoted 3 lines

It was appropriate before being the "wrong" vendor prefix was allocated, now that "brcm" has been allocated we should stick to it because otherwise we will break existing and on-going DT work.

I still prefer bcm to brcm and I find enough evidence that bcm would be better in the long term.

So if Broadcomers can agree on bcm, now it's still the cheapest time to fix in that direction, later will not be better.

Quoted 7 lines

If we are to fix it in stone, once and for all, let's go for the full name
which would avoid any kind of future confusion (this also seems to be the
tendency with new vendor prefixes these days). That way we could make everyone happy with say: "broadcom,bcm2835". Would that work for everyone?

I really like that.

-Matt

Quoted 9 lines

Quoted 3 lines

broadcom works for me also.
thanks,
csd

I have no strong objection at this point in principle to renaming the vendor prefix used by the RPi support, although it will cause a bunch of pointless churn in the drivers to match the new compatible values, and in the pinctrl bindings for the custom properties there...

I'd be happy to have "broadcom" for all *new* bindings, as it's already in some bindings alongside "bcm" and "brcm", and is certainly the clearest of the available options.

However, given the strong feelings of many against breaking existing dts, we need to support the existing instances of "bcm" and "brcm" in

bindings. This doesn't preclude us also supporting "broadcom,$DEVICE" alongside the existing "bcm,$DEVICE" and/or "brcm,$DEVICE" for those that have a strong desire for consistency in future dts, unless there's a feeling that creates too much churn.

In the end, this is a purely cosmetic change, so we can live with it as-is at the cost of another entry in an FAQ somewhere.

On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:

Quoted 6 lines

I'd be happy to have "broadcom" for all *new* bindings, as it's already in some bindings alongside "bcm" and "brcm", and is certainly the clearest of the available options.

However, given the strong feelings of many against breaking existing dts, we need to support the existing instances of "bcm" and "brcm" in

Whoa, how would existing dts break? At this instant in time, all the bindings and dts are still in the kernel tree. A series to address this make all bindings, drivers, and dts consistent in one shot.

Quoted 1 line · Matt Porter

On Mon, Jul 29, 2013 at 10:30:00AM +0100, Mark Rutland wrote:

...

Quoted 9 lines

Quoted 6 lines

I'd be happy to have "broadcom" for all *new* bindings, as it's already in some bindings alongside "bcm" and "brcm", and is certainly the clearest of the available options.

However, given the strong feelings of many against breaking existing dts, we need to support the existing instances of "bcm" and "brcm" in

Whoa, how would existing dts break? At this instant in time, all the bindings and dts are still in the kernel tree. A series to address this make all bindings, drivers, and dts consistent in one shot.

While there are some *.dts files in the kernel source tree, that is no guarantee that:

a) People don't have custom *.dts files that are not in the kernel source tree, and hence can't be updated by Linux kernel patches.

b) People actually replace their *.dtb when updating their zImage. Since DT is explicitly supposed to be an ABI, everything is explicitly supposed to work if they do only update their zImage and not their *.dtb.

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 1 line

arch/arm/boot/dts/bcm5301x.dtsi new file +1 -0

+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

(as of Linux 3.11-rc1)

So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.

Quoted 15 lines

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

Quoted 1 line

+ compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 3 lines

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

[Update: I thought some more about this and investigated why Broadcom started
using "bcm" and changed my mind]

Can you provide a cite?

I can tell you that within Broadcom they have
been moving to get rid of it. That is why you see all this Broadcom originated code using "bcm" because it actually matches their part number prefix. As further evidence of the preference for "bcm", feel free to look through the entire public catalog of parts at
http://www.broadcom.com/products/ and note that they all have BCM as the part prefix...this carries over into all driver references to the parts as well including everything in the wireless world.

Quoted 9 lines

the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

Quoted 4 lines

(as of Linux 3.11-rc1)

So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.

I believe getting this "right" is far more important than the difference in churn of a mere 38 instances of use of brcm. "Right" is two things:
1) it needs to be consistent 2) it should be what makes sense.

If you want to add more confusion, because there is, drivers/staging/bcm which stands for Beceem has been later acquired by Broadcom, eventually turning this 3 letter word into something "consistent" from a Broadcom point of view. As far as I am concerned, I would just stick with the allocated vendor prefix and replace "bcm" with "brcm" because the allocated one is the authoritative one.

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

(as of Linux 3.11-rc1)

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.

I believe getting this "right" is far more important than the difference in churn of a mere 38 instances of use of brcm. "Right" is two things:
1) it needs to be consistent 2) it should be what makes sense.

I agree, which is the reason why I would stick with the vendor prefix and end the story there.

--
Florian

2013/7/23 Matt Porter <[email protected]>:

Quoted 16 lines · Florian Fainelli

Quoted 15 lines

Hello,

Le mardi 16 juillet 2013 11:14:36 Matt Porter a ?crit :

Quoted 11 lines

Quoted 1 line

+ compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Quoted 8 lines

Quoted 3 lines

I would like to keep "brcm" here because that is what has been defined as a vendor prefix, and is used beyond the scope of the ARM Linux kernel support even within Broadcom. Maybe it was an oversight, or rather a mistake to let

[Update: I thought some more about this and investigated why Broadcom started
using "bcm" and changed my mind]

Can you provide a cite?

Well, I can tell you that this is what my group is using for its vendor prefix in DT because this is the one that was allocated in vendor-prefixes.txt. This is also what the upstream BCM63xx DSL SoC is using even though that port is still WIP, so could be subject to changing.

Quoted 8 lines

I can tell you that within Broadcom they have
been moving to get rid of it. That is why you see all this Broadcom originated code using "bcm" because it actually matches their part number prefix. As further evidence of the preference for "bcm", feel free to look through the entire public catalog of parts at
http://www.broadcom.com/products/ and note that they all have BCM as the part prefix...this carries over into all driver references to the parts as well including everything in the wireless world.

If you want to add more confusion, because there is, drivers/staging/bcm which stands for Beceem has been later acquired by Broadcom, eventually turning this 3 letter word into something "consistent" from a Broadcom point of view. As far as I am concerned, I would just stick with the allocated vendor prefix and replace "bcm" with "brcm" because the allocated one is the authoritative one.

Quoted 14 lines

Quoted 13 lines

the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

(as of Linux 3.11-rc1)

So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.

Quoted 3 lines

I believe getting this "right" is far more important than the difference in churn of a mere 38 instances of use of brcm. "Right" is two things:
1) it needs to be consistent 2) it should be what makes sense.

I agree, which is the reason why I would stick with the vendor prefix and end the story there.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

the bcm281x/kona family support code be merged and use "bcm" there, without registering it. Besides, a simple rule of number here wins:

git grep "brcm," * | wc -l
63
git grep "bcm," * | wc -l
25

(as of Linux 3.11-rc1)

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

So consistency we should get the bcm281x/kona DT bindings to rename their vendor prefix as well.

I believe getting this "right" is far more important than the difference in churn of a mere 38 instances of use of brcm. "Right" is two things:
1) it needs to be consistent 2) it should be what makes sense.

I agree, which is the reason why I would stick with the vendor prefix and end the story there.

It doesn't end there. An update to all the in process stuff has to happen, plus the upstream stuff. So in both cases there are changes to be made both upstream and with work-in-progress. The only difference is that I was suggesting an update to correct the prefix in vendor-prefixes.txt.

However, if I'm the only one that cares enough to speak up for "bcm" I'll abandon that and submit the patch to adjust bcm281xx to be compliant with the current state of vendor-prefixes.txt. :)

Quoted 5 lines · On Wednesday, July 24, 2013, Hauke Mehrtens <[email protected]…

Quoted 4 lines · Domenico Andreoli

Quoted 3 lines · Hauke Mehrtens

Quoted 2 lines · Thomas Petazzoni

Review

Quoted 2 lines

(quoted diff) +0 -0

b/arch/arm/mach-bcm53xx/Kconfig

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines

Quoted 10 lines

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 7 lines

new file mode 100644
index 0000000..1e16e87

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+  bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

Quoted 1 line

Quoted 1 line

At the time of the BCM281XX merge we considered that such directories

would

Quoted 7 lines

Quoted 4 lines

mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

So you think I should move the file from arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?

yes

this looks more comsistent with the actual soc name:
arch/arm/mach-bcm/bcm530xx.c

but I find also acceptable the complete name of the "parent" soc (as I'm doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c

Quoted 13 lines

Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from the same family and they should be supported by the same code, so there is no reason to have a bcm47xx.c and a bcm53xx.c.

Quoted 9 lines

Quoted 7 lines

Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I do not know why there are two different names, probably marketing.

Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to not conflict with the MIPS part now. I know this could still cause problems and people will get confused, but I do not know a better name.

I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are

ARM11,

Quoted 8 lines

Quoted 3 lines

single-core SoCs.

Can we agree on a nice naming so that we actually clarify this silliness?

We could name it BCM5301X like it is named the the vendor source code. Currently there are the following SoCs of this family available:
BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, BCM4708 and BCM4709.

There is not a clear single pattern here, whatever choice won't be 100% right. Users will need to read some help to pick the right choice. BCM53010? But mine is not a strong opinion.

Quoted 2 lines

Internal there are two different
chip IDs available 53010 (BCM4707) and 53018 (BCM53018).

what do you mean with "internal" here?

Quoted 34 lines · Domenico Andreoli

Quoted 5 lines · On Wednesday, July 24, 2013, Hauke Mehrtens <[email protected]…

Quoted 4 lines · Domenico Andreoli

Quoted 3 lines · Hauke Mehrtens

Quoted 2 lines · Thomas Petazzoni

Review

Quoted 2 lines

(quoted diff) +0 -0

b/arch/arm/mach-bcm53xx/Kconfig

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines

Quoted 10 lines

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 7 lines

new file mode 100644
index 0000000..1e16e87

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+  bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

Quoted 1 line

Quoted 1 line

At the time of the BCM281XX merge we considered that such directories

would

Quoted 7 lines

Quoted 4 lines

mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

So you think I should move the file from arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?

yes

this looks more comsistent with the actual soc name:
arch/arm/mach-bcm/bcm530xx.c

Quoted 2 lines

but I find also acceptable the complete name of the "parent" soc (as I'm doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c

I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) have more in common than the vendor name, so I do not think it is a good idea to place them all at mach-bcm.

Quoted 31 lines

Quoted 14 lines

Most (All?) of the Router SoCs in the BCM53XX and BCM47XX line are from the same family and they should be supported by the same code, so there is no reason to have a bcm47xx.c and a bcm53xx.c.

Quoted 9 lines

Quoted 7 lines

Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I do not know why there are two different names, probably marketing.

Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to not conflict with the MIPS part now. I know this could still cause problems and people will get confused, but I do not know a better name.

I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are

ARM11,

Quoted 8 lines

Quoted 3 lines

single-core SoCs.

Can we agree on a nice naming so that we actually clarify this silliness?

We could name it BCM5301X like it is named the the vendor source code. Currently there are the following SoCs of this family available:
BCM53010, BCM53011, BCM53012, BCM53014, BCM53015, BCM53016, BCM53017, BCM53018, BCM4707, BCM4708 and BCM4709.

There is not a clear single pattern here, whatever choice won't be 100% right. Users will need to read some help to pick the right choice. BCM53010? But mine is not a strong opinion.

Quoted 2 lines

Internal there are two different
chip IDs available 53010 (BCM4707) and 53018 (BCM53018).

Quoted 1 line

what do you mean with "internal" here?

There is some register in the chip where the chipid is stored, according to the vendor code these two values are currently possible. This was changed for every generation with the MIPS SoCs, while one generation had some SoCs.

Hauke

Quoted 35 lines · Hauke Mehrtens

Quoted 34 lines · Domenico Andreoli

Quoted 5 lines · On Wednesday, July 24, 2013, Hauke Mehrtens <[email protected]…

Quoted 4 lines · Domenico Andreoli

Quoted 3 lines · Hauke Mehrtens

Quoted 2 lines · Thomas Petazzoni

Review

Quoted 2 lines

(quoted diff) +0 -0

b/arch/arm/mach-bcm53xx/Kconfig

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines

Quoted 10 lines

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 7 lines

new file mode 100644
index 0000000..1e16e87

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+  bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

Quoted 1 line

Quoted 1 line

At the time of the BCM281XX merge we considered that such directories

would

Quoted 7 lines

Quoted 4 lines

mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

So you think I should move the file from arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?

yes

this looks more comsistent with the actual soc name:
arch/arm/mach-bcm/bcm530xx.c

Quoted 6 lines

Quoted 2 lines

but I find also acceptable the complete name of the "parent" soc (as I'm doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c

I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) have more in common than the vendor name, so I do not think it is a good idea to place them all at mach-bcm.

In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever two or more SoCs share can hopefully modelled in a driver and as such would go in the drivers/ subtree. What's left is really SoC specific and, again hopefully, very minimal.

There should not be any SoC so weird to require a whole subdirectory full of that SoC specific stuff. So grouping everything by vendor name looks quite appealing to me.

Sharing the same subdir requires people working in it to talk and find agreements some more than the sparsely populated subdir did (because there is not a single maintainer who owns it). I think this is a big advantage Broadcomers can start with right now.

Quoted 41 lines · Domenico Andreoli

Quoted 27 lines · Hauke Mehrtens

Quoted 26 lines · Domenico Andreoli

Quoted 4 lines · On Wednesday, July 24, 2013, Hauke Mehrtens <[email protected]…

Quoted 3 lines · Domenico Andreoli

Quoted 2 lines · Hauke Mehrtens

Quoted 1 line · Thomas Petazzoni

Review

Quoted 1 line

(quoted diff) +0 -0

b/arch/arm/mach-bcm53xx/Kconfig

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 9 lines

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 7 lines

new file mode 100644
index 0000000..1e16e87

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+  bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

At the time of the BCM281XX merge we considered that such directories

would

Quoted 6 lines

Quoted 4 lines

mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

So you think I should move the file from arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?

yes

Quoted 8 lines

Quoted 5 lines

this looks more comsistent with the actual soc name:
arch/arm/mach-bcm/bcm530xx.c

but I find also acceptable the complete name of the "parent" soc (as I'm doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c

I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) have more in common than the vendor name, so I do not think it is a good idea to place them all at mach-bcm.

In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever two or more SoCs share can hopefully modelled in a driver and as such would go in the drivers/ subtree. What's left is really SoC specific and, again hopefully, very minimal.

Quoted 8 lines

There should not be any SoC so weird to require a whole subdirectory full of that SoC specific stuff. So grouping everything by vendor name looks quite appealing to me.

Sharing the same subdir requires people working in it to talk and find agreements some more than the sparsely populated subdir did (because there is not a single maintainer who owns it). I think this is a big advantage Broadcomers can start with right now.

I want to be able to build the BCM5301X SoC without building the current CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ? My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom submenu, but not build any code. Then the list of Broadcom SoCs is opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.

Quoted 50 lines · Hauke Mehrtens

Quoted 41 lines · Domenico Andreoli

Quoted 27 lines · Hauke Mehrtens

Quoted 26 lines · Domenico Andreoli

Quoted 4 lines · On Wednesday, July 24, 2013, Hauke Mehrtens <[email protected]…

Quoted 3 lines · Domenico Andreoli

Quoted 2 lines · Hauke Mehrtens

Quoted 1 line · Thomas Petazzoni

Review

Quoted 1 line

(quoted diff) +0 -0

b/arch/arm/mach-bcm53xx/Kconfig

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 9 lines

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 7 lines

new file mode 100644
index 0000000..1e16e87

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+  bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

At the time of the BCM281XX merge we considered that such directories

would

Quoted 6 lines

Quoted 4 lines

mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

So you think I should move the file from arch/arm/mach-bcm53xx/bcm53xx.c to arch/arm/mach-bcm/bcm53xx.c ?

yes

Quoted 8 lines

Quoted 5 lines

this looks more comsistent with the actual soc name:
arch/arm/mach-bcm/bcm530xx.c

but I find also acceptable the complete name of the "parent" soc (as I'm doing with the bcm4760), so: arch/arm/mach-bcm/bcm53010.c

I do not think these Broadcom ARM SoCs (bcm4760, BCM5301X, bcm11351) have more in common than the vendor name, so I do not think it is a good idea to place them all at mach-bcm.

In an ideal DT-only world (as basically is for Broadcom ARM SoCs), whatever two or more SoCs share can hopefully modelled in a driver and as such would go in the drivers/ subtree. What's left is really SoC specific and, again hopefully, very minimal.

Quoted 8 lines

There should not be any SoC so weird to require a whole subdirectory full of that SoC specific stuff. So grouping everything by vendor name looks quite appealing to me.

Sharing the same subdir requires people working in it to talk and find agreements some more than the sparsely populated subdir did (because there is not a single maintainer who owns it). I think this is a big advantage Broadcomers can start with right now.

Quoted 7 lines

I want to be able to build the BCM5301X SoC without building the current CONFIG_ARCH_BCM, so what name do you suggest for board_bcm.o ? My plan would be to make CONFIG_ARCH_BCM just activate the Broadcom submenu, but not build any code. Then the list of Broadcom SoCs is opened like CONFIG_ARCH_BCM5301X and the "old" CONFIG_ARCH_BCM.

CONFIG_ARCH_BCM wasn't the best name, but it is there now. We intend to upstream the (mobile-team) ARM SoCs going forward, and have them be multiplatform and all buildable into a single zImage with the ARCH_BCM config option. Which is why this option does not have a chip name on it.
Take ARCH_BCM == Broadcom Mobile team SoCs (I think that's what the help on it says).

Quoted 8 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +2 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.

arch/arm/boot/dts/bcm5301x.dtsi line 12

Quoted 10 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +10 -0

+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "brcm,bcm5301x";

Ok, this was nagging at me before I went on my very long vacation. I see the "brcm" vendor prefix as a real consistency problem. I noticed on the bcm281xx/kona family, we have been using "bcm" which is not logged in vendor-prefixes.txt as a legitimate prefix. I see that bcm2835 had already established use of "brcm" before any of the bcm281xx support came in. Ideally, the vendor prefix should change to "bcm" since every reference in the family names is BCM. However, if others want the least amount of churn in making this consistent, we might have to go with "brcm" across the board.

Arnd, any thoughts here?

Last thing, compatible strings are not to have wildcards in them. See
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
and note the Warning at the bottom. Also see how bcm2835.txt and bcm11351.txt use a specific model.

arch/arm/boot/dts/bcm5301x.dtsi new file +3 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *

arch/arm/mach-bcm53xx/Kconfig new file +16 -0

+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)

Dear Hauke Mehrtens,

arch/arm/boot/dts/bcm5301x-netgear-r6250.dts line 15

Quoted 5 lines · Hauke Mehrtens

arch/arm/boot/dts/bcm5301x-netgear-r6250.dts new file +5 -0

+/include/ "bcm5301x.dtsi"
+
+/ {
+	model = "Netgear R6250 V1 (BCM4708)";
+	compatible = "netgear,r6250v1", "brcm,bcm5301x";

I don't think using "brcm,bcm5301x" has a compatible string is very appropriate. It should really reflect which particular SoC this board is using.

Quoted 16 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +9 -0

new file mode 100644
index 0000000..638350d
@@ -0,0 +1,72 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+/include/ "skeleton.dtsi"

arch/arm/boot/dts/bcm5301x.dtsi line 13

Quoted 4 lines

arch/arm/boot/dts/bcm5301x.dtsi new file +4 -0

+
+/ {
+	compatible = "brcm,bcm5301x";
+	model = "BCM5301X/BCM4707/BCM4708/BCM4709 SoC";

Same here. Most likely, there will be difference between those SoCs, so a compatible string of bcm5301x doesn't seem right, and also the model that says this will handle all those platforms.

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 9 lines

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

arch/arm/mach-bcm53xx/Kconfig line 8

Quoted 7 lines

arch/arm/mach-bcm53xx/Kconfig new file +6 -0

+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE

CFE ?

Quoted 22 lines

arch/arm/mach-bcm53xx/Kconfig new file +22 -0

+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)

arch/arm/mach-bcm53xx/Kconfig

Quoted 4 lines

arch/arm/mach-bcm53xx/Kconfig new file +4 -0

+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}

That's a nitpick, but I personally tend to like when callbacks are ordered as they are called, i.e ->map_io() first, and then ->init_time().

arch/arm/mach-bcm53xx/Kconfig

Quoted 4 lines

arch/arm/mach-bcm53xx/Kconfig new file +4 -0

+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}

Not needed, this is the default. When ->init_machine() is NULL, the ARM core already calls automatically of_platform_populate().

arch/arm/mach-bcm53xx/Kconfig

Quoted 5 lines

arch/arm/mach-bcm53xx/Kconfig new file +5 -0

+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",
+	NULL,

Don't list the boards here, only the SoCs. Otherwise, this place is going to become a nightmare of conflicts.

arch/arm/mach-bcm53xx/Kconfig

Quoted 7 lines

arch/arm/mach-bcm53xx/Kconfig new file +7 -0

+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END

You also probably want to add this new platform to the multi_v7_defconfig.

Best regards,

Thomas

Quoted 12 lines · Thomas Petazzoni

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 9 lines

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I do not know why there are two different names, probably marketing.

Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to not conflict with the MIPS part now. I know this could still cause problems and people will get confused, but I do not know a better name.

Quoted 13 lines · Hauke Mehrtens

Quoted 12 lines · Thomas Petazzoni

arch/arm/mach-bcm53xx/Kconfig line 2

Quoted 9 lines

arch/arm/mach-bcm53xx/Kconfig new file +2 -0

new file mode 100644
index 0000000..1e16e87
@@ -0,0 +1,10 @@
+config ARCH_BCM53XX
+	bool "Broadcom BCM47XX / BCM53XX ARM SoC"

So the directory is named mach-bcm53xx, but you also handle BCM47xx SoCs. This doesn't sound really easy to follow.

At the time of the BCM281XX merge we considered that such directories would mostly contain board files only, being these new entries DT based. Hence the choice of mach-bcm to collect all of them.

I think you should then put this stuff there.

Quoted 7 lines

Yes the BCM53XX and BCM47XX SoCs are technically from the same line. I do not know why there are two different names, probably marketing.

Earlier versions of these SoC lines (also BCM47XX and BCM53XX) used a MIPS core and they are supported by arch/mips/bcm47xx/. I use BCM53XX to not conflict with the MIPS part now. I know this could still cause problems and people will get confused, but I do not know a better name.

I'll throw also BCM476x (bcm4760 and bcm4761) on the table. These are ARM11, single-core SoCs.

Can we agree on a nice naming so that we actually clarify this silliness?

Dear Hauke Mehrtens,

arch/arm/mach-bcm53xx/bcm53xx.c line 23

Quoted 6 lines · Hauke Mehrtens

arch/arm/mach-bcm53xx/bcm53xx.c new file +6 -0

+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE

CFE ?

Quoted 22 lines

arch/arm/mach-bcm53xx/bcm53xx.c new file +22 -0

+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)

arch/arm/mach-bcm53xx/bcm53xx.c line 49

Quoted 4 lines

arch/arm/mach-bcm53xx/bcm53xx.c new file +4 -0

+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}

That's a nitpick, but I personally tend to like when callbacks are ordered as they are called, i.e ->map_io() first, and then ->init_time().

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

arch/arm/Kconfig.debug +5 -0

index e401a76..74e32f6 100644
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X

@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART

arch/arm/include/debug/bcm53xx.S new file +9 -0

new file mode 100644
index 0000000..98c836b
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300

arch/arm/mach-bcm53xx/bcm53xx.c new file +58 -0

new file mode 100644
index 0000000..aa5bd397
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",

Hi Hauke,

Quoted 10 lines · Hauke Mehrtens

This patch adds support for the BCM5301/BCM470X SoCs with an ARM CPU. Currently just booting to a shell is working and nothing else, no Ethernet, wifi, flash, ...

This SoC uses a Dual core CPU, but this is currently not implemented. More information about this SoC can be found here:
http://www.anandtech.com/show/5925/broadcom-announces-bcm4708x-and-bcm5301x-socs-for-80211ac-routers

Signed-off-by Hauke Mehrtens <[email protected]>

---

...

Quoted 23 lines

arch/arm/Kconfig.debug +5 -0

index e401a76..74e32f6 100644
@@ -93,6 +93,10 @@ choice
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835
 
+	config DEBUG_BCM53XX
+		bool "Kernel low-level debugging on BCM53XX UART1"
+		depends on ARCH_BCM53XX
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X

@@ -762,6 +766,7 @@ endchoice
 config DEBUG_LL_INCLUDE
 	string
 	default "debug/bcm2835.S" if DEBUG_BCM2835
+	default "debug/bcm53xx.S" if DEBUG_BCM53XX
 	default "debug/cns3xxx.S" if DEBUG_CNS3XXX
 	default "debug/exynos.S" if DEBUG_EXYNOS_UART
 	default "debug/highbank.S" if DEBUG_HIGHBANK_UART

...

Quoted 21 lines

arch/arm/include/debug/bcm53xx.S new file +15 -0

new file mode 100644
index 0000000..98c836b
@@ -0,0 +1,19 @@
+/*
+ * Macros used for EARLY_PRINTK, in low-level UART debug console
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#define BCM53XX_UART1_PHYS	0x18000300
+#define BCM53XX_UART1_VIRT	0xf1000300
+#define BCM53XX_UART1_SH	0
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =BCM53XX_UART1_PHYS 	@ MMU off, Physical
+	ldr	\rv, =BCM53XX_UART1_VIRT 	@ MMU on, Virtual

arch/arm/include/debug/bcm53xx.S line 19

Quoted 4 lines

arch/arm/include/debug/bcm53xx.S new file +4 -0

+	.endm
+
+#define UART_SHIFT	BCM53XX_UART1_SH
+#include <asm/hardware/debug-8250.S>

don't know if it's worth to add this debug uart support here. there is a series from Russel to consolidate 8250 and pl01x debug uarts. maybe you want to delay this.

Quoted 65 lines

arch/arm/mach-bcm53xx/bcm53xx.c new file +58 -0

new file mode 100644
index 0000000..aa5bd397
@@ -0,0 +1,68 @@
+/*
+ * Broadcom BCM47XX / BCM53XX ARM platform code.
+ *
+ * Copyright 2013 Hauke Mehrtens <[email protected]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/irqchip.h>
+#include <linux/clocksource.h>
+#include <linux/clk-provider.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/signal.h>
+
+static int bcm53xx_abort_handler(unsigned long addr, unsigned int fsr,
+				 struct pt_regs *regs)
+{
+	/*
+	 * These happen for no good reason
+	 * possibly left over from CFE
+	 */
+	pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x ignored.\n",
+		addr, fsr);
+
+	/* Returning non-zero causes fault display and panic */
+	return 0;
+}
+
+static void bcm53xx_aborts_enable(void)
+{
+	/* Install our hook */
+	hook_fault_code(16 + 6, bcm53xx_abort_handler, SIGBUS, 0,
+			"imprecise external abort");
+}
+
+static void __init bcm53xx_timer_init(void)
+{
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+void __init bcm53xx_map_io(void)
+{
+	debug_ll_io_init();
+	bcm53xx_aborts_enable();
+}
+
+static void __init bcm53xx_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char const *bcm53xx_dt_compat[] = {
+	"brcm,bcm5301x",
+	"netgear,r6250v1",

arch/arm/mach-bcm53xx/bcm53xx.c line 68

Quoted 10 lines

arch/arm/mach-bcm53xx/bcm53xx.c new file +10 -0

+	NULL,
+};
+
+DT_MACHINE_START(BCM53XX, "BCM53XX")
+	.init_machine = bcm53xx_dt_init,
+	.map_io = bcm53xx_map_io,
+	.init_irq = irqchip_init,
+	.init_time = bcm53xx_timer_init,
+	.dt_compat = bcm53xx_dt_compat,
+MACHINE_END

the trend is to consolidate machine descriptors.

so .init_irq can go, irqchip_init is picked anyway if .init_irq is NULL.

also .init_time could be dropped, it can be specified using CLOCKSOURCE_OF_DECLARE(), but I see bcm53xx_timer_init is already quite minimal here and I'm struggling to see the big picture here. So mine is actually a question for others... :)