Convert Netgear WNR854T to devicetree

This is an attempt to resurrect the mainline WNR854T support (I had no
luck getting a non-DT kernel to boot). First 2 patches are trivial,
the next 3 add DT bindings for the SoC, then the old board file is
swapped out for DT. The final 3 patches configure the PHY leds as
Netgear intended.

There's one major flaw; unicast traffic is never received on any port.
Broadcast traffic is received however, and on the correct port. Thus
an external machine can make an ARP request and get a response, for
example. With a manually-entered ARP entry, the router can send pings
out to a remote machine which responds, and the response is lost in the
DSA switch. "ethtool -S" reports pings received on "in_unicast" but
nothing makes it through the switch. This thread[0] seems very similar.
I've run out of ideas here and can't find any switch datasheets to give
me pointers so any suggestions greatly appreciated.

I've not tried to move the PCI support into DT yet. Are there other
branches that tackle this already?

Patch 8 is the least-intrusive patch I could think of to find the PHY
node, but I'm not sure it's the best approach. I tried to get
dsa_slave_phy_connect() to wire up the OF node correctly[1], but doing
this properly would require changes to the mdiobus api, any exposed
methods register all nodes in an MDIO bus node, which doesn't exist in
this case.

Applied against v4.6 mainline, .config:
http://jamie.lentin.co.uk/devices/netgear-wnr854t/wnr854t-support-v0a/kernel-config.txt
Log output:
http://jamie.lentin.co.uk/devices/netgear-wnr854t/wnr854t-support-v0a/u-boot.dmesg.txt

The patchset is also available here:
https://github.com/lentinj/linux/commits/wnr854t-support-v0a

To use the supplied PCI Wifi card see the following patch:
https://github.com/lentinj/linux/commit/d6b7b4695b7dcbf36d0663aea9cb4ecd65a1ada8
...but this is probably a matter for another thread.

Cheers,

38 more lines

This is a router based on the mv88f5181 chipset.

http://www.netgear.com/support/product/WNR854T.aspx
http://wiki.openwrt.org/toh/netgear/wnr854t

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts      | 200 +++++++++++++++++++++
 arch/arm/mach-orion5x/Kconfig                      |   6 +
 arch/arm/mach-orion5x/Makefile                     |   1 +
 arch/arm/mach-orion5x/board-wnr854t.c              |  78 ++++++++
 6 files changed, 287 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
 create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
index ff3c120..748a8f2 100644
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

@@ -22,3 +22,4 @@ board. Currently known boards are:
 "lacie,d2-network"
 "marvell,rd-88f5182-nas"
 "maxtor,shared-storage-2"
+"netgear,wnr854t"

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..63b9202 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile

@@ -535,6 +535,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
 	orion5x-linkstation-lswtgl.dtb \
 	orion5x-lswsgl.dtb \
 	orion5x-maxtor-shared-storage-2.dtb \
+	orion5x-netgear-wnr854t.dtb \
 	orion5x-rd88f5182-nas.dtb
 dtb-$(CONFIG_ARCH_PRIMA2) += \
 	prima2-evb.dtb

diff --git a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
new file mode 100644
index 0000000..a8e89d8
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts

@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2014 Jamie Lentin <jm@lentin.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "orion5x-mv88f5181.dtsi"
+
+/ {
+	model = "Netgear WNR854-t";
+	compatible = "netgear,wnr854t", "marvell,orion5x-88f5181",
+			"marvell,orion5x";
+
+	memory {
+		reg = <0x00000000 0x2000000>; /* 32 MB */
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+		linux,stdout-path = &uart0;
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
+			<MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
+			<MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x800000>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&pmx_reset_switch>;
+		pinctrl-names = "default";
+
+		reset {
+			label = "Reset Button";
+			linux,code = <KEY_RESTART>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_power_led &pmx_power_led_blink &pmx_wan_led>;
+		pinctrl-names = "default";
+
+		led@0 {
+			label = "power:green";
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+
+		led@1 {
+			label = "power:blink";
+			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+
+		led@2 {
+			label = "wan:green";
+			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	dsa@0 {
+		compatible = "marvell,dsa";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dsa,ethernet = <&ethport>;
+		dsa,mii-bus = <&mdio>;
+
+		switch@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0 0>;	/* MDIO address 0, switch 0 in tree */
+
+			port@0 {
+				reg = <0>;
+				label = "lan3";
+			};
+
+			port@1 {
+				reg = <1>;
+				label = "lan4";
+			};
+
+			port@2 {
+				reg = <2>;
+				label = "wan";
+			};
+
+			port@3 {
+				reg = <3>;
+				label = "cpu";
+			};
+
+			port@5 {
+				reg = <5>;
+				label = "lan1";
+			};
+
+			port@7 {
+				reg = <7>;
+				label = "lan2";
+			};
+		};
+	};
+};
+
+&devbus_bootcs {
+	status = "okay";
+
+	devbus,keep-config;
+
+	flash@0 {
+		compatible = "cfi-flash";
+		reg = <0 0x800000>;
+		bank-width = <1>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		partition@0 {
+			label = "kernel";
+			reg = <0x0 0x100000>;
+		};
+
+		partition@100000 {
+			label = "rootfs";
+			reg = <0x100000 0x660000>;
+		};
+
+		partition@760000 {
+			label = "uboot_env";
+			reg = <0x760000 0x20000>;
+		};
+
+		partition@780000 {
+			label = "uboot";
+			reg = <0x780000 0x80000>;
+			read-only;
+		};
+	};
+};
+
+&mdio {
+	status = "okay";
+};
+
+&eth {
+	status = "okay";
+	ethernet-port@0 {
+		speed = <1000>;
+		duplex = <1>;
+	};
+};
+
+&pinctrl {
+	pinctrl-0 = <&pmx_pci_gpios &pmx_ge>;
+	pinctrl-names = "default";
+
+	pmx_power_led: pmx-power-led {
+		marvell,pins = "mpp0";
+		marvell,function = "gpio";
+	};
+
+	pmx_reset_switch: pmx-reset-switch {
+		marvell,pins = "mpp1";
+		marvell,function = "gpio";
+	};
+
+	pmx_power_led_blink: pmx-power-led-blink {
+		marvell,pins = "mpp2";
+		marvell,function = "gpio";
+	};
+
+	pmx_wan_led: pmx-wan-led {
+		marvell,pins = "mpp3";
+		marvell,function = "gpio";
+	};
+
+	pmx_pci_gpios: pmx-pci-gpios {
+		marvell,pins = "mpp4";
+		marvell,function = "gpio";
+	};
+
+	pmx_ge: pmx-ge {
+		marvell,pins = "mpp9", "mpp12",	"mpp13", "mpp14", "mpp15",
+				"mpp16", "mpp17", "mpp18", "mpp19";
+		marvell,function = "ge";
+	};
+};
+
+&uart0 {
+	/* Pin 1: Tx, Pin 7: Rx, Pin 8: Gnd */
+	status = "okay";
+};

diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index a2af158..1fdb95d 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig

@@ -151,6 +151,12 @@ config MACH_MSS2_DT
 	  Say 'Y' here if you want your kernel to support the
 	  Maxtor Shared Storage II platform.
 
+config MACH_WNR854T_DT
+	bool "Netgear WNR854T (Flattened Device Tree)"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Netgear WNR854T platform.
+
 config MACH_WNR854T
 	bool "Netgear WNR854T"
 	help

diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
index 4b2502b..9dff2d3 100644
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion5x/Makefile

@@ -24,3 +24,4 @@ obj-$(CONFIG_ARCH_ORION5X_DT)		+= board-dt.o
 obj-$(CONFIG_MACH_D2NET_DT)	+= board-d2net.o
 obj-$(CONFIG_MACH_MSS2_DT)	+= board-mss2.o
 obj-$(CONFIG_MACH_RD88F5182_DT)	+= board-rd88f5182.o
+obj-$(CONFIG_MACH_WNR854T_DT)	+= board-wnr854t.o

diff --git a/arch/arm/mach-orion5x/board-wnr854t.c b/arch/arm/mach-orion5x/board-wnr854t.c
new file mode 100644
index 0000000..c506e33
--- /dev/null
+++ b/arch/arm/mach-orion5x/board-wnr854t.c

@@ -0,0 +1,78 @@
+/*
+ * Netgear WNR854T PCI setup
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/gpio.h>
+#include <linux/platform_device.h>
+#include <linux/pci.h>
+#include <asm/mach/pci.h>
+#include "common.h"
+#include "orion5x.h"
+
+#define WNR854T_PCI_SLOT0_OFFS	7
+#define WNR854T_PCI_SLOT0_IRQ_PIN	4
+
+static void __init wnr854t_pci_preinit(void)
+{
+	int pin;
+
+	/*
+	 * Configure PCI GPIO IRQ pins
+	 */
+	pin = WNR854T_PCI_SLOT0_IRQ_PIN;
+	if (gpio_request(pin, "PCI Int") == 0) {
+		if (gpio_direction_input(pin) == 0) {
+			irq_set_irq_type(gpio_to_irq(pin), IRQ_TYPE_LEVEL_LOW);
+		} else {
+			pr_err("wnr854t_pci_preinit failed to set_irq_type pin %d\n",
+				pin);
+			gpio_free(pin);
+		}
+	} else {
+		pr_err("wnr854t_pci_preinit failed to request gpio %d\n", pin);
+	}
+}
+
+static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
+	u8 pin)
+{
+	int irq;
+
+	/*
+	 * Check for devices with hard-wired IRQs.
+	 */
+	irq = orion5x_pci_map_irq(dev, slot, pin);
+	if (irq != -1)
+		return irq;
+
+	/*
+	 * PCI IRQs are connected via GPIOs
+	 */
+	switch (slot - WNR854T_PCI_SLOT0_OFFS) {
+	case 0:
+		return gpio_to_irq(WNR854T_PCI_SLOT0_IRQ_PIN);
+	default:
+		return -1;
+	}
+}
+
+static struct hw_pci wnr854t_pci __initdata = {
+	.nr_controllers	= 2,
+	.preinit	= wnr854t_pci_preinit,
+	.setup		= orion5x_pci_sys_setup,
+	.scan		= orion5x_pci_sys_scan_bus,
+	.map_irq	= wnr854t_pci_map_irq,
+};
+
+static int __init wnr854t_pci_init(void)
+{
+	if (of_machine_is_compatible("netgear,wnr854t"))
+		pci_common_init(&wnr854t_pci);
+
+	return 0;
+}
+/* NB: Use late_initcall so we can gpio_request() without being deferred */
+late_initcall(wnr854t_pci_init);

-- 
2.8.1

orion-wdt refuses to start without these properties defined, so lift
definitions out of kirkwood/dove.dtsi

Signed-off-by: Jamie Lentin <redacted>
---
 arch/arm/boot/dts/orion5x.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index e1b6d2a..fbccfbb 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi

@@ -144,9 +144,10 @@
 
 			wdt: wdt@20300 {
 				compatible = "marvell,orion-wdt";
-				reg = <0x20300 0x28>;
+				reg = <0x20300 0x28>, <0x20108 0x4>;
 				interrupt-parent = <&bridge_intc>;
 				interrupts = <3>;
+				clocks = <&core_clk 0>;
 				status = "okay";
 			};
 

-- 
2.8.1

Referring to values in the u-boot port, add support for the mv88f5181

Signed-off-by: Jamie Lentin <redacted>
---
 .../devicetree/bindings/clock/mvebu-core-clock.txt |  1 +
 drivers/clk/mvebu/orion.c                          | 70 ++++++++++++++++++++++
 2 files changed, 71 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
index 670c2af..eb985a6 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt

@@ -52,6 +52,7 @@ Required properties:
 	"marvell,dove-core-clock" - for Dove SoC core clocks
 	"marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
 	"marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC
+	"marvell,mv88f5181-core-clock" - for Orion MV88F5181 SoC
 	"marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC
 	"marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC
 	"marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC

diff --git a/drivers/clk/mvebu/orion.c b/drivers/clk/mvebu/orion.c
index fd12956..a6e5bee 100644
--- a/drivers/clk/mvebu/orion.c
+++ b/drivers/clk/mvebu/orion.c

@@ -21,6 +21,76 @@ static const struct coreclk_ratio orion_coreclk_ratios[] __initconst = {
 };
 
 /*
+ * Orion 5181
+ */
+
+#define SAR_MV88F5181_TCLK_FREQ      8
+#define SAR_MV88F5181_TCLK_FREQ_MASK 0x3
+
+static u32 __init mv88f5181_get_tclk_freq(void __iomem *sar)
+{
+	u32 opt = (readl(sar) >> SAR_MV88F5181_TCLK_FREQ) &
+		SAR_MV88F5181_TCLK_FREQ_MASK;
+	if (opt == 0)
+		return 133333333;
+	else if (opt == 1)
+		return 150000000;
+	else if (opt == 2)
+		return 166666667;
+	else
+		return 0;
+}
+
+#define SAR_MV88F5181_CPU_FREQ       4
+#define SAR_MV88F5181_CPU_FREQ_MASK  0xf
+
+static u32 __init mv88f5181_get_cpu_freq(void __iomem *sar)
+{
+	u32 opt = (readl(sar) >> SAR_MV88F5181_CPU_FREQ) &
+		SAR_MV88F5181_CPU_FREQ_MASK;
+	if (opt == 0)
+		return 333333333;
+	else if (opt == 1 || opt == 2)
+		return 400000000;
+	else if (opt == 3)
+		return 500000000;
+	else
+		return 0;
+}
+
+static void __init mv88f5181_get_clk_ratio(void __iomem *sar, int id,
+					   int *mult, int *div)
+{
+	u32 opt = (readl(sar) >> SAR_MV88F5181_CPU_FREQ) &
+		SAR_MV88F5181_CPU_FREQ_MASK;
+	if (opt == 0 || opt == 1) {
+		*mult = 1;
+		*div  = 2;
+	} else if (opt == 2 || opt == 3) {
+		*mult = 1;
+		*div  = 3;
+	} else {
+		*mult = 0;
+		*div  = 1;
+	}
+}
+
+static const struct coreclk_soc_desc mv88f5181_coreclks = {
+	.get_tclk_freq = mv88f5181_get_tclk_freq,
+	.get_cpu_freq = mv88f5181_get_cpu_freq,
+	.get_clk_ratio = mv88f5181_get_clk_ratio,
+	.ratios = orion_coreclk_ratios,
+	.num_ratios = ARRAY_SIZE(orion_coreclk_ratios),
+};
+
+static void __init mv88f5181_clk_init(struct device_node *np)
+{
+	return mvebu_coreclk_setup(np, &mv88f5181_coreclks);
+}
+
+CLK_OF_DECLARE(mv88f5181_clk, "marvell,mv88f5181-core-clock", mv88f5181_clk_init);
+
+/*
  * Orion 5182
  */
 

-- 
2.8.1

Signed-off-by: Jamie Lentin <redacted>
---
 arch/arm/mach-orion5x/Makefile        |   1 -
 arch/arm/mach-orion5x/wnr854t-setup.c | 185 ----------------------------------
 2 files changed, 186 deletions(-)
 delete mode 100644 arch/arm/mach-orion5x/wnr854t-setup.c

diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
index 9dff2d3..a2c9ebc 100644
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion5x/Makefile

@@ -14,7 +14,6 @@ obj-$(CONFIG_MACH_WRT350N_V2)	+= wrt350n-v2-setup.o
 obj-$(CONFIG_MACH_TS78XX)	+= ts78xx-setup.o
 obj-$(CONFIG_MACH_MV2120)	+= mv2120-setup.o
 obj-$(CONFIG_MACH_NET2BIG)	+= net2big-setup.o
-obj-$(CONFIG_MACH_WNR854T)	+= wnr854t-setup.o
 obj-$(CONFIG_MACH_RD88F5181L_GE)	+= rd88f5181l-ge-setup.o
 obj-$(CONFIG_MACH_RD88F5181L_FXO)	+= rd88f5181l-fxo-setup.o
 obj-$(CONFIG_MACH_RD88F6183AP_GE)	+= rd88f6183ap-ge-setup.o

diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion5x/wnr854t-setup.c
deleted file mode 100644
index 4e1e5c8..0000000
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ /dev/null

@@ -1,185 +0,0 @@
-/*
- * arch/arm/mach-orion5x/wnr854t-setup.c
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-#include <linux/gpio.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/pci.h>
-#include <linux/irq.h>
-#include <linux/delay.h>
-#include <linux/mtd/physmap.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/ethtool.h>
-#include <net/dsa.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/pci.h>
-#include "orion5x.h"
-#include "common.h"
-#include "mpp.h"
-
-static unsigned int wnr854t_mpp_modes[] __initdata = {
-	MPP0_GPIO,		/* Power LED green (0=on) */
-	MPP1_GPIO,		/* Reset Button (0=off) */
-	MPP2_GPIO,		/* Power LED blink (0=off) */
-	MPP3_GPIO,		/* WAN Status LED amber (0=off) */
-	MPP4_GPIO,		/* PCI int */
-	MPP5_GPIO,		/* ??? */
-	MPP6_GPIO,		/* ??? */
-	MPP7_GPIO,		/* ??? */
-	MPP8_UNUSED,		/* ??? */
-	MPP9_GIGE,		/* GE_RXERR */
-	MPP10_UNUSED,		/* ??? */
-	MPP11_UNUSED,		/* ??? */
-	MPP12_GIGE,		/* GE_TXD[4] */
-	MPP13_GIGE,		/* GE_TXD[5] */
-	MPP14_GIGE,		/* GE_TXD[6] */
-	MPP15_GIGE,		/* GE_TXD[7] */
-	MPP16_GIGE,		/* GE_RXD[4] */
-	MPP17_GIGE,		/* GE_RXD[5] */
-	MPP18_GIGE,		/* GE_RXD[6] */
-	MPP19_GIGE,		/* GE_RXD[7] */
-	0,
-};
-
-/*
- * 8M NOR flash Device bus boot chip select
- */
-#define WNR854T_NOR_BOOT_BASE	0xf4000000
-#define WNR854T_NOR_BOOT_SIZE	SZ_8M
-
-static struct mtd_partition wnr854t_nor_flash_partitions[] = {
-	{
-		.name		= "kernel",
-		.offset		= 0x00000000,
-		.size		= 0x00100000,
-	}, {
-		.name		= "rootfs",
-		.offset		= 0x00100000,
-		.size		= 0x00660000,
-	}, {
-		.name		= "uboot",
-		.offset		= 0x00760000,
-		.size		= 0x00040000,
-	},
-};
-
-static struct physmap_flash_data wnr854t_nor_flash_data = {
-	.width		= 2,
-	.parts		= wnr854t_nor_flash_partitions,
-	.nr_parts	= ARRAY_SIZE(wnr854t_nor_flash_partitions),
-};
-
-static struct resource wnr854t_nor_flash_resource = {
-	.flags		= IORESOURCE_MEM,
-	.start		= WNR854T_NOR_BOOT_BASE,
-	.end		= WNR854T_NOR_BOOT_BASE + WNR854T_NOR_BOOT_SIZE - 1,
-};
-
-static struct platform_device wnr854t_nor_flash = {
-	.name			= "physmap-flash",
-	.id			= 0,
-	.dev		= {
-		.platform_data	= &wnr854t_nor_flash_data,
-	},
-	.num_resources		= 1,
-	.resource		= &wnr854t_nor_flash_resource,
-};
-
-static struct mv643xx_eth_platform_data wnr854t_eth_data = {
-	.phy_addr	= MV643XX_ETH_PHY_NONE,
-	.speed		= SPEED_1000,
-	.duplex		= DUPLEX_FULL,
-};
-
-static struct dsa_chip_data wnr854t_switch_chip_data = {
-	.port_names[0] = "lan3",
-	.port_names[1] = "lan4",
-	.port_names[2] = "wan",
-	.port_names[3] = "cpu",
-	.port_names[5] = "lan1",
-	.port_names[7] = "lan2",
-};
-
-static struct dsa_platform_data wnr854t_switch_plat_data = {
-	.nr_chips	= 1,
-	.chip		= &wnr854t_switch_chip_data,
-};
-
-static void __init wnr854t_init(void)
-{
-	/*
-	 * Setup basic Orion functions. Need to be called early.
-	 */
-	orion5x_init();
-
-	orion5x_mpp_conf(wnr854t_mpp_modes);
-
-	/*
-	 * Configure peripherals.
-	 */
-	orion5x_eth_init(&wnr854t_eth_data);
-	orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
-	orion5x_uart0_init();
-
-	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
-				    ORION_MBUS_DEVBUS_BOOT_ATTR,
-				    WNR854T_NOR_BOOT_BASE,
-				    WNR854T_NOR_BOOT_SIZE);
-	platform_device_register(&wnr854t_nor_flash);
-}
-
-static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
-	u8 pin)
-{
-	int irq;
-
-	/*
-	 * Check for devices with hard-wired IRQs.
-	 */
-	irq = orion5x_pci_map_irq(dev, slot, pin);
-	if (irq != -1)
-		return irq;
-
-	/*
-	 * Mini-PCI slot.
-	 */
-	if (slot == 7)
-		return gpio_to_irq(4);
-
-	return -1;
-}
-
-static struct hw_pci wnr854t_pci __initdata = {
-	.nr_controllers	= 2,
-	.setup		= orion5x_pci_sys_setup,
-	.scan		= orion5x_pci_sys_scan_bus,
-	.map_irq	= wnr854t_pci_map_irq,
-};
-
-static int __init wnr854t_pci_init(void)
-{
-	if (machine_is_wnr854t())
-		pci_common_init(&wnr854t_pci);
-
-	return 0;
-}
-subsys_initcall(wnr854t_pci_init);
-
-MACHINE_START(WNR854T, "Netgear WNR854T")
-	/* Maintainer: Imre Kaloz <kaloz@openwrt.org> */
-	.atag_offset	= 0x100,
-	.nr_irqs	= ORION5X_NR_IRQS,
-	.init_machine	= wnr854t_init,
-	.map_io		= orion5x_map_io,
-	.init_early	= orion5x_init_early,
-	.init_irq	= orion5x_init_irq,
-	.init_time	= orion5x_timer_init,
-	.fixup		= tag_fixup_mem32,
-	.restart	= orion5x_restart,
-MACHINE_END

-- 
2.8.1

If PHY is registered via. a DSA switch, the MDIO bus the phy is on does
not exist in devicetree, but there may be a reference to the PHY node
on the physical MDIO bus to use.

Signed-off-by: Jamie Lentin <redacted>
---
 drivers/net/phy/marvell.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 280e879..c2ca347 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c

@@ -302,14 +302,24 @@ static int marvell_config_aneg(struct phy_device *phydev)
  */
 static int marvell_of_reg_init(struct phy_device *phydev)
 {
-	const __be32 *paddr;
+	const __be32 *paddr = NULL;
 	int len, i, saved_page, current_page, page_changed, ret;
+	struct device_node *phy_dn;
+
+	if (phydev->mdio.dev.of_node)
+		paddr = of_get_property(phydev->mdio.dev.of_node,
+					"marvell,reg-init", &len);
+	else if (phydev->attached_dev->dev.of_node) {
+		/* A DSA slave-mii-bus has no OF node, but the PHY might */
+		phy_dn = of_parse_phandle(phydev->attached_dev->dev.of_node,
+					  "phy-handle", 0);
+		if (phy_dn) {
+			paddr = of_get_property(phy_dn,
+						"marvell,reg-init", &len);
+			of_node_put(phy_dn);
+		}
+	}
 
-	if (!phydev->mdio.dev.of_node)
-		return 0;
-
-	paddr = of_get_property(phydev->mdio.dev.of_node,
-				"marvell,reg-init", &len);
 	if (!paddr || len < (4 * sizeof(*paddr)))
 		return 0;
 

-- 
2.8.1

marvell,reg-init is generally used to apply a custom LED configuration
on boot. However this is then blatted in m88e1121_config_aneg when the
interface is brought up. Re-apply any custom configuration afterwards,
to keep custom LED configuration.

Signed-off-by: Jamie Lentin <redacted>
---
 drivers/net/phy/marvell.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c2ca347..b55e4e0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c

@@ -424,6 +424,10 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
 	phy_write(phydev, MII_MARVELL_PHY_PAGE, oldpage);
 
 	err = genphy_config_aneg(phydev);
+	if (err < 0)
+		return err;
+
+	err = marvell_of_reg_init(phydev);
 
 	return err;
 }

-- 
2.8.1

Copy the format for kirkwood/dove to orion5x

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
new file mode 100644
index 0000000..a888011
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

@@ -0,0 +1,23 @@
+Marvell Orion SoC Family Device Tree Bindings
+---------------------------------------------
+
+Boards with a SoC of the Marvell Orion family, eg 88f5181
+
+* Required root node properties:
+compatible: must contain "marvell,orion5x"
+
+In addition, the above compatible shall be extended with the specific
+SoC. Currently known SoC compatibles are:
+
+"marvell,orion5x-88f5182"
+
+And in addition, the compatible shall be extended with the specific
+board. Currently known boards are:
+
+"buffalo,lsgl"
+"buffalo,lswsgl"
+"buffalo,lswtgl"
+"lacie,ethernet-disk-mini-v2"
+"lacie,d2-network"
+"marvell,rd-88f5182-nas"
+"maxtor,shared-storage-2"

-- 
2.8.1

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       |  1 +
 arch/arm/boot/dts/orion5x-mv88f5181.dtsi           | 35 ++++++++++++++++++++++
 2 files changed, 36 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-mv88f5181.dtsi

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
index a888011..ff3c120 100644
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

@@ -9,6 +9,7 @@ compatible: must contain "marvell,orion5x"
 In addition, the above compatible shall be extended with the specific
 SoC. Currently known SoC compatibles are:
 
+"marvell,orion5x-88f5181"
 "marvell,orion5x-88f5182"
 
 And in addition, the compatible shall be extended with the specific

diff --git a/arch/arm/boot/dts/orion5x-mv88f5181.dtsi b/arch/arm/boot/dts/orion5x-mv88f5181.dtsi
new file mode 100644
index 0000000..b51e7ac
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-mv88f5181.dtsi

@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2016 Jamie Lentin <jm@lentin.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include "orion5x.dtsi"
+
+/ {
+	compatible = "marvell,orion5x-88f5181", "marvell,orion5x";
+
+	soc {
+		compatible = "marvell,orion5x-88f5181-mbus", "simple-bus";
+
+		internal-regs {
+			pinctrl: pinctrl@10000 {
+				compatible = "marvell,88f5181-pinctrl";
+				reg = <0x10000 0x8>, <0x10050 0x4>;
+			};
+
+			core_clk: core-clocks@10030 {
+				compatible = "marvell,mv88f5181-core-clock";
+				reg = <0x10010 0x4>;
+				#clock-cells = <1>;
+			};
+
+			mbusc: mbus-controller@20000 {
+				compatible = "marvell,mbus-controller";
+				reg = <0x20000 0x100>, <0x1500 0x20>;
+			};
+		};
+	};
+};

-- 
2.8.1

The default bootloader leaves the LEDs orange, and the 88E1121R driver
applies it's own inappropriate configuration. Configure as per manual,
i.e. orange = 100 / green = 1000 / blink = activity

Signed-off-by: Jamie Lentin <redacted>
---
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts | 45 +++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
index a8e89d8..635b396 100644
--- a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
+++ b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts

@@ -81,16 +81,19 @@
 			port@0 {
 				reg = <0>;
 				label = "lan3";
+				phy-handle = <&lan3phy>;
 			};
 
 			port@1 {
 				reg = <1>;
 				label = "lan4";
+				phy-handle = <&lan4phy>;
 			};
 
 			port@2 {
 				reg = <2>;
 				label = "wan";
+				phy-handle = <&wanphy>;
 			};
 
 			port@3 {

@@ -101,11 +104,13 @@
 			port@5 {
 				reg = <5>;
 				label = "lan1";
+				phy-handle = <&lan1phy>;
 			};
 
 			port@7 {
 				reg = <7>;
 				label = "lan2";
+				phy-handle = <&lan2phy>;
 			};
 		};
 	};

