Re: wrap around in a memory region property?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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



[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux