[RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

Hello all,

I am making an attempt to create a device tree for D-Link DNS-323 devices
but I am falling short on a few specific details. I am requesting a
general review of the device tree files. I have access to DNS-323 rev A1
only and the B1 and C1 need to be tested separately, so I am reaching out
to people who might have them. The questions that I have at the moment are
below.

- some of resulting IRQs are different from what was requested in device tree
- logs say NR_IRQS is different from mach file one
- sata_mv fails to initialise with -22 (-EINVAL)
- there is no concensus on how to get ascii formatted MAC address from mtd
  partitions so eth is not fully functional without setting the MAC from
  userspace
- revs B1 and C1 need testing
- how to configure RTC to wake system from sleep?

What currently works in rev A1
 - leds
 - keys
 - fan
 - temperature sensor
 - shutdown
 - reboot
 - mtd partitions
 - ethernet (mac address must be set manually)

I have included relevant parts from boot log to better illustrate what seems
to be off target

-------------------------------- DT log ---------------------------------------
...
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
...
sata_mv 0000:00:01.0: Gen-IIE 32 slots 4 ports SCSI mode IRQ via INTx
sata_mv: probe of 0000:00:01.0 failed with error -22
...
mv64xxx_i2c mv64xxx_i2c.0: can't get pinctrl, bus recovery not supported
...
-------------------------------------------------------------------------------

Best regards,
Mauri

Mauri Sandberg (1):
  ARM: orion5x: convert D-Link DNS-323 to the Device Tree

 arch/arm/boot/dts/Makefile                   |   3 +
 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 217 ++++++
 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  59 ++
 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  38 +
 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  80 ++
 arch/arm/mach-orion5x/Kconfig                |   6 +-
 arch/arm/mach-orion5x/Makefile               |   2 +-
 arch/arm/mach-orion5x/board-dns323.c         | 118 +++
 arch/arm/mach-orion5x/board-dt.c             |   3 +
 arch/arm/mach-orion5x/common.h               |   6 +
 arch/arm/mach-orion5x/dns323-setup.c         | 724 -------------------
 11 files changed, 528 insertions(+), 728 deletions(-)
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
 create mode 100644 arch/arm/mach-orion5x/board-dns323.c
 delete mode 100644 arch/arm/mach-orion5x/dns323-setup.c


base-commit: 46cf2c613f4b10eb12f749207b0fd2c1bfae3088
--
2.25.1

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

[RFC RFT PATCH v1 1/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

Convert D-Link DNS-323 to use the device tree and remove associated
mach file.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
 arch/arm/boot/dts/Makefile                   |   3 +
 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 217 ++++++
 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  59 ++
 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  38 +
 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  80 ++
 arch/arm/mach-orion5x/Kconfig                |   6 +-
 arch/arm/mach-orion5x/Makefile               |   2 +-
 arch/arm/mach-orion5x/board-dns323.c         | 118 +++
 arch/arm/mach-orion5x/board-dt.c             |   3 +
 arch/arm/mach-orion5x/common.h               |   6 +
 arch/arm/mach-orion5x/dns323-setup.c         | 724 -------------------
 11 files changed, 528 insertions(+), 728 deletions(-)
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
 create mode 100644 arch/arm/mach-orion5x/board-dns323.c
 delete mode 100644 arch/arm/mach-orion5x/dns323-setup.c

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7c16f8a2b738..c7c5c0b6c843 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -949,6 +949,9 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
 	dra71-evm.dtb \
 	dra76-evm.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += \
+	orion5x-dlink-dns323a1.dtb \
+	orion5x-dlink-dns323b1.dtb \
+	orion5x-dlink-dns323c1.dtb \
 	orion5x-kuroboxpro.dtb \
 	orion5x-lacie-d2-network.dtb \
 	orion5x-lacie-ethernet-disk-mini-v2.dtb \
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
new file mode 100644
index 000000000000..2b033d37cbf8
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/ {
+	model = "D-Link DNS-323";
+	compatible = "dlink,dns323", "marvell,orion5x";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x4000000>; /* 64 MB */
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
+			 <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
+			 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x800000>;
+
+		/delete-node/ devbus-cs0;
+		/delete-node/ devbus-cs1;
+		/delete-node/ devbus-cs2;
+
+		internal-regs {
+			/delete-node/ dma-controller@60900;  /* xor */
+			/delete-node/ ehci@a0000;            /* ehci1 */
+			/delete-node/ serial@12100;          /* uart1 */
+			/delete-node/ spi@10600;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&pmx_gpio_keys>;
+		pinctrl-names = "default";
+
+		key-0 {
+			label = "Power button";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+		};
+
+		key-1 {
+			label = "Reset button";
+			linux,code = <KEY_RESTART>;
+			gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_gpio_leds>;
+		pinctrl-names = "default";
+
+		led-0 {
+			label = "amber:right";
+			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+		};
+
+		led-1 {
+			label = "amber:left";
+			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+
+		led-2 {
+			label = "blue:power";
+			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			default-state = "on";
+		};
+	};
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		pinctrl-0 = <&pmx_power_off>;
+		pinctrl-names = "default";
+
+		gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+		timeout-ms = <3000>;
+	};
+};
+
+&devbus_bootcs {
+	status = "okay";
+	devbus,keep-config;
+
+	flash@0 {
+		compatible = "cfi-flash";
+		reg = <0 0x800000>;
+		bank-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "MTD1";
+				reg = <0x000000 0x010000>;
+				read-only;
+			};
+
+			partition@10000 {
+				label = "MTD2";
+				reg = <0x010000 0x010000>;
+				read-only;
+			};
+
+			partition@20000 {
+				label = "Linux Kernel";
+				reg = <0x020000 0x180000>;
+			};
+
+			partition@1a0000 {
+				label = "File System";
+				reg = <0x1a0000 0x630000>;
+			};
+
+			uboot: partition@7d0000 {
+				label = "U-boot";
+				reg = <0x7d0000 0x030000>;
+				read-only;
+			};
+		};
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&i2c {
+	status = "okay";
+	clock-frequency = <100000>;
+
+	/* fan speed PWM */
+	fan@3e {
+		compatible = "g760a";
+		reg = <0x3e>;
+	};
+
+	/* temp sensor and thermal watchdog */
+	temperature-sensor@48 {
+		compatible = "gmt,g751";
+		reg = <0x48>;
+	};
+
+	/* RTC w/ alarm */
+	rtc@68 {
+		compatible = "st,m41t80";
+		reg = <0x68>;
+	};
+};
+
+&mdio {
+	status = "okay";
+
+	ethphy: ethernet-phy {
+		reg = <8>;
+	};
+};
+
+&eth {
+	status = "okay";
+	pinctrl-0 = <&pmx_ge>;
+	pinctrl-names = "default";
+};
+
+&ethport {
+	phy-handle = <&ethphy>;
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&pinctrl {
+	pmx_gpio_leds: pmx-gpio-leds {
+		marvell,pins = "mpp1", "mpp2", "mpp5";
+		marvell,function = "gpio";
+	};
+
+	pmx_gpio_misc: pmx-gpio-misc {
+		/* set marvell,pins in board file */
+		marvell,function = "gpio";
+	};
+
+	pmx_power_off: pmx-power-off {
+		marvell,pins = "mpp8";
+		marvell,function = "gpio";
+	};
+
+	pmx_gpio_keys: pmx-gpio-keys {
+		marvell,pins = "mpp9", "mpp10";
+		marvell,function = "gpio";
+	};
+
+	pmx_ge: pmx-ge {
+		marvell,function = "ge";
+	};
+};
+
+&sata {
+	pinctrl-0 = <&pmx_sata0 &pmx_sata1>;
+	pinctrl-names = "default";
+	status = "okay";
+	nr-ports = <2>;
+};
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323a1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
new file mode 100644
index 000000000000..73e7006ab5a7
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "orion5x-mv88f5181.dtsi"
+#include "orion5x-dlink-dns323.dtsi"
+
+/ {
+	compatible = "dlink,dns323a1", "dlink,dns323", "marvell,orion5x-88f5181",
+		     "marvell,orion5x";
+
+	/delete-node/ sa-sram;	/* crypto_sram */
+
+	soc {
+		internal-regs {
+			/delete-node/ crypto@90000;
+			/delete-node/ sata@80000;
+		};
+	};
+};
+
+&gpio0 {
+	pinctrl-0 = <&pmx_gpio_misc>;
+	pinctrl-names = "default";
+
+	/* The DNS323 rev A1 power LED requires GPIO 4 to be low. */
+	pin_gpio0_4 {
+		gpio-hog;
+		gpios = <4 GPIO_ACTIVE_LOW>;
+		output-high;
+		line-name = "Power led enable";
+	};
+};
+
+&pinctrl {
+	pinctrl-0 = <&pmx_pci_pins>;
+	pinctrl-names = "default";
+
+	pmx_pci_pins: pmx-pci-pins {
+		marvell,pins = "mpp0";
+		marvell,function = "pcie";
+	};
+};
+
+&pmx_gpio_misc {
+	marvell,pins = "mpp4";
+};
+
+&pmx_ge {
+	marvell,pins = "mpp11", "mpp12", "mpp13", "mpp14", "mpp15",
+		       "mpp16", "mpp17", "mpp18", "mpp19";
+};
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
new file mode 100644
index 000000000000..31251f64c573
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "orion5x-mv88f5182.dtsi"
+#include "orion5x-dlink-dns323.dtsi"
+
+/ {
+	compatible = "dlink,dns323b1", "dlink,dns323", "marvell,orion5x-88f5182",
+		     "marvell,orion5x";
+};
+
+&gpio0 {
+	pinctrl-0 = <&pmx_gpio_misc>;
+	pinctrl-names = "default";
+
+	/* The rev B1 has a flag to indicate the system is up.
+	 * Without this flag set, power LED will flash and cannot be
+	 * controlled via gpio-leds.
+	 */
+	pin_gpio0_3 {
+		gpio-hog;
+		gpios = <3 GPIO_ACTIVE_LOW>;
+		output-high;
+		line-name = "System up";
+	};
+};
+
+&pmx_gpio_misc {
+	marvell,pins = "mpp3";
+};
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323c1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
new file mode 100644
index 000000000000..c36af513ecd7
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "orion5x-mv88f5182.dtsi"
+#include "orion5x-dlink-dns323.dtsi"
+
+/ {
+	compatible = "dlink,dns323c1", "dlink,dns323", "marvell,orion5x-88f5182",
+		     "marvell,orion5x";
+
+	fan {
+		compatible = "gpio-fan";
+		pinctrl-0 = <&pmx_gpio_fan>;
+		pinctrl-names = "default";
+
+		gpios = <&gpio0 19 GPIO_ACTIVE_LOW
+			 &gpio0 18 GPIO_ACTIVE_LOW>;
+
+		gpio-fan,speed-map = <0    0
+				      1000 1
+				      2000 2>;
+		alarm-gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
+	};
+
+	gpio-keys {
+		/delete-node/ key-1;
+
+		key-0 {
+			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-leds {
+		led-0 {
+			gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
+		};
+
+		led-1 {
+			gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+		};
+
+		led-2 {
+			gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
+
+&i2c {
+	/delete-node/ fan@3e;
+};
+
+&pinctrl {
+	/delete-node/ pmx-gpio-misc;
+
+	pmx_gpio_fan: pmx-gpio-fan {
+		marvell,pins = "mpp10", "mpp18", "mpp19";
+		marvell,function = "gpio";
+	};
+};
+
+&pmx_gpio_leds {
+	marvell,pins = "mpp8", "mpp9", "mpp17";
+};
+
+&pmx_power_off {
+	marvell,pins = "mpp2";
+};
+
+&pmx_gpio_keys {
+	marvell,pins = "mpp1";
+};
diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index c77f3b4e287b..65cd5307a460 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -55,9 +55,9 @@ config MACH_KUROBOX_PRO
 	  Say 'Y' here if you want your kernel to support the
 	  KuroBox Pro platform.
 
-config MACH_DNS323
-	bool "D-Link DNS-323"
-	select I2C_BOARDINFO if I2C
+config MACH_DNS323_DT
+	bool "D-Link DNS-323 (Flattened Device Tree)"
+	select ARCH_ORION5X_DT
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  D-Link DNS-323 platform.
diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
index 1a585a62d5e6..b8c0671fbd1c 100644
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion5x/Makefile
@@ -8,7 +8,6 @@ obj-$(CONFIG_MACH_KUROBOX_PRO)	+= kurobox_pro-setup.o
 obj-$(CONFIG_MACH_TERASTATION_PRO2)	+= terastation_pro2-setup.o
 obj-$(CONFIG_MACH_LINKSTATION_PRO) += kurobox_pro-setup.o
 obj-$(CONFIG_MACH_LINKSTATION_LS_HGL) += ls_hgl-setup.o
-obj-$(CONFIG_MACH_DNS323)	+= dns323-setup.o
 obj-$(CONFIG_MACH_TS209)	+= ts209-setup.o tsx09-common.o
 obj-$(CONFIG_MACH_TS409)	+= ts409-setup.o tsx09-common.o
 obj-$(CONFIG_MACH_WRT350N_V2)	+= wrt350n-v2-setup.o
@@ -22,5 +21,6 @@ obj-$(CONFIG_MACH_RD88F6183AP_GE)	+= rd88f6183ap-ge-setup.o
 
 obj-$(CONFIG_ARCH_ORION5X_DT)		+= board-dt.o
 obj-$(CONFIG_MACH_D2NET_DT)	+= board-d2net.o
+obj-$(CONFIG_MACH_DNS323_DT)	+= board-dns323.o
 obj-$(CONFIG_MACH_MSS2_DT)	+= board-mss2.o
 obj-$(CONFIG_MACH_RD88F5182_DT)	+= board-rd88f5182.o
diff --git a/arch/arm/mach-orion5x/board-dns323.c b/arch/arm/mach-orion5x/board-dns323.c
new file mode 100644
index 000000000000..705ddb7b691a
--- /dev/null
+++ b/arch/arm/mach-orion5x/board-dns323.c
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ * Flattened Device Tree board initialization
+ *
+ * This is adapted from existing mach file and most of the source code is
+ * originally written by:
+ *  Copyright (C) 2007 Herbert Valerio Riedel <hvr@gnu.org>
+ *  Copyright (C) 2010 Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ */
+
+#include <linux/of.h>
+#include <linux/phy.h>
+#include <linux/marvell_phy.h>
+#include <asm/mach/pci.h>
+#include "bridge-regs.h"
+#include "common.h"
+
+/* Rev A1 and B1 */
+#define DNS323_GPIO_LED_RIGHT_AMBER	1
+#define DNS323_GPIO_LED_LEFT_AMBER	2
+#define DNS323_GPIO_SYSTEM_UP		3
+#define DNS323_GPIO_LED_POWER1		4
+#define DNS323_GPIO_LED_POWER2		5
+#define DNS323_GPIO_OVERTEMP		6
+#define DNS323_GPIO_RTC			7
+#define DNS323_GPIO_POWER_OFF		8
+#define DNS323_GPIO_KEY_POWER		9
+#define DNS323_GPIO_KEY_RESET		10
+
+/* Rev C1 */
+#define DNS323C_GPIO_KEY_POWER		1
+#define DNS323C_GPIO_POWER_OFF		2
+#define DNS323C_GPIO_LED_RIGHT_AMBER	8
+#define DNS323C_GPIO_LED_LEFT_AMBER	9
+#define DNS323C_GPIO_LED_POWER		17
+#define DNS323C_GPIO_FAN_BIT1		18
+#define DNS323C_GPIO_FAN_BIT0		19
+
+/* Exposed to userspace, do not change */
+enum {
+	DNS323_REV_A1,	/* 0 */
+	DNS323_REV_B1,	/* 1 */
+	DNS323_REV_C1,	/* 2 */
+};
+
+/****************************************************************************
+ * PCI setup
+ */
+
+static int __init dns323_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;
+
+	return -1;
+}
+
+static struct hw_pci dns323_pci __initdata = {
+	.nr_controllers = 2,
+	.setup		= orion5x_pci_sys_setup,
+	.scan		= orion5x_pci_sys_scan_bus,
+	.map_irq	= dns323_pci_map_irq,
+};
+
+static int __init dns323_pci_init(void)
+{
+	/* Rev B1 and C1 doesn't really use its PCI bus, and
+	 * initialising PCI gets in the way of initialising the SATA
+	 * controller.
+	 */
+	if (of_machine_is_compatible("dlink,dns323a1"))
+		pci_common_init(&dns323_pci);
+
+	return 0;
+}
+subsys_initcall(dns323_pci_init);
+
+/****************************************************************************
+ * Fix-ups
+ */
+
+static int dns323c_phy_fixup(struct phy_device *phy)
+{
+	phy->dev_flags |= MARVELL_PHY_M1118_DNS323_LEDS;
+
+	return 0;
+}
+
+void __init dns323_init(void)
+{
+	if (of_machine_is_compatible("dlink,dns323a1")) {
+		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
+	} else if (of_machine_is_compatible("dlink,dns323c1") &&
+		IS_BUILTIN(CONFIG_PHYLIB)) {
+		/* Register fixup for the PHY LEDs */
+		phy_register_fixup_for_uid(MARVELL_PHY_ID_88E1118,
+					   MARVELL_PHY_ID_MASK,
+					   dns323c_phy_fixup);
+
+		/* Now, -this- should theorically be done by the sata_mv driver
+		 * once I figure out what's going on there. Maybe the behaviour
+		 * of the LEDs should be somewhat passed via the platform_data.
+		 * for now, just whack the register and make the LEDs happy
+		 *
+		 * Note: AFAIK, rev B1 needs the same treatement but I'll let
+		 * somebody else test it.
+		 */
+		writel(0x5, ORION5X_SATA_VIRT_BASE + 0x2c);
+	}
+}
diff --git a/arch/arm/mach-orion5x/board-dt.c b/arch/arm/mach-orion5x/board-dt.c
index 3d36f1d95196..279194483fcf 100644
--- a/arch/arm/mach-orion5x/board-dt.c
+++ b/arch/arm/mach-orion5x/board-dt.c
@@ -60,6 +60,9 @@ static void __init orion5x_dt_init(void)
 		cpu_idle_poll_ctrl(true);
 	}
 
+	if (of_machine_is_compatible("dlink,dns323"))
+		dns323_init();
+
 	if (of_machine_is_compatible("maxtor,shared-storage-2"))
 		mss2_init();
 
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index eb96009e21c4..ac92b67bf9ec 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -75,6 +75,12 @@ extern void mss2_init(void);
 static inline void mss2_init(void) {}
 #endif
 
+#ifdef CONFIG_MACH_DNS323_DT
+extern void dns323_init(void);
+#else
+static inline void dns323_init(void) {}
+#endif
+
 /*****************************************************************************
  * Helpers to access Orion registers
  ****************************************************************************/
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion5x/dns323-setup.c
deleted file mode 100644
index 87cb47220e82..000000000000
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ /dev/null
@@ -1,724 +0,0 @@
-/*
- * arch/arm/mach-orion5x/dns323-setup.c
- *
- * Copyright (C) 2007 Herbert Valerio Riedel <hvr@gnu.org>
- *
- * Support for HW Rev C1:
- *
- * Copyright (C) 2010 Benjamin Herrenschmidt <benh@kernel.crashing.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU Lesser General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- */
-#include <linux/gpio.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/delay.h>
-#include <linux/platform_device.h>
-#include <linux/pci.h>
-#include <linux/irq.h>
-#include <linux/mtd/physmap.h>
-#include <linux/mv643xx_eth.h>
-#include <linux/leds.h>
-#include <linux/gpio_keys.h>
-#include <linux/input.h>
-#include <linux/i2c.h>
-#include <linux/ata_platform.h>
-#include <linux/phy.h>
-#include <linux/marvell_phy.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <asm/mach/pci.h>
-#include <asm/system_info.h>
-#include <plat/orion-gpio.h>
-#include "orion5x.h"
-#include "common.h"
-#include "mpp.h"
-
-/* Rev A1 and B1 */
-#define DNS323_GPIO_LED_RIGHT_AMBER	1
-#define DNS323_GPIO_LED_LEFT_AMBER	2
-#define DNS323_GPIO_SYSTEM_UP		3
-#define DNS323_GPIO_LED_POWER1		4
-#define DNS323_GPIO_LED_POWER2		5
-#define DNS323_GPIO_OVERTEMP		6
-#define DNS323_GPIO_RTC			7
-#define DNS323_GPIO_POWER_OFF		8
-#define DNS323_GPIO_KEY_POWER		9
-#define DNS323_GPIO_KEY_RESET		10
-
-/* Rev C1 */
-#define DNS323C_GPIO_KEY_POWER		1
-#define DNS323C_GPIO_POWER_OFF		2
-#define DNS323C_GPIO_LED_RIGHT_AMBER	8
-#define DNS323C_GPIO_LED_LEFT_AMBER	9
-#define DNS323C_GPIO_LED_POWER		17
-#define DNS323C_GPIO_FAN_BIT1		18
-#define DNS323C_GPIO_FAN_BIT0		19
-
-/* Exposed to userspace, do not change */
-enum {
-	DNS323_REV_A1,	/* 0 */
-	DNS323_REV_B1,	/* 1 */
-	DNS323_REV_C1,	/* 2 */
-};
-
-
-/****************************************************************************
- * PCI setup
- */
-
-static int __init dns323_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;
-
-	return -1;
-}
-
-static struct hw_pci dns323_pci __initdata = {
-	.nr_controllers = 2,
-	.setup		= orion5x_pci_sys_setup,
-	.scan		= orion5x_pci_sys_scan_bus,
-	.map_irq	= dns323_pci_map_irq,
-};
-
-static int __init dns323_pci_init(void)
-{
-	/* Rev B1 and C1 doesn't really use its PCI bus, and initialising PCI
-	 * gets in the way of initialising the SATA controller.
-	 */
-	if (machine_is_dns323() && system_rev == DNS323_REV_A1)
-		pci_common_init(&dns323_pci);
-
-	return 0;
-}
-
-subsys_initcall(dns323_pci_init);
-
-/****************************************************************************
- * 8MiB NOR flash (Spansion S29GL064M90TFIR4)
- *
- * Layout as used by D-Link:
- *  0x00000000-0x00010000 : "MTD1"
- *  0x00010000-0x00020000 : "MTD2"
- *  0x00020000-0x001a0000 : "Linux Kernel"
- *  0x001a0000-0x007d0000 : "File System"
- *  0x007d0000-0x00800000 : "u-boot"
- */
-
-#define DNS323_NOR_BOOT_BASE 0xf4000000
-#define DNS323_NOR_BOOT_SIZE SZ_8M
-
-static struct mtd_partition dns323_partitions[] = {
-	{
-		.name	= "MTD1",
-		.size	= 0x00010000,
-		.offset	= 0,
-	}, {
-		.name	= "MTD2",
-		.size	= 0x00010000,
-		.offset = 0x00010000,
-	}, {
-		.name	= "Linux Kernel",
-		.size	= 0x00180000,
-		.offset	= 0x00020000,
-	}, {
-		.name	= "File System",
-		.size	= 0x00630000,
-		.offset	= 0x001A0000,
-	}, {
-		.name	= "u-boot",
-		.size	= 0x00030000,
-		.offset	= 0x007d0000,
-	},
-};
-
-static struct physmap_flash_data dns323_nor_flash_data = {
-	.width		= 1,
-	.parts		= dns323_partitions,
-	.nr_parts	= ARRAY_SIZE(dns323_partitions)
-};
-
-static struct resource dns323_nor_flash_resource = {
-	.flags		= IORESOURCE_MEM,
-	.start		= DNS323_NOR_BOOT_BASE,
-	.end		= DNS323_NOR_BOOT_BASE + DNS323_NOR_BOOT_SIZE - 1,
-};
-
-static struct platform_device dns323_nor_flash = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &dns323_nor_flash_data,
-	},
-	.resource	= &dns323_nor_flash_resource,
-	.num_resources	= 1,
-};
-
-/****************************************************************************
- * Ethernet
- */
-
-static struct mv643xx_eth_platform_data dns323_eth_data = {
-	.phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
-/* dns323_parse_hex_*() taken from tsx09-common.c; should a common copy of these
- * functions be kept somewhere?
- */
-static int __init dns323_parse_hex_nibble(char n)
-{
-	if (n >= '0' && n <= '9')
-		return n - '0';
-
-	if (n >= 'A' && n <= 'F')
-		return n - 'A' + 10;
-
-	if (n >= 'a' && n <= 'f')
-		return n - 'a' + 10;
-
-	return -1;
-}
-
-static int __init dns323_parse_hex_byte(const char *b)
-{
-	int hi;
-	int lo;
-
-	hi = dns323_parse_hex_nibble(b[0]);
-	lo = dns323_parse_hex_nibble(b[1]);
-
-	if (hi < 0 || lo < 0)
-		return -1;
-
-	return (hi << 4) | lo;
-}
-
-static int __init dns323_read_mac_addr(void)
-{
-	u_int8_t addr[6];
-	int i;
-	char *mac_page;
-
-	/* MAC address is stored as a regular ol' string in /dev/mtdblock4
-	 * (0x007d0000-0x00800000) starting at offset 196480 (0x2ff80).
-	 */
-	mac_page = ioremap(DNS323_NOR_BOOT_BASE + 0x7d0000 + 196480, 1024);
-	if (!mac_page)
-		return -ENOMEM;
-
-	/* Sanity check the string we're looking at */
-	for (i = 0; i < 5; i++) {
-		if (*(mac_page + (i * 3) + 2) != ':') {
-			goto error_fail;
-		}
-	}
-
-	for (i = 0; i < 6; i++)	{
-		int byte;
-
-		byte = dns323_parse_hex_byte(mac_page + (i * 3));
-		if (byte < 0) {
-			goto error_fail;
-		}
-
-		addr[i] = byte;
-	}
-
-	iounmap(mac_page);
-	printk("DNS-323: Found ethernet MAC address: %pM\n", addr);
-
-	memcpy(dns323_eth_data.mac_addr, addr, 6);
-
-	return 0;
-
-error_fail:
-	iounmap(mac_page);
-	return -EINVAL;
-}
-
-/****************************************************************************
- * GPIO LEDs (simple - doesn't use hardware blinking support)
- */
-
-static struct gpio_led dns323ab_leds[] = {
-	{
-		.name = "power:blue",
-		.gpio = DNS323_GPIO_LED_POWER2,
-		.default_trigger = "default-on",
-	}, {
-		.name = "right:amber",
-		.gpio = DNS323_GPIO_LED_RIGHT_AMBER,
-		.active_low = 1,
-	}, {
-		.name = "left:amber",
-		.gpio = DNS323_GPIO_LED_LEFT_AMBER,
-		.active_low = 1,
-	},
-};
-
-
-static struct gpio_led dns323c_leds[] = {
-	{
-		.name = "power:blue",
-		.gpio = DNS323C_GPIO_LED_POWER,
-		.default_trigger = "timer",
-		.active_low = 1,
-	}, {
-		.name = "right:amber",
-		.gpio = DNS323C_GPIO_LED_RIGHT_AMBER,
-		.active_low = 1,
-	}, {
-		.name = "left:amber",
-		.gpio = DNS323C_GPIO_LED_LEFT_AMBER,
-		.active_low = 1,
-	},
-};
-
-
-static struct gpio_led_platform_data dns323ab_led_data = {
-	.num_leds	= ARRAY_SIZE(dns323ab_leds),
-	.leds		= dns323ab_leds,
-	.gpio_blink_set = orion_gpio_led_blink_set,
-};
-
-static struct gpio_led_platform_data dns323c_led_data = {
-	.num_leds	= ARRAY_SIZE(dns323c_leds),
-	.leds		= dns323c_leds,
-	.gpio_blink_set = orion_gpio_led_blink_set,
-};
-
-static struct platform_device dns323_gpio_leds = {
-	.name		= "leds-gpio",
-	.id		= -1,
-	.dev		= {
-		.platform_data	= &dns323ab_led_data,
-	},
-};
-
-/****************************************************************************
- * GPIO Attached Keys
- */
-
-static struct gpio_keys_button dns323ab_buttons[] = {
-	{
-		.code		= KEY_RESTART,
-		.gpio		= DNS323_GPIO_KEY_RESET,
-		.desc		= "Reset Button",
-		.active_low	= 1,
-	}, {
-		.code		= KEY_POWER,
-		.gpio		= DNS323_GPIO_KEY_POWER,
-		.desc		= "Power Button",
-		.active_low	= 1,
-	},
-};
-
-static struct gpio_keys_platform_data dns323ab_button_data = {
-	.buttons	= dns323ab_buttons,
-	.nbuttons	= ARRAY_SIZE(dns323ab_buttons),
-};
-
-static struct gpio_keys_button dns323c_buttons[] = {
-	{
-		.code		= KEY_POWER,
-		.gpio		= DNS323C_GPIO_KEY_POWER,
-		.desc		= "Power Button",
-		.active_low	= 1,
-	},
-};
-
-static struct gpio_keys_platform_data dns323c_button_data = {
-	.buttons	= dns323c_buttons,
-	.nbuttons	= ARRAY_SIZE(dns323c_buttons),
-};
-
-static struct platform_device dns323_button_device = {
-	.name		= "gpio-keys",
-	.id		= -1,
-	.num_resources	= 0,
-	.dev		= {
-		.platform_data	= &dns323ab_button_data,
-	},
-};
-
-/*****************************************************************************
- * SATA
- */
-static struct mv_sata_platform_data dns323_sata_data = {
-       .n_ports        = 2,
-};
-
-/****************************************************************************
- * General Setup
- */
-static unsigned int dns323a_mpp_modes[] __initdata = {
-	MPP0_PCIE_RST_OUTn,
-	MPP1_GPIO,		/* right amber LED (sata ch0) */
-	MPP2_GPIO,		/* left amber LED (sata ch1) */
-	MPP3_UNUSED,
-	MPP4_GPIO,		/* power button LED */
-	MPP5_GPIO,		/* power button LED */
-	MPP6_GPIO,		/* GMT G751-2f overtemp */
-	MPP7_GPIO,		/* M41T80 nIRQ/OUT/SQW */
-	MPP8_GPIO,		/* triggers power off */
-	MPP9_GPIO,		/* power button switch */
-	MPP10_GPIO,		/* reset button switch */
-	MPP11_UNUSED,
-	MPP12_UNUSED,
-	MPP13_UNUSED,
-	MPP14_UNUSED,
-	MPP15_UNUSED,
-	MPP16_UNUSED,
-	MPP17_UNUSED,
-	MPP18_UNUSED,
-	MPP19_UNUSED,
-	0,
-};
-
-static unsigned int dns323b_mpp_modes[] __initdata = {
-	MPP0_UNUSED,
-	MPP1_GPIO,		/* right amber LED (sata ch0) */
-	MPP2_GPIO,		/* left amber LED (sata ch1) */
-	MPP3_GPIO,		/* system up flag */
-	MPP4_GPIO,		/* power button LED */
-	MPP5_GPIO,		/* power button LED */
-	MPP6_GPIO,		/* GMT G751-2f overtemp */
-	MPP7_GPIO,		/* M41T80 nIRQ/OUT/SQW */
-	MPP8_GPIO,		/* triggers power off */
-	MPP9_GPIO,		/* power button switch */
-	MPP10_GPIO,		/* reset button switch */
-	MPP11_UNUSED,
-	MPP12_SATA_LED,
-	MPP13_SATA_LED,
-	MPP14_SATA_LED,
-	MPP15_SATA_LED,
-	MPP16_UNUSED,
-	MPP17_UNUSED,
-	MPP18_UNUSED,
-	MPP19_UNUSED,
-	0,
-};
-
-static unsigned int dns323c_mpp_modes[] __initdata = {
-	MPP0_GPIO,		/* ? input */
-	MPP1_GPIO,		/* input power switch (0 = pressed) */
-	MPP2_GPIO,		/* output power off */
-	MPP3_UNUSED,		/* ? output */
-	MPP4_UNUSED,		/* ? output */
-	MPP5_UNUSED,		/* ? output */
-	MPP6_UNUSED,		/* ? output */
-	MPP7_UNUSED,		/* ? output */
-	MPP8_GPIO,		/* i/o right amber LED */
-	MPP9_GPIO,		/* i/o left amber LED */
-	MPP10_GPIO,		/* input */
-	MPP11_UNUSED,
-	MPP12_SATA_LED,
-	MPP13_SATA_LED,
-	MPP14_SATA_LED,
-	MPP15_SATA_LED,
-	MPP16_UNUSED,
-	MPP17_GPIO,		/* power button LED */
-	MPP18_GPIO,		/* fan speed bit 0 */
-	MPP19_GPIO,		/* fan speed bit 1 */
-	0,
-};
-
-/* Rev C1 Fan speed notes:
- *
- * The fan is controlled by 2 GPIOs on this board. The settings
- * of the bits is as follow:
- *
- *  GPIO 18    GPIO 19    Fan
- *
- *    0          0        stopped
- *    0          1        low speed
- *    1          0        high speed
- *    1          1        don't do that (*)
- *
- * (*) I think the two bits control two feed-in resistors into a fixed
- *     PWN circuit, setting both bits will basically go a 'bit' faster
- *     than high speed, but d-link doesn't do it and you may get out of
- *     HW spec so don't do it.
- */
-
-/*
- * On the DNS-323 A1 and B1 the following devices are attached via I2C:
- *
- *  i2c addr | chip        | description
- *  0x3e     | GMT G760Af  | fan speed PWM controller
- *  0x48     | GMT G751-2f | temp. sensor and therm. watchdog (LM75 compatible)
- *  0x68     | ST M41T80   | RTC w/ alarm
- */
-static struct i2c_board_info __initdata dns323ab_i2c_devices[] = {
-	{
-		I2C_BOARD_INFO("g760a", 0x3e),
-	}, {
-		I2C_BOARD_INFO("lm75", 0x48),
-	}, {
-		I2C_BOARD_INFO("m41t80", 0x68),
-	},
-};
-
-/*
- * On the DNS-323 C1 the following devices are attached via I2C:
- *
- *  i2c addr | chip        | description
- *  0x48     | GMT G751-2f | temp. sensor and therm. watchdog (LM75 compatible)
- *  0x68     | ST M41T80   | RTC w/ alarm
- */
-static struct i2c_board_info __initdata dns323c_i2c_devices[] = {
-	{
-		I2C_BOARD_INFO("lm75", 0x48),
-	}, {
-		I2C_BOARD_INFO("m41t80", 0x68),
-	},
-};
-
-/* DNS-323 rev. A specific power off method */
-static void dns323a_power_off(void)
-{
-	pr_info("DNS-323: Triggering power-off...\n");
-	gpio_set_value(DNS323_GPIO_POWER_OFF, 1);
-}
-
-/* DNS-323 rev B specific power off method */
-static void dns323b_power_off(void)
-{
-	pr_info("DNS-323: Triggering power-off...\n");
-	/* Pin has to be changed to 1 and back to 0 to do actual power off. */
-	gpio_set_value(DNS323_GPIO_POWER_OFF, 1);
-	mdelay(100);
-	gpio_set_value(DNS323_GPIO_POWER_OFF, 0);
-}
-
-/* DNS-323 rev. C specific power off method */
-static void dns323c_power_off(void)
-{
-	pr_info("DNS-323: Triggering power-off...\n");
-	gpio_set_value(DNS323C_GPIO_POWER_OFF, 1);
-}
-
-static int dns323c_phy_fixup(struct phy_device *phy)
-{
-	phy->dev_flags |= MARVELL_PHY_M1118_DNS323_LEDS;
-
-	return 0;
-}
-
-static int __init dns323_identify_rev(void)
-{
-	u32 dev, rev, i, reg;
-
-	pr_debug("DNS-323: Identifying board ... \n");
-
-	/* Rev A1 has a 5181 */
-	orion5x_pcie_id(&dev, &rev);
-	if (dev == MV88F5181_DEV_ID) {
-		pr_debug("DNS-323: 5181 found, board is A1\n");
-		return DNS323_REV_A1;
-	}
-	pr_debug("DNS-323: 5182 found, board is B1 or C1, checking PHY...\n");
-
-	/* Rev B1 and C1 both have 5182, let's poke at the eth PHY. This is
-	 * a bit gross but we want to do that without links into the eth
-	 * driver so let's poke at it directly. We default to rev B1 in
-	 * case the accesses fail
-	 */
-
-#define ETH_SMI_REG		(ORION5X_ETH_VIRT_BASE + 0x2000 + 0x004)
-#define  SMI_BUSY		0x10000000
-#define  SMI_READ_VALID		0x08000000
-#define  SMI_OPCODE_READ	0x04000000
-#define  SMI_OPCODE_WRITE	0x00000000
-
-	for (i = 0; i < 1000; i++) {
-		reg = readl(ETH_SMI_REG);
-		if (!(reg & SMI_BUSY))
-			break;
-	}
-	if (i >= 1000) {
-		pr_warn("DNS-323: Timeout accessing PHY, assuming rev B1\n");
-		return DNS323_REV_B1;
-	}
-	writel((3 << 21)	/* phy ID reg */ |
-	       (8 << 16)	/* phy addr */ |
-	       SMI_OPCODE_READ, ETH_SMI_REG);
-	for (i = 0; i < 1000; i++) {
-		reg = readl(ETH_SMI_REG);
-		if (reg & SMI_READ_VALID)
-			break;
-	}
-	if (i >= 1000) {
-		pr_warn("DNS-323: Timeout reading PHY, assuming rev B1\n");
-		return DNS323_REV_B1;
-	}
-	pr_debug("DNS-323: Ethernet PHY ID 0x%x\n", reg & 0xffff);
-
-	/* Note: the Marvell tools mask the ID with 0x3f0 before comparison
-	 * but I don't see that making a difference here, at least with
-	 * any known Marvell PHY ID
-	 */
-	switch(reg & 0xfff0) {
-	case 0x0cc0: /* MV88E1111 */
-		return DNS323_REV_B1;
-	case 0x0e10: /* MV88E1118 */
-		return DNS323_REV_C1;
-	default:
-		pr_warn("DNS-323: Unknown PHY ID 0x%04x, assuming rev B1\n",
-			reg & 0xffff);
-	}
-	return DNS323_REV_B1;
-}
-
-static void __init dns323_init(void)
-{
-	/* Setup basic Orion functions. Need to be called early. */
-	orion5x_init();
-
-	/* Identify revision */
-	system_rev = dns323_identify_rev();
-	pr_info("DNS-323: Identified HW revision %c1\n", 'A' + system_rev);
-
-	/* Just to be tricky, the 5182 has a completely different
-	 * set of MPP modes to the 5181.
-	 */
-	switch(system_rev) {
-	case DNS323_REV_A1:
-		orion5x_mpp_conf(dns323a_mpp_modes);
-		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
-		break;
-	case DNS323_REV_B1:
-		orion5x_mpp_conf(dns323b_mpp_modes);
-		break;
-	case DNS323_REV_C1:
-		orion5x_mpp_conf(dns323c_mpp_modes);
-		break;
-	}
-
-	/* setup flash mapping
-	 * CS3 holds a 8 MB Spansion S29GL064M90TFIR4
-	 */
-	mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
-				    ORION_MBUS_DEVBUS_BOOT_ATTR,
-				    DNS323_NOR_BOOT_BASE,
-				    DNS323_NOR_BOOT_SIZE);
-	platform_device_register(&dns323_nor_flash);
-
-	/* Sort out LEDs, Buttons and i2c devices */
-	switch(system_rev) {
-	case DNS323_REV_A1:
-		/* The 5181 power LED is active low and requires
-		 * DNS323_GPIO_LED_POWER1 to also be low.
-		 */
-		 dns323ab_leds[0].active_low = 1;
-		 gpio_request(DNS323_GPIO_LED_POWER1, "Power Led Enable");
-		 gpio_direction_output(DNS323_GPIO_LED_POWER1, 0);
-		fallthrough;
-	case DNS323_REV_B1:
-		i2c_register_board_info(0, dns323ab_i2c_devices,
-				ARRAY_SIZE(dns323ab_i2c_devices));
-		break;
-	case DNS323_REV_C1:
-		/* Hookup LEDs & Buttons */
-		dns323_gpio_leds.dev.platform_data = &dns323c_led_data;
-		dns323_button_device.dev.platform_data = &dns323c_button_data;
-
-		/* Hookup i2c devices and fan driver */
-		i2c_register_board_info(0, dns323c_i2c_devices,
-				ARRAY_SIZE(dns323c_i2c_devices));
-		platform_device_register_simple("dns323c-fan", 0, NULL, 0);
-
-		/* Register fixup for the PHY LEDs */
-		if (!IS_BUILTIN(CONFIG_PHYLIB))
-			break;
-		phy_register_fixup_for_uid(MARVELL_PHY_ID_88E1118,
-					   MARVELL_PHY_ID_MASK,
-					   dns323c_phy_fixup);
-	}
-
-	platform_device_register(&dns323_gpio_leds);
-	platform_device_register(&dns323_button_device);
-
-	/*
-	 * Configure peripherals.
-	 */
-	if (dns323_read_mac_addr() < 0)
-		printk("DNS-323: Failed to read MAC address\n");
-	orion5x_ehci0_init();
-	orion5x_eth_init(&dns323_eth_data);
-	orion5x_i2c_init();
-	orion5x_uart0_init();
-
-	/* Remaining GPIOs */
-	switch(system_rev) {
-	case DNS323_REV_A1:
-		/* Poweroff GPIO */
-		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
-		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
-			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323a_power_off;
-		break;
-	case DNS323_REV_B1:
-		/* 5182 built-in SATA init */
-		orion5x_sata_init(&dns323_sata_data);
-
-		/* The DNS323 rev B1 has flag to indicate the system is up.
-		 * Without this flag set, power LED will flash and cannot be
-		 * controlled via leds-gpio.
-		 */
-		if (gpio_request(DNS323_GPIO_SYSTEM_UP, "SYS_READY") == 0)
-			gpio_direction_output(DNS323_GPIO_SYSTEM_UP, 1);
-
-		/* Poweroff GPIO */
-		if (gpio_request(DNS323_GPIO_POWER_OFF, "POWEROFF") != 0 ||
-		    gpio_direction_output(DNS323_GPIO_POWER_OFF, 0) != 0)
-			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323b_power_off;
-		break;
-	case DNS323_REV_C1:
-		/* 5182 built-in SATA init */
-		orion5x_sata_init(&dns323_sata_data);
-
-		/* Poweroff GPIO */
-		if (gpio_request(DNS323C_GPIO_POWER_OFF, "POWEROFF") != 0 ||
-		    gpio_direction_output(DNS323C_GPIO_POWER_OFF, 0) != 0)
-			pr_err("DNS-323: failed to setup power-off GPIO\n");
-		pm_power_off = dns323c_power_off;
-
-		/* Now, -this- should theorically be done by the sata_mv driver
-		 * once I figure out what's going on there. Maybe the behaviour
-		 * of the LEDs should be somewhat passed via the platform_data.
-		 * for now, just whack the register and make the LEDs happy
-		 *
-		 * Note: AFAIK, rev B1 needs the same treatement but I'll let
-		 * somebody else test it.
-		 */
-		writel(0x5, ORION5X_SATA_VIRT_BASE + 0x2c);
-		break;
-	}
-}
-
-/* Warning: D-Link uses a wrong mach-type (=526) in their bootloader */
-MACHINE_START(DNS323, "D-Link DNS-323")
-	/* Maintainer: Herbert Valerio Riedel <hvr@gnu.org> */
-	.atag_offset	= 0x100,
-	.nr_irqs	= ORION5X_NR_IRQS,
-	.init_machine	= dns323_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.25.1


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

Re: [RFC RFT PATCH v1 1/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> Convert D-Link DNS-323 to use the device tree and remove associated
> mach file.
>
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> ---
>  arch/arm/boot/dts/Makefile                   |   3 +
>  arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 217 ++++++
>  arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  59 ++
>  arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  38 +
>  arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  80 ++
>  arch/arm/mach-orion5x/Kconfig                |   6 +-
>  arch/arm/mach-orion5x/Makefile               |   2 +-
>  arch/arm/mach-orion5x/board-dns323.c         | 118 +++
>  arch/arm/mach-orion5x/board-dt.c             |   3 +
>  arch/arm/mach-orion5x/common.h               |   6 +
>  arch/arm/mach-orion5x/dns323-setup.c         | 724 -------------------
>  11 files changed, 528 insertions(+), 728 deletions(-)
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
>  create mode 100644 arch/arm/mach-orion5x/board-dns323.c
>  delete mode 100644 arch/arm/mach-orion5x/dns323-setup.c

Having the combined patch is generally fine for review, but for actually
merging it, I would prefer splitting the new DT from the code removal,
as I send these through different trees to Linus.

       Arnd

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

Re: [RFC RFT PATCH v1 1/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

On 27.4.2022 21.12, Arnd Bergmann wrote:
> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>
>> Convert D-Link DNS-323 to use the device tree and remove associated
>> mach file.
>>
>> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
>> ---
>>   arch/arm/boot/dts/Makefile                   |   3 +
>>   arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 217 ++++++
>>   arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  59 ++
>>   arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  38 +
>>   arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  80 ++
>>   arch/arm/mach-orion5x/Kconfig                |   6 +-
>>   arch/arm/mach-orion5x/Makefile               |   2 +-
>>   arch/arm/mach-orion5x/board-dns323.c         | 118 +++
>>   arch/arm/mach-orion5x/board-dt.c             |   3 +
>>   arch/arm/mach-orion5x/common.h               |   6 +
>>   arch/arm/mach-orion5x/dns323-setup.c         | 724 -------------------
>>   11 files changed, 528 insertions(+), 728 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
>>   create mode 100644 arch/arm/mach-orion5x/board-dns323.c
>>   delete mode 100644 arch/arm/mach-orion5x/dns323-setup.c
> 
> Having the combined patch is generally fine for review, but for actually
> merging it, I would prefer splitting the new DT from the code removal,
> as I send these through different trees to Linus.

You know, I had them initially in separate patches but then I looked at 
the existing commit history and at least a few ones were in a single 
commit so I merged them. :)

Will split this in two in the next iteration.


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

Re: [RFC RFT PATCH v1 1/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Thu, Apr 28, 2022 at 10:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> You know, I had them initially in separate patches but then I looked at
> the existing commit history and at least a few ones were in a single
> commit so I merged them. :)

Just for context, we sometimes do a mass-conversion in a separate branch
when there are a lot of changes that touch both DT and source files.

If you only do a single board, I would not make that a separate top-level
pull request, so it has to fit into the regular branches.

        Arnd

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

Re: [RFC RFT PATCH v1 1/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Krzysztof Kozlowski]

On 27/04/2022 18:21, Mauri Sandberg wrote:
> Convert D-Link DNS-323 to use the device tree and remove associated
> mach file.
> 

Thank you for your patch. There is something to discuss/improve.

> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> ---
>  arch/arm/boot/dts/Makefile                   |   3 +
>  arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 217 ++++++
>  arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  59 ++
>  arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  38 +
>  arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  80 ++
>  arch/arm/mach-orion5x/Kconfig                |   6 +-
>  arch/arm/mach-orion5x/Makefile               |   2 +-
>  arch/arm/mach-orion5x/board-dns323.c         | 118 +++
>  arch/arm/mach-orion5x/board-dt.c             |   3 +
>  arch/arm/mach-orion5x/common.h               |   6 +
>  arch/arm/mach-orion5x/dns323-setup.c         | 724 -------------------
>  11 files changed, 528 insertions(+), 728 deletions(-)
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
>  create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
>  create mode 100644 arch/arm/mach-orion5x/board-dns323.c
>  delete mode 100644 arch/arm/mach-orion5x/dns323-setup.c

DTS goes separately.

> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7c16f8a2b738..c7c5c0b6c843 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -949,6 +949,9 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
>  	dra71-evm.dtb \
>  	dra76-evm.dtb
>  dtb-$(CONFIG_ARCH_ORION5X) += \
> +	orion5x-dlink-dns323a1.dtb \
> +	orion5x-dlink-dns323b1.dtb \
> +	orion5x-dlink-dns323c1.dtb \
>  	orion5x-kuroboxpro.dtb \
>  	orion5x-lacie-d2-network.dtb \
>  	orion5x-lacie-ethernet-disk-mini-v2.dtb \
> diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
> new file mode 100644
> index 000000000000..2b033d37cbf8
> --- /dev/null
> +++ b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
> + *
> + */
> +
> +/ {
> +	model = "D-Link DNS-323";
> +	compatible = "dlink,dns323", "marvell,orion5x";
> 

You need to also document the compatibles in bindings file for boards.
It would be nice to convert
Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt to DT
Schema (see armada-7k-8k.yaml for example), but it is not a requirement.


Best regards,
Krzysztof

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

Re: [RFC RFT PATCH v1 1/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

Hello Krzysztof and thanks for your feedback

On 28.4.2022 10.13, Krzysztof Kozlowski wrote:
> On 27/04/2022 18:21, Mauri Sandberg wrote:
>> Convert D-Link DNS-323 to use the device tree and remove associated
>> mach file.
>>
> 
> Thank you for your patch. There is something to discuss/improve.
> 
>> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
>> ---
>>   arch/arm/boot/dts/Makefile                   |   3 +
>>   arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 217 ++++++
>>   arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  59 ++
>>   arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  38 +
>>   arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  80 ++
>>   arch/arm/mach-orion5x/Kconfig                |   6 +-
>>   arch/arm/mach-orion5x/Makefile               |   2 +-
>>   arch/arm/mach-orion5x/board-dns323.c         | 118 +++
>>   arch/arm/mach-orion5x/board-dt.c             |   3 +
>>   arch/arm/mach-orion5x/common.h               |   6 +
>>   arch/arm/mach-orion5x/dns323-setup.c         | 724 -------------------
>>   11 files changed, 528 insertions(+), 728 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
>>   create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
>>   create mode 100644 arch/arm/mach-orion5x/board-dns323.c
>>   delete mode 100644 arch/arm/mach-orion5x/dns323-setup.c
> 
> DTS goes separately.
Duly noted. :)

> 
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 7c16f8a2b738..c7c5c0b6c843 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -949,6 +949,9 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
>>   	dra71-evm.dtb \
>>   	dra76-evm.dtb
>>   dtb-$(CONFIG_ARCH_ORION5X) += \
>> +	orion5x-dlink-dns323a1.dtb \
>> +	orion5x-dlink-dns323b1.dtb \
>> +	orion5x-dlink-dns323c1.dtb \
>>   	orion5x-kuroboxpro.dtb \
>>   	orion5x-lacie-d2-network.dtb \
>>   	orion5x-lacie-ethernet-disk-mini-v2.dtb \
>> diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
>> new file mode 100644
>> index 000000000000..2b033d37cbf8
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
>> @@ -0,0 +1,217 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
>> + *
>> + */
>> +
>> +/ {
>> +	model = "D-Link DNS-323";
>> +	compatible = "dlink,dns323", "marvell,orion5x";
>>
> 
> You need to also document the compatibles in bindings file for boards.
> It would be nice to convert
> Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt to DT
> Schema (see armada-7k-8k.yaml for example), but it is not a requirement.

Ah, I hadn't even noticed them before. Will look into this.


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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> Hello all,
>
> I am making an attempt to create a device tree for D-Link DNS-323 devices
> but I am falling short on a few specific details. I am requesting a
> general review of the device tree files. I have access to DNS-323 rev A1
> only and the B1 and C1 need to be tested separately, so I am reaching out
> to people who might have them.

Hi Mauri,

It's really nice to see some progress on this! I don't have the hardware,
but I'll try to answer some of your questions anyway.

> The questions that I have at the moment are below.
>
> - some of resulting IRQs are different from what was requested in device tree
> - logs say NR_IRQS is different from mach file one

This is all normal: with a board file, all on-board IRQs are statically
assigned to fixed numbers. With DT based boot, IRQ controllers
usually define their own IRQ domains, which get a number space assigned
according to probe order, and above the preallocated IRQ numbers.

> - sata_mv fails to initialise with -22 (-EINVAL)

No idea, I'd try inserting a printk in every code path that can return -EINVAL
from there

> - there is no concensus on how to get ascii formatted MAC address from mtd
>   partitions so eth is not fully functional without setting the MAC from
>   userspace

Ideally this is handled by the boot loader, but that requires being
able to update
it. If you cannot, this could perhaps be done using something like
https://github.com/zonque/pxa-impedance-matcher

       Arnd

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Andrew Lunn]

> > - there is no concensus on how to get ascii formatted MAC address from mtd
> >   partitions so eth is not fully functional without setting the MAC from
> >   userspace
> 
> Ideally this is handled by the boot loader, but that requires being
> able to update
> it.

The mv643xx Ethernet driver is happy if it finds the MAC address
already in the hardware. The vendor uboot often does this. Does tftp
boot work in uboot? That would indicate it has access to the MAC
address.

	Andrew

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

Hello Andrew!

On 28.4.2022 3.18, Andrew Lunn wrote:
>>> - there is no concensus on how to get ascii formatted MAC address from mtd
>>>    partitions so eth is not fully functional without setting the MAC from
>>>    userspace
>>
>> Ideally this is handled by the boot loader, but that requires being
>> able to update
>> it.
> 
> The mv643xx Ethernet driver is happy if it finds the MAC address
> already in the hardware. The vendor uboot often does this. Does tftp
> boot work in uboot? That would indicate it has access to the MAC
> address.

The u-boot is really limited and I am transferring new images over 
kermit. Tftp is not enabled.


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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Andrew Lunn]

On Thu, Apr 28, 2022 at 11:25:00PM +0300, Mauri Sandberg wrote:
> Hello Andrew!
> 
> On 28.4.2022 3.18, Andrew Lunn wrote:
> > > > - there is no concensus on how to get ascii formatted MAC address from mtd
> > > >    partitions so eth is not fully functional without setting the MAC from
> > > >    userspace
> > > 
> > > Ideally this is handled by the boot loader, but that requires being
> > > able to update
> > > it.
> > 
> > The mv643xx Ethernet driver is happy if it finds the MAC address
> > already in the hardware. The vendor uboot often does this. Does tftp
> > boot work in uboot? That would indicate it has access to the MAC
> > address.
> 
> The u-boot is really limited and I am transferring new images over kermit.

Ouch!

If you can, try kexec. You can use wget or similar to grab the kernel
from you host machine, and then something like:

kexec --append 'rootwait ro earlyprintk console=ttyS0,115200n8' bzImage

wget will be much faster then kernel.

      Andrew

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

On 29.04.22 02:26, Andrew Lunn wrote:
> On Thu, Apr 28, 2022 at 11:25:00PM +0300, Mauri Sandberg wrote:
>> Hello Andrew!
>>
>> On 28.4.2022 3.18, Andrew Lunn wrote:
>>>>> - there is no concensus on how to get ascii formatted MAC address from mtd
>>>>>     partitions so eth is not fully functional without setting the MAC from
>>>>>     userspace
>>>> Ideally this is handled by the boot loader, but that requires being
>>>> able to update
>>>> it.
>>> The mv643xx Ethernet driver is happy if it finds the MAC address
>>> already in the hardware. The vendor uboot often does this. Does tftp
>>> boot work in uboot? That would indicate it has access to the MAC
>>> address.
>> The u-boot is really limited and I am transferring new images over kermit.
> Ouch!
>
> If you can, try kexec. You can use wget or similar to grab the kernel
> from you host machine, and then something like:
>
> kexec --append 'rootwait ro earlyprintk console=ttyS0,115200n8' bzImage
>
> wget will be much faster then kernel.
>
Nice, this looks promising. Thanks for the tip.



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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

Hi Arnd and thanks for your quick reply.

On 27.4.2022 21.10, Arnd Bergmann wrote:
> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>
>> Hello all,
>>
>> I am making an attempt to create a device tree for D-Link DNS-323 devices
>> but I am falling short on a few specific details. I am requesting a
>> general review of the device tree files. I have access to DNS-323 rev A1
>> only and the B1 and C1 need to be tested separately, so I am reaching out
>> to people who might have them.
> 
> Hi Mauri,
> 
> It's really nice to see some progress on this! I don't have the hardware,
> but I'll try to answer some of your questions anyway.
> 
>> The questions that I have at the moment are below.
>>
>> - some of resulting IRQs are different from what was requested in device tree
>> - logs say NR_IRQS is different from mach file one
> 
Ok thanks, I won't worry about it anymore.

> This is all normal: with a board file, all on-board IRQs are statically
> assigned to fixed numbers. With DT based boot, IRQ controllers
> usually define their own IRQ domains, which get a number space assigned
> according to probe order, and above the preallocated IRQ numbers.
> 
>> - sata_mv fails to initialise with -22 (-EINVAL)
> 
> No idea, I'd try inserting a printk in every code path that can return -EINVAL
> from there
> 
I had something like that but I didn't get any wiser immediately. Then I 
suspected it's something to do with initialisation of the PCIe bus and 
that clashing with sata_mv initialisation and thought it's better to 
ask. The PCIe initialisation uses hardwired irq and maybe that was 
getting in the way. Is there a way to describe the PCIe bus in the 
device tree? The initalisation of that bus is done for rev A1 only.

>> - there is no concensus on how to get ascii formatted MAC address from mtd
>>    partitions so eth is not fully functional without setting the MAC from
>>    userspace
> 
> Ideally this is handled by the boot loader, but that requires being
> able to update
> it. If you cannot, this could perhaps be done using something like
> https://github.com/zonque/pxa-impedance-matcher

I had a look at the pxa-impedance-matcher but I am not sure how to use 
it. Should it be flashed on the device and then it would the boot the 
rest of the system? Maybe I'll have to add some dns323 specifics there 
too first. On the dns323 there are these mtd partitions MTD1 and MTD2, 
which I am not really sure what they are for. Maybe those could 
accommodate a 3rd stage loader. But I'll consider it as my last resort 
as they put it in their documentation too. In linux-mtd there's been a 
few attempts to find a solution and I am hoping one will be found 
eventually.

Adding support in the u-boot was stalled back in the days for some 
reason and I am not sure I will be much wiser than the previous people 
that were at it. But I have jtag programmer that should be suitable.

-- Mauri

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> On 27.4.2022 21.10, Arnd Bergmann wrote:
> > On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > This is all normal: with a board file, all on-board IRQs are statically
> > assigned to fixed numbers. With DT based boot, IRQ controllers
> > usually define their own IRQ domains, which get a number space assigned
> > according to probe order, and above the preallocated IRQ numbers.
> >
> >> - sata_mv fails to initialise with -22 (-EINVAL)
> >
> > No idea, I'd try inserting a printk in every code path that can return -EINVAL
> > from there
> >
> I had something like that but I didn't get any wiser immediately. Then I
> suspected it's something to do with initialisation of the PCIe bus and
> that clashing with sata_mv initialisation and thought it's better to
> ask. The PCIe initialisation uses hardwired irq and maybe that was
> getting in the way. Is there a way to describe the PCIe bus in the
> device tree? The initalisation of that bus is done for rev A1 only.

I'm not too familiar with the platform, but my interpretation is that the
DT support here is incomplete:

The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
is not hooked up in orion5x.dtsi, and the traditional pci code does
not work with DT.

I see that orion5x has two separate blocks --  a PCIe host that is
similar to the kirkwood one, and a legacy PCI host that needs
a completely separate driver.

Which of the two do you actually need here?

> >> - there is no concensus on how to get ascii formatted MAC address from mtd
> >>    partitions so eth is not fully functional without setting the MAC from
> >>    userspace
> >
> > Ideally this is handled by the boot loader, but that requires being
> > able to update
> > it. If you cannot, this could perhaps be done using something like
> > https://github.com/zonque/pxa-impedance-matcher
>
> I had a look at the pxa-impedance-matcher but I am not sure how to use
> it. Should it be flashed on the device and then it would the boot the
> rest of the system? Maybe I'll have to add some dns323 specifics there
> too first. On the dns323 there are these mtd partitions MTD1 and MTD2,
> which I am not really sure what they are for. Maybe those could
> accommodate a 3rd stage loader. But I'll consider it as my last resort
> as they put it in their documentation too. In linux-mtd there's been a
> few attempts to find a solution and I am hoping one will be found
> eventually.
>
> Adding support in the u-boot was stalled back in the days for some
> reason and I am not sure I will be much wiser than the previous people
> that were at it. But I have jtag programmer that should be suitable.

I think the idea of the impedance-matcher is that you can combine it
with a DT-enabled kernel image into a file that looks to the existing
boot loader like an old kernel and then provides both a way for
code to run before booting the kernel, and for adding in the DT.

       Arnd

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

On 28.4.2022 23.56, Arnd Bergmann wrote:
> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>> On 27.4.2022 21.10, Arnd Bergmann wrote:
>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>> - sata_mv fails to initialise with -22 (-EINVAL)
>>>
>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
>>> from there
>>>

With debugging the reason for -EINVAL remains a bit mystery.
  - sata_mv calls ata_host_activate() [1]
  - later on, in request_threaded_irq(), there are sanity checks [2]
  - that fail with irq_settings_can_request() returning 0 [3]

I cannot really put my finger on why the irq cannot be requested in DT
approach.

>> Is there a way to describe the PCIe bus in the
>> device tree? The initalisation of that bus is done for rev A1 only.
> 
> I'm not too familiar with the platform, but my interpretation is that the
> DT support here is incomplete:
> 
> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> is not hooked up in orion5x.dtsi, and the traditional pci code does
> not work with DT.

Can the existing pci code still be used to init the PCI bus and describe
the rest in the DT or is it a futile attempt?

> I see that orion5x has two separate blocks --  a PCIe host that is
> similar to the kirkwood one, and a legacy PCI host that needs
> a completely separate driver.
> 
> Which of the two do you actually need here?
> 

I really cannot say which one is it. How can I tell? The functions given
in struct hw_pci find their way to drivers/pci/probe.c eventually and
use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
kirkwood explicitly at least.

Here's the output from lspci if the ids reveal anything.

# lspci -v -k
00:00.0 Class 0580: 11ab:5181
01:00.0 Class 0580: 11ab:5181
00:01.0 Class 0100: 11ab:7042 sata_mv

-- Mauri

[1] 
https://elixir.bootlin.com/linux/v5.17/source/drivers/ata/sata_mv.c#L4434

[2] https://elixir.bootlin.com/linux/v5.17/source/kernel/irq/manage.c#L2146

[3] https://elixir.bootlin.com/linux/v5.17/source/kernel/irq/settings.h#L100

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> On 28.4.2022 23.56, Arnd Bergmann wrote:
> > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >> On 27.4.2022 21.10, Arnd Bergmann wrote:
> >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >>>> - sata_mv fails to initialise with -22 (-EINVAL)
> >>>
> >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
> >>> from there
> >>>
>
> With debugging the reason for -EINVAL remains a bit mystery.
>   - sata_mv calls ata_host_activate() [1]
>   - later on, in request_threaded_irq(), there are sanity checks [2]
>   - that fail with irq_settings_can_request() returning 0 [3]
>
> I cannot really put my finger on why the irq cannot be requested in DT
> approach.

Are you sure the marvell,orion-intc driver is successfully probed
at this point? If not, the interrupt won't be there.

I see that the "sata_mv" driver can be used either as a platform
driver for the orion5x on-chip controller, or as a PCI driver for
an add-on chip connected to the external bus. It sounds like
your system has both. Do you know which one fails?

The PCI driver cannot work unless the PCI host works correctly,
and that in turn requires a correct devicetree description for it.

> >> Is there a way to describe the PCIe bus in the
> >> device tree? The initalisation of that bus is done for rev A1 only.
> >
> > I'm not too familiar with the platform, but my interpretation is that the
> > DT support here is incomplete:
> >
> > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> > is not hooked up in orion5x.dtsi, and the traditional pci code does
> > not work with DT.
>
> Can the existing pci code still be used to init the PCI bus and describe
> the rest in the DT or is it a futile attempt?
>
> > I see that orion5x has two separate blocks --  a PCIe host that is
> > similar to the kirkwood one, and a legacy PCI host that needs
> > a completely separate driver.
> >
> > Which of the two do you actually need here?
> >
>
> I really cannot say which one is it. How can I tell? The functions given
> in struct hw_pci find their way to drivers/pci/probe.c eventually and
> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
> kirkwood explicitly at least.
>
> Here's the output from lspci if the ids reveal anything.
>
> # lspci -v -k
> 00:00.0 Class 0580: 11ab:5181
> 01:00.0 Class 0580: 11ab:5181
> 00:01.0 Class 0100: 11ab:7042 sata_mv

The first two seem to be the host bridges, but unfortunately they
 seem both have the same device ID, despite being very different
devices.  The first one (00:00.0) should be the PCIe driver, the
second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
device is a PCIe device, and it's on the bus (00) of the first host
bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
if you add the bits for probing.

Thomas Petazzoni originally wrote the new driver, and I think he was
planning at one point to use it for orion5x. I don't know if there were
any major problems preventing this at the time, or if it just needs to
get hooked up in the dtsi file.

         Arnd

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Pali Rohár]

On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > On 28.4.2022 23.56, Arnd Bergmann wrote:
> > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > >> On 27.4.2022 21.10, Arnd Bergmann wrote:
> > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > >>>> - sata_mv fails to initialise with -22 (-EINVAL)
> > >>>
> > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
> > >>> from there
> > >>>
> >
> > With debugging the reason for -EINVAL remains a bit mystery.
> >   - sata_mv calls ata_host_activate() [1]
> >   - later on, in request_threaded_irq(), there are sanity checks [2]
> >   - that fail with irq_settings_can_request() returning 0 [3]
> >
> > I cannot really put my finger on why the irq cannot be requested in DT
> > approach.
> 
> Are you sure the marvell,orion-intc driver is successfully probed
> at this point? If not, the interrupt won't be there.
> 
> I see that the "sata_mv" driver can be used either as a platform
> driver for the orion5x on-chip controller, or as a PCI driver for
> an add-on chip connected to the external bus. It sounds like
> your system has both. Do you know which one fails?
> 
> The PCI driver cannot work unless the PCI host works correctly,
> and that in turn requires a correct devicetree description for it.
> 
> > >> Is there a way to describe the PCIe bus in the
> > >> device tree? The initalisation of that bus is done for rev A1 only.
> > >
> > > I'm not too familiar with the platform, but my interpretation is that the
> > > DT support here is incomplete:
> > >
> > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> > > is not hooked up in orion5x.dtsi, and the traditional pci code does
> > > not work with DT.
> >
> > Can the existing pci code still be used to init the PCI bus and describe
> > the rest in the DT or is it a futile attempt?

Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
PCIe buses. This is not device tree driver.

> > > I see that orion5x has two separate blocks --  a PCIe host that is
> > > similar to the kirkwood one, and a legacy PCI host that needs
> > > a completely separate driver.
> > >
> > > Which of the two do you actually need here?
> > >
> >
> > I really cannot say which one is it. How can I tell? The functions given
> > in struct hw_pci find their way to drivers/pci/probe.c eventually and
> > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
> > kirkwood explicitly at least.
> >
> > Here's the output from lspci if the ids reveal anything.
> >
> > # lspci -v -k
> > 00:00.0 Class 0580: 11ab:5181
> > 01:00.0 Class 0580: 11ab:5181
> > 00:01.0 Class 0100: 11ab:7042 sata_mv
> 
> The first two seem to be the host bridges, but unfortunately they
>  seem both have the same device ID, despite being very different
> devices.  The first one (00:00.0) should be the PCIe driver, the
> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
> device is a PCIe device, and it's on the bus (00) of the first host
> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
> if you add the bits for probing.

Last time when I looked on Orion PCIe controller registers, I though
that they are same as in Kirkwood PCIe controller registers. And
Kirkwood is already supported by pci-mvebu.c driver.

About PCI host bridge, I do not know.

Beware that PCI Class Id and all PCI registers which are different for
Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
Marvell SoCs. Those registers on Marvell SoCs have different meaning as
what is defined in PCI and PCIe specs. So it means that lspci _may_
display bogus information about PCIe Root Port. pci-mvebu.c uses Root
Port emulator which fills correct data to make kernel and lspci happy.

If you are going to extend pci-mvebu.c to support also Orion PCIe
controller, I could try to help with it. But I do not have any Orion
hardware, so just basic help...

Links to Orion documentations, including PCIe errata is available in
kernel documentation. So this could help to understand some details:
https://www.kernel.org/doc/html/latest/arm/marvell.html

Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
outputs from Orion?

> Thomas Petazzoni originally wrote the new driver, and I think he was
> planning at one point to use it for orion5x. I don't know if there were
> any major problems preventing this at the time, or if it just needs to
> get hooked up in the dtsi file.
> 
>          Arnd

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Pali Rohár]

On Sunday 08 May 2022 17:22:37 Pali Rohár wrote:
> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
> > On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > > On 28.4.2022 23.56, Arnd Bergmann wrote:
> > > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > > >> On 27.4.2022 21.10, Arnd Bergmann wrote:
> > > >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > > >>>> - sata_mv fails to initialise with -22 (-EINVAL)
> > > >>>
> > > >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
> > > >>> from there
> > > >>>
> > >
> > > With debugging the reason for -EINVAL remains a bit mystery.
> > >   - sata_mv calls ata_host_activate() [1]
> > >   - later on, in request_threaded_irq(), there are sanity checks [2]
> > >   - that fail with irq_settings_can_request() returning 0 [3]
> > >
> > > I cannot really put my finger on why the irq cannot be requested in DT
> > > approach.
> > 
> > Are you sure the marvell,orion-intc driver is successfully probed
> > at this point? If not, the interrupt won't be there.
> > 
> > I see that the "sata_mv" driver can be used either as a platform
> > driver for the orion5x on-chip controller, or as a PCI driver for
> > an add-on chip connected to the external bus. It sounds like
> > your system has both. Do you know which one fails?
> > 
> > The PCI driver cannot work unless the PCI host works correctly,
> > and that in turn requires a correct devicetree description for it.
> > 
> > > >> Is there a way to describe the PCIe bus in the
> > > >> device tree? The initalisation of that bus is done for rev A1 only.
> > > >
> > > > I'm not too familiar with the platform, but my interpretation is that the
> > > > DT support here is incomplete:
> > > >
> > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> > > > is not hooked up in orion5x.dtsi, and the traditional pci code does
> > > > not work with DT.
> > >
> > > Can the existing pci code still be used to init the PCI bus and describe
> > > the rest in the DT or is it a futile attempt?
> 
> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
> PCIe buses. This is not device tree driver.

Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls
common functions from mach-orion5x/pci.c driver.

> > > > I see that orion5x has two separate blocks --  a PCIe host that is
> > > > similar to the kirkwood one, and a legacy PCI host that needs
> > > > a completely separate driver.
> > > >
> > > > Which of the two do you actually need here?
> > > >
> > >
> > > I really cannot say which one is it. How can I tell? The functions given
> > > in struct hw_pci find their way to drivers/pci/probe.c eventually and
> > > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
> > > kirkwood explicitly at least.
> > >
> > > Here's the output from lspci if the ids reveal anything.
> > >
> > > # lspci -v -k
> > > 00:00.0 Class 0580: 11ab:5181
> > > 01:00.0 Class 0580: 11ab:5181
> > > 00:01.0 Class 0100: 11ab:7042 sata_mv
> > 
> > The first two seem to be the host bridges, but unfortunately they
> >  seem both have the same device ID, despite being very different
> > devices.  The first one (00:00.0) should be the PCIe driver, the
> > second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
> > device is a PCIe device, and it's on the bus (00) of the first host
> > bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
> > if you add the bits for probing.
> 
> Last time when I looked on Orion PCIe controller registers, I though
> that they are same as in Kirkwood PCIe controller registers. And
> Kirkwood is already supported by pci-mvebu.c driver.
> 
> About PCI host bridge, I do not know.
> 
> Beware that PCI Class Id and all PCI registers which are different for
> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
> Marvell SoCs. Those registers on Marvell SoCs have different meaning as
> what is defined in PCI and PCIe specs. So it means that lspci _may_
> display bogus information about PCIe Root Port. pci-mvebu.c uses Root
> Port emulator which fills correct data to make kernel and lspci happy.
> 
> If you are going to extend pci-mvebu.c to support also Orion PCIe
> controller, I could try to help with it. But I do not have any Orion
> hardware, so just basic help...
> 
> Links to Orion documentations, including PCIe errata is available in
> kernel documentation. So this could help to understand some details:
> https://www.kernel.org/doc/html/latest/arm/marvell.html
> 
> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
> outputs from Orion?
> 
> > Thomas Petazzoni originally wrote the new driver, and I think he was
> > planning at one point to use it for orion5x. I don't know if there were
> > any major problems preventing this at the time, or if it just needs to
> > get hooked up in the dtsi file.
> > 
> >          Arnd

There is Orion-specific errata that config space via CF8/CFC registers
is broken. Workaround documented in errata documented (linked from above
documentation) does not work when DMA is used and instead other
undocumented workaround is needed (implemented in arch/arm) which maps
config space to memory (and therefore avoids usage of broken CF8/CFC
memory mapped registers).

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Sun, May 8, 2022 at 5:41 PM Pali Rohár <pali@kernel.org> wrote:
> On Sunday 08 May 2022 17:22:37 Pali Rohár wrote:
> > On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
> > > >
> > > > Can the existing pci code still be used to init the PCI bus and describe
> > > > the rest in the DT or is it a futile attempt?
> >
> > Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
> > PCIe buses. This is not device tree driver.
>
> Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls
> common functions from mach-orion5x/pci.c driver.

FWIW, I have an older patch series that turns the plat-orion/pcie.c and
mach-orion5x/pci.c into standalone host bridge drivers that no longer
use the arm/kernel/bios32.c helpers. If anyone wants to work on DT
support for the legacy-pci side (not for this machine but maybe another
orion5x one), I can try to rebase those patches to make it easier to
add the missing DT support.

          Arnd

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

On 8.5.2022 18.41, Pali Rohár wrote:
> On Sunday 08 May 2022 17:22:37 Pali Rohár wrote:
>> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
>>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>> On 28.4.2022 23.56, Arnd Bergmann wrote:
>>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote:
>>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL)
>>>>>>>
>>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
>>>>>>> from there
>>>>>>>
>>>>
>>>> With debugging the reason for -EINVAL remains a bit mystery.
>>>>   - sata_mv calls ata_host_activate() [1]
>>>>   - later on, in request_threaded_irq(), there are sanity checks [2]
>>>>   - that fail with irq_settings_can_request() returning 0 [3]
>>>>
>>>> I cannot really put my finger on why the irq cannot be requested in DT
>>>> approach.
>>>
>>> Are you sure the marvell,orion-intc driver is successfully probed
>>> at this point? If not, the interrupt won't be there.
>>>
>>> I see that the "sata_mv" driver can be used either as a platform
>>> driver for the orion5x on-chip controller, or as a PCI driver for
>>> an add-on chip connected to the external bus. It sounds like
>>> your system has both. Do you know which one fails?
>>>
>>> The PCI driver cannot work unless the PCI host works correctly,
>>> and that in turn requires a correct devicetree description for it.
>>>
>>>>>> Is there a way to describe the PCIe bus in the
>>>>>> device tree? The initalisation of that bus is done for rev A1 only.
>>>>>
>>>>> I'm not too familiar with the platform, but my interpretation is that the
>>>>> DT support here is incomplete:
>>>>>
>>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
>>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does
>>>>> not work with DT.
>>>>
>>>> Can the existing pci code still be used to init the PCI bus and describe
>>>> the rest in the DT or is it a futile attempt?
>>
>> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
>> PCIe buses. This is not device tree driver.
> 
> Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls
> common functions from mach-orion5x/pci.c driver.
> 
>>>>> I see that orion5x has two separate blocks --  a PCIe host that is
>>>>> similar to the kirkwood one, and a legacy PCI host that needs
>>>>> a completely separate driver.
>>>>>
>>>>> Which of the two do you actually need here?
>>>>>
>>>>
>>>> I really cannot say which one is it. How can I tell? The functions given
>>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and
>>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
>>>> kirkwood explicitly at least.
>>>>
>>>> Here's the output from lspci if the ids reveal anything.
>>>>
>>>> # lspci -v -k
>>>> 00:00.0 Class 0580: 11ab:5181
>>>> 01:00.0 Class 0580: 11ab:5181
>>>> 00:01.0 Class 0100: 11ab:7042 sata_mv
>>>
>>> The first two seem to be the host bridges, but unfortunately they
>>>  seem both have the same device ID, despite being very different
>>> devices.  The first one (00:00.0) should be the PCIe driver, the
>>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
>>> device is a PCIe device, and it's on the bus (00) of the first host
>>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
>>> if you add the bits for probing.
>>
>> Last time when I looked on Orion PCIe controller registers, I though
>> that they are same as in Kirkwood PCIe controller registers. And
>> Kirkwood is already supported by pci-mvebu.c driver.
>>
>> About PCI host bridge, I do not know.
>>
>> Beware that PCI Class Id and all PCI registers which are different for
>> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
>> Marvell SoCs. Those registers on Marvell SoCs have different meaning as
>> what is defined in PCI and PCIe specs. So it means that lspci _may_
>> display bogus information about PCIe Root Port. pci-mvebu.c uses Root
>> Port emulator which fills correct data to make kernel and lspci happy.
>>
>> If you are going to extend pci-mvebu.c to support also Orion PCIe
>> controller, I could try to help with it. But I do not have any Orion
>> hardware, so just basic help...
>>
>> Links to Orion documentations, including PCIe errata is available in
>> kernel documentation. So this could help to understand some details:
>> https://www.kernel.org/doc/html/latest/arm/marvell.html
>>
>> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
>> outputs from Orion?
>>
>>> Thomas Petazzoni originally wrote the new driver, and I think he was
>>> planning at one point to use it for orion5x. I don't know if there were
>>> any major problems preventing this at the time, or if it just needs to
>>> get hooked up in the dtsi file.
>>>
>>>          Arnd
> 
> There is Orion-specific errata that config space via CF8/CFC registers
> is broken. Workaround documented in errata documented (linked from above
> documentation) does not work when DMA is used and instead other
> undocumented workaround is needed (implemented in arch/arm) which maps
> config space to memory (and therefore avoids usage of broken CF8/CFC
> memory mapped registers).

So basically I should look at arch/arm/plat-orion/pcie.c for the
configuration part, add new compatible to pci-mvebu.c for orion5x
and alter the probing function accoringly for the same. Did I get
it correctly?

If so, sounds simple when said out lout but I might need some more
pointers to get started. Like with configuration people generally
mean setting BARs and WINs? Or is there more to it? :) If you
could lay out the basic steps that are needed I would really
appreciate it.

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Pali Rohár]

On Monday 09 May 2022 13:48:53 Mauri Sandberg wrote:
> On 8.5.2022 18.41, Pali Rohár wrote:
> > On Sunday 08 May 2022 17:22:37 Pali Rohár wrote:
> >> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
> >>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >>>> On 28.4.2022 23.56, Arnd Bergmann wrote:
> >>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote:
> >>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL)
> >>>>>>>
> >>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
> >>>>>>> from there
> >>>>>>>
> >>>>
> >>>> With debugging the reason for -EINVAL remains a bit mystery.
> >>>>   - sata_mv calls ata_host_activate() [1]
> >>>>   - later on, in request_threaded_irq(), there are sanity checks [2]
> >>>>   - that fail with irq_settings_can_request() returning 0 [3]
> >>>>
> >>>> I cannot really put my finger on why the irq cannot be requested in DT
> >>>> approach.
> >>>
> >>> Are you sure the marvell,orion-intc driver is successfully probed
> >>> at this point? If not, the interrupt won't be there.
> >>>
> >>> I see that the "sata_mv" driver can be used either as a platform
> >>> driver for the orion5x on-chip controller, or as a PCI driver for
> >>> an add-on chip connected to the external bus. It sounds like
> >>> your system has both. Do you know which one fails?
> >>>
> >>> The PCI driver cannot work unless the PCI host works correctly,
> >>> and that in turn requires a correct devicetree description for it.
> >>>
> >>>>>> Is there a way to describe the PCIe bus in the
> >>>>>> device tree? The initalisation of that bus is done for rev A1 only.
> >>>>>
> >>>>> I'm not too familiar with the platform, but my interpretation is that the
> >>>>> DT support here is incomplete:
> >>>>>
> >>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> >>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does
> >>>>> not work with DT.
> >>>>
> >>>> Can the existing pci code still be used to init the PCI bus and describe
> >>>> the rest in the DT or is it a futile attempt?
> >>
> >> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
> >> PCIe buses. This is not device tree driver.
> > 
> > Correction, Orion PCIe driver is arch/arm/plat-orion/pcie.c and it calls
> > common functions from mach-orion5x/pci.c driver.
> > 
> >>>>> I see that orion5x has two separate blocks --  a PCIe host that is
> >>>>> similar to the kirkwood one, and a legacy PCI host that needs
> >>>>> a completely separate driver.
> >>>>>
> >>>>> Which of the two do you actually need here?
> >>>>>
> >>>>
> >>>> I really cannot say which one is it. How can I tell? The functions given
> >>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and
> >>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
> >>>> kirkwood explicitly at least.
> >>>>
> >>>> Here's the output from lspci if the ids reveal anything.
> >>>>
> >>>> # lspci -v -k
> >>>> 00:00.0 Class 0580: 11ab:5181
> >>>> 01:00.0 Class 0580: 11ab:5181
> >>>> 00:01.0 Class 0100: 11ab:7042 sata_mv
> >>>
> >>> The first two seem to be the host bridges, but unfortunately they
> >>>  seem both have the same device ID, despite being very different
> >>> devices.  The first one (00:00.0) should be the PCIe driver, the
> >>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
> >>> device is a PCIe device, and it's on the bus (00) of the first host
> >>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
> >>> if you add the bits for probing.
> >>
> >> Last time when I looked on Orion PCIe controller registers, I though
> >> that they are same as in Kirkwood PCIe controller registers. And
> >> Kirkwood is already supported by pci-mvebu.c driver.
> >>
> >> About PCI host bridge, I do not know.
> >>
> >> Beware that PCI Class Id and all PCI registers which are different for
> >> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
> >> Marvell SoCs. Those registers on Marvell SoCs have different meaning as
> >> what is defined in PCI and PCIe specs. So it means that lspci _may_
> >> display bogus information about PCIe Root Port. pci-mvebu.c uses Root
> >> Port emulator which fills correct data to make kernel and lspci happy.
> >>
> >> If you are going to extend pci-mvebu.c to support also Orion PCIe
> >> controller, I could try to help with it. But I do not have any Orion
> >> hardware, so just basic help...
> >>
> >> Links to Orion documentations, including PCIe errata is available in
> >> kernel documentation. So this could help to understand some details:
> >> https://www.kernel.org/doc/html/latest/arm/marvell.html
> >>
> >> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
> >> outputs from Orion?
> >>
> >>> Thomas Petazzoni originally wrote the new driver, and I think he was
> >>> planning at one point to use it for orion5x. I don't know if there were
> >>> any major problems preventing this at the time, or if it just needs to
> >>> get hooked up in the dtsi file.
> >>>
> >>>          Arnd
> > 
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
> > undocumented workaround is needed (implemented in arch/arm) which maps
> > config space to memory (and therefore avoids usage of broken CF8/CFC
> > memory mapped registers).
> 
> So basically I should look at arch/arm/plat-orion/pcie.c for the
> configuration part, add new compatible to pci-mvebu.c for orion5x
> and alter the probing function accoringly for the same. Did I get
> it correctly?

You would need to replace mvebu_pcie_child_rd_conf() and
mvebu_pcie_child_wr_conf() implementation in pci-mvebu.c with the
correct orion implementation. Orion implementation is in function
pcie_rd_conf_wa() or pcie_rd_conf() (file arch/arm/mach-orion5x/pci.c)
based on the fact if workaround has to be applied or not. Same for *wr*
functions.

Workaround uses wa_base address, which needs to be mapped via mbus
driver. This is something new which is not supported by pci-mvebu.c. And
wa_base address should be correctly specified in ranges= property of
type "configuration space" (ss = 00). See:
https://elinux.org/Device_Tree_Usage#PCI_Address_Translation

> If so, sounds simple when said out lout but I might need some more
> pointers to get started. Like with configuration people generally
> mean setting BARs and WINs? Or is there more to it? :) If you
> could lay out the basic steps that are needed I would really
> appreciate it.

BARs and WINs are configured by pci-mvebu.c. You just have specify
correct ids in DTS. See usage of MBUS_ID() macro and Port X IO/MEM
comments e.g. in arch/arm/boot/dts/armada-385.dtsi file. Also it is
required to set pcie-mem-aperture and pcie-io-aperture properties, see
e.g. in arch/arm/boot/dts/armada-38x.dtsi file.

I'm not sure if this is clear for you. If not, please ask additional
questions :-)

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

On 08.05.22 18:22, Pali Rohár wrote:
> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>> On 28.4.2022 23.56, Arnd Bergmann wrote:
>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote:
>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL)
>>>>>>
>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
>>>>>> from there
>>>>>>
>>>
>>> With debugging the reason for -EINVAL remains a bit mystery.
>>>    - sata_mv calls ata_host_activate() [1]
>>>    - later on, in request_threaded_irq(), there are sanity checks [2]
>>>    - that fail with irq_settings_can_request() returning 0 [3]
>>>
>>> I cannot really put my finger on why the irq cannot be requested in DT
>>> approach.
>>
>> Are you sure the marvell,orion-intc driver is successfully probed
>> at this point? If not, the interrupt won't be there.

I made the pci setup to be the very last thing in the boot and
results are still the same. There are other devices that do get
their interrupts from intc.

>>
>> I see that the "sata_mv" driver can be used either as a platform
>> driver for the orion5x on-chip controller, or as a PCI driver for
>> an add-on chip connected to the external bus. It sounds like
>> your system has both. Do you know which one fails?
>>
>> The PCI driver cannot work unless the PCI host works correctly,
>> and that in turn requires a correct devicetree description for it.
>>
>>>>> Is there a way to describe the PCIe bus in the
>>>>> device tree? The initalisation of that bus is done for rev A1 only.
>>>>
>>>> I'm not too familiar with the platform, but my interpretation is that the
>>>> DT support here is incomplete:
>>>>
>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does
>>>> not work with DT.
>>>
>>> Can the existing pci code still be used to init the PCI bus and describe
>>> the rest in the DT or is it a futile attempt?
> 
> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
> PCIe buses. This is not device tree driver.
> 
>>>> I see that orion5x has two separate blocks --  a PCIe host that is
>>>> similar to the kirkwood one, and a legacy PCI host that needs
>>>> a completely separate driver.
>>>>
>>>> Which of the two do you actually need here?
>>>>
>>>
>>> I really cannot say which one is it. How can I tell? The functions given
>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and
>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
>>> kirkwood explicitly at least.
>>>
>>> Here's the output from lspci if the ids reveal anything.
>>>
>>> # lspci -v -k
>>> 00:00.0 Class 0580: 11ab:5181
>>> 01:00.0 Class 0580: 11ab:5181
>>> 00:01.0 Class 0100: 11ab:7042 sata_mv
>>
>> The first two seem to be the host bridges, but unfortunately they
>>   seem both have the same device ID, despite being very different
>> devices.  The first one (00:00.0) should be the PCIe driver, the
>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
>> device is a PCIe device, and it's on the bus (00) of the first host
>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
>> if you add the bits for probing.
> 
> Last time when I looked on Orion PCIe controller registers, I though
> that they are same as in Kirkwood PCIe controller registers. And
> Kirkwood is already supported by pci-mvebu.c driver.
> 