@@ -148,6 +153,46 @@
 
 &mdio {
 	status = "okay";
+
+	lan3phy: ethernet-phy@0 {
+		/* Marvell 88E1121R (port 1) */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <0>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	lan4phy: ethernet-phy@1 {
+		/* Marvell 88E1121R (port 2) */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	wanphy: ethernet-phy@2 {
+		/* Marvell 88E1121R (port 1) */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <2>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	lan1phy: ethernet-phy@5 {
+		/* Marvell 88E1112 */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <5>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
+
+	lan2phy: ethernet-phy@7 {
+		/* Marvell 88E1112 */
+		compatible = "ethernet-phy-id0141.0cb0",
+			     "ethernet-phy-ieee802.3-c22";
+		reg = <7>;
+		marvell,reg-init = <3 16 0 0x1777 3 17 0 0x15>;
+	};
 };
 
 &eth {

-- 
2.8.1

As far as I'm aware the mv88f5181-b1 and mv88f5181l are the same at the
pinctrl level, so re-use the definitions for both.

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/pinctrl/marvell,orion-pinctrl.txt     |  4 ++--
 drivers/pinctrl/mvebu/pinctrl-orion.c              | 23 +++++++++++-----------
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
index 27570a3..5a79bad 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt

@@ -4,8 +4,8 @@ Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
 part and usage.
 
 Required properties:
-- compatible: "marvell,88f5181l-pinctrl", "marvell,88f5182-pinctrl",
-              "marvell,88f5281-pinctrl"
+- compatible: "marvell,88f5181-pinctrl", "marvell,88f5181l-pinctrl",
+              "marvell,88f5182-pinctrl", "marvell,88f5281-pinctrl"
 
 - reg: two register areas, the first one describing the first two
   contiguous MPP registers, and the second one describing the single

diff --git a/drivers/pinctrl/mvebu/pinctrl-orion.c b/drivers/pinctrl/mvebu/pinctrl-orion.c
index 3b7122d..6f9c8ee 100644
--- a/drivers/pinctrl/mvebu/pinctrl-orion.c
+++ b/drivers/pinctrl/mvebu/pinctrl-orion.c

@@ -64,11 +64,11 @@ static int orion_mpp_ctrl_set(unsigned pid, unsigned long config)
 	return 0;
 }
 
-#define V(f5181l, f5182, f5281) \
-	((f5181l << 0) | (f5182 << 1) | (f5281 << 2))
+#define V(f5181, f5182, f5281) \
+	((f5181 << 0) | (f5182 << 1) | (f5281 << 2))
 
 enum orion_variant {
-	V_5181L = V(1, 0, 0),
+	V_5181  = V(1, 0, 0),
 	V_5182  = V(0, 1, 0),
 	V_5281  = V(0, 0, 1),
 	V_ALL   = V(1, 1, 1),

@@ -103,13 +103,13 @@ static struct mvebu_mpp_mode orion_mpp_modes[] = {
 		 MPP_VAR_FUNCTION(0x0, "gpio", NULL,        V_ALL),
 		 MPP_VAR_FUNCTION(0x2, "pci", "req5",       V_ALL),
 		 MPP_VAR_FUNCTION(0x4, "nand", "re0",       V_5182 | V_5281),
-		 MPP_VAR_FUNCTION(0x5, "pci-1", "clk",      V_5181L),
+		 MPP_VAR_FUNCTION(0x5, "pci-1", "clk",      V_5181),
 		 MPP_VAR_FUNCTION(0x5, "sata0", "act",      V_5182)),
 	MPP_MODE(7,
 		 MPP_VAR_FUNCTION(0x0, "gpio", NULL,        V_ALL),
 		 MPP_VAR_FUNCTION(0x2, "pci", "gnt5",       V_ALL),
 		 MPP_VAR_FUNCTION(0x4, "nand", "we0",       V_5182 | V_5281),
-		 MPP_VAR_FUNCTION(0x5, "pci-1", "clk",      V_5181L),
+		 MPP_VAR_FUNCTION(0x5, "pci-1", "clk",      V_5181),
 		 MPP_VAR_FUNCTION(0x5, "sata1", "act",      V_5182)),
 	MPP_MODE(8,
 		 MPP_VAR_FUNCTION(0x0, "gpio", NULL,        V_ALL),

@@ -165,7 +165,7 @@ static struct mvebu_mpp_ctrl orion_mpp_controls[] = {
 	MPP_FUNC_CTRL(0, 19, NULL, orion_mpp_ctrl),
 };
 
-static struct pinctrl_gpio_range mv88f5181l_gpio_ranges[] = {
+static struct pinctrl_gpio_range mv88f5181_gpio_ranges[] = {
 	MPP_GPIO_RANGE(0, 0, 0, 16),
 };
 

@@ -177,14 +177,14 @@ static struct pinctrl_gpio_range mv88f5281_gpio_ranges[] = {
 	MPP_GPIO_RANGE(0, 0, 0, 16),
 };
 
-static struct mvebu_pinctrl_soc_info mv88f5181l_info = {
-	.variant = V_5181L,
+static struct mvebu_pinctrl_soc_info mv88f5181_info = {
+	.variant = V_5181,
 	.controls = orion_mpp_controls,
 	.ncontrols = ARRAY_SIZE(orion_mpp_controls),
 	.modes = orion_mpp_modes,
 	.nmodes = ARRAY_SIZE(orion_mpp_modes),
-	.gpioranges = mv88f5181l_gpio_ranges,
-	.ngpioranges = ARRAY_SIZE(mv88f5181l_gpio_ranges),
+	.gpioranges = mv88f5181_gpio_ranges,
+	.ngpioranges = ARRAY_SIZE(mv88f5181_gpio_ranges),
 };
 
 static struct mvebu_pinctrl_soc_info mv88f5182_info = {

@@ -212,7 +212,8 @@ static struct mvebu_pinctrl_soc_info mv88f5281_info = {
  * muxing, they are identical.
  */
 static const struct of_device_id orion_pinctrl_of_match[] = {
-	{ .compatible = "marvell,88f5181l-pinctrl", .data = &mv88f5181l_info },
+	{ .compatible = "marvell,88f5181-pinctrl", .data = &mv88f5181_info },
+	{ .compatible = "marvell,88f5181l-pinctrl", .data = &mv88f5181_info },
 	{ .compatible = "marvell,88f5182-pinctrl", .data = &mv88f5182_info },
 	{ .compatible = "marvell,88f5281-pinctrl", .data = &mv88f5281_info },
 	{ }

-- 
2.8.1

On Sat, Jul 16, 2016 at 03:28:59PM +0100, Jamie Lentin wrote:

orion-wdt refuses to start without these properties defined, so lift
definitions out of kirkwood/dove.dtsi

Signed-off-by: Jamie Lentin <redacted>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

On Sat, Jul 16, 2016 at 03:29:00PM +0100, Jamie Lentin wrote:

Copy the format for kirkwood/dove to orion5x

Signed-off-by: Jamie Lentin <redacted>

Reviewed-by: Andrew Lunn <redacted>

    Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Jul 16, 2016 at 03:29:01PM +0100, Jamie Lentin wrote:

Referring to values in the u-boot port, add support for the mv88f5181

Signed-off-by: Jamie Lentin <redacted>

Reviewed-by: Andrew Lunn <redacted>

    Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Jul 16, 2016 at 03:29:02PM +0100, Jamie Lentin wrote:

As far as I'm aware the mv88f5181-b1 and mv88f5181l are the same at the
pinctrl level, so re-use the definitions for both.

Good, you add a new compatibile string. So it if turns out they are
not identical, we can fix it later without causing problems.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

On Sat, Jul 16, 2016 at 03:29:03PM +0100, Jamie Lentin wrote:

You need to put somewhere here for the commit log.

Otherwise this looks O.K.

	  Andrew

23 more quoted lines

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

You can put the board rate etc in the stdout-patch. Something like:

                stdout-path = "serial0:115200n8";

Documentation/leds/leds-class.txt says:

LED Device Naming
=================

Is currently of the form:

"devicename:colour:function"

5 more quoted lines

This all looks sensible, if a bit mixed up. Lets discuss the switch
issue in a different thread.

Documentation/devicetree/bindings/mtd/partition.txt says the
partitions should be placed under a partitions node. There are some
conditions when that does not work. So please try it, and if it does
not, ignore my comment...

Ah, this is missing from your DSA node. You can then add:

reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;

inside the switch@0 node.

This can go into the .dtsi file your previous patch added. 

Nice to see the comment.

     Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Jul 16, 2016 at 03:29:05PM +0100, Jamie Lentin wrote:

Again, you need a commit log. It could be something like:

The setup file for the wnr854t has bit rotted to such an extent it no
longer works. Replace it with a working device tree description.

       Andrew

Ah! I think i interpreted that wrong. This does not reset the Ethernet
switch. It is actually a switch on the front to reset the whole box?

How about calling it button, not switch?

    Andrew

On Sat, Jul 16, 2016 at 03:29:06PM +0100, Jamie Lentin wrote:

If PHY is registered via. a DSA switch, the MDIO bus the phy is on does
not exist in devicetree, but there may be a reference to the PHY node
on the physical MDIO bus to use.

O.K, i see what you are trying to achieve, it makes sense, but sorry,
NACK.

There is however a nice solution :-)

If you look in net-next, you will notice a big change to DSA. There is
a new binding, and the mv88e6xxx driver now exports the switch
internal MDIO bus just like any other MDIO bus. So you can have a phy
on the MDIO bus, and that phy can have "marvell,reg-init" properties.

     Andrew

4 more quoted lines

On Sat, Jul 16, 2016 at 03:29:07PM +0100, Jamie Lentin wrote:

marvell,reg-init is generally used to apply a custom LED configuration
on boot. However this is then blatted in m88e1121_config_aneg when the
interface is brought up. Re-apply any custom configuration afterwards,
to keep custom LED configuration.

This has been fixed in net-next.

     Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello.

On 7/16/2016 5:29 PM, Jamie Lentin wrote:

Referring to values in the u-boot port, add support for the mv88f5181

Signed-off-by: Jamie Lentin <redacted>

[...]

   Do you know about the *switch* statement? :-)

   Asks to be a *switch* as well...

    This one too...

[...]

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Saturday, July 16, 2016 3:29:04 PM CEST Jamie Lentin wrote:

7 more quoted lines

The other patches all appear good to me, but I find this one suspicious.

Why are you not using the device tree for probing PCI? Is there anything
missing in drivers/pci/host/pci-mvebu.c, or do you just need help
describing it in DT?

	Arnd

There's one major flaw; unicast traffic is never received on any port.
Broadcast traffic is received however, and on the correct port. Thus
an external machine can make an ARP request and get a response, for
example. With a manually-entered ARP entry, the router can send pings
out to a remote machine which responds, and the response is lost in the
DSA switch. "ethtool -S" reports pings received on "in_unicast" but
nothing makes it through the switch. This thread[0] seems very similar.
I've run out of ideas here and can't find any switch datasheets to give
me pointers so any suggestions greatly appreciated.

Hi Jamie

So it is 6131? So part of the 6185 family. 

I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
configuration. Try swapping to EDSA. I even removed support for
TAG_DSA in one of the recent patches.

Please also can you get https://github.com/vivien/linux.git commit
323321875671dfe95b6b91ce051a74d415c7158c which will give you some
extra debug files /sys/kernel/debug/mv88e6xxx. 

The reg, stats, and atu would be interesting.

    Andrew

On Sat, 16 Jul 2016, Arnd Bergmann wrote:

On Saturday, July 16, 2016 3:29:04 PM CEST Jamie Lentin wrote:

quoted

+
+#define WNR854T_PCI_SLOT0_OFFS	7
+#define WNR854T_PCI_SLOT0_IRQ_PIN	4
+
+static void __init wnr854t_pci_preinit(void)
+{
+	int pin;
+
+	/*
+	 * Configure PCI GPIO IRQ pins
+	 */
+	pin = WNR854T_PCI_SLOT0_IRQ_PIN;
+	if (gpio_request(pin, "PCI Int") == 0) {
+		if (gpio_direction_input(pin) == 0) {
+			irq_set_irq_type(gpio_to_irq(pin), IRQ_TYPE_LEVEL_LOW);
+		} else {
+			pr_err("wnr854t_pci_preinit failed to set_irq_type pin %d\n",
+				pin);
+			gpio_free(pin);
+		}
+	} else {
+		pr_err("wnr854t_pci_preinit failed to request gpio %d\n", pin);
+	}
+}
+
+static int __init wnr854t_pci_map_irq(const struct pci_dev *dev, u8 slot,
+	u8 pin)
+{
+	int irq;
+
+	/*
+	 * Check for devices with hard-wired IRQs.
+	 */
+	irq = orion5x_pci_map_irq(dev, slot, pin);
+	if (irq != -1)
+		return irq;
+
+	/*
+	 * PCI IRQs are connected via GPIOs

14 more quoted lines

Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port as well as a PCIe port. Given no other orion5x boards seem to use pci-mvebu, I'm assuming there's work to be done before the PCI port can be used via. pci-mvebu.c

This is something I can look into if there aren't patches out there, but wanted to get the rest into a reasonable state first.

	Arnd

-- 
Jamie Lentin

On Sat, 16 Jul 2016, Andrew Lunn wrote:

quoted

There's one major flaw; unicast traffic is never received on any port.
Broadcast traffic is received however, and on the correct port. Thus
an external machine can make an ARP request and get a response, for
example. With a manually-entered ARP entry, the router can send pings
out to a remote machine which responds, and the response is lost in the
DSA switch. "ethtool -S" reports pings received on "in_unicast" but
nothing makes it through the switch. This thread[0] seems very similar.
I've run out of ideas here and can't find any switch datasheets to give
me pointers so any suggestions greatly appreciated.

Hi Jamie

So it is 6131? So part of the 6185 family.

Yes, that's what's detected and the OpenWRT page says 88E6131-LAR1. And my test setup looks like:

88e6131
  |- lan1:10.100.1.55 <-- switch --> eth0:10.100.1.41 -|
  |- lan4:10.100.4.55 <-- cable  --> enp0:10.100.4.41 -|
                                                    laptop
enp0 is a 100M USB network card, the switch is gigabit and on the rest of my network here, so there's assorted background broadcast chatter. If the noise is confusing matters then can disconnect it.

Firstly I've tried to to rebase against net-next[0], but after adding 6131 to mv88e6xxx_of_match, &chip->ppu_work seems to be causing a NULL pointer ooops. I'll assume it's not done yet and ignore net-next for now.

I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
configuration. Try swapping to EDSA. I even removed support for
TAG_DSA in one of the recent patches.

Okay, back to my original wnr854t-support-v0a branch based on 4.6, switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to add support, but there's no traffic in/out of any port. tcpdump on the underlying ethernet port shows encapsulated broadcast traffic, e.g. this ARP request from enp0:10.100.4.41:

00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast, ethertype Unknown (0xc008), length 64:
        0x0000:  0000 0806 0001 0800 0604 0001 1aff 0ffe  ................
        0x0010:  1022 0a64 0429 0000 0000 0000 0a64 0437  .".d.).......d.7
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000                                     ..

...but no unicast traffic.

Please also can you get https://github.com/vivien/linux.git commit
323321875671dfe95b6b91ce051a74d415c7158c which will give you some
extra debug files /sys/kernel/debug/mv88e6xxx.

The reg, stats, and atu would be interesting.

Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the LEDs, cherry-picked the above commit. Pushed the result if it's useful[1]. The debugfs code wouldn't patch cleanly onto 4.6 or net-next.

On boot up I get:

mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 switch
libphy: dsa slave smi: probed
Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R]  (mii_bus:phy_addr=dsa-0:00:00, irq=-1)
Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:01, irq=-1)
Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:02, irq=-1)
Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:05, irq=-1)
Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:07, irq=-1)

Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no traffic visible with tcpdump on lan1/4 (broadcast or unicast), only broadcast traffic on the backing port, eth0.

# cat /sys/kernel/debug/mv88e6xxx.0/regs
    GLOBAL GLOBAL2 SERDES     0    1    2    3    4    5    6    7
 0:  c800       0       0  7080 7d80 7080 6e88 6086 7e86 6086 7086
 1:    1b       0       0     3    3    3   3e  403  403  403  403
 2:  2fd5       0       0     0    0    0    0    0    0    0    0
 3:  9df4    ffff       0  1066 1066 1066 1066 1066 1066 1066 1066
 4:  4000     191       0   433  433  433 3533  433  433  433  433
 5:  1000      ff       0     0    0    0    0    0    0    0    0
 6:  c000    1f0f       0   708  708  708  7f7  708  708  708  708
 7:     0    70ff       0     0    0    0    0    0    0    0    0
 8:     0    7800       0    83   83   83   c3   83   83   83   83
 9:     0       0       0     1    1    1    1    1    1    1    1
 a:  f148       0       0     0    0    0    0    0    0    0    0
 b:  400f       0       0     1    2    4    0   10   20   40   80
 c:     0       0       0     0    0    0    0    0    0    0    0
 d:  ffff       0       0     0    0    0    0    0    0    0    0
 e:  ffff       0       0     0    0    0    0    0    0    0    0
 f:  ffff      77       0     0    0    0    0    0    0    0    0
10:     0       0       0     0    0    0    0    0    0    0    0
11:     0       0       0     0    0    0    0    0    0    0    0
12:  5555       0       0     0    0    0   12    0    0    0    0
13:  5555       0       0     0    0    0    0    0    0    0    0
14:  aaaa       0       0   403  403  403 8403  403  403  403  403
15:  aaaa       0       0     0    0    0    0    0    0    0    0

62 more lines

   Andrew

[0] https://github.com/lentinj/linux/tree/wnr854t-support-v0b-net-next-experiment
[1] https://github.com/lentinj/linux/tree/wnr854t-support-v0a-rebase-4.7-rc7

-- 
Jamie Lentin

Firstly I've tried to to rebase against net-next[0], but after
adding 6131 to mv88e6xxx_of_match, &chip->ppu_work seems to be
causing a NULL pointer ooops. I'll assume it's not done yet and
ignore net-next for now.

You don't need to modify mv88e6xxx_of_match, the 6131 is compatible
with the mv88e6085. Just use the compatible string of
"marvell,mv88e6085". So far, ever Marvell chip we support is
compatible with the mv88e6085, in terms of probing. Once the driver
has probed, and read the device ID from a register, it knows enough to
decide for itself what features the chip has.

In order to get the LEDs working as you want, you are going to have to
use the new binding. So i would suggest sticking with that.

quoted

I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
configuration. Try swapping to EDSA. I even removed support for
TAG_DSA in one of the recent patches.

Okay, back to my original wnr854t-support-v0a branch based on 4.6,
switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to
add support, but there's no traffic in/out of any port. tcpdump on
the underlying ethernet port shows encapsulated broadcast traffic,
e.g. this ARP request from enp0:10.100.4.41:

00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast,
ethertype Unknown (0xc008), length 64:
        0x0000:  0000 0806 0001 0800 0604 0001 1aff 0ffe  ................
        0x0010:  1022 0a64 0429 0000 0000 0000 0a64 0437  .".d.).......d.7
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000                                     ..

...but no unicast traffic.

Uh, that does not look like EDSA tagging. Expect an ethertype of
0xdada. Also, if you get the latest tcpdump sources, it knows how to
decode the additional EDSA header which is added.

quoted

Please also can you get https://github.com/vivien/linux.git commit
323321875671dfe95b6b91ce051a74d415c7158c which will give you some
extra debug files /sys/kernel/debug/mv88e6xxx.

The reg, stats, and atu would be interesting.

Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the
LEDs, cherry-picked the above commit. Pushed the result if it's
useful[1]. The debugfs code wouldn't patch cleanly onto 4.6 or
net-next.

Yes, the debug code is a real pain. Something i'm working on in the
background, get something generic which is acceptable for mainline.
 

On boot up I get:

mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 switch
libphy: dsa slave smi: probed
Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R]  (mii_bus:phy_addr=dsa-0:00:00, irq=-1)
Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:01, irq=-1)
Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:02, irq=-1)
Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:05, irq=-1)
Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:07, irq=-1)

That looks good, it found the PHYs etc.

Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no
traffic visible with tcpdump on lan1/4 (broadcast or unicast), only
broadcast traffic on the backing port, eth0.

# cat /sys/kernel/debug/mv88e6xxx.0/regs
    GLOBAL GLOBAL2 SERDES     0    1    2    3    4    5    6    7
 0:  c800       0       0  7080 7d80 7080 6e88 6086 7e86 6086 7086
 1:    1b       0       0     3    3    3   3e  403  403  403  403
 2:  2fd5       0       0     0    0    0    0    0    0    0    0
 3:  9df4    ffff       0  1066 1066 1066 1066 1066 1066 1066 1066
 4:  4000     191       0   433  433  433 3533  433  433  433  433
 5:  1000      ff       0     0    0    0    0    0    0    0    0
 6:  c000    1f0f       0   708  708  708  7f7  708  708  708  708
 7:     0    70ff       0     0    0    0    0    0    0    0    0
 8:     0    7800       0    83   83   83   c3   83   83   83   83
 9:     0       0       0     1    1    1    1    1    1    1    1
 a:  f148       0       0     0    0    0    0    0    0    0    0
 b:  400f       0       0     1    2    4    0   10   20   40   80
 c:     0       0       0     0    0    0    0    0    0    0    0
 d:  ffff       0       0     0    0    0    0    0    0    0    0
 e:  ffff       0       0     0    0    0    0    0    0    0    0
 f:  ffff      77       0     0    0    0    0    0    0    0    0
10:     0       0       0     0    0    0    0    0    0    0    0
11:     0       0       0     0    0    0    0    0    0    0    0
12:  5555       0       0     0    0    0   12    0    0    0    0
13:  5555       0       0     0    0    0    0    0    0    0    0
14:  aaaa       0       0   403  403  403 8403  403  403  403  403
15:  aaaa       0       0     0    0    0    0    0    0    0    0
16:  ffff       0       0   700  70d  700  700  f41  f0e  f41  f02
17:  ffff       0       0     0    0    0    0    0    0    0    0
18:  fa41       0       0  3210 3210 3210 3210 3210 3210 3210 3210
19:  8100       0       0  7654 7654 7654 7654 7654 7654 7654 7654
1a:  3330       0       0     -    -    -    -    -    -    -    -
1b:    f4       0       0     -    -    -    -    -    -    -    -
1c:  f000       0       0     -    -    -    -    -    -    -    -
1d:  5c07       0       0     -    -    -    -    -    -    -    -
1e:     0      f0       0     -    -    -    -    -    -    -    -
1f:     0       0       0     -    -    -    -    -    -    -    -

# cat /sys/kernel/debug/mv88e6xxx.0/stats

35 more quoted lines

So as you say, no unicast traffic to/from the CPU port. The 18
sw_in_filtered also look suspicious.
 

[0] https://github.com/lentinj/linux/tree/wnr854t-support-v0b-net-next-experiment

+	port@3 {
+			reg = <3>;
+			label = "cpu";
+			ethernet = <&eth>;
+			fixed-link {
+				speed = <1000>;
+				full-duplex;
+			};

You don't need a fixed-link here. The cpu port is automatically
configured fixed at the highest speed the port will do.

However, 

 &eth {
      status = "okay";
-     ethernet-port@0 {
-     		speed = <1000>;
-		duplex = <1>;
-    };
 };

here you do need the fixed link, otherwise it thinks there is a PHY
connected and tried to do auto-negotiation. That will never work.

	  Andrew

On Sat, Jul 16, 2016 at 03:29:00PM +0100, Jamie Lentin wrote:

Copy the format for kirkwood/dove to orion5x

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

Acked-by: Rob Herring <redacted>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Jul 16, 2016 at 03:29:01PM +0100, Jamie Lentin wrote:

Referring to values in the u-boot port, add support for the mv88f5181

Signed-off-by: Jamie Lentin <redacted>
---
 .../devicetree/bindings/clock/mvebu-core-clock.txt |  1 +

Acked-by: Rob Herring <redacted>

 drivers/clk/mvebu/orion.c                          | 70 ++++++++++++++++++++++
 2 files changed, 71 insertions(+)

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Jul 16, 2016 at 03:29:02PM +0100, Jamie Lentin wrote:

Please reformat to one per line. Otherwise,

Acked-by: Rob Herring <redacted>

 
 - reg: two register areas, the first one describing the first two
   contiguous MPP registers, and the second one describing the single

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Jul 16, 2016 at 03:29:03PM +0100, Jamie Lentin wrote:

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       |  1 +
 arch/arm/boot/dts/orion5x-mv88f5181.dtsi           | 35 ++++++++++++++++++++++
 2 files changed, 36 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-mv88f5181.dtsi

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

On Sunday, July 17, 2016 10:39:01 AM CEST Jamie Lentin wrote:

On Sat, 16 Jul 2016, Arnd Bergmann wrote:

quoted

The other patches all appear good to me, but I find this one suspicious.

Why are you not using the device tree for probing PCI? Is there anything
missing in drivers/pci/host/pci-mvebu.c, or do you just need help
describing it in DT?

Unlike the other SoC's supported by pci-mvebu.c, orion5x has one PCI port 
as well as a PCIe port. Given no other orion5x boards seem to use 
pci-mvebu, I'm assuming there's work to be done before the PCI port can be 
used via. pci-mvebu.c

This is something I can look into if there aren't patches out there, but 
wanted to get the rest into a reasonable state first.

Ok, I see your point. However, we also don't have any other Orion5x machines
using DT that rely on old probe method, and I this is something that
is particularly hard to retrofit later.

I would assume that the PCIe port should work out of the box with the driver
we have, but the PCI controller does not, and it will require some work.
Looking at https://wiki.openwrt.org/toh/netgear/wnr854t, I assume that
you want only PCI but not PCIe, correct?

The good news is that we can completely separate the two, we just have two
different PCI domains if both are enabled, so we just need to add a new
driver for the PCI port to drivers/pci/host. The pci_ops can be copied
from the existing driver, although a couple of minor cleanups would be
possible. The special handling of bus numbers and the rc_pci_fixup()
can probably just go away, and the latter part is particularly
important, because building a kernel with the fixup included might
break any system with a Marvell host bridge.

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

	Arnd

On Sat, Jul 16, 2016 at 03:29:04PM +0100, Jamie Lentin wrote:

6 more quoted lines

It's 2016 now.

As kind of mentioned, drop the linux prefix here.

60 more quoted lines

The new recommended style adds a level here with a partitions node and 
the type of partitioning.

43 more quoted lines

There should only be at most 1 kconfig entry for all orion5x DT based 
platforms.

Hello,

On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:

I would assume that the PCIe port should work out of the box with the driver

Unfortunately, no. The PCIe on Orion5x requires a workaround for
reading/writing the PCI configuration space. Instead of doing MMIO
accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
MBus window, which provides a memory-mapped view of the PCI
configuration space.

Definitely not impossible to implement, but the driver doesn't work
as-is.

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

MBus windows are needed. See:

        mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
                                          ORION_MBUS_PCI_IO_ATTR,
                                          ORION5X_PCI_IO_PHYS_BASE,
                                          ORION5X_PCI_IO_SIZE,
                                          ORION5X_PCI_IO_BUS_BASE);
        mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
                                    ORION_MBUS_PCI_MEM_ATTR,
                                    ORION5X_PCI_MEM_PHYS_BASE,
                                    ORION5X_PCI_MEM_SIZE);

in orion5x_setup_wins().

Note that we already have some Orion5x converted to DT, and that use
PCI: board-rd88f5182.c is an example. So we could very well take Jamie
patches as-is, and move later to a DT-representation for PCI/PCIe.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:

On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:

quoted

I would assume that the PCIe port should work out of the box with the driver

Unfortunately, no. The PCIe on Orion5x requires a workaround for
reading/writing the PCI configuration space. Instead of doing MMIO
accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
MBus window, which provides a memory-mapped view of the PCI
configuration space.

Definitely not impossible to implement, but the driver doesn't work
as-is.

Ok.

quoted

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

MBus windows are needed. See:

        mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
                                          ORION_MBUS_PCI_IO_ATTR,
                                          ORION5X_PCI_IO_PHYS_BASE,
                                          ORION5X_PCI_IO_SIZE,
                                          ORION5X_PCI_IO_BUS_BASE);
        mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
                                    ORION_MBUS_PCI_MEM_ATTR,
                                    ORION5X_PCI_MEM_PHYS_BASE,
                                    ORION5X_PCI_MEM_SIZE);

in orion5x_setup_wins().

Ok, I was just looking at the wrong file, as they are set up from
common.c, not pci.c.

Note that we already have some Orion5x converted to DT, and that use
PCI: board-rd88f5182.c is an example. So we could very well take Jamie
patches as-is, and move later to a DT-representation for PCI/PCIe.

Ah, I thought all the DT users were moved to mach-mvebu. I agree
this new patch isn't introducing anything we don't already have then,
so we can just take it, but the conversion will not be nice when
we do that.

I was also hoping that we could get to the point where pci_common_init()
is only used for legacy machines without DT and without multiplatform,
it seems I missed a couple of users here.

	Arnd

On Sun, 17 Jul 2016, Andrew Lunn wrote:

quoted

Firstly I've tried to to rebase against net-next[0], but after
adding 6131 to mv88e6xxx_of_match, &chip->ppu_work seems to be
causing a NULL pointer ooops. I'll assume it's not done yet and
ignore net-next for now.

You don't need to modify mv88e6xxx_of_match, the 6131 is compatible
with the mv88e6085. Just use the compatible string of
"marvell,mv88e6085". So far, ever Marvell chip we support is
compatible with the mv88e6085, in terms of probing. Once the driver
has probed, and read the device ID from a register, it knows enough to
decide for itself what features the chip has.

Okay, besides the DT mistakes you mention below (changes are pushed to the same branch), I've worked out out what my problem was here. The switch was probed before the ethernet device is available, so mv88e6xxx_probe() has to back out with EPROBE_DEFER at mv88e6xxx_register_switch().

However mv88e6xxx_mdio_unregister() doesn't tidy up fully. The following lets me boot, but I'm not really clear what the usleep is helping solve and don't like it:

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5cb06f7..c46ac54 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c

@@ -3387,6 +3387,10 @@ static void mv88e6xxx_mdio_unregister(struct mv88e6xxx_chip *chip)
 {
 	struct mii_bus *bus = chip->mdio_bus;

+	/* Stop any timers attempting to re-activate the PPU */
+	del_timer(&chip->ppu_timer);
+	usleep_range(1000, 2000);
+
 	mdiobus_unregister(bus);

 	if (chip->mdio_np)

FWIW I now get:

libphy: Fixed MDIO Bus: probed
libphy: mdio_driver_register: mv88e6085
libphy: orion_mdio_bus: probed
mdio_bus f1072004.mdio-bu:00: mdio_device_register
mv88e6085 f1072004.mdio-bu:00: switch 0x106 detected: Marvell 88E6131, revision 6
libphy: /soc/internal-regs/mdio-bus@72004/switch@0: probed
mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:1b:2f:d5:9d:f4
 . . .
mv88e6085 f1072004.mdio-bu:00: switch 0x106 detected: Marvell 88E6131, revision 6
libphy: /soc/internal-regs/mdio-bus@72004/switch@0: probed
DSA: switch 0 0 parsed
DSA: tree 0 parsed
Marvell 88E1121R !soc!internal-re:00: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=!soc!internal-re:00, irq=-1)
Marvell 88E1121R !soc!internal-re:01: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=!soc!internal-re:01, irq=-1)
Marvell 88E1121R !soc!internal-re:02: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=!soc!internal-re:02, irq=-1)
Marvell 88E1112 !soc!internal-re:05: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=!soc!internal-re:05, irq=-1)
Marvell 88E1112 !soc!internal-re:07: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=!soc!internal-re:07, irq=-1)

However, nothing's changed since 4.7-rc7 in terms of getting the switch to work.

In order to get the LEDs working as you want, you are going to have to
use the new binding. So i would suggest sticking with that.

Some have suggested I should be more worried about being able to shift packets than getting the LEDs working, but where's the fun in that? :)

quoted

quoted

I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
configuration. Try swapping to EDSA. I even removed support for
TAG_DSA in one of the recent patches.

Okay, back to my original wnr854t-support-v0a branch based on 4.6,
switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to
add support, but there's no traffic in/out of any port. tcpdump on
the underlying ethernet port shows encapsulated broadcast traffic,
e.g. this ARP request from enp0:10.100.4.41:

00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast,
ethertype Unknown (0xc008), length 64:
        0x0000:  0000 0806 0001 0800 0604 0001 1aff 0ffe  ................
        0x0010:  1022 0a64 0429 0000 0000 0000 0a64 0437  .".d.).......d.7
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000                                     ..

...but no unicast traffic.

Uh, that does not look like EDSA tagging. Expect an ethertype of
0xdada. Also, if you get the latest tcpdump sources, it knows how to
decode the additional EDSA header which is added.

Okay. Frames sent from the port are EDSA-tagged (which isn't exactly surprising), but I'm yet to see the switch receive 0xdada frames. Even with the net-next branch which uses DSA_TAG_PROTO_EDSA for all chip types.

However, the ethertype is reflecting the port:-

lan1/5 : ethertype Unknown (0xc028), length 176:
lan2/7 : ethertype Unknown (0xc038), length 176:
lan3/0 : ethertype Unknown (0xc000), length 176:
lan4/1 : ethertype Unknown (0xc008), length 176:
wan/2  : ethertype Unknown (0xc010), length 176:

My other one of these routers, running OpenWRT / Linux 3.3.8, shows the same ethertypes, which suggests that the switch is still in DSA tagging mode. I'll poke around further and see what I find.

quoted

quoted

Please also can you get https://github.com/vivien/linux.git commit
323321875671dfe95b6b91ce051a74d415c7158c which will give you some
extra debug files /sys/kernel/debug/mv88e6xxx.

The reg, stats, and atu would be interesting.

Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the
LEDs, cherry-picked the above commit. Pushed the result if it's
useful[1]. The debugfs code wouldn't patch cleanly onto 4.6 or
net-next.

Yes, the debug code is a real pain. Something i'm working on in the
background, get something generic which is acceptable for mainline.

quoted

On boot up I get:

mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 switch
libphy: dsa slave smi: probed
Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R]  (mii_bus:phy_addr=dsa-0:00:00, irq=-1)
Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:01, irq=-1)
Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:02, irq=-1)
Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:05, irq=-1)
Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:07, irq=-1)

That looks good, it found the PHYs etc.

quoted

Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no
traffic visible with tcpdump on lan1/4 (broadcast or unicast), only
broadcast traffic on the backing port, eth0.

# cat /sys/kernel/debug/mv88e6xxx.0/regs
    GLOBAL GLOBAL2 SERDES     0    1    2    3    4    5    6    7
 0:  c800       0       0  7080 7d80 7080 6e88 6086 7e86 6086 7086
 1:    1b       0       0     3    3    3   3e  403  403  403  403
 2:  2fd5       0       0     0    0    0    0    0    0    0    0
 3:  9df4    ffff       0  1066 1066 1066 1066 1066 1066 1066 1066
 4:  4000     191       0   433  433  433 3533  433  433  433  433
 5:  1000      ff       0     0    0    0    0    0    0    0    0
 6:  c000    1f0f       0   708  708  708  7f7  708  708  708  708

65 more quoted lines

Yes, I've also noticed this, but not got anywhere in finding out what filtered means---is it a set of rules the PHY applies, if so where do they come from?

quoted

[0] https://github.com/lentinj/linux/tree/wnr854t-support-v0b-net-next-experiment

+	port@3 {
+			reg = <3>;
+			label = "cpu";
+			ethernet = <&eth>;
+			fixed-link {
+				speed = <1000>;
+				full-duplex;
+			};

You don't need a fixed-link here. The cpu port is automatically
configured fixed at the highest speed the port will do.

However,

&eth {
     status = "okay";
-     ethernet-port@0 {
-     		speed = <1000>;
-		duplex = <1>;
-    };
};

here you do need the fixed link, otherwise it thinks there is a PHY
connected and tried to do auto-negotiation. That will never work.

	  Andrew

-- 
Jamie Lentin

On Sun, 17 Jul 2016, Rob Herring wrote:

On Sat, Jul 16, 2016 at 03:29:04PM +0100, Jamie Lentin wrote:

quoted

This is a router based on the mv88f5181 chipset.

http://www.netgear.com/support/product/WNR854T.aspx
http://wiki.openwrt.org/toh/netgear/wnr854t

Signed-off-by: Jamie Lentin <redacted>
---
 .../bindings/arm/marvell/marvell,orion5x.txt       |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts      | 200 +++++++++++++++++++++
 arch/arm/mach-orion5x/Kconfig                      |   6 +
 arch/arm/mach-orion5x/Makefile                     |   1 +
 arch/arm/mach-orion5x/board-wnr854t.c              |  78 ++++++++
 6 files changed, 287 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
 create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
index ff3c120..748a8f2 100644
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt

@@ -22,3 +22,4 @@ board. Currently known boards are:
 "lacie,d2-network"
 "marvell,rd-88f5182-nas"
 "maxtor,shared-storage-2"
+"netgear,wnr854t"

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..63b9202 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile

@@ -535,6 +535,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
 	orion5x-linkstation-lswtgl.dtb \
 	orion5x-lswsgl.dtb \
 	orion5x-maxtor-shared-storage-2.dtb \
+	orion5x-netgear-wnr854t.dtb \
 	orion5x-rd88f5182-nas.dtb
 dtb-$(CONFIG_ARCH_PRIMA2) += \
 	prima2-evb.dtb

diff --git a/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts b/arch/arm/boot/dts/orion5x-netgear-wnr854t.dts

227 more quoted lines

Even though it needs arch/arm/mach-orion5x/board-wnr854t.c to init the PCI? orion5x currently has other board _DT options, I presumed for this reason.

quoted

+	bool "Netgear WNR854T (Flattened Device Tree)"
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  Netgear WNR854T platform.
+
 config MACH_WNR854T
 	bool "Netgear WNR854T"
 	help

-- 
Jamie Lentin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tuesday, July 19, 2016 10:40:16 AM CEST Jamie Lentin wrote:

On Mon, 18 Jul 2016, Arnd Bergmann wrote:

quoted

On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:

quoted

On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:

quoted

I would assume that the PCIe port should work out of the box with the driver

Unfortunately, no. The PCIe on Orion5x requires a workaround for
reading/writing the PCI configuration space. Instead of doing MMIO
accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
MBus window, which provides a memory-mapped view of the PCI
configuration space.

Definitely not impossible to implement, but the driver doesn't work
as-is.

Ok.

Unfortunately this isn't something I can test as the PCIe port on the SoC 
doesn't go anywhere in my case.

As I said, this wouldn't be a problem: we should consider the PCI and PCIe
ports on this chip as completely separate anyway, so we can work on
the drivers independently.

quoted

quoted

quoted

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

MBus windows are needed. See:

        mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
                                          ORION_MBUS_PCI_IO_ATTR,
                                          ORION5X_PCI_IO_PHYS_BASE,
                                          ORION5X_PCI_IO_SIZE,
                                          ORION5X_PCI_IO_BUS_BASE);
        mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
                                    ORION_MBUS_PCI_MEM_ATTR,
                                    ORION5X_PCI_MEM_PHYS_BASE,
                                    ORION5X_PCI_MEM_SIZE);

in orion5x_setup_wins().

Ok, I was just looking at the wrong file, as they are set up from
common.c, not pci.c.

quoted

Note that we already have some Orion5x converted to DT, and that use
PCI: board-rd88f5182.c is an example. So we could very well take Jamie
patches as-is, and move later to a DT-representation for PCI/PCIe.

Ah, I thought all the DT users were moved to mach-mvebu. I agree
this new patch isn't introducing anything we don't already have then,
so we can just take it, but the conversion will not be nice when
we do that.

Yes, board-wnr854t.c is a clone of the existing board-rd88f5182.c. 
Although I'd presume that it too would need late_initcall() or somesuch 
mechanism to probe PCI once the GPIO controller is available.

Deferred probing should be fine once the driver is migrated from
pci_common_init() to registering the host bridge directly.

	Arnd

On Mon, 18 Jul 2016, Arnd Bergmann wrote:

On Monday, July 18, 2016 11:44:24 AM CEST Thomas Petazzoni wrote:

quoted

On Sun, 17 Jul 2016 22:41:35 +0200, Arnd Bergmann wrote:

quoted

I would assume that the PCIe port should work out of the box with the driver

Unfortunately, no. The PCIe on Orion5x requires a workaround for
reading/writing the PCI configuration space. Instead of doing MMIO
accesses to PCIE_CONF_ADDR_OFF / PCIE_CONF_DATA_OFF, you must map a
MBus window, which provides a memory-mapped view of the PCI
configuration space.

Definitely not impossible to implement, but the driver doesn't work
as-is.

Ok.

Unfortunately this isn't something I can test as the PCIe port on the SoC doesn't go anywhere in my case.

quoted

quoted

We also don't seem to need any MBUS window setup for the I/O and
memory spaces, which greatly simplifies the driver compared to the
pci-mvebu one, it would be a fairly straightforward implementation
based on pci-host-generic.c (which unfortunately just got way
more complicated and might need to go on a diet).

MBus windows are needed. See:

        mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
                                          ORION_MBUS_PCI_IO_ATTR,
                                          ORION5X_PCI_IO_PHYS_BASE,
                                          ORION5X_PCI_IO_SIZE,
                                          ORION5X_PCI_IO_BUS_BASE);
        mvebu_mbus_add_window_by_id(ORION_MBUS_PCI_MEM_TARGET,
                                    ORION_MBUS_PCI_MEM_ATTR,
                                    ORION5X_PCI_MEM_PHYS_BASE,
                                    ORION5X_PCI_MEM_SIZE);

in orion5x_setup_wins().

Ok, I was just looking at the wrong file, as they are set up from
common.c, not pci.c.

quoted

Note that we already have some Orion5x converted to DT, and that use
PCI: board-rd88f5182.c is an example. So we could very well take Jamie
patches as-is, and move later to a DT-representation for PCI/PCIe.

Ah, I thought all the DT users were moved to mach-mvebu. I agree
this new patch isn't introducing anything we don't already have then,
so we can just take it, but the conversion will not be nice when
we do that.

Yes, board-wnr854t.c is a clone of the existing board-rd88f5182.c. Although I'd presume that it too would need late_initcall() or somesuch mechanism to probe PCI once the GPIO controller is available.

I was also hoping that we could get to the point where pci_common_init()
is only used for legacy machines without DT and without multiplatform,
it seems I missed a couple of users here.

	Arnd

-- 
Jamie Lentin

However, the ethertype is reflecting the port:-

lan1/5 : ethertype Unknown (0xc028), length 176:
lan2/7 : ethertype Unknown (0xc038), length 176:
lan3/0 : ethertype Unknown (0xc000), length 176:
lan4/1 : ethertype Unknown (0xc008), length 176:
wan/2  : ethertype Unknown (0xc010), length 176:

My other one of these routers, running OpenWRT / Linux 3.3.8, shows
the same ethertypes, which suggests that the switch is still in DSA
tagging mode. I'll poke around further and see what I find.

O.K. With this wrong, nothing is going to work.

I will check that the 6131 actually supports EDSA!

  Andrew

[Reducing the Cc: list a bit to networking people]

Okay. Frames sent from the port are EDSA-tagged (which isn't exactly
surprising), but I'm yet to see the switch receive 0xdada frames.
Even with the net-next branch which uses DSA_TAG_PROTO_EDSA for all
chip types.

However, the ethertype is reflecting the port:-

lan1/5 : ethertype Unknown (0xc028), length 176:
lan2/7 : ethertype Unknown (0xc038), length 176:
lan3/0 : ethertype Unknown (0xc000), length 176:
lan4/1 : ethertype Unknown (0xc008), length 176:
wan/2  : ethertype Unknown (0xc010), length 176:

O.K, we broke it :-(

The 6185 does not support EDSA, only DSA.

Vivien, this is going to cause us problems. We need two different
dsa_switch_driver structures, one for EDSA capable devices, and one
for those which are not.

Or we do something more radical, like add a driver callback to return
the tagging protocol, rather than hard code it in the structure? We
can then use a capability flag.

    Andrew

Hi Andrew,

Andrew Lunn [off-list ref] writes:

[Reducing the Cc: list a bit to networking people]

quoted

Okay. Frames sent from the port are EDSA-tagged (which isn't exactly
surprising), but I'm yet to see the switch receive 0xdada frames.
Even with the net-next branch which uses DSA_TAG_PROTO_EDSA for all
chip types.

However, the ethertype is reflecting the port:-

lan1/5 : ethertype Unknown (0xc028), length 176:
lan2/7 : ethertype Unknown (0xc038), length 176:
lan3/0 : ethertype Unknown (0xc000), length 176:
lan4/1 : ethertype Unknown (0xc008), length 176:
wan/2  : ethertype Unknown (0xc010), length 176:

O.K, we broke it :-(

The 6185 does not support EDSA, only DSA.

I'm wondering if EDSA could be simulated on 6185 (only) with the
CoreTagType register (0x19) and DoubleTag bit in Port Control (0x04)...

Or we do something more radical, like add a driver callback to return
the tagging protocol, rather than hard code it in the structure? We
can then use a capability flag.

The driver callback is the way to go. The supported tag format is
identifiable via the register layout. 6352 and newer have a 2-bit
FrameMode in Port Control (0x04), while 6185 has a single DSA_Tag bit.

A new switch operation can return the tag protocol enum, or an exposed
xmit/recv pair from net/dsa/tag_*.c, which must be used by the CPU.

Note: 88E6060 (which is likely to be supported by mv88e6xxx) has the
same issue and requires this, since it uses the Trailer tagging format.

Thanks,

        Vivien