On Fri, Oct 5, 2018 at 1:05 AM AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> wrote: > > # This issue was raised from a discussion on my patch set of kexec_file > support on arm64. Please see the thread[1] for the background. > > Let's think about the case that we want to modify a device tree blob and > dynamically add a sort of "memory region" property to some node: > mem_range = <addr size>; > > When #address_cells == 1 and #size_cells == 1, how we should deal with > the memory if "addr + size" overflows a 32-bit range and wraps around? > > One instance is (from Frank's email), > > / memory@0xfffff000 { > > reg = <0xfffff000 0x2000>; > > } > > > > or must it be specified as (option 1): > > > > / memory@0xfffff000 { > > reg = <0xfffff000 0x1000 0x0 0x1000> Normally, we'd put these in address order. > > } > > > > or (option 2): > > > > / memory@0xfffff000 { > > reg = <0xfffff000 0x1000>; > > } > > memory@0 { > > reg = <0x0 0x1000>; > > } Either option 1 or 2 is valid. Probably 1 is more common. Note that even these wrap. They wrap to 0 which I think we have to support, but going past that shouldn't be allowed IMO. We had numerous discussions in the past about this in context of dma-ranges. > Or does it imply, in fact, > 0x0fffff000-0x0ffffffff, and > 0x100000000-0x100000fff ? > (because neither #address_cells nor #size_cells, in theory, prevents > the host from having >32-bit memory space.) No. If you have more than 32-bits, increase the cells. Rob