On Thu, Aug 28, 2014 at 03:23:49PM -0700, Olof Johansson wrote:

On Thu, Aug 28, 2014 at 10:54 AM, Rob Herring [off-list ref] wrote:

quoted

On Thu, Aug 28, 2014 at 12:19 PM, Olof Johansson [off-list ref] wrote:

quoted

On Thu, Aug 28, 2014 at 10:03 AM, Mark Rutland [off-list ref] wrote:

quoted

On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote:

quoted

On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland [off-list ref] wrote:

quoted

Hi,

quoted

quoted

+   cpus {
+           #address-cells = <2>;
+           #size-cells = <0>;

Why size-cells=2? Can you not fit a cpuid in 32 bits?

As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing
CPU reg property) Linux can handle single-cell cpu node reg entries
where /cpus/#address-cells = <1>.

I can't make any guarantees about other code (e.g. bootloaders) which
might try to do things with cpu nodes, YMMV.

Ok. If address-cells is kept at 2 the unit address needs to be changed
to "0,0". So one or the other has to be changed.

I'm happy either way.

I'm not sure the rest of the tree had "0," prefixes on all of the
unit-addresses for 64-bit addresses that were under 4GB, and I'm not
sure that existing dts consistently do that either.

Do we want to enforce that for all 64-bit unit-addresses?

Yeah, I believe that's the only valid format for a 2-address-cell unit address.

But we don't do leading 0's anywhere else like single cell unit
addresses. Buses expressed with ranges and offsets are one example.
Also, I2C addresses have a 32-bit size in DT yet are only 8-bit and we
don't do leading zero's there.

Ok, I'm happily proven wrong here, also by confirming how this is done
on "real" OF.

According to benh:

15:20 <benh> ojn: 0,0 is not quite right, it's supposed to be used
when the two numbers are different things, like device,fn on PCI

The same is true for >2^32 unit addresses, they just use the one
integer instead of x,y.

So, I take back all I've said on this in the last 72 hours. :) It
looks like we might need to revisit some of the 32-bit DTs.  Simon,
drop the series you had. :)

Thanks will do.

Is the way forward for me to apply my original patch to
change memory@180000000 to memory@140000000? And abandon all
the ',' only changes?This one:

This is the original patch:

From: Simon Horman <redacted>

[PATCH] ARM: shmobile: lager: correct memory map

The base address of the second memory region on the lager
board is 0x140000000. Update the tag used in the dts file accordingly.

This is a documentation fix and should have no run-time affect.

This problem was introduced when the second memory region
was added to the lager dts file by 62bc32a2573c4219
("ARM: shmobile: Include all 4 GiB of memory on Lager)"
in v3.14.

Reported-by: NAOYA SHIIBA <redacted>
Signed-off-by: Simon Horman <redacted>
---
 arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 0118cbf..84dcafa 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts

@@ -32,7 +32,7 @@
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
-	memory@180000000 {
+	memory@140000000 {
 		device_type = "memory";
 		reg = <1 0x40000000 0 0xc0000000>;
 	};

-- 
2.0.1