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

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. :)


-Olof