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
