Skip to contentSkip to conversation

4xx: Add aliases node to 4xx dts files

PATCH Applied Stefan Roese 5 participants 10 messages Dec 15, 2007 – Dec 17, 2007

Subsystems (2)
Device tree bindings PowerPC
lore
Share & tools
lore

Stefan Roese

author
#0 lore raw

PATCH 1/1 4xx: Add aliases node to 4xx dts files

Signed-off-by Stefan Roese <[email protected]>
---
 arch/powerpc/boot/dts/bamboo.dts  |    9 +++++++++
 arch/powerpc/boot/dts/ebony.dts   |    7 +++++++
 arch/powerpc/boot/dts/ep405.dts   |    6 ++++++
 arch/powerpc/boot/dts/katmai.dts  |    7 +++++++
 arch/powerpc/boot/dts/kilauea.dts |    7 +++++++
 arch/powerpc/boot/dts/rainier.dts |   11 ++++++++++-
 arch/powerpc/boot/dts/sequoia.dts |    9 +++++++++
 arch/powerpc/boot/dts/taishan.dts |    7 +++++++
 arch/powerpc/boot/dts/walnut.dts  |    6 ++++++
 9 files changed, 68 insertions(+), 1 deletions(-)
arch/powerpc/boot/dts/bamboo.dts +9 -0
index 3652aec..2ebb437 100644
@@ -18,6 +18,15 @@
 	compatible = "amcc,bamboo";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+		serial2 = &UART2;
+		serial3 = &UART3;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/ebony.dts +7 -0
index 3cb2849..f8790c4 100644
@@ -18,6 +18,13 @@
 	compatible = "ibm,ebony";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/ep405.dts +6 -0
index 16cfc0d..9293855 100644
@@ -16,6 +16,12 @@
 	compatible = "ep405";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/katmai.dts +7 -0
index 824cf4e..350e70e 100644
@@ -19,6 +19,13 @@
 	compatible = "amcc,katmai";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC0;
+		serial0 = &UART0;
+		serial1 = &UART1;
+		serial2 = &UART2;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/kilauea.dts +7 -0
index 0a3fbfa..3814199 100644
@@ -15,6 +15,13 @@
 	compatible = "amcc,kilauea";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/rainier.dts +10 -1
index 63d996e..b2e8231 100644
@@ -19,6 +19,15 @@
 	compatible = "amcc,rainier";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+		serial2 = &UART2;
+		serial3 = &UART3;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;

@@ -93,7 +102,7 @@
 		#size-cells = <1>;
 		ranges;
 		clock-frequency = <0>; /* Filled in by zImage */