I seemed that way to me too on the first glance. And it looks like there
are no devices using the PCI driver. I knocked off that part altogether 
and the boot log looks pretty much the same it was. Perhaps I can do
with describing the PCIe bus only.

> About PCI host bridge, I do not know.
> 
> Beware that PCI Class Id and all PCI registers which are different for
> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
> Marvell SoCs. Those registers on Marvell SoCs have different meaning as
> what is defined in PCI and PCIe specs. So it means that lspci _may_
> display bogus information about PCIe Root Port. pci-mvebu.c uses Root
> Port emulator which fills correct data to make kernel and lspci happy.
> 
> If you are going to extend pci-mvebu.c to support also Orion PCIe
> controller, I could try to help with it. But I do not have any Orion
> hardware, so just basic help...

I could make an attempt at this. Should I try to look at an existing
kirkwood based device first, say kirkwood-6281.dtsi? I didn't see
anything SoC-specific in pci-mvebu.c. All different compatibles seem
to share the same functionality.

> 
> Links to Orion documentations, including PCIe errata is available in
> kernel documentation. So this could help to understand some details:
> https://www.kernel.org/doc/html/latest/arm/marvell.html
> 
> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
> outputs from Orion?

# lspci -nn -vv
0000:00:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 
88f5181 [Orion-1] ARM SoC [11ab:5181] (rev 03)
	Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 0
	Region 0: Memory at <ignored> (64-bit, prefetchable)
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- RBE-
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s 
<256ns
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s (ok), Width x1 (ok)
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		RootCap: CRSVisible-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-

0000:00:01.0 SCSI storage controller [0100]: Marvell Technology Group 
Ltd. 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02)
	Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=1M]
	Region 2: I/O ports at 1000 [size=256]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s 
<256ns
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
		LnkCtl:	ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s (ok), Width x1 (downgraded)
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Kernel driver in use: sata_mv

0001:01:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 
88f5181 [Orion-1] ARM SoC [11ab:5181] (rev 03)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
Stepping- SERR+ FastB2B+ DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 0
	BIST result: 00
	Region 0: Memory at <unassigned> (64-bit, prefetchable)
	Region 2: Memory at <ignored> (64-bit, prefetchable)
	Region 4: Memory at <ignored> (64-bit, non-prefetchable)
	Expansion ROM at <ignored> [disabled]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
	Capabilities: [48] Vital Product Data
		Not readable
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [60] PCI-X non-bridge device
		Command: DPERE- ERO- RBC=512 OST=4
		Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 
DMOST=4 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Capabilities: [68] CompactPCI hot-swap <?>

# lspci -nn -t -v
-+-[0001:01]---00.0  Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM 
SoC [11ab:5181]
  \-[0000:00]-+-00.0  Marvell Technology Group Ltd. 88f5181 [Orion-1] 
ARM SoC [11ab:5181]
              \-01.0  Marvell Technology Group Ltd. 88SX7042 PCI-e 
4-port SATA-II [11ab:7042]

> 
>> Thomas Petazzoni originally wrote the new driver, and I think he was
>> planning at one point to use it for orion5x. I don't know if there were
>> any major problems preventing this at the time, or if it just needs to
>> get hooked up in the dtsi file.
>>
>>           Arnd

-- Mauri

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Pali Rohár]

On Sunday 08 May 2022 22:34:19 Mauri Sandberg wrote:
> On 08.05.22 18:22, Pali Rohár wrote:
> > On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
> > > On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > > > On 28.4.2022 23.56, Arnd Bergmann wrote:
> > > > > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > > > > > On 27.4.2022 21.10, Arnd Bergmann wrote:
> > > > > > > On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> > > > > > > > - sata_mv fails to initialise with -22 (-EINVAL)
> > > > > > > 
> > > > > > > No idea, I'd try inserting a printk in every code path that can return -EINVAL
> > > > > > > from there
> > > > > > > 
> > > > 
> > > > With debugging the reason for -EINVAL remains a bit mystery.
> > > >    - sata_mv calls ata_host_activate() [1]
> > > >    - later on, in request_threaded_irq(), there are sanity checks [2]
> > > >    - that fail with irq_settings_can_request() returning 0 [3]
> > > > 
> > > > I cannot really put my finger on why the irq cannot be requested in DT
> > > > approach.
> > > 
> > > Are you sure the marvell,orion-intc driver is successfully probed
> > > at this point? If not, the interrupt won't be there.
> 
> I made the pci setup to be the very last thing in the boot and
> results are still the same. There are other devices that do get
> their interrupts from intc.
> 
> > > 
> > > I see that the "sata_mv" driver can be used either as a platform
> > > driver for the orion5x on-chip controller, or as a PCI driver for
> > > an add-on chip connected to the external bus. It sounds like
> > > your system has both. Do you know which one fails?
> > > 
> > > The PCI driver cannot work unless the PCI host works correctly,
> > > and that in turn requires a correct devicetree description for it.
> > > 
> > > > > > Is there a way to describe the PCIe bus in the
> > > > > > device tree? The initalisation of that bus is done for rev A1 only.
> > > > > 
> > > > > I'm not too familiar with the platform, but my interpretation is that the
> > > > > DT support here is incomplete:
> > > > > 
> > > > > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> > > > > is not hooked up in orion5x.dtsi, and the traditional pci code does
> > > > > not work with DT.
> > > > 
> > > > Can the existing pci code still be used to init the PCI bus and describe
> > > > the rest in the DT or is it a futile attempt?
> > 
> > Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
> > PCIe buses. This is not device tree driver.
> > 
> > > > > I see that orion5x has two separate blocks --  a PCIe host that is
> > > > > similar to the kirkwood one, and a legacy PCI host that needs
> > > > > a completely separate driver.
> > > > > 
> > > > > Which of the two do you actually need here?
> > > > > 
> > > > 
> > > > I really cannot say which one is it. How can I tell? The functions given
> > > > in struct hw_pci find their way to drivers/pci/probe.c eventually and
> > > > use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
> > > > kirkwood explicitly at least.
> > > > 
> > > > Here's the output from lspci if the ids reveal anything.
> > > > 
> > > > # lspci -v -k
> > > > 00:00.0 Class 0580: 11ab:5181
> > > > 01:00.0 Class 0580: 11ab:5181
> > > > 00:01.0 Class 0100: 11ab:7042 sata_mv
> > > 
> > > The first two seem to be the host bridges, but unfortunately they
> > >   seem both have the same device ID, despite being very different
> > > devices.  The first one (00:00.0) should be the PCIe driver, the
> > > second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
> > > device is a PCIe device, and it's on the bus (00) of the first host
> > > bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
> > > if you add the bits for probing.
> > 
> > Last time when I looked on Orion PCIe controller registers, I though
> > that they are same as in Kirkwood PCIe controller registers. And
> > Kirkwood is already supported by pci-mvebu.c driver.
> > 
> 
> I seemed that way to me too on the first glance. And it looks like there
> are no devices using the PCI driver. I knocked off that part altogether and
> the boot log looks pretty much the same it was. Perhaps I can do
> with describing the PCIe bus only.
> 
> > About PCI host bridge, I do not know.
> > 
> > Beware that PCI Class Id and all PCI registers which are different for
> > Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
> > Marvell SoCs. Those registers on Marvell SoCs have different meaning as
> > what is defined in PCI and PCIe specs. So it means that lspci _may_
> > display bogus information about PCIe Root Port. pci-mvebu.c uses Root
> > Port emulator which fills correct data to make kernel and lspci happy.
> > 
> > If you are going to extend pci-mvebu.c to support also Orion PCIe
> > controller, I could try to help with it. But I do not have any Orion
> > hardware, so just basic help...
> 
> I could make an attempt at this. Should I try to look at an existing
> kirkwood based device first, say kirkwood-6281.dtsi? I didn't see
> anything SoC-specific in pci-mvebu.c. All different compatibles seem
> to share the same functionality.

Yes, this could be a good starting point. But you will need new
compatible string for orion, specially to implement workaround for
accessing config space.

> > 
> > Links to Orion documentations, including PCIe errata is available in
> > kernel documentation. So this could help to understand some details:
> > https://www.kernel.org/doc/html/latest/arm/marvell.html
> > 
> > Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
> > outputs from Orion?
> 
> # lspci -nn -vv
> 0000:00:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181
> [Orion-1] ARM SoC [11ab:5181] (rev 03)
> 	Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0, Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 0
> 	Region 0: Memory at <ignored> (64-bit, prefetchable)
> 	Capabilities: [40] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> 		Address: 0000000000000000  Data: 0000
> 	Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00
> 		DevCap:	MaxPayload 128 bytes, PhantFunc 0
> 			ExtTag- RBE-
> 		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
> 			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> 			MaxPayload 128 bytes, MaxReadReq 512 bytes
> 		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
> 		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s
> <256ns
> 			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> 		LnkCtl:	ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> 		LnkSta:	Speed 2.5GT/s (ok), Width x1 (ok)
> 			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> 		RootCap: CRSVisible-
> 		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
> 		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> 
> 0000:00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd.
> 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02)
> 	Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0, Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 12
> 	Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=1M]
> 	Region 2: I/O ports at 1000 [size=256]
> 	Capabilities: [40] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> 		Address: 0000000000000000  Data: 0000
> 	Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
> 		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us
> 			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> 		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
> 			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> 			MaxPayload 128 bytes, MaxReadReq 512 bytes
> 		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
> 		LnkCap:	Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s
> <256ns
> 			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> 		LnkCtl:	ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> 		LnkSta:	Speed 2.5GT/s (ok), Width x1 (downgraded)
> 			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> 	Kernel driver in use: sata_mv
> 
> 0001:01:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181
> [Orion-1] ARM SoC [11ab:5181] (rev 03)
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B+ DisINTx-
> 	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
> <MAbort+ >SERR- <PERR- INTx-
> 	Latency: 0, Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 0
> 	BIST result: 00
> 	Region 0: Memory at <unassigned> (64-bit, prefetchable)
> 	Region 2: Memory at <ignored> (64-bit, prefetchable)
> 	Region 4: Memory at <ignored> (64-bit, non-prefetchable)
> 	Expansion ROM at <ignored> [disabled]
> 	Capabilities: [40] Power Management version 2
> 		Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
> 	Capabilities: [48] Vital Product Data
> 		Not readable
> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> 		Address: 0000000000000000  Data: 0000
> 	Capabilities: [60] PCI-X non-bridge device
> 		Command: DPERE- ERO- RBC=512 OST=4
> 		Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 DMOST=4
> DMCRS=8 RSCEM- 266MHz- 533MHz-
> 	Capabilities: [68] CompactPCI hot-swap <?>
> 
> # lspci -nn -t -v
> -+-[0001:01]---00.0  Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC
> [11ab:5181]
>  \-[0000:00]-+-00.0  Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC
> [11ab:5181]
>              \-01.0  Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port
> SATA-II [11ab:7042]

Ok, so domain 0 is PCIe bus for sure.
0000:00:00.0 is PCIe Root Port (PCI-to-PCI bridge) incorrectly detected
as Memory controller (known HW issue on all 32-bit Marvell SoCs).
0000:00:01.0 seems to be that SATA controller and this device is
connected behind the PCIe Root Port. Topology is also incorrectly
reports due to same known issue.

Then there is domain 1 (first line in -t output) on which is just one
device 0001:01:00.0 detected as Memory controller and has capability of
"PCI-X non-bridge device". This seems to be PCI bus. I guess that Memory
controller is also bogus information.

What is "PCI-X non-bridge device"? I thought that "root" of the PCI bus
should be Host Bridge.

Anyway, there is my pending patch which should fix Class ID to not
report incorrect Memory controller identification:
https://lore.kernel.org/linux-pci/20211102171259.9590-1-pali@kernel.org/#Z31arch:arm:mach-orion5x:pci.c

> > 
> > > Thomas Petazzoni originally wrote the new driver, and I think he was
> > > planning at one point to use it for orion5x. I don't know if there were
> > > any major problems preventing this at the time, or if it just needs to
> > > get hooked up in the dtsi file.
> > > 
> > >           Arnd
> 
> -- Mauri

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Mauri Sandberg]

On 8.5.2022 23.10, Pali Rohár wrote:
> On Sunday 08 May 2022 22:34:19 Mauri Sandberg wrote:
>> On 08.05.22 18:22, Pali Rohár wrote:
>>> On Sunday 08 May 2022 17:02:17 Arnd Bergmann wrote:
>>>> On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>> On 28.4.2022 23.56, Arnd Bergmann wrote:
>>>>>> On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>>>> On 27.4.2022 21.10, Arnd Bergmann wrote:
>>>>>>>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>>>>>>>>> - sata_mv fails to initialise with -22 (-EINVAL)
>>>>>>>>
>>>>>>>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
>>>>>>>> from there
>>>>>>>>
>>>>>
>>>>> With debugging the reason for -EINVAL remains a bit mystery.
>>>>>    - sata_mv calls ata_host_activate() [1]
>>>>>    - later on, in request_threaded_irq(), there are sanity checks [2]
>>>>>    - that fail with irq_settings_can_request() returning 0 [3]
>>>>>
>>>>> I cannot really put my finger on why the irq cannot be requested in DT
>>>>> approach.
>>>>
>>>> Are you sure the marvell,orion-intc driver is successfully probed
>>>> at this point? If not, the interrupt won't be there.
>>
>> I made the pci setup to be the very last thing in the boot and
>> results are still the same. There are other devices that do get
>> their interrupts from intc.
>>
>>>>
>>>> I see that the "sata_mv" driver can be used either as a platform
>>>> driver for the orion5x on-chip controller, or as a PCI driver for
>>>> an add-on chip connected to the external bus. It sounds like
>>>> your system has both. Do you know which one fails?
>>>>
>>>> The PCI driver cannot work unless the PCI host works correctly,
>>>> and that in turn requires a correct devicetree description for it.
>>>>
>>>>>>> Is there a way to describe the PCIe bus in the
>>>>>>> device tree? The initalisation of that bus is done for rev A1 only.
>>>>>>
>>>>>> I'm not too familiar with the platform, but my interpretation is that the
>>>>>> DT support here is incomplete:
>>>>>>
>>>>>> The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
>>>>>> is not hooked up in orion5x.dtsi, and the traditional pci code does
>>>>>> not work with DT.
>>>>>
>>>>> Can the existing pci code still be used to init the PCI bus and describe
>>>>> the rest in the DT or is it a futile attempt?
>>>
>>> Hello! Orion uses arch/arm/mach-orion5x/pci.c driver for both PCI and
>>> PCIe buses. This is not device tree driver.
>>>
>>>>>> I see that orion5x has two separate blocks --  a PCIe host that is
>>>>>> similar to the kirkwood one, and a legacy PCI host that needs
>>>>>> a completely separate driver.
>>>>>>
>>>>>> Which of the two do you actually need here?
>>>>>>
>>>>>
>>>>> I really cannot say which one is it. How can I tell? The functions given
>>>>> in struct hw_pci find their way to drivers/pci/probe.c eventually and
>>>>> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
>>>>> kirkwood explicitly at least.
>>>>>
>>>>> Here's the output from lspci if the ids reveal anything.
>>>>>
>>>>> # lspci -v -k
>>>>> 00:00.0 Class 0580: 11ab:5181
>>>>> 01:00.0 Class 0580: 11ab:5181
>>>>> 00:01.0 Class 0100: 11ab:7042 sata_mv
>>>>
>>>> The first two seem to be the host bridges, but unfortunately they
>>>>   seem both have the same device ID, despite being very different
>>>> devices.  The first one (00:00.0) should be the PCIe driver, the
>>>> second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
>>>> device is a PCIe device, and it's on the bus (00) of the first host
>>>> bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
>>>> if you add the bits for probing.
>>>
>>> Last time when I looked on Orion PCIe controller registers, I though
>>> that they are same as in Kirkwood PCIe controller registers. And
>>> Kirkwood is already supported by pci-mvebu.c driver.
>>>
>>
>> I seemed that way to me too on the first glance. And it looks like there
>> are no devices using the PCI driver. I knocked off that part altogether and
>> the boot log looks pretty much the same it was. Perhaps I can do
>> with describing the PCIe bus only.
>>
>>> About PCI host bridge, I do not know.
>>>
>>> Beware that PCI Class Id and all PCI registers which are different for
>>> Type 0 and Type 1 are _broken_ on all PCIe Root Ports form all 32-bit
>>> Marvell SoCs. Those registers on Marvell SoCs have different meaning as
>>> what is defined in PCI and PCIe specs. So it means that lspci _may_
>>> display bogus information about PCIe Root Port. pci-mvebu.c uses Root
>>> Port emulator which fills correct data to make kernel and lspci happy.
>>>
>>> If you are going to extend pci-mvebu.c to support also Orion PCIe
>>> controller, I could try to help with it. But I do not have any Orion
>>> hardware, so just basic help...
>>
>> I could make an attempt at this. Should I try to look at an existing
>> kirkwood based device first, say kirkwood-6281.dtsi? I didn't see
>> anything SoC-specific in pci-mvebu.c. All different compatibles seem
>> to share the same functionality.
> 
> Yes, this could be a good starting point. But you will need new
> compatible string for orion, specially to implement workaround for
> accessing config space.
> 
>>>
>>> Links to Orion documentations, including PCIe errata is available in
>>> kernel documentation. So this could help to understand some details:
>>> https://www.kernel.org/doc/html/latest/arm/marvell.html
>>>
>>> Anyway, could you please provide 'lspci -nn -vv' and 'lspci -nn -t -v'
>>> outputs from Orion?
>>
>> # lspci -nn -vv
>> 0000:00:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181
>> [Orion-1] ARM SoC [11ab:5181] (rev 03)
>> 	Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
>> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>> Stepping- SERR+ FastB2B- DisINTx-
>> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
>> <MAbort- >SERR- <PERR- INTx-
>> 	Latency: 0, Cache Line Size: 32 bytes
>> 	Interrupt: pin A routed to IRQ 0
>> 	Region 0: Memory at <ignored> (64-bit, prefetchable)
>> 	Capabilities: [40] Power Management version 2
>> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>> 		Address: 0000000000000000  Data: 0000
>> 	Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00
>> 		DevCap:	MaxPayload 128 bytes, PhantFunc 0
>> 			ExtTag- RBE-
>> 		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
>> 			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>> 			MaxPayload 128 bytes, MaxReadReq 512 bytes
>> 		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
>> 		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s
>> <256ns
>> 			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>> 		LnkCtl:	ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
>> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> 		LnkSta:	Speed 2.5GT/s (ok), Width x1 (ok)
>> 			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> 		RootCap: CRSVisible-
>> 		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
>> 		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>>
>> 0000:00:01.0 SCSI storage controller [0100]: Marvell Technology Group Ltd.
>> 88SX7042 PCI-e 4-port SATA-II [11ab:7042] (rev 02)
>> 	Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
>> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>> Stepping- SERR+ FastB2B- DisINTx-
>> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
>> <MAbort- >SERR- <PERR- INTx-
>> 	Latency: 0, Cache Line Size: 32 bytes
>> 	Interrupt: pin A routed to IRQ 12
>> 	Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=1M]
>> 	Region 2: I/O ports at 1000 [size=256]
>> 	Capabilities: [40] Power Management version 2
>> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>> 		Address: 0000000000000000  Data: 0000
>> 	Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
>> 		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us
>> 			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>> 		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
>> 			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>> 			MaxPayload 128 bytes, MaxReadReq 512 bytes
>> 		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
>> 		LnkCap:	Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s
>> <256ns
>> 			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>> 		LnkCtl:	ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
>> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> 		LnkSta:	Speed 2.5GT/s (ok), Width x1 (downgraded)
>> 			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> 	Kernel driver in use: sata_mv
>>
>> 0001:01:00.0 Memory controller [0580]: Marvell Technology Group Ltd. 88f5181
>> [Orion-1] ARM SoC [11ab:5181] (rev 03)
>> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>> Stepping- SERR+ FastB2B+ DisINTx-
>> 	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
>> <MAbort+ >SERR- <PERR- INTx-
>> 	Latency: 0, Cache Line Size: 32 bytes
>> 	Interrupt: pin A routed to IRQ 0
>> 	BIST result: 00
>> 	Region 0: Memory at <unassigned> (64-bit, prefetchable)
>> 	Region 2: Memory at <ignored> (64-bit, prefetchable)
>> 	Region 4: Memory at <ignored> (64-bit, non-prefetchable)
>> 	Expansion ROM at <ignored> [disabled]
>> 	Capabilities: [40] Power Management version 2
>> 		Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
>> 		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
>> 	Capabilities: [48] Vital Product Data
>> 		Not readable
>> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>> 		Address: 0000000000000000  Data: 0000
>> 	Capabilities: [60] PCI-X non-bridge device
>> 		Command: DPERE- ERO- RBC=512 OST=4
>> 		Status: Dev=ff:1f.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 DMOST=4
>> DMCRS=8 RSCEM- 266MHz- 533MHz-
>> 	Capabilities: [68] CompactPCI hot-swap <?>
>>
>> # lspci -nn -t -v
>> -+-[0001:01]---00.0  Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC
>> [11ab:5181]
>>  \-[0000:00]-+-00.0  Marvell Technology Group Ltd. 88f5181 [Orion-1] ARM SoC
>> [11ab:5181]
>>              \-01.0  Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port
>> SATA-II [11ab:7042]
> 
> Ok, so domain 0 is PCIe bus for sure.
> 0000:00:00.0 is PCIe Root Port (PCI-to-PCI bridge) incorrectly detected
> as Memory controller (known HW issue on all 32-bit Marvell SoCs).
> 0000:00:01.0 seems to be that SATA controller and this device is
> connected behind the PCIe Root Port. Topology is also incorrectly
> reports due to same known issue.
> 
> Then there is domain 1 (first line in -t output) on which is just one
> device 0001:01:00.0 detected as Memory controller and has capability of
> "PCI-X non-bridge device". This seems to be PCI bus. I guess that Memory
> controller is also bogus information.
> 
> What is "PCI-X non-bridge device"? I thought that "root" of the PCI bus
> should be Host Bridge.
> 
> Anyway, there is my pending patch which should fix Class ID to not
> report incorrect Memory controller identification:
> https://lore.kernel.org/linux-pci/20211102171259.9590-1-pali@kernel.org/#Z31arch:arm:mach-orion5x:pci.c

With the patch the roots are identified as follows:

# lspci -nn -vv
0000:00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 88f5181
[Orion-1] ARM SoC [11ab:5181] (rev 03)
...
0001:01:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 88f5181
[Orion-1] ARM SoC [11ab:5181] (rev 03)

Everything else remained the same.


>>>
>>>> Thomas Petazzoni originally wrote the new driver, and I think he was
>>>> planning at one point to use it for orion5x. I don't know if there were
>>>> any major problems preventing this at the time, or if it just needs to
>>>> get hooked up in the dtsi file.
>>>>
>>>>           Arnd
>>
>> -- Mauri

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

Re: [RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Andrew Lunn]

> - how to configure RTC to wake system from sleep?

The st,m41t80 binding document has:

Optional properties:
- interrupts: rtc alarm interrupt.
- clock-output-names: From common clock binding to override the default output
                      clock name
- wakeup-source: Enables wake up of host system on alarm

which you don't appear to have in your DT files.

      Andrew

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

[PATCH v2 0/3] ARM: orion5x: add D-Link DNS323 based on device treee

[Mauri Sandberg]

Hello all,

This is the second iteration of my series to add D-Link DNS323 devices,
which are based on a device tree. It adds the bindings, the device tree
source files and a new board file to take care of initialising what little
remains that cannot be done via device tree. The initialisation of MAC address
will be neater once method for passing ASCII string based address is agreed on.

Functionally this series has a dependency to Pali's mvebu pci series, which
adds support for Orion PCIe and which should be scheduled for a merge window
any time soon:
https://lore.kernel.org/linux-pci/20220905192310.22786-1-pali@kernel.org/

What currently is tested and works in rev A1
 - leds
 - keys
 - fan
 - temperature sensor
 - shutdown
 - reboot
 - mtd partitions
 - ethernet
 - PCIe and with that sata_mv

And the variants B1 and C1 need testing still.

Thanks,
Mauri

Mauri Sandberg (3):
  dt-bindings: arm: add DT binding for D-Link DNS-323
  ARM: dts: orion5x: Add D-Link DNS-323 Device Tree
  ARM: orion5x: Add D-Link DNS-323 based on Device Tree

 .../bindings/arm/marvell/marvell,orion5x.txt  |  12 +
 arch/arm/boot/dts/Makefile                    |   3 +
 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi   | 215 ++++++++++++++++++
 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts  |  44 ++++
 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts  |  39 ++++
 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts  |  81 +++++++
 arch/arm/mach-orion5x/Kconfig                 |   7 +
 arch/arm/mach-orion5x/Makefile                |   1 +
 arch/arm/mach-orion5x/board-dns323.c          | 208 +++++++++++++++++
 arch/arm/mach-orion5x/board-dt.c              |   3 +
 arch/arm/mach-orion5x/common.h                |   6 +
 11 files changed, 619 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
 create mode 100644 arch/arm/mach-orion5x/board-dns323.c


base-commit: c69cf88cda5faca0e411babb67ac0d8bfd8b4646
--
2.25.1

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

[PATCH v2 1/3] dt-bindings: arm: add DT binding for D-Link DNS-323

[Mauri Sandberg]

Add bindings for D-Link DNS-323. It introduces altogether four new
compatibles: dlink,dns323, dlink,dns323a1, dlink,dns323b1 and
dlink,dns323c1. One is for the common parts between the devices and
then there is one for each three hardware variants.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
changes from v1:
 - split patches, this one adds bindings
