Message ID | 877f81b013.fsf@free-electrons.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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
--- 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 ---------^