[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Gregory CLEMENT]

The Armada 385 RD board is the reference design board from Marvell
for the Armada 385 SoC. This commit adds a Device Tree description for
this board, which enables the following features:

 * Network interfaces
 * I2C bus
 * Serial port
 * SPI bus, with a SPI flash
 * PCIe interface

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Hi,

I have received this board only recently, so that why its device tree
comes only now. This patch should not cause any trouble to other part
of the kernel, so that's why I think it is reasonable to have it in
3.15.

Thanks,

Gregory


 arch/arm/boot/dts/Makefile          |   3 +-
 arch/arm/boot/dts/armada-385-rd.dts | 104 ++++++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/armada-385-rd.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f7d678808122..9155cf48e1b1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -153,7 +153,8 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
 dtb-$(CONFIG_MACH_ARMADA_375) += \
 	armada-375-db.dtb
 dtb-$(CONFIG_MACH_ARMADA_38X) += \
-	armada-385-db.dtb
+	armada-385-db.dtb \
+	armada-385-rd.dtb
 dtb-$(CONFIG_MACH_ARMADA_XP) += \
 	armada-xp-axpwifiap.dtb \
 	armada-xp-db.dtb \
diff --git a/arch/arm/boot/dts/armada-385-rd.dts b/arch/arm/boot/dts/armada-385-rd.dts
new file mode 100644
index 000000000000..951bd91059e1
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-rd.dts
@@ -0,0 +1,104 @@
+/*
+ * Device Tree file for Marvell Armada 385 Reference Design board
+ * (RD-88F6820-AP)
+ *
+ *  Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+/ {
+	model = "Marvell Armada 385 Reference Design";
+	compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada38x";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x10000000>; /* 256 MB */
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+		internal-regs {
+			spi at 10600 {
+				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "m25p128";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <108000000>;
+				};
+			};
+
+			i2c at 11000 {
+				status = "okay";
+				clock-frequency = <100000>;
+			};
+
+			serial at 12000 {
+				clock-frequency = <200000000>;
+				status = "okay";
+			};
+
+
+			/*
+			 * The Ethernet nodes are not ordered by
+			 * address on purpose. Indeed the first
+			 * Ethernet port of the board (Giga0) is
+			 * located at 0x70000 whereas the the second
+			 * Ethernet(Giga 1) port is located at
+			 * 0x30000.
+			 */
+
+			ethernet at 70000 {
+				status = "okay";
+				phy = <&phy0>;
+				phy-mode = "rgmii";
+			};
+
+			ethernet at 30000 {
+				status = "okay";
+				phy = <&phy1>;
+				phy-mode = "rgmii";
+			};
+
+
+			mdio {
+				phy0: ethernet-phy at 0 {
+					reg = <0>;
+				};
+
+				phy1: ethernet-phy at 1 {
+					reg = <1>;
+				};
+			};
+		};
+
+		pcie-controller {
+			status = "okay";
+			/*
+			 * One PCIe units is accessible through
+			 * standard PCIe slot on the board.
+			 */
+			pcie at 1,0 {
+				/* Port 0, Lane 0 */
+				status = "okay";
+			};
+		};
+	};
+};
-- 
1.8.1.2

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Andrew Lunn]