---
 .../bindings/arm/marvell/marvell,orion5x.txt         | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
index 748a8f287462..ead80ed2262f 100644
--- a/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
@@ -23,3 +23,15 @@ board. Currently known boards are:
 "marvell,rd-88f5182-nas"
 "maxtor,shared-storage-2"
 "netgear,wnr854t"
+
+The D-Link DNS-323 has three different revisions. Their common parts are
+collected in:
+
+"dlink,dns323"
+
+The three different variants (A1 being 88f5181, the two others being 88f5182)
+are specified with compatibles:
+
+"dlink,dns323a1"
+"dlink,dns323b1"
+"dlink,dns323c1"
-- 
2.25.1


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

Re: [PATCH v2 1/3] dt-bindings: arm: add DT binding for D-Link DNS-323

[Andrew Lunn]

On Thu, Sep 22, 2022 at 11:24:56PM +0300, Mauri Sandberg wrote:
> Add bindings for D-Link DNS-323. It introduces altogether four new
> compatibles: dlink,dns323, dlink,dns323a1, dlink,dns323b1 and
> dlink,dns323c1. One is for the common parts between the devices and
> then there is one for each three hardware variants.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>

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

    Andrew

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

Re: [PATCH v2 1/3] dt-bindings: arm: add DT binding for D-Link DNS-323

[Krzysztof Kozlowski]

On 22/09/2022 22:24, Mauri Sandberg wrote:
> Add bindings for D-Link DNS-323. It introduces altogether four new
> compatibles: dlink,dns323, dlink,dns323a1, dlink,dns323b1 and
> dlink,dns323c1. One is for the common parts between the devices and
> then there is one for each three hardware variants.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof


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

[PATCH v2 2/3] ARM: dts: orion5x: Add D-Link DNS-323 Device Tree

[Mauri Sandberg]

Add a device tree for D-Link DNS-323. The device has three different
variants; A1, B1 and C1. Common parts are included in a .dtsi file
and each hardware variant has its own .dts file.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
changes from v1
 - split patches, this one adds the device tree
 - set pciec and pcie1 nodes to 'okay'
---
 arch/arm/boot/dts/Makefile                   |   3 +
 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi  | 215 +++++++++++++++++++
 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts |  44 ++++
 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts |  39 ++++
 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts |  81 +++++++
 5 files changed, 382 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
 create mode 100644 arch/arm/boot/dts/orion5x-dlink-dns323c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 05d8aef6e5d2..bc41749cd889 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -997,6 +997,9 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
 	dra71-evm.dtb \
 	dra76-evm.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += \
+	orion5x-dlink-dns323a1.dtb \
+	orion5x-dlink-dns323b1.dtb \
+	orion5x-dlink-dns323c1.dtb \
 	orion5x-kuroboxpro.dtb \
 	orion5x-lacie-d2-network.dtb \
 	orion5x-lacie-ethernet-disk-mini-v2.dtb \
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
new file mode 100644
index 000000000000..05b0b134edb3
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323.dtsi
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/ {
+	model = "D-Link DNS-323";
+	compatible = "dlink,dns323", "marvell,orion5x";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x4000000>; /* 64 MB */
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,  /* on-chip peripheral registers */
+			 <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,     /* SRAM for crypto */
+			 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x800000>;  /* device bus mapping (boot) */
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&pmx_gpio_keys>;
+		pinctrl-names = "default";
+
+		key-0 {
+			label = "Power button";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+		};
+
+		key-1 {
+			label = "Reset button";
+			linux,code = <KEY_RESTART>;
+			gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_gpio_leds>;
+		pinctrl-names = "default";
+
+		led-0 {
+			label = "amber:right";
+			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+		};
+
+		led-1 {
+			label = "amber:left";
+			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+
+		led-2 {
+			label = "blue:power";
+			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+			default-state = "on";
+		};
+	};
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		pinctrl-0 = <&pmx_power_off>;
+		pinctrl-names = "default";
+
+		gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+		timeout-ms = <3000>;
+	};
+};
+
+&devbus_bootcs {
+	status = "okay";
+	devbus,keep-config;
+
+	flash@0 {
+		compatible = "cfi-flash";
+		reg = <0 0x800000>;
+		bank-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "MTD1";
+				reg = <0x000000 0x010000>;
+				read-only;
+			};
+
+			partition@10000 {
+				label = "MTD2";
+				reg = <0x010000 0x010000>;
+				read-only;
+			};
+
+			partition@20000 {
+				label = "Linux Kernel";
+				reg = <0x020000 0x180000>;
+			};
+
+			partition@1a0000 {
+				label = "File System";
+				reg = <0x1a0000 0x630000>;
+			};
+
+			uboot: partition@7d0000 {
+				label = "U-boot";
+				reg = <0x7d0000 0x030000>;
+				read-only;
+			};
+		};
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&i2c {
+	status = "okay";
+	clock-frequency = <100000>;
+
+	/* fan speed PWM */
+	fan@3e {
+		compatible = "g760a";
+		reg = <0x3e>;
+	};
+
+	/* temp sensor and thermal watchdog */
+	temperature-sensor@48 {
+		compatible = "gmt,g751";
+		reg = <0x48>;
+	};
+
+	/* RTC w/ alarm */
+	rtc@68 {
+		compatible = "st,m41t80";
+		reg = <0x68>;
+	};
+};
+
+&mdio {
+	status = "okay";
+
+	ethphy: ethernet-phy {
+		reg = <8>;
+	};
+};
+
+&eth {
+	status = "okay";
+	pinctrl-0 = <&pmx_ge>;
+	pinctrl-names = "default";
+	clocks = <&core_clk 0>;
+};
+
+&ethport {
+	phy-handle = <&ethphy>;
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&pinctrl {
+	pmx_gpio_leds: pmx-gpio-leds {
+		marvell,pins = "mpp1", "mpp2", "mpp5";
+		marvell,function = "gpio";
+	};
+
+	pmx_gpio_misc: pmx-gpio-misc {
+		/* set marvell,pins in board file */
+		marvell,function = "gpio";
+	};
+
+	pmx_power_off: pmx-power-off {
+		marvell,pins = "mpp8";
+		marvell,function = "gpio";
+	};
+
+	pmx_gpio_keys: pmx-gpio-keys {
+		marvell,pins = "mpp9", "mpp10";
+		marvell,function = "gpio";
+	};
+
+	pmx_ge: pmx-ge {
+		marvell,function = "ge";
+	};
+};
+
+&sata {
+	pinctrl-0 = <&pmx_sata0 &pmx_sata1>;
+	pinctrl-names = "default";
+	status = "okay";
+	nr-ports = <2>;
+};
+
+&pciec {
+	status = "okay";
+};
+
+&pcie0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323a1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
new file mode 100644
index 000000000000..235cc842f289
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323a1.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "orion5x-mv88f5181.dtsi"
+#include "orion5x-dlink-dns323.dtsi"
+
+/ {
+	model = "D-Link DNS-323 rev A1";
+	compatible = "dlink,dns323a1", "dlink,dns323", "marvell,orion5x-88f5181",
+		     "marvell,orion5x";
+};
+
+/delete-node/ &sata;
+
+&gpio0 {
+	pinctrl-0 = <&pmx_gpio_misc>;
+	pinctrl-names = "default";
+
+	/* The DNS323 rev A1 power LED requires GPIO 4 to be low. */
+	pin_gpio0_4 {
+		gpio-hog;
+		gpios = <4 GPIO_ACTIVE_LOW>;
+		output-high;
+		line-name = "Power led enable";
+	};
+};
+
+&pmx_gpio_misc {
+	marvell,pins = "mpp4";
+};
+
+&pmx_ge {
+	marvell,pins = "mpp11", "mpp12", "mpp13", "mpp14", "mpp15",
+		       "mpp16", "mpp17", "mpp18", "mpp19";
+};
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
new file mode 100644
index 000000000000..e01ba809ffca
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "orion5x-mv88f5182.dtsi"
+#include "orion5x-dlink-dns323.dtsi"
+
+/ {
+	model = "D-Link DNS-323 rev B1";
+	compatible = "dlink,dns323b1", "dlink,dns323", "marvell,orion5x-88f5182",
+		     "marvell,orion5x";
+};
+
+&gpio0 {
+	pinctrl-0 = <&pmx_gpio_misc>;
+	pinctrl-names = "default";
+
+	/* The rev B1 has a flag to indicate the system is up.
+	 * Without this flag set, power LED will flash and cannot be
+	 * controlled via gpio-leds.
+	 */
+	pin_gpio0_3 {
+		gpio-hog;
+		gpios = <3 GPIO_ACTIVE_LOW>;
+		output-high;
+		line-name = "System up";
+	};
+};
+
+&pmx_gpio_misc {
+	marvell,pins = "mpp3";
+};
diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323c1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
new file mode 100644
index 000000000000..c24da08bdc8f
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-dlink-dns323c1.dts
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "orion5x-mv88f5182.dtsi"
+#include "orion5x-dlink-dns323.dtsi"
+
+/ {
+	model = "D-Link DNS-323 rev C1";
+	compatible = "dlink,dns323c1", "dlink,dns323", "marvell,orion5x-88f5182",
+		     "marvell,orion5x";
+
+	fan {
+		compatible = "gpio-fan";
+		pinctrl-0 = <&pmx_gpio_fan>;
+		pinctrl-names = "default";
+
+		gpios = <&gpio0 19 GPIO_ACTIVE_LOW
+			 &gpio0 18 GPIO_ACTIVE_LOW>;
+
+		gpio-fan,speed-map = <0    0
+				      1000 1
+				      2000 2>;
+		alarm-gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
+	};
+
+	gpio-keys {
+		/delete-node/ key-1;
+
+		key-0 {
+			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-leds {
+		led-0 {
+			gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
+		};
+
+		led-1 {
+			gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+		};
+
+		led-2 {
+			gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
+
+&i2c {
+	/delete-node/ fan@3e;
+};
+
+&pinctrl {
+	/delete-node/ pmx-gpio-misc;
+
+	pmx_gpio_fan: pmx-gpio-fan {
+		marvell,pins = "mpp10", "mpp18", "mpp19";
+		marvell,function = "gpio";
+	};
+};
+
+&pmx_gpio_leds {
+	marvell,pins = "mpp8", "mpp9", "mpp17";
+};
+
+&pmx_power_off {
+	marvell,pins = "mpp2";
+};
+
+&pmx_gpio_keys {
+	marvell,pins = "mpp1";
+};
-- 
2.25.1


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

Re: [PATCH v2 2/3] ARM: dts: orion5x: Add D-Link DNS-323 Device Tree

[Andrew Lunn]

> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +		bootargs = "console=ttyS0,115200n8 earlyprintk";

bootargs is generally not liked. Since you have stdout-path do you
need console=ttyS0,115200n8? earlyprintk should not be needed now you
have something which boots.

> +&mdio {
> +	status = "okay";
> +
> +	ethphy: ethernet-phy {
> +		reg = <8>;

Since you have a reg value, this should be ethernet-phy@9

      Andrew

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

Re: [PATCH v2 2/3] ARM: dts: orion5x: Add D-Link DNS-323 Device Tree

[Pali Rohár]

On Thursday 22 September 2022 22:45:47 Andrew Lunn wrote:
> > +&mdio {
> > +	status = "okay";
> > +
> > +	ethphy: ethernet-phy {
> > +		reg = <8>;
> 
> Since you have a reg value, this should be ethernet-phy@9

ethernet-phy@8 no?

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

Re: [PATCH v2 2/3] ARM: dts: orion5x: Add D-Link DNS-323 Device Tree

[Andrew Lunn]

On Thu, Sep 22, 2022 at 11:14:08PM +0200, Pali Rohár wrote:
> On Thursday 22 September 2022 22:45:47 Andrew Lunn wrote:
> > > +&mdio {
> > > +	status = "okay";
> > > +
> > > +	ethphy: ethernet-phy {
> > > +		reg = <8>;
> > 
> > Since you have a reg value, this should be ethernet-phy@9
> 
> ethernet-phy@8 no?

Yes, @8. Sorry.

     Andrew

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

Re: [PATCH v2 2/3] ARM: dts: orion5x: Add D-Link DNS-323 Device Tree

[Krzysztof Kozlowski]

On 22/09/2022 22:24, Mauri Sandberg wrote:
> Add a device tree for D-Link DNS-323. The device has three different
> variants; A1, B1 and C1. Common parts are included in a .dtsi file
> and each hardware variant has its own .dts file.

Thank you for your patch. There is something to discuss/improve.

> +
> +/delete-node/ &sata;
> +
> +&gpio0 {
> +	pinctrl-0 = <&pmx_gpio_misc>;
> +	pinctrl-names = "default";
> +
> +	/* The DNS323 rev A1 power LED requires GPIO 4 to be low. */
> +	pin_gpio0_4 {

No underscores in node names.

> +		gpio-hog;
> +		gpios = <4 GPIO_ACTIVE_LOW>;
> +		output-high;
> +		line-name = "Power led enable";
> +	};
> +};
> +
> +&pmx_gpio_misc {
> +	marvell,pins = "mpp4";
> +};
> +
> +&pmx_ge {
> +	marvell,pins = "mpp11", "mpp12", "mpp13", "mpp14", "mpp15",
> +		       "mpp16", "mpp17", "mpp18", "mpp19";
> +};
> diff --git a/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts b/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
> new file mode 100644
> index 000000000000..e01ba809ffca
> --- /dev/null
> +++ b/arch/arm/boot/dts/orion5x-dlink-dns323b1.dts
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include "orion5x-mv88f5182.dtsi"
> +#include "orion5x-dlink-dns323.dtsi"
> +
> +/ {
> +	model = "D-Link DNS-323 rev B1";
> +	compatible = "dlink,dns323b1", "dlink,dns323", "marvell,orion5x-88f5182",
> +		     "marvell,orion5x";
> +};
> +
> +&gpio0 {
> +	pinctrl-0 = <&pmx_gpio_misc>;
> +	pinctrl-names = "default";
> +
> +	/* The rev B1 has a flag to indicate the system is up.
> +	 * Without this flag set, power LED will flash and cannot be
> +	 * controlled via gpio-leds.
> +	 */
> +	pin_gpio0_3 {

No underscores in node names.

Best regards,
Krzysztof


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

[PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[Mauri Sandberg]

Add D-Link DNS-323 that is based on Device Tree.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
changes from v1
 - split patches, this one modifies source code
 - add DT based dns323 board file
 - don't remove any existing code
---
 arch/arm/mach-orion5x/Kconfig        |   7 +
 arch/arm/mach-orion5x/Makefile       |   1 +
 arch/arm/mach-orion5x/board-dns323.c | 208 +++++++++++++++++++++++++++
 arch/arm/mach-orion5x/board-dt.c     |   3 +
 arch/arm/mach-orion5x/common.h       |   6 +
 5 files changed, 225 insertions(+)
 create mode 100644 arch/arm/mach-orion5x/board-dns323.c

diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index 0044b2823710..1ee0d7e06828 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -68,6 +68,13 @@ config MACH_DNS323
 	  Say 'Y' here if you want your kernel to support the
 	  D-Link DNS-323 platform.
 
+config MACH_DNS323_DT
+	bool "D-Link DNS-323 (Flattened Device Tree)"
+	select ARCH_ORION5X_DT
+	help
+	  Say 'Y' here if you want your kernel to support the
+	  D-Link DNS-323 platform.
+
 config MACH_TS209
 	bool "QNAP TS-109/TS-209"
 	depends on ATAGS
diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
index 1a585a62d5e6..2ed6bafa7acb 100644
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion5x/Makefile
@@ -22,5 +22,6 @@ obj-$(CONFIG_MACH_RD88F6183AP_GE)	+= rd88f6183ap-ge-setup.o
 
 obj-$(CONFIG_ARCH_ORION5X_DT)		+= board-dt.o
 obj-$(CONFIG_MACH_D2NET_DT)	+= board-d2net.o
+obj-$(CONFIG_MACH_DNS323_DT)	+= board-dns323.o
 obj-$(CONFIG_MACH_MSS2_DT)	+= board-mss2.o
 obj-$(CONFIG_MACH_RD88F5182_DT)	+= board-rd88f5182.o
diff --git a/arch/arm/mach-orion5x/board-dns323.c b/arch/arm/mach-orion5x/board-dns323.c
new file mode 100644
index 000000000000..72a1f3e228b3
--- /dev/null
+++ b/arch/arm/mach-orion5x/board-dns323.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Mauri Sandberg <maukka@ext.kapsi.fi>
+ *
+ * Flattened Device Tree board initialization
+ *
+ * This is adapted from existing mach files and most of the source code is
+ * originally written by:
+ *  Copyright (C) 2007 Herbert Valerio Riedel <hvr@gnu.org>
+ *  Copyright (C) 2010 Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ *  Copyright 2012 (C), Jason Cooper <jason@lakedaemon.net>
+ */
+
+#include <linux/of.h>
+#include <linux/phy.h>
+#include <linux/marvell_phy.h>
+#include <linux/of_net.h>
+#include <linux/clk.h>
+#include "bridge-regs.h"
+
+/* Exposed to userspace, do not change */
+enum {
+	DNS323_REV_A1,	/* 0 */
+	DNS323_REV_B1,	/* 1 */
+	DNS323_REV_C1,	/* 2 */
+};
+
+/****************************************************************************
+ * Fix-ups
+ */
+
+static int dns323c_phy_fixup(struct phy_device *phy)
+{
+	phy->dev_flags |= MARVELL_PHY_M1118_DNS323_LEDS;
+
+	return 0;
+}
+
+/****************************************************************************
+ * Ethernet
+ */
+
+/* dns323_parse_hex_*() taken from tsx09-common.c; should a common copy of these
+ * functions be kept somewhere?
+ */
+static int __init dns323_parse_hex_nibble(char n)
+{
+	if (n >= '0' && n <= '9')
+		return n - '0';
+
+	if (n >= 'A' && n <= 'F')
+		return n - 'A' + 10;
+
+	if (n >= 'a' && n <= 'f')
+		return n - 'a' + 10;
+
+	return -1;
+}
+
+static int __init dns323_parse_hex_byte(const char *b)
+{
+	int hi;
+	int lo;
+
+	hi = dns323_parse_hex_nibble(b[0]);
+	lo = dns323_parse_hex_nibble(b[1]);
+
+	if (hi < 0 || lo < 0)
+		return -1;
+
+	return (hi << 4) | lo;
+}
+
+#define DNS323_NOR_BOOT_BASE 0xf4000000
+
+static int __init dns323_read_mac_addr(u8 *addr)
+{
+	int i;
+	char *mac_page;
+
+	/* MAC address is stored as a regular ol' string in /dev/mtdblock4
+	 * (0x007d0000-0x00800000) starting at offset 196480 (0x2ff80).
+	 */
+	mac_page = ioremap(DNS323_NOR_BOOT_BASE + 0x7d0000 + 196480, 1024);
+	if (!mac_page)
+		return -ENOMEM;
+
+	/* Sanity check the string we're looking at */
+	for (i = 0; i < 5; i++) {
+		if (*(mac_page + (i * 3) + 2) != ':')
+			goto error_fail;
+	}
+
+	for (i = 0; i < ETH_ALEN; i++)	{
+		int byte;
+
+		byte = dns323_parse_hex_byte(mac_page + (i * 3));
+		if (byte < 0)
+			goto error_fail;
+
+		addr[i] = byte;
+	}
+
+	iounmap(mac_page);
+
+	return 0;
+
+error_fail:
+	iounmap(mac_page);
+	return -EINVAL;
+}
+
+static void __init dns323_dt_eth_fixup(void)
+{
+	struct device_node *np;
+	u8 addr[ETH_ALEN];
+	int ret;
+
+	/*
+	 * The ethernet interfaces forget the MAC address assigned by u-boot
+	 * if the clocks are turned off. Usually, u-boot on orion boards
+	 * has no DT support to properly set local-mac-address property.
+	 * As a workaround, we get the MAC address that is stored in flash
+	 * and update the port device node if no valid MAC address is set.
+	 */
+	ret = dns323_read_mac_addr(addr);
+
+	if (ret) {
+		pr_warn("Unable to find MAC address in flash memory\n");
+		return;
+	}
+
+	np = of_find_compatible_node(NULL, NULL, "marvell,orion-eth-port");
+
+	if (!IS_ERR(np)) {
+		struct device_node *pnp = of_get_parent(np);
+		struct clk *clk;
+		struct property *pmac;
+		u8 tmpmac[ETH_ALEN];
+		u8 *macaddr;
+		int i;
+
+		if (!pnp)
+			return;
+
+		/* skip disabled nodes or nodes with valid MAC address*/
+		if (!of_device_is_available(pnp) ||
+		    !of_get_mac_address(np, tmpmac))
+			goto eth_fixup_skip;
+
+		clk = of_clk_get(pnp, 0);
+		if (IS_ERR(clk))
+			goto eth_fixup_skip;
+
+		/* ensure port clock is not gated to not hang CPU */
+		clk_prepare_enable(clk);
+
+		/* store MAC address register contents in local-mac-address */
+		pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
+		if (!pmac)
+			goto eth_fixup_no_mem;
+
+		pmac->value = pmac + 1;
+		pmac->length = ETH_ALEN;
+		pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
+		if (!pmac->name) {
+			kfree(pmac);
+			goto eth_fixup_no_mem;
+		}
+
+		macaddr = pmac->value;
+		for (i = 0; i < ETH_ALEN; i++)
+			macaddr[i] = addr[i];
+
+		of_update_property(np, pmac);
+
+eth_fixup_no_mem:
+		clk_disable_unprepare(clk);
+		clk_put(clk);
+eth_fixup_skip:
+		of_node_put(pnp);
+	}
+}
+
+void __init dns323_init_dt(void)
+{
+	if (of_machine_is_compatible("dlink,dns323a1")) {
+		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
+	} else if (of_machine_is_compatible("dlink,dns323c1") &&
+		IS_BUILTIN(CONFIG_PHYLIB)) {
+		/* Register fixup for the PHY LEDs */
+		phy_register_fixup_for_uid(MARVELL_PHY_ID_88E1118,
+					   MARVELL_PHY_ID_MASK,
+					   dns323c_phy_fixup);
+
+		/* Now, -this- should theorically be done by the sata_mv driver
+		 * once I figure out what's going on there. Maybe the behaviour
+		 * of the LEDs should be somewhat passed via the platform_data.
+		 * for now, just whack the register and make the LEDs happy
+		 *
+		 * Note: AFAIK, rev B1 needs the same treatement but I'll let
+		 * somebody else test it.
+		 */
+		writel(0x5, ORION5X_SATA_VIRT_BASE + 0x2c);
+	}
+
+	dns323_dt_eth_fixup();
+}
diff --git a/arch/arm/mach-orion5x/board-dt.c b/arch/arm/mach-orion5x/board-dt.c
index e3736ffc8347..670bff5e53f6 100644
--- a/arch/arm/mach-orion5x/board-dt.c
+++ b/arch/arm/mach-orion5x/board-dt.c
@@ -57,6 +57,9 @@ static void __init orion5x_dt_init(void)
 		cpu_idle_poll_ctrl(true);
 	}
 
+	if (of_machine_is_compatible("dlink,dns323"))
+		dns323_init_dt();
+
 	if (of_machine_is_compatible("maxtor,shared-storage-2"))
 		mss2_init();
 
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion5x/common.h
index eb96009e21c4..7a21f7216c65 100644
--- a/arch/arm/mach-orion5x/common.h
+++ b/arch/arm/mach-orion5x/common.h
@@ -75,6 +75,12 @@ extern void mss2_init(void);
 static inline void mss2_init(void) {}
 #endif
 
+#ifdef CONFIG_MACH_DNS323_DT
+extern void dns323_init_dt(void);
+#else
+static inline void dns323_init_dt(void) {}
+#endif
+
 /*****************************************************************************
  * Helpers to access Orion registers
  ****************************************************************************/
-- 
2.25.1


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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[Andrew Lunn]

> +static void __init dns323_dt_eth_fixup(void)
> +{
> +	struct device_node *np;
> +	u8 addr[ETH_ALEN];
> +	int ret;
> +
> +	/*
> +	 * The ethernet interfaces forget the MAC address assigned by u-boot
> +	 * if the clocks are turned off. Usually, u-boot on orion boards
> +	 * has no DT support to properly set local-mac-address property.
> +	 * As a workaround, we get the MAC address that is stored in flash
> +	 * and update the port device node if no valid MAC address is set.
> +	 */

This is true for Kirkwood, but orion5x does not have any clocks to
gate. So i'm pretty sure this is not true. You copied this code for a
different reason. Please document here the real reason for this code.

> +	ret = dns323_read_mac_addr(addr);
> +
> +	if (ret) {
> +		pr_warn("Unable to find MAC address in flash memory\n");
> +		return;
> +	}
> +
> +	np = of_find_compatible_node(NULL, NULL, "marvell,orion-eth-port");
> +
> +	if (!IS_ERR(np)) {
> +		struct device_node *pnp = of_get_parent(np);
> +		struct clk *clk;
> +		struct property *pmac;
> +		u8 tmpmac[ETH_ALEN];
> +		u8 *macaddr;
> +		int i;
> +
> +		if (!pnp)
> +			return;
> +
> +		/* skip disabled nodes or nodes with valid MAC address*/
> +		if (!of_device_is_available(pnp) ||
> +		    !of_get_mac_address(np, tmpmac))
> +			goto eth_fixup_skip;
> +
> +		clk = of_clk_get(pnp, 0);
> +		if (IS_ERR(clk))
> +			goto eth_fixup_skip;
> +
> +		/* ensure port clock is not gated to not hang CPU */
> +		clk_prepare_enable(clk);

I'm pretty sure this clock stuff is not needed. Please comment it out
and see if the machine locks up. Kirkwood just stops dead if you
access registers when there clocks are disabled. For Orion5x, the
ethernet should always have a clock.

> +
> +		/* store MAC address register contents in local-mac-address */
> +		pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
> +		if (!pmac)
> +			goto eth_fixup_no_mem;
> +
> +		pmac->value = pmac + 1;
> +		pmac->length = ETH_ALEN;
> +		pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
> +		if (!pmac->name) {
> +			kfree(pmac);
> +			goto eth_fixup_no_mem;
> +		}
> +
> +		macaddr = pmac->value;
> +		for (i = 0; i < ETH_ALEN; i++)
> +			macaddr[i] = addr[i];
> +
> +		of_update_property(np, pmac);
> +
> +eth_fixup_no_mem:
> +		clk_disable_unprepare(clk);
> +		clk_put(clk);
> +eth_fixup_skip:
> +		of_node_put(pnp);
> +	}
> +}
> +
> +void __init dns323_init_dt(void)
> +{
> +	if (of_machine_is_compatible("dlink,dns323a1")) {
> +		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */

I spotted this in dns323-setup.c as well. Do you have any idea what it
does?

	Andrew

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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[maukka]

On 23.9.2022 00:10, Andrew Lunn wrote:
>> +static void __init dns323_dt_eth_fixup(void)
>> +{
>> +	struct device_node *np;
>> +	u8 addr[ETH_ALEN];
>> +	int ret;
>> +
>> +	/*
>> +	 * The ethernet interfaces forget the MAC address assigned by u-boot
>> +	 * if the clocks are turned off. Usually, u-boot on orion boards
>> +	 * has no DT support to properly set local-mac-address property.
>> +	 * As a workaround, we get the MAC address that is stored in flash
>> +	 * and update the port device node if no valid MAC address is set.
>> +	 */
> 
> This is true for Kirkwood, but orion5x does not have any clocks to
> gate. So i'm pretty sure this is not true. You copied this code for a
> different reason. Please document here the real reason for this code.
> 

Yes, will do. To my understanding it looks like uboot does not pass 
anything
to the kernel.

>> +	ret = dns323_read_mac_addr(addr);
>> +
>> +	if (ret) {
>> +		pr_warn("Unable to find MAC address in flash memory\n");
>> +		return;
>> +	}
>> +
>> +	np = of_find_compatible_node(NULL, NULL, "marvell,orion-eth-port");
>> +
>> +	if (!IS_ERR(np)) {
>> +		struct device_node *pnp = of_get_parent(np);
>> +		struct clk *clk;
>> +		struct property *pmac;
>> +		u8 tmpmac[ETH_ALEN];
>> +		u8 *macaddr;
>> +		int i;
>> +
>> +		if (!pnp)
>> +			return;
>> +
>> +		/* skip disabled nodes or nodes with valid MAC address*/
>> +		if (!of_device_is_available(pnp) ||
>> +		    !of_get_mac_address(np, tmpmac))
>> +			goto eth_fixup_skip;
>> +
>> +		clk = of_clk_get(pnp, 0);
>> +		if (IS_ERR(clk))
>> +			goto eth_fixup_skip;
>> +
>> +		/* ensure port clock is not gated to not hang CPU */
>> +		clk_prepare_enable(clk);
> 
> I'm pretty sure this clock stuff is not needed. Please comment it out
> and see if the machine locks up. Kirkwood just stops dead if you
> access registers when there clocks are disabled. For Orion5x, the
> ethernet should always have a clock.
> 

Will do.

>> +
>> +		/* store MAC address register contents in local-mac-address */
>> +		pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL);
>> +		if (!pmac)
>> +			goto eth_fixup_no_mem;
>> +
>> +		pmac->value = pmac + 1;
>> +		pmac->length = ETH_ALEN;
>> +		pmac->name = kstrdup("local-mac-address", GFP_KERNEL);
>> +		if (!pmac->name) {
>> +			kfree(pmac);
>> +			goto eth_fixup_no_mem;
>> +		}
>> +
>> +		macaddr = pmac->value;
>> +		for (i = 0; i < ETH_ALEN; i++)
>> +			macaddr[i] = addr[i];
>> +
>> +		of_update_property(np, pmac);
>> +
>> +eth_fixup_no_mem:
>> +		clk_disable_unprepare(clk);
>> +		clk_put(clk);
>> +eth_fixup_skip:
>> +		of_node_put(pnp);
>> +	}
>> +}
>> +
>> +void __init dns323_init_dt(void)
>> +{
>> +	if (of_machine_is_compatible("dlink,dns323a1")) {
>> +		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
> 
> I spotted this in dns323-setup.c as well. Do you have any idea what it
> does?
> 

No idea. I have tried to replicate what was in dns323-setup.c as exactly 
as possible.
I can try to leave it out and see if anything changes.


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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[Andrew Lunn]

> > > +	if (of_machine_is_compatible("dlink,dns323a1")) {
> > > +		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
> > 
> > I spotted this in dns323-setup.c as well. Do you have any idea what it
> > does?
> > 
> 
> No idea. I have tried to replicate what was in dns323-setup.c as exactly as
> possible.
> I can try to leave it out and see if anything changes.

It is best to keep what we don't understand. It will be there for a
reason.

	Andrew

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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[Pali Rohár]

On Friday 23 September 2022 14:12:24 Andrew Lunn wrote:
> > > > +	if (of_machine_is_compatible("dlink,dns323a1")) {
> > > > +		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
> > > 
> > > I spotted this in dns323-setup.c as well. Do you have any idea what it
> > > does?
> > > 
> > 
> > No idea. I have tried to replicate what was in dns323-setup.c as exactly as
> > possible.
> > I can try to leave it out and see if anything changes.
> 
> It is best to keep what we don't understand. It will be there for a
> reason.
> 
> 	Andrew

Hello! I tried to index all publicly available Marvell SoC
documentations into kernel documentation subfolder:
https://docs.kernel.org/arm/marvell.html

For Orion there is linked Datasheet and User Manual, so you could try to
find in those documents that mentioned register and check what it is
doing.

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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[maukka]

On 23.9.2022 21:02, Pali Rohár wrote:
> On Friday 23 September 2022 14:12:24 Andrew Lunn wrote:
>> > > > +	if (of_machine_is_compatible("dlink,dns323a1")) {
>> > > > +		writel(0, MPP_DEV_CTRL);		/* DEV_D[31:16] */
>> > >
>> > > I spotted this in dns323-setup.c as well. Do you have any idea what it
>> > > does?
>> > >
>> >
>> > No idea. I have tried to replicate what was in dns323-setup.c as exactly as
>> > possible.
>> > I can try to leave it out and see if anything changes.
>> 
>> It is best to keep what we don't understand. It will be there for a
>> reason.
>> 
>> 	Andrew
> 
> Hello! I tried to index all publicly available Marvell SoC
> documentations into kernel documentation subfolder:
> https://docs.kernel.org/arm/marvell.html
> 
> For Orion there is linked Datasheet and User Manual, so you could try 
> to
> find in those documents that mentioned register and check what it is
> doing.

MPP_DEV_CTRL refers to register at address 0x10008. According to the 
88F5152 user manual it's
'Device Multiplex Control Register' Offset: 0x10008.

Bits    Field     Type/InitVal     Description
[31:0]  Reserved  RES 0x03FF0000   Reserved. NOTE: Must be 0x03FF0000'.

DEV_D[31:16] receives no hits in the documentation, only to DEV_D[15:0] 
are referred.

Maybe 88F5151 is different, hard to say.

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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[Arnd Bergmann]

On Thu, Sep 22, 2022, at 10:24 PM, Mauri Sandberg wrote:
> +
> +/* dns323_parse_hex_*() taken from tsx09-common.c; should a common 
> copy of these
> + * functions be kept somewhere?
> + */
> +static int __init dns323_parse_hex_nibble(char n)
> +{
> +	if (n >= '0' && n <= '9')
> +		return n - '0';
> +
> +	if (n >= 'A' && n <= 'F')
> +		return n - 'A' + 10;
> +
> +	if (n >= 'a' && n <= 'f')
> +		return n - 'a' + 10;
> +
> +	return -1;
> +}
> +
> +static int __init dns323_parse_hex_byte(const char *b)
> +{
> +	int hi;
> +	int lo;
> +
> +	hi = dns323_parse_hex_nibble(b[0]);
> +	lo = dns323_parse_hex_nibble(b[1]);
> +
> +	if (hi < 0 || lo < 0)
> +		return -1;
> +
> +	return (hi << 4) | lo;
> +}
> +

Can you use simple_strntoull() to parse the address into a u64 instead?

> +static int __init dns323_read_mac_addr(u8 *addr)
> +{
> +	int i;
> +	char *mac_page;
> +
> +	/* MAC address is stored as a regular ol' string in /dev/mtdblock4
> +	 * (0x007d0000-0x00800000) starting at offset 196480 (0x2ff80).
> +	 */
> +	mac_page = ioremap(DNS323_NOR_BOOT_BASE + 0x7d0000 + 196480, 1024);
> +	if (!mac_page)
> +		return -ENOMEM;

It would be nicer to use of_iomap() on the nor device than a
hardcoded physical address here, at least if that doesn't add
too much extra complexity.

     Arnd

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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[maukka]

On 23.9.2022 00:39, Arnd Bergmann wrote:
> On Thu, Sep 22, 2022, at 10:24 PM, Mauri Sandberg wrote:
>> +
>> +/* dns323_parse_hex_*() taken from tsx09-common.c; should a common
>> copy of these
>> + * functions be kept somewhere?
>> + */
>> +static int __init dns323_parse_hex_nibble(char n)
>> +{
>> +	if (n >= '0' && n <= '9')
>> +		return n - '0';
>> +
>> +	if (n >= 'A' && n <= 'F')
>> +		return n - 'A' + 10;
>> +
>> +	if (n >= 'a' && n <= 'f')
>> +		return n - 'a' + 10;
>> +
>> +	return -1;
>> +}
>> +
>> +static int __init dns323_parse_hex_byte(const char *b)
>> +{
>> +	int hi;
>> +	int lo;
>> +
>> +	hi = dns323_parse_hex_nibble(b[0]);
>> +	lo = dns323_parse_hex_nibble(b[1]);
>> +
>> +	if (hi < 0 || lo < 0)
>> +		return -1;
>> +
>> +	return (hi << 4) | lo;
>> +}
>> +
> 
> Can you use simple_strntoull() to parse the address into a u64 instead?
> 
Nice idea. Its current replacement seems to be kstrtoull(). I'll have to 
do
it byte by byte, right? Or what do you have in mind with 64bit unsigned?

>> +static int __init dns323_read_mac_addr(u8 *addr)
>> +{
>> +	int i;
>> +	char *mac_page;
>> +
>> +	/* MAC address is stored as a regular ol' string in /dev/mtdblock4
>> +	 * (0x007d0000-0x00800000) starting at offset 196480 (0x2ff80).
>> +	 */
>> +	mac_page = ioremap(DNS323_NOR_BOOT_BASE + 0x7d0000 + 196480, 1024);
>> +	if (!mac_page)
>> +		return -ENOMEM;
> 
> It would be nicer to use of_iomap() on the nor device than a
> hardcoded physical address here, at least if that doesn't add
> too much extra complexity.
> 

I'll look into this.

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

Re: [PATCH v2 3/3] ARM: orion5x: Add D-Link DNS-323 based on Device Tree

[Arnd Bergmann]

On Fri, Sep 23, 2022, at 11:13 AM, maukka@ext.kapsi.fi wrote:
> On 23.9.2022 00:39, Arnd Bergmann wrote:
>> Can you use simple_strntoull() to parse the address into a u64 instead?
>> 
> Nice idea. Its current replacement seems to be kstrtoull().

Right.

> I'll have to do
> it byte by byte, right? Or what do you have in mind with 64bit unsigned?

I misread your code and assumed it was stored as a 12-digit
hexadecimal number, but you are right: with the colons you still
need to iterate the bytes.

I looked a little further and found the mac_pton() function
that I think does exactly what you need.

      Arnd

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