-		
+
 		SDRAM0: sdram {
 			compatible = "ibm,sdram-440grx", "ibm,sdram-44x-ddr2denali";
 			dcr-reg = <010 2>;
arch/powerpc/boot/dts/sequoia.dts +9 -0
index dbb1b3b..fb88028 100644
@@ -19,6 +19,15 @@
 	compatible = "amcc,sequoia";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+		serial2 = &UART2;
+		serial3 = &UART3;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/taishan.dts +7 -0
index 0dec702..0706a4a 100644
@@ -17,6 +17,13 @@
 	compatible = "amcc,taishan";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC2;
+		ethernet1 = &EMAC3;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
arch/powerpc/boot/dts/walnut.dts +6 -0
index 8fcf6aa..0e3825e 100644
@@ -16,6 +16,12 @@
 	compatible = "ibm,walnut";
 	dcr-parent = <&/cpus/cpu@0>;
 
+	aliases {
+		ethernet0 = &EMAC;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
Signature · 1 line
1.5.3.7.949.g2221a6
#3 lore raw
Quoted 2 lines

Applied to my candidates tree. Though I'd really like dtc to be merged so that we can figure out what the in-kernel version will support.

Hopefully some version that stores path strings in the properties in /aliases, and not phandles. Or does that current version of DTC do that correctly already, and just has an inconvenient source syntax?

Segher

#4 lore raw
Quoted 6 lines · On Sun, 16 Dec 2007 19:10:02 +0100 Segher Boessenkool…
Quoted 2 lines

Applied to my candidates tree. Though I'd really like dtc to be merged so that we can figure out what the in-kernel version will support.

Hopefully some version that stores path strings in the properties in /aliases, and not phandles. Or does that current version of DTC do that correctly already, and just has an inconvenient source syntax?

I have no idea. I can't even keep track of whether various DTC features are dts-v1 only or not, and which "version" of DTC supports which features. That's why I'm sort of waiting for Paul to merge whatever version of DTC he is going to merge. *HINT*

We should also probably make a clear cut DTC release Real Soon Now. *HINT*

josh

#5 lore raw
In reply to Segher Boessenkool
Quoted 7 lines · Segher Boessenkool
Quoted 2 lines

Applied to my candidates tree. Though I'd really like dtc to be merged so that we can figure out what the in-kernel version will support.

Hopefully some version that stores path strings in the properties in /aliases, and not phandles. Or does that current version of DTC do that correctly already, and just has an inconvenient source syntax?

I don't think anyone's actually gone and generated phandles in /aliases, although it was suggested early on. The syntax is

	foo = < &bar >;
to generate a phandle and
	foo = &bar;

to generate a path.

I was a bit worried about confusion between these forms, but at least Kumar and myself came up with this syntax independently, which suggests it's not too surprising to most people, and no-one had any other suggestions.

Signature · 4 lines
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
#6 lore raw
Quoted 11 lines
Quoted 4 lines

Hopefully some version that stores path strings in the properties in /aliases, and not phandles. Or does that current version of DTC do that correctly already, and just has an inconvenient source syntax?

I don't think anyone's actually gone and generated phandles in /aliases, although it was suggested early on. The syntax is

	foo = < &bar >;
to generate a phandle and
	foo = &bar;

to generate a path.

Ah, I see.

Quoted 4 lines

I was a bit worried about confusion between these forms, but at least Kumar and myself came up with this syntax independently, which suggests it's not too surprising to most people, and no-one had any other suggestions.

I think I suggested it before, but anyway:

how about you write

	aliases {
		foo = "/the/path/to/foo";
	};

and then you can use &foo in the rest of the DTS to refer to the phandle (or path string, as it turns out :-) ) of the node? I.e., use the aliases node to _generate_ aliases.

Seems simpler than the current thing to me.

Segher

#7 lore raw
Quoted 27 lines · Segher Boessenkool
Quoted 11 lines
Quoted 4 lines

Hopefully some version that stores path strings in the properties in /aliases, and not phandles. Or does that current version of DTC do that correctly already, and just has an inconvenient source syntax?

I don't think anyone's actually gone and generated phandles in /aliases, although it was suggested early on. The syntax is

	foo = < &bar >;
to generate a phandle and
	foo = &bar;

to generate a path.

Ah, I see.

Quoted 4 lines

I was a bit worried about confusion between these forms, but at least Kumar and myself came up with this syntax independently, which suggests it's not too surprising to most people, and no-one had any other suggestions.

I think I suggested it before, but anyway:

how about you write

	aliases {
		foo = "/the/path/to/foo";
	};
Quoted 5 lines

and then you can use &foo in the rest of the DTS to refer to the phandle (or path string, as it turns out :-) ) of the node? I.e., use the aliases node to _generate_ aliases.

Seems simpler than the current thing to me.

No. First, it's much nicer to have the label definition local to the node it's labelling, rather than having to keep looking over at the aliases node. Second, this syntax can only generate labels to nodes, whereas the current syntax can label properties, their contents and reserve entries as well. Third, we absolutely don't want to ditch the current well-established and widely used syntax.

What I do want to add is a way of making aliases from labels without having to explicitly fill in the aliases node. Perhaps something like

	EMAC0[ethernet0]: ethernet@... { ... };
which would be equivalent to 
	EMAC0: ethernet@... { ... };
	...
	aliases { ethernet0 = &EMAC0; };
Signature · 4 lines
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
#8 lore raw
In reply to David Gibson

So, like, the other day David Gibson mumbled:

Quoted 4 lines · Segher Boessenkool
Quoted 3 lines

Hopefully some version that stores path strings in the properties in /aliases, and not phandles.

Yes.

Quoted 3 lines
Quoted 3 lines

Or does that current version of DTC
do that correctly already, and just has an inconvenient source syntax?

Feh. If there is an "inconvenient source syntax", or any other annoying irregularity, please, by all means, suggest improvements and offer patches!

Quoted 11 lines

I don't think anyone's actually gone and generated phandles in /aliases, although it was suggested early on. The syntax is

	foo = < &bar >;
to generate a phandle and
	foo = &bar;

to generate a path.

I was a bit worried about confusion between these forms, but at least Kumar and myself came up with this syntax independently, which suggests it's not too surprising to most people, and no-one had any other suggestions.

To be a bit more complete, Kumar and I discussed this as well.

jdl

#9 lore raw
In reply to Josh Boyer
Quoted 9 lines · Josh Boyer
Quoted 3 lines · On Sun, 16 Dec 2007 17:19:59 +1100 David Gibson <[email protected]>…
Quoted 1 line · Stefan Roese
Signed-off-by Stefan Roese <[email protected]>
Acked-by David Gibson <[email protected]>

Applied to my candidates tree. Though I'd really like dtc to be merged so that we can figure out what the in-kernel version will support.

I know, I know. I've been a little preoccupied lately and need to get back to working out what to do with the merge patches.

Signature · 4 lines
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson