* [PATCH v3 01/13] ARM: dts: armada-375: Add node labels
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
As it was previously done for kirkwood and for aramda 370/XP, this adds
missing node labels to Armada 375 and SoC specific nodes to allow to
reference them more easily.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 62 +++++++++++++++++++--------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 45fa92f9cf5c..e016ff3ed970 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -84,12 +84,12 @@
#size-cells = <0>;
enable-method = "marvell,armada-375-smp";
- cpu@0 {
+ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
- cpu@1 {
+ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
@@ -115,7 +115,7 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus-bootcs {
+ devbus_bootcs: devbus-bootcs {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -125,7 +125,7 @@
status = "disabled";
};
- devbus-cs0 {
+ devbus_cs0: devbus-cs0 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -135,7 +135,7 @@
status = "disabled";
};
- devbus-cs1 {
+ devbus_cs1: devbus-cs1 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -145,7 +145,7 @@
status = "disabled";
};
- devbus-cs2 {
+ devbus_cs2: devbus-cs2 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -155,7 +155,7 @@
status = "disabled";
};
- devbus-cs3 {
+ devbus_cs3: devbus-cs3 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
@@ -182,12 +182,12 @@
prefetch-data = <1>;
};
- scu@c000 {
+ scu: scu@c000 {
compatible = "arm,cortex-a9-scu";
reg = <0xc000 0x58>;
};
- timer@c600 {
+ timer0: timer@c600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xc600 0x20>;
interrupts = <GIC_PPI 13 (IRQ_TYPE_EDGE_RISING | GIC_CPU_MASK_SIMPLE(2))>;
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio {
+ mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
@@ -212,7 +212,7 @@
};
/* Network controller */
- ethernet@f0000 {
+ ethernet: ethernet@f0000 {
compatible = "marvell,armada-375-pp2";
reg = <0xf0000 0xa000>, /* Packet Processor regs */
<0xc0000 0x3060>, /* LMS regs */
@@ -235,7 +235,7 @@
};
};
- rtc@10300 {
+ rtc: rtc@10300 {
compatible = "marvell,orion-rtc";
reg = <0x10300 0x20>;
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
@@ -307,7 +307,7 @@
status = "disabled";
};
- pinctrl {
+ pinctrl: pinctrl {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
@@ -382,7 +382,7 @@
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
};
- system-controller@18200 {
+ systemc: system-controller@18200 {
compatible = "marvell,armada-375-system-controller";
reg = <0x18200 0x100>;
};
@@ -415,7 +415,7 @@
interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
};
- timer@20300 {
+ timer1: timer@20300 {
compatible = "marvell,armada-375-timer", "marvell,armada-370-timer";
reg = <0x20300 0x30>, <0x21040 0x30>;
interrupts-extended = <&gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
@@ -428,24 +428,24 @@
clock-names = "nbclk", "fixed";
};
- watchdog@20300 {
+ watchdog: watchdog@20300 {
compatible = "marvell,armada-375-wdt";
reg = <0x20300 0x34>, <0x20704 0x4>, <0x18254 0x4>;
clocks = <&coreclk 0>, <&refclk>;
clock-names = "nbclk", "fixed";
};
- cpurst@20800 {
+ cpurst: cpurst@20800 {
compatible = "marvell,armada-370-cpu-reset";
reg = <0x20800 0x10>;
};
- coherency-fabric@21010 {
+ coherencyfab: coherency-fabric@21010 {
compatible = "marvell,armada-375-coherency-fabric";
reg = <0x21010 0x1c>;
};
- usb@50000 {
+ usb0: usb@50000 {
compatible = "marvell,orion-ehci";
reg = <0x50000 0x500>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
@@ -455,7 +455,7 @@
status = "disabled";
};
- usb@54000 {
+ usb1: usb@54000 {
compatible = "marvell,orion-ehci";
reg = <0x54000 0x500>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
@@ -463,7 +463,7 @@
status = "disabled";
};
- usb3@58000 {
+ usb2: usb3@58000 {
compatible = "marvell,armada-375-xhci";
reg = <0x58000 0x20000>,<0x5b880 0x80>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
@@ -473,7 +473,7 @@
status = "disabled";
};
- xor@60800 {
+ xor0: xor@60800 {
compatible = "marvell,orion-xor";
reg = <0x60800 0x100
0x60A00 0x100>;
@@ -493,7 +493,7 @@
};
};
- xor@60900 {
+ xor1: xor@60900 {
compatible = "marvell,orion-xor";
reg = <0x60900 0x100
0x60b00 0x100>;
@@ -513,7 +513,7 @@
};
};
- crypto@90000 {
+ cesa: crypto@90000 {
compatible = "marvell,armada-375-crypto";
reg = <0x90000 0x10000>;
reg-names = "regs";
@@ -528,7 +528,7 @@
marvell,crypto-sram-size = <0x800>;
};
- sata@a0000 {
+ sata: sata@a0000 {
compatible = "marvell,armada-370-sata";
reg = <0xa0000 0x5000>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -537,7 +537,7 @@
status = "disabled";
};
- nand@d0000 {
+ nand: nand@d0000 {
compatible = "marvell,armada370-nand";
reg = <0xd0000 0x54>;
#address-cells = <1>;
@@ -547,7 +547,7 @@
status = "disabled";
};
- mvsdio@d4000 {
+ sdio: mvsdio@d4000 {
compatible = "marvell,orion-sdio";
reg = <0xd4000 0x200>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
@@ -559,7 +559,7 @@
status = "disabled";
};
- thermal@e8078 {
+ thermal: thermal@e8078 {
compatible = "marvell,armada375-thermal";
reg = <0xe8078 0x4>, <0xe807c 0x8>;
status = "okay";
@@ -580,7 +580,7 @@
};
};
- pcie-controller {
+ pciec: pcie-controller {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
@@ -599,7 +599,7 @@
0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 1 MEM */
0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 1 IO */>;
- pcie@1,0 {
+ pcie0: pcie@1,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
reg = <0x0800 0 0 0 0>;
@@ -616,7 +616,7 @@
status = "disabled";
};
- pcie@2,0 {
+ pcie1: pcie@2,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
reg = <0x1000 0 0 0 0>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 01/13] ARM: dts: armada-375: Add node labels
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
As it was previously done for kirkwood and for aramda 370/XP, this adds
missing node labels to Armada 375 and SoC specific nodes to allow to
reference them more easily.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 62 +++++++++++++++++++--------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 45fa92f9cf5c..e016ff3ed970 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -84,12 +84,12 @@
#size-cells = <0>;
enable-method = "marvell,armada-375-smp";
- cpu at 0 {
+ cpu0: cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
- cpu at 1 {
+ cpu1: cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
@@ -115,7 +115,7 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus-bootcs {
+ devbus_bootcs: devbus-bootcs {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -125,7 +125,7 @@
status = "disabled";
};
- devbus-cs0 {
+ devbus_cs0: devbus-cs0 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -135,7 +135,7 @@
status = "disabled";
};
- devbus-cs1 {
+ devbus_cs1: devbus-cs1 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -145,7 +145,7 @@
status = "disabled";
};
- devbus-cs2 {
+ devbus_cs2: devbus-cs2 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -155,7 +155,7 @@
status = "disabled";
};
- devbus-cs3 {
+ devbus_cs3: devbus-cs3 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
@@ -182,12 +182,12 @@
prefetch-data = <1>;
};
- scu at c000 {
+ scu: scu at c000 {
compatible = "arm,cortex-a9-scu";
reg = <0xc000 0x58>;
};
- timer at c600 {
+ timer0: timer at c600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0xc600 0x20>;
interrupts = <GIC_PPI 13 (IRQ_TYPE_EDGE_RISING | GIC_CPU_MASK_SIMPLE(2))>;
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio {
+ mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
@@ -212,7 +212,7 @@
};
/* Network controller */
- ethernet at f0000 {
+ ethernet: ethernet at f0000 {
compatible = "marvell,armada-375-pp2";
reg = <0xf0000 0xa000>, /* Packet Processor regs */
<0xc0000 0x3060>, /* LMS regs */
@@ -235,7 +235,7 @@
};
};
- rtc at 10300 {
+ rtc: rtc at 10300 {
compatible = "marvell,orion-rtc";
reg = <0x10300 0x20>;
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
@@ -307,7 +307,7 @@
status = "disabled";
};
- pinctrl {
+ pinctrl: pinctrl {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
@@ -382,7 +382,7 @@
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
};
- system-controller at 18200 {
+ systemc: system-controller at 18200 {
compatible = "marvell,armada-375-system-controller";
reg = <0x18200 0x100>;
};
@@ -415,7 +415,7 @@
interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
};
- timer at 20300 {
+ timer1: timer at 20300 {
compatible = "marvell,armada-375-timer", "marvell,armada-370-timer";
reg = <0x20300 0x30>, <0x21040 0x30>;
interrupts-extended = <&gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
@@ -428,24 +428,24 @@
clock-names = "nbclk", "fixed";
};
- watchdog at 20300 {
+ watchdog: watchdog at 20300 {
compatible = "marvell,armada-375-wdt";
reg = <0x20300 0x34>, <0x20704 0x4>, <0x18254 0x4>;
clocks = <&coreclk 0>, <&refclk>;
clock-names = "nbclk", "fixed";
};
- cpurst at 20800 {
+ cpurst: cpurst at 20800 {
compatible = "marvell,armada-370-cpu-reset";
reg = <0x20800 0x10>;
};
- coherency-fabric at 21010 {
+ coherencyfab: coherency-fabric at 21010 {
compatible = "marvell,armada-375-coherency-fabric";
reg = <0x21010 0x1c>;
};
- usb at 50000 {
+ usb0: usb at 50000 {
compatible = "marvell,orion-ehci";
reg = <0x50000 0x500>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
@@ -455,7 +455,7 @@
status = "disabled";
};
- usb at 54000 {
+ usb1: usb at 54000 {
compatible = "marvell,orion-ehci";
reg = <0x54000 0x500>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
@@ -463,7 +463,7 @@
status = "disabled";
};
- usb3 at 58000 {
+ usb2: usb3 at 58000 {
compatible = "marvell,armada-375-xhci";
reg = <0x58000 0x20000>,<0x5b880 0x80>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
@@ -473,7 +473,7 @@
status = "disabled";
};
- xor at 60800 {
+ xor0: xor at 60800 {
compatible = "marvell,orion-xor";
reg = <0x60800 0x100
0x60A00 0x100>;
@@ -493,7 +493,7 @@
};
};
- xor at 60900 {
+ xor1: xor at 60900 {
compatible = "marvell,orion-xor";
reg = <0x60900 0x100
0x60b00 0x100>;
@@ -513,7 +513,7 @@
};
};
- crypto at 90000 {
+ cesa: crypto at 90000 {
compatible = "marvell,armada-375-crypto";
reg = <0x90000 0x10000>;
reg-names = "regs";
@@ -528,7 +528,7 @@
marvell,crypto-sram-size = <0x800>;
};
- sata at a0000 {
+ sata: sata at a0000 {
compatible = "marvell,armada-370-sata";
reg = <0xa0000 0x5000>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -537,7 +537,7 @@
status = "disabled";
};
- nand at d0000 {
+ nand: nand at d0000 {
compatible = "marvell,armada370-nand";
reg = <0xd0000 0x54>;
#address-cells = <1>;
@@ -547,7 +547,7 @@
status = "disabled";
};
- mvsdio at d4000 {
+ sdio: mvsdio at d4000 {
compatible = "marvell,orion-sdio";
reg = <0xd4000 0x200>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
@@ -559,7 +559,7 @@
status = "disabled";
};
- thermal at e8078 {
+ thermal: thermal at e8078 {
compatible = "marvell,armada375-thermal";
reg = <0xe8078 0x4>, <0xe807c 0x8>;
status = "okay";
@@ -580,7 +580,7 @@
};
};
- pcie-controller {
+ pciec: pcie-controller {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
@@ -599,7 +599,7 @@
0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 1 MEM */
0x81000000 0x2 0 MBUS_ID(0x04, 0xd0) 0 1 0 /* Port 1 IO */>;
- pcie at 1,0 {
+ pcie0: pcie at 1,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
reg = <0x0800 0 0 0 0>;
@@ -616,7 +616,7 @@
status = "disabled";
};
- pcie at 2,0 {
+ pcie1: pcie at 2,0 {
device_type = "pci";
assigned-addresses = <0x82000800 0 0x44000 0 0x2000>;
reg = <0x1000 0 0 0 0>;
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 02/13] ARM: dts: armada-375: Use the node labels
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Use the node label when possible. As a result it flattens the device tree
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375-db.dts | 269 ++++++++++++++++++------------------
1 file changed, 136 insertions(+), 133 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index cded5f0a262d..b33a674088ed 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -69,138 +69,141 @@
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
- internal-regs {
- spi@10600 {
- pinctrl-0 = <&spi0_pins>;
- pinctrl-names = "default";
- /*
- * SPI conflicts with NAND, so we disable it
- * here, and select NAND as the enabled device
- * by default.
- */
- status = "disabled";
-
- spi-flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "n25q128a13", "jedec,spi-nor";
- reg = <0>; /* Chip select 0 */
- spi-max-frequency = <108000000>;
- };
- };
-
- i2c@11000 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- };
-
- i2c@11100 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c1_pins>;
- pinctrl-names = "default";
- };
-
- serial@12000 {
- status = "okay";
- };
-
- pinctrl {
- sdio_st_pins: sdio-st-pins {
- marvell,pins = "mpp44", "mpp45";
- marvell,function = "gpio";
- };
- };
-
- sata@a0000 {
- status = "okay";
- nr-ports = <2>;
- };
-
- nand: nand@d0000 {
- pinctrl-0 = <&nand_pins>;
- pinctrl-names = "default";
- status = "okay";
- num-cs = <1>;
- marvell,nand-keep-config;
- marvell,nand-enable-arbiter;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
-
- partition@0 {
- label = "U-Boot";
- reg = <0 0x800000>;
- };
- partition@800000 {
- label = "Linux";
- reg = <0x800000 0x800000>;
- };
- partition@1000000 {
- label = "Filesystem";
- reg = <0x1000000 0x3f000000>;
- };
- };
-
- usb@54000 {
- status = "okay";
- };
-
- usb3@58000 {
- status = "okay";
- };
-
- mvsdio@d4000 {
- pinctrl-0 = <&sdio_pins &sdio_st_pins>;
- pinctrl-names = "default";
- status = "okay";
- cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
- wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
- };
-
- mdio {
- phy0: ethernet-phy@0 {
- reg = <0>;
- };
-
- phy3: ethernet-phy@3 {
- reg = <3>;
- };
- };
-
- ethernet@f0000 {
- status = "okay";
-
- eth0@c4000 {
- status = "okay";
- phy = <&phy0>;
- phy-mode = "rgmii-id";
- };
-
- eth1@c5000 {
- status = "okay";
- phy = <&phy3>;
- phy-mode = "gmii";
- };
- };
- };
-
- pcie-controller {
- status = "okay";
- /*
- * The two PCIe units are accessible through
- * standard PCIe slots on the board.
- */
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = "okay";
- };
- pcie@2,0 {
- /* Port 1, Lane 0 */
- status = "okay";
- };
- };
};
};
+&pciec {
+ status = "okay";
+};
+
+/*
+ * The two PCIe units are accessible through
+ * standard PCIe slots on the board.
+ */
+&pcie0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+};
+
+&pcie1 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+};
+
+
+&spi0 {
+ pinctrl-0 = <&spi0_pins>;
+ pinctrl-names = "default";
+
+ /*
+ * SPI conflicts with NAND, so we disable it here, and
+ * select NAND as the enabled device by default.
+ */
+
+ status = "disabled";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&pinctrl {
+ sdio_st_pins: sdio-st-pins {
+ marvell,pins = "mpp44", "mpp45";
+ marvell,function = "gpio";
+ };
+};
+
+&sata {
+ status = "okay";
+ nr-ports = <2>;
+};
+
+&nand {
+ pinctrl-0 = <&nand_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partition@0 {
+ label = "U-Boot";
+ reg = <0 0x800000>;
+ };
+ partition@800000 {
+ label = "Linux";
+ reg = <0x800000 0x800000>;
+ };
+ partition@1000000 {
+ label = "Filesystem";
+ reg = <0x1000000 0x3f000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&sdio {
+ pinctrl-0 = <&sdio_pins &sdio_st_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+};
+
+&mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ };
+};
+
+ðernet {
+ status = "okay";
+};
+
+
+ð0 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+};
+
+ð1 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "gmii";
+};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 02/13] ARM: dts: armada-375: Use the node labels
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
Use the node label when possible. As a result it flattens the device tree
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 269 ++++++++++++++++++------------------
1 file changed, 136 insertions(+), 133 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index cded5f0a262d..b33a674088ed 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -69,138 +69,141 @@
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
- internal-regs {
- spi at 10600 {
- pinctrl-0 = <&spi0_pins>;
- pinctrl-names = "default";
- /*
- * SPI conflicts with NAND, so we disable it
- * here, and select NAND as the enabled device
- * by default.
- */
- status = "disabled";
-
- spi-flash at 0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "n25q128a13", "jedec,spi-nor";
- reg = <0>; /* Chip select 0 */
- spi-max-frequency = <108000000>;
- };
- };
-
- i2c at 11000 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- };
-
- i2c at 11100 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c1_pins>;
- pinctrl-names = "default";
- };
-
- serial at 12000 {
- status = "okay";
- };
-
- pinctrl {
- sdio_st_pins: sdio-st-pins {
- marvell,pins = "mpp44", "mpp45";
- marvell,function = "gpio";
- };
- };
-
- sata at a0000 {
- status = "okay";
- nr-ports = <2>;
- };
-
- nand: nand at d0000 {
- pinctrl-0 = <&nand_pins>;
- pinctrl-names = "default";
- status = "okay";
- num-cs = <1>;
- marvell,nand-keep-config;
- marvell,nand-enable-arbiter;
- nand-on-flash-bbt;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
-
- partition at 0 {
- label = "U-Boot";
- reg = <0 0x800000>;
- };
- partition at 800000 {
- label = "Linux";
- reg = <0x800000 0x800000>;
- };
- partition at 1000000 {
- label = "Filesystem";
- reg = <0x1000000 0x3f000000>;
- };
- };
-
- usb at 54000 {
- status = "okay";
- };
-
- usb3 at 58000 {
- status = "okay";
- };
-
- mvsdio at d4000 {
- pinctrl-0 = <&sdio_pins &sdio_st_pins>;
- pinctrl-names = "default";
- status = "okay";
- cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
- wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
- };
-
- mdio {
- phy0: ethernet-phy at 0 {
- reg = <0>;
- };
-
- phy3: ethernet-phy at 3 {
- reg = <3>;
- };
- };
-
- ethernet at f0000 {
- status = "okay";
-
- eth0 at c4000 {
- status = "okay";
- phy = <&phy0>;
- phy-mode = "rgmii-id";
- };
-
- eth1 at c5000 {
- status = "okay";
- phy = <&phy3>;
- phy-mode = "gmii";
- };
- };
- };
-
- pcie-controller {
- status = "okay";
- /*
- * The two PCIe units are accessible through
- * standard PCIe slots on the board.
- */
- pcie at 1,0 {
- /* Port 0, Lane 0 */
- status = "okay";
- };
- pcie at 2,0 {
- /* Port 1, Lane 0 */
- status = "okay";
- };
- };
};
};
+&pciec {
+ status = "okay";
+};
+
+/*
+ * The two PCIe units are accessible through
+ * standard PCIe slots on the board.
+ */
+&pcie0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+};
+
+&pcie1 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+};
+
+
+&spi0 {
+ pinctrl-0 = <&spi0_pins>;
+ pinctrl-names = "default";
+
+ /*
+ * SPI conflicts with NAND, so we disable it here, and
+ * select NAND as the enabled device by default.
+ */
+
+ status = "disabled";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>; /* Chip select 0 */
+ spi-max-frequency = <108000000>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&pinctrl {
+ sdio_st_pins: sdio-st-pins {
+ marvell,pins = "mpp44", "mpp45";
+ marvell,function = "gpio";
+ };
+};
+
+&sata {
+ status = "okay";
+ nr-ports = <2>;
+};
+
+&nand {
+ pinctrl-0 = <&nand_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x800000>;
+ };
+ partition at 800000 {
+ label = "Linux";
+ reg = <0x800000 0x800000>;
+ };
+ partition at 1000000 {
+ label = "Filesystem";
+ reg = <0x1000000 0x3f000000>;
+ };
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&sdio {
+ pinctrl-0 = <&sdio_pins &sdio_st_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ cd-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ wp-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+};
+
+&mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <3>;
+ };
+};
+
+ðernet {
+ status = "okay";
+};
+
+
+ð0 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+};
+
+ð1 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "gmii";
+};
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 03/13] ARM: dts: armada-375: Fixup mdio DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
MDIO has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e016ff3ed970..97b663d83fb6 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio: mdio {
+ mdio: mdio@c0054 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 03/13] ARM: dts: armada-375: Fixup mdio DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
MDIO has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e016ff3ed970..97b663d83fb6 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio: mdio {
+ mdio: mdio at c0054 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 04/13] ARM: dts: armada-375: Fixup bootrom DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
bootrom has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 97b663d83fb6..1c83ae504b64 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -110,7 +110,11 @@
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
- bootrom {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ bootrom@11d00000000 {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 04/13] ARM: dts: armada-375: Fixup bootrom DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
bootrom has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 97b663d83fb6..1c83ae504b64 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -110,7 +110,11 @@
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
- bootrom {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ bootrom at 11d00000000 {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 05/13] ARM: dts: armada-375: Fixup devbus DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
devbus has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 1c83ae504b64..9791a61f076b 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -119,7 +119,12 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus_bootcs: devbus-bootcs {
+ /* The following unit addresses (for devbus) are composed of
+ * the target value (bit [40-47]), attributes value (bits
+ * [32-39], and the address value in the window memory: [0-31].
+ */
+
+ devbus_bootcs: devbus-bootcs@f00100010400 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -129,7 +134,7 @@
status = "disabled";
};
- devbus_cs0: devbus-cs0 {
+ devbus_cs0: devbus-cs@f00100010408 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -139,7 +144,7 @@
status = "disabled";
};
- devbus_cs1: devbus-cs1 {
+ devbus_cs1: devbus-cs@f00100010410 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -149,7 +154,7 @@
status = "disabled";
};
- devbus_cs2: devbus-cs2 {
+ devbus_cs2: devbus-cs@f00100010418 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -159,7 +164,7 @@
status = "disabled";
};
- devbus_cs3: devbus-cs3 {
+ devbus_cs3: devbus-cs@f00100010420 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 05/13] ARM: dts: armada-375: Fixup devbus DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
devbus has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 1c83ae504b64..9791a61f076b 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -119,7 +119,12 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus_bootcs: devbus-bootcs {
+ /* The following unit addresses (for devbus) are composed of
+ * the target value (bit [40-47]), attributes value (bits
+ * [32-39], and the address value in the window memory: [0-31].
+ */
+
+ devbus_bootcs: devbus-bootcs at f00100010400 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -129,7 +134,7 @@
status = "disabled";
};
- devbus_cs0: devbus-cs0 {
+ devbus_cs0: devbus-cs at f00100010408 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -139,7 +144,7 @@
status = "disabled";
};
- devbus_cs1: devbus-cs1 {
+ devbus_cs1: devbus-cs at f00100010410 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -149,7 +154,7 @@
status = "disabled";
};
- devbus_cs2: devbus-cs2 {
+ devbus_cs2: devbus-cs at f00100010418 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -159,7 +164,7 @@
status = "disabled";
};
- devbus_cs3: devbus-cs3 {
+ devbus_cs3: devbus-cs at f00100010420 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
sa-sram which is a mmio-sram has a reg property so the unit name should
contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 9791a61f076b..80e1a4915d1d 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -644,7 +644,12 @@
};
- crypto_sram0: sa-sram0 {
+ /* The following unit addresses (for sa-sram) are composed of
+ * the target value (bit [40-47]), attributes value (bits
+ * [32-39], and the address value in the window memory: [0-31].
+ */
+
+ crypto_sram0: sa-sram@90900000000 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
clocks = <&gateclk 30>;
@@ -653,7 +658,7 @@
ranges = <0 MBUS_ID(0x09, 0x09) 0 0x800>;
};
- crypto_sram1: sa-sram1 {
+ crypto_sram1: sa-sram@90500000000 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
clocks = <&gateclk 31>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
sa-sram which is a mmio-sram has a reg property so the unit name should
contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 9791a61f076b..80e1a4915d1d 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -644,7 +644,12 @@
};
- crypto_sram0: sa-sram0 {
+ /* The following unit addresses (for sa-sram) are composed of
+ * the target value (bit [40-47]), attributes value (bits
+ * [32-39], and the address value in the window memory: [0-31].
+ */
+
+ crypto_sram0: sa-sram at 90900000000 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
clocks = <&gateclk 30>;
@@ -653,7 +658,7 @@
ranges = <0 MBUS_ID(0x09, 0x09) 0 0x800>;
};
- crypto_sram1: sa-sram1 {
+ crypto_sram1: sa-sram at 90500000000 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
clocks = <&gateclk 31>;
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread[parent not found: <20161117230830.31047-7-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-18 8:59 ` Thomas Petazzoni
-1 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 8:59 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hello,
On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
> - crypto_sram0: sa-sram0 {
> + /* The following unit addresses (for sa-sram) are composed of
> + * the target value (bit [40-47]), attributes value (bits
> + * [32-39], and the address value in the window memory: [0-31].
> + */
The "address value in the window memory" part doesn't make a lot of
sense. Maybe:
"The following unit addresses are composed of the window target ID
(bits 40-47), the window target attributes (bits 32-39) and the offset
inside the window."
Also, the comment formatting is not compliant with the coding style,
should be:
/*
* ...
* ...
*/
But do we really want this comment above each node? Couldn't we instead
add this explanation in the mvebu-mbus.txt DT binding?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
@ 2016-11-18 8:59 ` Thomas Petazzoni
0 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 8:59 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
> - crypto_sram0: sa-sram0 {
> + /* The following unit addresses (for sa-sram) are composed of
> + * the target value (bit [40-47]), attributes value (bits
> + * [32-39], and the address value in the window memory: [0-31].
> + */
The "address value in the window memory" part doesn't make a lot of
sense. Maybe:
"The following unit addresses are composed of the window target ID
(bits 40-47), the window target attributes (bits 32-39) and the offset
inside the window."
Also, the comment formatting is not compliant with the coding style,
should be:
/*
* ...
* ...
*/
But do we really want this comment above each node? Couldn't we instead
add this explanation in the mvebu-mbus.txt DT binding?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread[parent not found: <20161118095925.770496c3-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
2016-11-18 8:59 ` Thomas Petazzoni
@ 2016-11-18 12:06 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-18 12:06 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
>
>> - crypto_sram0: sa-sram0 {
>> + /* The following unit addresses (for sa-sram) are composed of
>> + * the target value (bit [40-47]), attributes value (bits
>> + * [32-39], and the address value in the window memory: [0-31].
>> + */
>
> The "address value in the window memory" part doesn't make a lot of
> sense. Maybe:
>
> "The following unit addresses are composed of the window target ID
> (bits 40-47), the window target attributes (bits 32-39) and the offset
> inside the window."
I'm fine with it
>
> Also, the comment formatting is not compliant with the coding style,
> should be:
>
> /*
> * ...
> * ...
> */
>
Hum yes I need to teach emacs how to properly format the comments.
> But do we really want this comment above each node? Couldn't we instead
> add this explanation in the mvebu-mbus.txt DT binding?
We could but I fear that nobody will read it.
Indeed if you know that in order to understand the unit address, you will
have to have a look an the binding of the mvebu-mbus, then it means that
you already are an expert and actually you barely need to read it!
In order to have less change we could at least put it near the MBUS_ID
macro and if the mvebu-mbus.txt DT binding too.
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
@ 2016-11-18 12:06 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-18 12:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
>
>> - crypto_sram0: sa-sram0 {
>> + /* The following unit addresses (for sa-sram) are composed of
>> + * the target value (bit [40-47]), attributes value (bits
>> + * [32-39], and the address value in the window memory: [0-31].
>> + */
>
> The "address value in the window memory" part doesn't make a lot of
> sense. Maybe:
>
> "The following unit addresses are composed of the window target ID
> (bits 40-47), the window target attributes (bits 32-39) and the offset
> inside the window."
I'm fine with it
>
> Also, the comment formatting is not compliant with the coding style,
> should be:
>
> /*
> * ...
> * ...
> */
>
Hum yes I need to teach emacs how to properly format the comments.
> But do we really want this comment above each node? Couldn't we instead
> add this explanation in the mvebu-mbus.txt DT binding?
We could but I fear that nobody will read it.
Indeed if you know that in order to understand the unit address, you will
have to have a look an the binding of the mvebu-mbus, then it means that
you already are an expert and actually you barely need to read it!
In order to have less change we could at least put it near the MBUS_ID
macro and if the mvebu-mbus.txt DT binding too.
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
2016-11-18 12:06 ` Gregory CLEMENT
@ 2016-11-18 13:35 ` Thomas Petazzoni
-1 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 13:35 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Andrew Lunn, Jason Cooper, devicetree, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
Hello,
On Fri, 18 Nov 2016 13:06:17 +0100, Gregory CLEMENT wrote:
> > But do we really want this comment above each node? Couldn't we instead
> > add this explanation in the mvebu-mbus.txt DT binding?
>
> We could but I fear that nobody will read it.
>
> Indeed if you know that in order to understand the unit address, you will
> have to have a look an the binding of the mvebu-mbus, then it means that
> you already are an expert and actually you barely need to read it!
Well, you anyway need to read the DT binding if you want to add more
nodes that use this magic MBUS_ID() thing, so I believe it makes sense
to have this comment in the binding documentation.
> In order to have less change we could at least put it near the MBUS_ID
> macro and if the mvebu-mbus.txt DT binding too.
Fine with that.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
@ 2016-11-18 13:35 ` Thomas Petazzoni
0 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 13:35 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 18 Nov 2016 13:06:17 +0100, Gregory CLEMENT wrote:
> > But do we really want this comment above each node? Couldn't we instead
> > add this explanation in the mvebu-mbus.txt DT binding?
>
> We could but I fear that nobody will read it.
>
> Indeed if you know that in order to understand the unit address, you will
> have to have a look an the binding of the mvebu-mbus, then it means that
> you already are an expert and actually you barely need to read it!
Well, you anyway need to read the DT binding if you want to add more
nodes that use this magic MBUS_ID() thing, so I believe it makes sense
to have this comment in the binding documentation.
> In order to have less change we could at least put it near the MBUS_ID
> macro and if the mvebu-mbus.txt DT binding too.
Fine with that.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v3 07/13] ARM: dts: armada-375: Fixup pcie DT warnings
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
PCIe has a range property, so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 80e1a4915d1d..3afdc4c31032 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -589,7 +589,7 @@
};
};
- pciec: pcie-controller {
+ pciec: pcie-controller@82000000 {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 07/13] ARM: dts: armada-375: Fixup pcie DT warnings
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
PCIe has a range property, so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 80e1a4915d1d..3afdc4c31032 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -589,7 +589,7 @@
};
};
- pciec: pcie-controller {
+ pciec: pcie-controller at 82000000 {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 08/13] ARM: dts: armada-375: Fixup pinctrl DT warnings
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
pinctrl has a ranges property, so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 3afdc4c31032..f213b6786e10 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -316,7 +316,7 @@
status = "disabled";
};
- pinctrl: pinctrl {
+ pinctrl: pinctrl@18000 {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 08/13] ARM: dts: armada-375: Fixup pinctrl DT warnings
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
pinctrl has a ranges property, so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 3afdc4c31032..f213b6786e10 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -316,7 +316,7 @@
status = "disabled";
};
- pinctrl: pinctrl {
+ pinctrl: pinctrl at 18000 {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
soc has a ranges property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375-db.dts | 6 +++++-
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index b33a674088ed..5ed226236398 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,11 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc@f00100000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index f213b6786e10..120dd7ac40cb 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -101,7 +101,11 @@
interrupts-extended = <&mpic 3>;
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc@f00100000000 {
compatible = "marvell,armada375-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
soc has a ranges property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 6 +++++-
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index b33a674088ed..5ed226236398 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,11 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc at f00100000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index f213b6786e10..120dd7ac40cb 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -101,7 +101,11 @@
interrupts-extended = <&mpic 3>;
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc at f00100000000 {
compatible = "marvell,armada375-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread[parent not found: <20161117230830.31047-10-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-18 8:54 ` Thomas Petazzoni
-1 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 8:54 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hello,
On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
> - soc {
> + /* The following unit address is composed of the target
> + * value (bit [40-47]), attributes value (bits [32-39],
> + * and the address value in the window memory: [0-31].
> + */
> + soc@f00100000000 {
Where is this value coming from? Why does the soc node needs to have a
unit address? It doesn't have a 'reg' property if I remember correctly.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
@ 2016-11-18 8:54 ` Thomas Petazzoni
0 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 8:54 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
> - soc {
> + /* The following unit address is composed of the target
> + * value (bit [40-47]), attributes value (bits [32-39],
> + * and the address value in the window memory: [0-31].
> + */
> + soc at f00100000000 {
Where is this value coming from? Why does the soc node needs to have a
unit address? It doesn't have a 'reg' property if I remember correctly.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread[parent not found: <20161118095455.00bfe007-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
2016-11-18 8:54 ` Thomas Petazzoni
@ 2016-11-18 9:01 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-18 9:01 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
>
>> - soc {
>> + /* The following unit address is composed of the target
>> + * value (bit [40-47]), attributes value (bits [32-39],
>> + * and the address value in the window memory: [0-31].
>> + */
>> + soc@f00100000000 {
>
> Where is this value coming from? Why does the soc node needs to have a
It cames from the dts files.
> unit address? It doesn't have a 'reg' property if I remember
> correctly.
But it has a range property.
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
@ 2016-11-18 9:01 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-18 9:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
>
>> - soc {
>> + /* The following unit address is composed of the target
>> + * value (bit [40-47]), attributes value (bits [32-39],
>> + * and the address value in the window memory: [0-31].
>> + */
>> + soc at f00100000000 {
>
> Where is this value coming from? Why does the soc node needs to have a
It cames from the dts files.
> unit address? It doesn't have a 'reg' property if I remember
> correctly.
But it has a range property.
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread[parent not found: <87d1htb1qr.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
2016-11-18 9:01 ` Gregory CLEMENT
@ 2016-11-18 9:12 ` Thomas Petazzoni
-1 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 9:12 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hello,
On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
> >> + soc@f00100000000 {
> >
> > Where is this value coming from? Why does the soc node needs to have a
>
> It cames from the dts files.
Where?
> > unit address? It doesn't have a 'reg' property if I remember
> > correctly.
>
> But it has a range property.
And? There are multiple ranges, and you randomly took the first one for
the unit address of the soc node?
You realize that the ranges property is a list of ranges, and they
could be in any order? Why would you pick the base address of one of
the ranges rather than any of the others?
I believe there is simply no unit address for the soc {} node. There is
definitely one for the internal-regs {} node, but not for the soc {}
node.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
@ 2016-11-18 9:12 ` Thomas Petazzoni
0 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
> >> + soc at f00100000000 {
> >
> > Where is this value coming from? Why does the soc node needs to have a
>
> It cames from the dts files.
Where?
> > unit address? It doesn't have a 'reg' property if I remember
> > correctly.
>
> But it has a range property.
And? There are multiple ranges, and you randomly took the first one for
the unit address of the soc node?
You realize that the ranges property is a list of ranges, and they
could be in any order? Why would you pick the base address of one of
the ranges rather than any of the others?
I believe there is simply no unit address for the soc {} node. There is
definitely one for the internal-regs {} node, but not for the soc {}
node.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread[parent not found: <20161118101248.784eff2b-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
2016-11-18 9:12 ` Thomas Petazzoni
@ 2016-11-18 9:38 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-18 9:38 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
>
>> >> + soc@f00100000000 {
>> >
>> > Where is this value coming from? Why does the soc node needs to have a
>>
>> It cames from the dts files.
>
> Where?
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,11 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc@f00100000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
just here ---------^
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
>
>> > unit address? It doesn't have a 'reg' property if I remember
>> > correctly.
>>
>> But it has a range property.
>
> And? There are multiple ranges, and you randomly took the first one for
> the unit address of the soc node?
Not randomly I followed the same rules that for the regs mentioned in
the ePAPR paragraph 2.2.1.1:
"The unit-address should match the first address specified in the reg
property of the node."
>
> You realize that the ranges property is a list of ranges, and they
> could be in any order? Why would you pick the base address of one of
> the ranges rather than any of the others?
It is the same for the regs so as explained I followed the same rules.
>
> I believe there is simply no unit address for the soc {} node. There is
> definitely one for the internal-regs {} node, but not for the soc {}
> node.
It is not the interpretation of the DTC:
"Warning (unit_address_vs_reg): Node /soc has a reg or ranges property,
but no unit name"
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
@ 2016-11-18 9:38 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-18 9:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
>
>> >> + soc at f00100000000 {
>> >
>> > Where is this value coming from? Why does the soc node needs to have a
>>
>> It cames from the dts files.
>
> Where?
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,11 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc at f00100000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
just here ---------^
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
>
>> > unit address? It doesn't have a 'reg' property if I remember
>> > correctly.
>>
>> But it has a range property.
>
> And? There are multiple ranges, and you randomly took the first one for
> the unit address of the soc node?
Not randomly I followed the same rules that for the regs mentioned in
the ePAPR paragraph 2.2.1.1:
"The unit-address should match the first address specified in the reg
property of the node."
>
> You realize that the ranges property is a list of ranges, and they
> could be in any order? Why would you pick the base address of one of
> the ranges rather than any of the others?
It is the same for the regs so as explained I followed the same rules.
>
> I believe there is simply no unit address for the soc {} node. There is
> definitely one for the internal-regs {} node, but not for the soc {}
> node.
It is not the interpretation of the DTC:
"Warning (unit_address_vs_reg): Node /soc has a reg or ranges property,
but no unit name"
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread[parent not found: <877f81b013.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
2016-11-18 9:38 ` Gregory CLEMENT
@ 2016-11-18 13:38 ` Thomas Petazzoni
-1 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 13:38 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hello,
On Fri, 18 Nov 2016 10:38:32 +0100, Gregory CLEMENT wrote:
> >> > unit address? It doesn't have a 'reg' property if I remember
> >> > correctly.
> >>
> >> But it has a range property.
> >
> > And? There are multiple ranges, and you randomly took the first one for
> > the unit address of the soc node?
>
> Not randomly I followed the same rules that for the regs mentioned in
> the ePAPR paragraph 2.2.1.1:
>
> "The unit-address should match the first address specified in the reg
> property of the node."
But it doesn't say anything about the ranges property. Isn't the dtc
warning in fact over-zealous? The ePAPR says that the unit address
should be the first address of the reg property, but doesn't say
anything about the ranges property.
What I dislike is that there absolutely nothing that forces the ranges
to be written in this order. In another board, it can be written in a
completely different order, which means that the unit address would be
different, which is really silly.
I continue to believe this rule doesn't make sense, and the soc node
shouldn't have a unit address. Maybe Rob or Mark (who is not in Cc, for
some reason?) should say a word about this?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
@ 2016-11-18 13:38 ` Thomas Petazzoni
0 siblings, 0 replies; 44+ messages in thread
From: Thomas Petazzoni @ 2016-11-18 13:38 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, 18 Nov 2016 10:38:32 +0100, Gregory CLEMENT wrote:
> >> > unit address? It doesn't have a 'reg' property if I remember
> >> > correctly.
> >>
> >> But it has a range property.
> >
> > And? There are multiple ranges, and you randomly took the first one for
> > the unit address of the soc node?
>
> Not randomly I followed the same rules that for the regs mentioned in
> the ePAPR paragraph 2.2.1.1:
>
> "The unit-address should match the first address specified in the reg
> property of the node."
But it doesn't say anything about the ranges property. Isn't the dtc
warning in fact over-zealous? The ePAPR says that the unit address
should be the first address of the reg property, but doesn't say
anything about the ranges property.
What I dislike is that there absolutely nothing that forces the ranges
to be written in this order. In another board, it can be written in a
completely different order, which means that the unit address would be
different, which is really silly.
I continue to believe this rule doesn't make sense, and the soc node
shouldn't have a unit address. Maybe Rob or Mark (who is not in Cc, for
some reason?) should say a word about this?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v3 10/13] ARM: dts: armada-375: Fixup internal-regs DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
internal-regs has a ranges property so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 120dd7ac40cb..04333ba3f180 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -178,7 +178,11 @@
status = "disabled";
};
- internal-regs {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ internal-regs@f00100000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 10/13] ARM: dts: armada-375: Fixup internal-regs DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
internal-regs has a ranges property so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 120dd7ac40cb..04333ba3f180 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -178,7 +178,11 @@
status = "disabled";
};
- internal-regs {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ internal-regs at f00100000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 11/13] ARM: dts: armada-375: Remove skeleton.dtsi
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2e141 arm64: dts: kill skeleton.dtsi").
These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 04333ba3f180..3e61c2dd1437 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -45,7 +45,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "skeleton.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/phy/phy.h>
@@ -53,6 +52,9 @@
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
model = "Marvell Armada 375 family SoC";
compatible = "marvell,armada375";
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 11/13] ARM: dts: armada-375: Remove skeleton.dtsi
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2e141 arm64: dts: kill skeleton.dtsi").
These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 04333ba3f180..3e61c2dd1437 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -45,7 +45,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "skeleton.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/phy/phy.h>
@@ -53,6 +52,9 @@
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
model = "Marvell Armada 375 family SoC";
compatible = "marvell,armada375";
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 12/13] ARM: dts: armada-375: Fixup memory DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
memory has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 5ed226236398..64edd59486e0 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -58,7 +58,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 12/13] ARM: dts: armada-375: Fixup memory DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
memory has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 5ed226236398..64edd59486e0 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -58,7 +58,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH v3 13/13] ARM: dts: armada-375: Fixup ethernet child DT warning
2016-11-17 23:08 ` Gregory CLEMENT
@ 2016-11-17 23:08 ` Gregory CLEMENT
-1 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory CLEMENT
Cc: Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
Child of mvpp2 ethernet do not have a reg property so the unit name
should not contain an address: remove them.
Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 3e61c2dd1437..70243d2b8491 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -241,13 +241,13 @@
clock-names = "pp_clk", "gop_clk";
status = "disabled";
- eth0: eth0@c4000 {
+ eth0: eth0 {
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
port-id = <0>;
status = "disabled";
};
- eth1: eth1@c5000 {
+ eth1: eth1 {
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
port-id = <1>;
status = "disabled";
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 44+ messages in thread* [PATCH v3 13/13] ARM: dts: armada-375: Fixup ethernet child DT warning
@ 2016-11-17 23:08 ` Gregory CLEMENT
0 siblings, 0 replies; 44+ messages in thread
From: Gregory CLEMENT @ 2016-11-17 23:08 UTC (permalink / raw)
To: linux-arm-kernel
Child of mvpp2 ethernet do not have a reg property so the unit name
should not contain an address: remove them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 3e61c2dd1437..70243d2b8491 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -241,13 +241,13 @@
clock-names = "pp_clk", "gop_clk";
status = "disabled";
- eth0: eth0 at c4000 {
+ eth0: eth0 {
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
port-id = <0>;
status = "disabled";
};
- eth1: eth1 at c5000 {
+ eth1: eth1 {
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
port-id = <1>;
status = "disabled";
--
2.10.2
^ permalink raw reply related [flat|nested] 44+ messages in thread