diff mbox

[v3,09/13] ARM: dts: armada-375: Fixup soc DT warning

Message ID 877f81b013.fsf@free-electrons.com (mailing list archive)
State New, archived
Headers show

Commit Message

Gregory CLEMENT Nov. 18, 2016, 9:38 a.m. UTC
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@f00100000000 {  
>> >
>> > Where is this value coming from? Why does the soc node needs to have a  
>> 
>> It cames from the dts files.
>
> Where?


 			  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

Comments

Thomas Petazzoni Nov. 18, 2016, 1:38 p.m. UTC | #1
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
diff mbox

Patch

--- 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 ---------^