On Thu, Mar 06, 2014 at 01:11:08PM +0100, Gregory CLEMENT wrote:
> The Armada 385 RD board is the reference design board from Marvell
> for the Armada 385 SoC. This commit adds a Device Tree description for
> this board, which enables the following features:
> 
>  * Network interfaces
>  * I2C bus
>  * Serial port
>  * SPI bus, with a SPI flash
>  * PCIe interface
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Hi,
> 
> I have received this board only recently, so that why its device tree
> comes only now. This patch should not cause any trouble to other part
> of the kernel, so that's why I think it is reasonable to have it in
> 3.15.
> 
> Thanks,
> 
> Gregory
> 
> 
>  arch/arm/boot/dts/Makefile          |   3 +-
>  arch/arm/boot/dts/armada-385-rd.dts | 104 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 106 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/armada-385-rd.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f7d678808122..9155cf48e1b1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -153,7 +153,8 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
>  dtb-$(CONFIG_MACH_ARMADA_375) += \
>  	armada-375-db.dtb
>  dtb-$(CONFIG_MACH_ARMADA_38X) += \
> -	armada-385-db.dtb
> +	armada-385-db.dtb \
> +	armada-385-rd.dtb
>  dtb-$(CONFIG_MACH_ARMADA_XP) += \
>  	armada-xp-axpwifiap.dtb \
>  	armada-xp-db.dtb \
> diff --git a/arch/arm/boot/dts/armada-385-rd.dts b/arch/arm/boot/dts/armada-385-rd.dts
> new file mode 100644
> index 000000000000..951bd91059e1
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-rd.dts
> @@ -0,0 +1,104 @@
> +/*
> + * Device Tree file for Marvell Armada 385 Reference Design board
> + * (RD-88F6820-AP)
> + *
> + *  Copyright (C) 2014 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +#include "armada-385.dtsi"
> +
> +/ {
> +	model = "Marvell Armada 385 Reference Design";
> +	compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada38x";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x10000000>; /* 256 MB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> +
> +		internal-regs {
> +			spi at 10600 {
> +				status = "okay";
> +
> +				spi-flash at 0 {
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +					compatible = "m25p128";

Hi Gregory

I guess checkpatch.pl is probably complaining about missing vendor
prefix?

> +					reg = <0>; /* Chip select 0 */
> +					spi-max-frequency = <108000000>;
> +				};
> +			};
> +
> +			i2c at 11000 {
> +				status = "okay";
> +				clock-frequency = <100000>;
> +			};
> +
> +			serial at 12000 {
> +				clock-frequency = <200000000>;
> +				status = "okay";
> +			};
> +
> +
> +			/*
> +			 * The Ethernet nodes are not ordered by
> +			 * address on purpose. Indeed the first
> +			 * Ethernet port of the board (Giga0) is
> +			 * located at 0x70000 whereas the the second
> +			 * Ethernet(Giga 1) port is located at
> +			 * 0x30000.
> +			 */
> +
> +			ethernet at 70000 {
> +				status = "okay";
> +				phy = <&phy0>;
> +				phy-mode = "rgmii";
> +			};
> +
> +			ethernet at 30000 {
> +				status = "okay";
> +				phy = <&phy1>;
> +				phy-mode = "rgmii";
> +			};
> +

I think you can use aliases to get the order correct, independent of
how you list them in DT. That should be a lot safer than assuming
things are instantiated from top to bottom.

       Andrew

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Gregory CLEMENT]

Hi Andrew,

On 06/03/2014 14:14, Andrew Lunn wrote:
> On Thu, Mar 06, 2014 at 01:11:08PM +0100, Gregory CLEMENT wrote:
>> The Armada 385 RD board is the reference design board from Marvell
>> for the Armada 385 SoC. This commit adds a Device Tree description for
>> this board, which enables the following features:
>>
>>  * Network interfaces
>>  * I2C bus
>>  * Serial port
>>  * SPI bus, with a SPI flash
>>  * PCIe interface
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> Hi,
>>
>> I have received this board only recently, so that why its device tree
>> comes only now. This patch should not cause any trouble to other part
>> of the kernel, so that's why I think it is reasonable to have it in
>> 3.15.
>>
>> Thanks,
>>
>> Gregory
>>
>>
>>  arch/arm/boot/dts/Makefile          |   3 +-
>>  arch/arm/boot/dts/armada-385-rd.dts | 104 ++++++++++++++++++++++++++++++++++++
>>  2 files changed, 106 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/boot/dts/armada-385-rd.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index f7d678808122..9155cf48e1b1 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -153,7 +153,8 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
>>  dtb-$(CONFIG_MACH_ARMADA_375) += \
>>  	armada-375-db.dtb
>>  dtb-$(CONFIG_MACH_ARMADA_38X) += \
>> -	armada-385-db.dtb
>> +	armada-385-db.dtb \
>> +	armada-385-rd.dtb
>>  dtb-$(CONFIG_MACH_ARMADA_XP) += \
>>  	armada-xp-axpwifiap.dtb \
>>  	armada-xp-db.dtb \
>> diff --git a/arch/arm/boot/dts/armada-385-rd.dts b/arch/arm/boot/dts/armada-385-rd.dts
>> new file mode 100644
>> index 000000000000..951bd91059e1
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-385-rd.dts
>> @@ -0,0 +1,104 @@
>> +/*
>> + * Device Tree file for Marvell Armada 385 Reference Design board
>> + * (RD-88F6820-AP)
>> + *
>> + *  Copyright (C) 2014 Marvell
>> + *
>> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +/dts-v1/;
>> +#include "armada-385.dtsi"
>> +
>> +/ {
>> +	model = "Marvell Armada 385 Reference Design";
>> +	compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada38x";
>> +
>> +	chosen {
>> +		bootargs = "console=ttyS0,115200 earlyprintk";
>> +	};
>> +
>> +	memory {
>> +		device_type = "memory";
>> +		reg = <0x00000000 0x10000000>; /* 256 MB */
>> +	};
>> +
>> +	soc {
>> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
>> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
>> +
>> +		internal-regs {
>> +			spi at 10600 {
>> +				status = "okay";
>> +
>> +				spi-flash at 0 {
>> +					#address-cells = <1>;
>> +					#size-cells = <1>;
>> +					compatible = "m25p128";
> 
> Hi Gregory
> 
> I guess checkpatch.pl is probably complaining about missing vendor
> prefix?
> 

yes and also about m25p128 itself because it was not explicitly written
in Documentation/devicetree/bindings/. Actually it was written to "see the
"m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of" the compatible
name.

For the first warning I can add the vendor part, but for the other warning, do we
really want to copy the m25p_ids table in Documentation/devicetree/bindings/mtd/m25p80.txt ?

>> +					reg = <0>; /* Chip select 0 */
>> +					spi-max-frequency = <108000000>;
>> +				};
>> +			};
>> +
>> +			i2c at 11000 {
>> +				status = "okay";
>> +				clock-frequency = <100000>;
>> +			};
>> +
>> +			serial at 12000 {
>> +				clock-frequency = <200000000>;
>> +				status = "okay";
>> +			};
>> +
>> +
>> +			/*
>> +			 * The Ethernet nodes are not ordered by
>> +			 * address on purpose. Indeed the first
>> +			 * Ethernet port of the board (Giga0) is
>> +			 * located at 0x70000 whereas the the second
>> +			 * Ethernet(Giga 1) port is located at
>> +			 * 0x30000.
>> +			 */
>> +
>> +			ethernet at 70000 {
>> +				status = "okay";
>> +				phy = <&phy0>;
>> +				phy-mode = "rgmii";
>> +			};
>> +
>> +			ethernet at 30000 {
>> +				status = "okay";
>> +				phy = <&phy1>;
>> +				phy-mode = "rgmii";
>> +			};
>> +
> 
> I think you can use aliases to get the order correct, independent of
> how you list them in DT. That should be a lot safer than assuming
> things are instantiated from top to bottom.

It sounds interesting, how would you do this?


Thanks,

Gregory

> 
>        Andrew
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Andrew Lunn]

> > Hi Gregory
> > 
> > I guess checkpatch.pl is probably complaining about missing vendor
> > prefix?
> > 
> 
> yes and also about m25p128 itself because it was not explicitly written
> in Documentation/devicetree/bindings/. Actually it was written to "see the
> "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of" the compatible
> name.
> 
> For the first warning I can add the vendor part, but for the other warning, do we
> really want to copy the m25p_ids table in Documentation/devicetree/bindings/mtd/m25p80.txt ?

I think the DT Maintainers and checkpatch.pl maintainers need to think
about this. Maybe a regex would be enough in
Documentation/devicetree/bindings/mtd/m25p80.txt?

For the moment i would suggest adding a vendor prefix, but nothing
more.


> >> +			/*
> >> +			 * The Ethernet nodes are not ordered by
> >> +			 * address on purpose. Indeed the first
> >> +			 * Ethernet port of the board (Giga0) is
> >> +			 * located at 0x70000 whereas the the second
> >> +			 * Ethernet(Giga 1) port is located at
> >> +			 * 0x30000.
> >> +			 */
> >> +
> >> +			ethernet at 70000 {
> >> +				status = "okay";
> >> +				phy = <&phy0>;
> >> +				phy-mode = "rgmii";
> >> +			};
> >> +
> >> +			ethernet at 30000 {
> >> +				status = "okay";
> >> +				phy = <&phy1>;
> >> +				phy-mode = "rgmii";
> >> +			};
> >> +
> > 
> > I think you can use aliases to get the order correct, independent of
> > how you list them in DT. That should be a lot safer than assuming
> > things are instantiated from top to bottom.
> 
> It sounds interesting, how would you do this?

As there already is in armada-370-xp.dtsi

        aliases {
                eth0 = &eth0;
                eth1 = &eth1;
        };


	eth0: ethernet at 70000 {
	}
        eth1: ethernet at 74000 {
	}

This at least works for i2c devices. The pdev->id is set using the
alias number.

      Andrew

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Gregory CLEMENT]

On 06/03/2014 15:21, Andrew Lunn wrote:
>>> Hi Gregory
>>>
>>> I guess checkpatch.pl is probably complaining about missing vendor
>>> prefix?
>>>
>>
>> yes and also about m25p128 itself because it was not explicitly written
>> in Documentation/devicetree/bindings/. Actually it was written to "see the
>> "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of" the compatible
>> name.
>>
>> For the first warning I can add the vendor part, but for the other warning, do we
>> really want to copy the m25p_ids table in Documentation/devicetree/bindings/mtd/m25p80.txt ?
> 
> I think the DT Maintainers and checkpatch.pl maintainers need to think
> about this. Maybe a regex would be enough in
> Documentation/devicetree/bindings/mtd/m25p80.txt?
> 
> For the moment i would suggest adding a vendor prefix, but nothing
> more.

OK

> 
> 
>>>> +			/*
>>>> +			 * The Ethernet nodes are not ordered by
>>>> +			 * address on purpose. Indeed the first
>>>> +			 * Ethernet port of the board (Giga0) is
>>>> +			 * located at 0x70000 whereas the the second
>>>> +			 * Ethernet(Giga 1) port is located at
>>>> +			 * 0x30000.
>>>> +			 */
>>>> +
>>>> +			ethernet at 70000 {
>>>> +				status = "okay";
>>>> +				phy = <&phy0>;
>>>> +				phy-mode = "rgmii";
>>>> +			};
>>>> +
>>>> +			ethernet at 30000 {
>>>> +				status = "okay";
>>>> +				phy = <&phy1>;
>>>> +				phy-mode = "rgmii";
>>>> +			};
>>>> +
>>>
>>> I think you can use aliases to get the order correct, independent of
>>> how you list them in DT. That should be a lot safer than assuming
>>> things are instantiated from top to bottom.
>>
>> It sounds interesting, how would you do this?
> 
> As there already is in armada-370-xp.dtsi
> 
>         aliases {
>                 eth0 = &eth0;
>                 eth1 = &eth1;
>         };
> 
> 
> 	eth0: ethernet at 70000 {
> 	}
>         eth1: ethernet at 74000 {
> 	}
> 
> This at least works for i2c devices. The pdev->id is set using the
> alias number.

Well I think it doesn't work with ethernet devices because we already do
this in aramda-38x.dtsi:

	aliases {
		gpio0 = &gpio0;
		gpio1 = &gpio1;
		eth0 = &eth0;
		eth1 = &eth1;
		eth2 = &eth2;
	};

	eth1: ethernet at 30000 {
	}
	eth2: ethernet at 34000 {
	}
	eth0: ethernet at 70000 {
	}


Thanks,

Gregory

> 
>       Andrew
> 
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Andrew Lunn]

> >>> I think you can use aliases to get the order correct, independent of
> >>> how you list them in DT. That should be a lot safer than assuming
> >>> things are instantiated from top to bottom.
> >>
> >> It sounds interesting, how would you do this?
> > 
> > As there already is in armada-370-xp.dtsi
> > 
> >         aliases {
> >                 eth0 = &eth0;
> >                 eth1 = &eth1;
> >         };
> > 
> > 
> > 	eth0: ethernet at 70000 {
> > 	}
> >         eth1: ethernet at 74000 {
> > 	}
> > 
> > This at least works for i2c devices. The pdev->id is set using the
> > alias number.
> 
> Well I think it doesn't work with ethernet devices because we already do
> this in aramda-38x.dtsi:
> 
> 	aliases {
> 		gpio0 = &gpio0;
> 		gpio1 = &gpio1;
> 		eth0 = &eth0;
> 		eth1 = &eth1;
> 		eth2 = &eth2;
> 	};
> 
> 	eth1: ethernet at 30000 {
> 	}
> 	eth2: ethernet at 34000 {
> 	}
> 	eth0: ethernet at 70000 {
> 	}

Ah, Erm, O.K. 

It seems to be an i2c thing. Take a look at i2c_add_adapter().

        if (dev->of_node) {
                id = of_alias_get_id(dev->of_node, "i2c");
 
You could put something similar into the ethernet driver.

    Andrew

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Gregory CLEMENT]

On 06/03/2014 15:46, Andrew Lunn wrote:
>>>>> I think you can use aliases to get the order correct, independent of
>>>>> how you list them in DT. That should be a lot safer than assuming
>>>>> things are instantiated from top to bottom.
>>>>
>>>> It sounds interesting, how would you do this?
>>>
>>> As there already is in armada-370-xp.dtsi
>>>
>>>         aliases {
>>>                 eth0 = &eth0;
>>>                 eth1 = &eth1;
>>>         };
>>>
>>>
>>> 	eth0: ethernet at 70000 {
>>> 	}
>>>         eth1: ethernet at 74000 {
>>> 	}
>>>
>>> This at least works for i2c devices. The pdev->id is set using the
>>> alias number.
>>
>> Well I think it doesn't work with ethernet devices because we already do
>> this in aramda-38x.dtsi:
>>
>> 	aliases {
>> 		gpio0 = &gpio0;
>> 		gpio1 = &gpio1;
>> 		eth0 = &eth0;
>> 		eth1 = &eth1;
>> 		eth2 = &eth2;
>> 	};
>>
>> 	eth1: ethernet at 30000 {
>> 	}
>> 	eth2: ethernet at 34000 {
>> 	}
>> 	eth0: ethernet at 70000 {
>> 	}
> 
> Ah, Erm, O.K. 
> 
> It seems to be an i2c thing. Take a look at i2c_add_adapter().
> 
>         if (dev->of_node) {
>                 id = of_alias_get_id(dev->of_node, "i2c");
>  
> You could put something similar into the ethernet driver.
> 


Actually even what I did, didn't work as I expected. The order should have been changed in
the dsi file.

I will have a look on the ethernet driver.


Thanks,

Gregory


>     Andrew
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Gregory CLEMENT]

On 06/03/2014 15:51, Gregory CLEMENT wrote:
> On 06/03/2014 15:46, Andrew Lunn wrote:
>>>>>> I think you can use aliases to get the order correct, independent of
>>>>>> how you list them in DT. That should be a lot safer than assuming
>>>>>> things are instantiated from top to bottom.
>>>>>
>>>>> It sounds interesting, how would you do this?
>>>>
>>>> As there already is in armada-370-xp.dtsi
>>>>
>>>>         aliases {
>>>>                 eth0 = &eth0;
>>>>                 eth1 = &eth1;
>>>>         };
>>>>
>>>>
>>>> 	eth0: ethernet at 70000 {
>>>> 	}
>>>>         eth1: ethernet at 74000 {
>>>> 	}
>>>>
>>>> This at least works for i2c devices. The pdev->id is set using the
>>>> alias number.
>>>
>>> Well I think it doesn't work with ethernet devices because we already do
>>> this in aramda-38x.dtsi:
>>>
>>> 	aliases {
>>> 		gpio0 = &gpio0;
>>> 		gpio1 = &gpio1;
>>> 		eth0 = &eth0;
>>> 		eth1 = &eth1;
>>> 		eth2 = &eth2;
>>> 	};
>>>
>>> 	eth1: ethernet at 30000 {
>>> 	}
>>> 	eth2: ethernet at 34000 {
>>> 	}
>>> 	eth0: ethernet at 70000 {
>>> 	}
>>
>> Ah, Erm, O.K. 
>>
>> It seems to be an i2c thing. Take a look at i2c_add_adapter().
>>
>>         if (dev->of_node) {
>>                 id = of_alias_get_id(dev->of_node, "i2c");
>>  
>> You could put something similar into the ethernet driver.
>>
> 
> 
> Actually even what I did, didn't work as I expected. The order should have been changed in
> the dsi file.
> 
> I will have a look on the ethernet driver.

Well the naming is done in __dev_alloc_name() and it depends on
the probe order.

So I really wonder if we should not put the ethernet at 70000 before the othe
Ethernet node in the armada-38x.dts file. Otherwise it is very misleading to
have eth0 for the second interface, eth1 for the third one, and eth2 for
the first one.


Thanks,

Gregory

> 
> 
> Thanks,
> 
> Gregory
> 
> 
>>     Andrew
>>
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Ezequiel Garcia]

On Mar 06, Gregory CLEMENT wrote:
> On 06/03/2014 15:51, Gregory CLEMENT wrote:
> > the dsi file.
> > 
> > I will have a look on the ethernet driver.
> 
> Well the naming is done in __dev_alloc_name() and it depends on
> the probe order.
> 

Can't we fix this so the probe order doesn't affect the name?

Is that sane?
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Andrew Lunn]

> Can't we fix this so the probe order doesn't affect the name?
> 
> Is that sane?

You are not supposed to trust the device name, since probing can
happen in parallel, on different buses. udev should have rules to name
the interfaces based on the MAC address. On my Debian system i have:

/etc/udev/rules.d/70-persistent-net.rules

So what is important is that the MAC addresses are assigned correctly
to the device. And DT does that based on MMIO address, so should be
reliable, independent of probe order.

   Andrew

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Ezequiel Garcia]

On Mar 06, Andrew Lunn wrote:
> > Can't we fix this so the probe order doesn't affect the name?
> > 
> > Is that sane?
> 
> You are not supposed to trust the device name, since probing can
> happen in parallel, on different buses. udev should have rules to name
> the interfaces based on the MAC address. On my Debian system i have:
> 
> /etc/udev/rules.d/70-persistent-net.rules
> 
> So what is important is that the MAC addresses are assigned correctly
> to the device. And DT does that based on MMIO address, so should be
> reliable, independent of probe order.
> 

Right, makes perfect sense!

So we can just keep the nodes address-ordered, without caring about the name?

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Gregory CLEMENT]

On 06/03/2014 20:17, Ezequiel Garcia wrote:
> On Mar 06, Andrew Lunn wrote:
>>> Can't we fix this so the probe order doesn't affect the name?
>>>
>>> Is that sane?
>>
>> You are not supposed to trust the device name, since probing can
>> happen in parallel, on different buses. udev should have rules to name
>> the interfaces based on the MAC address. On my Debian system i have:
>>
>> /etc/udev/rules.d/70-persistent-net.rules
>>
>> So what is important is that the MAC addresses are assigned correctly
>> to the device. And DT does that based on MMIO address, so should be
>> reliable, independent of probe order.
>>

I was aware of this solution, and indeed for the end user it is the thing
to do.

However my concern was more about the people testing the kernel early or for
people bringing up a new board. I fear that we will have many false bug report
about it.

For the second category, I think we should at least point this in the dtsi.


Thanks,

Gregory


> 
> Right, makes perfect sense!
> 
> So we can just keep the nodes address-ordered, without caring about the name?
> 




-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[Jason Cooper]

On Fri, Mar 07, 2014 at 10:53:42AM +0100, Gregory CLEMENT wrote:
> On 06/03/2014 20:17, Ezequiel Garcia wrote:
> > On Mar 06, Andrew Lunn wrote:
> >>> Can't we fix this so the probe order doesn't affect the name?
> >>>
> >>> Is that sane?
> >>
> >> You are not supposed to trust the device name, since probing can
> >> happen in parallel, on different buses. udev should have rules to name
> >> the interfaces based on the MAC address. On my Debian system i have:
> >>
> >> /etc/udev/rules.d/70-persistent-net.rules
> >>
> >> So what is important is that the MAC addresses are assigned correctly
> >> to the device. And DT does that based on MMIO address, so should be
> >> reliable, independent of probe order.

errr... I've always viewed the udev rules for persistent naming as a
hacky work-around.  If we have an opportunity to present consistent
names to userspace, then we should do that.  Otherwise, why would
devicetree have the ability to assign aliases?

> I was aware of this solution, and indeed for the end user it is the thing
> to do.

If we're broken, then yes.  Once we fix it, then the udev rules would
just confirm that the naming is the same from the previous boot.

thx,

Jason.

[PATCH] ARM: mvebu: add Device Tree for the Armada 385 RD board

[One Thousand Gnomes]

On Thu, 6 Mar 2014 18:23:39 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

> > Can't we fix this so the probe order doesn't affect the name?
> > 
> > Is that sane?
> 
> You are not supposed to trust the device name, since probing can
> happen in parallel, on different buses. udev should have rules to name
> the interfaces based on the MAC address. On my Debian system i have:
> 
> /etc/udev/rules.d/70-persistent-net.rules
> 
> So what is important is that the MAC addresses are assigned correctly
> to the device. And DT does that based on MMIO address, so should be
> reliable, independent of probe order.

Remembering of course thats its valid to have one MAC address per system
not per network controller, so this does blow up in certain cases. You
can still use udev rules for most of those cases to identify off some
other property.

Alan