Re: [Xen-devel] [PATCH v3 3/6] xen/arm: keep track of reserved-memory regions

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
> 
> On 7/8/19 8:02 PM, Oleksandr wrote:
> > On 22.06.19 02:56, Stefano Stabellini wrote:
> > I have tested this series and got the same behavior as with V2 [1].
> > 
> > The "non-reserved-memory" node in my device-tree
> > (sram@47FFF000->scp_shmem@0) is still interpreted as a "reserved-memory".
> > I think, this takes place because current implementation iterates over all
> > device tree nodes starting
> > from real "reserved-memory" node up to the end of the device tree. And if
> > there is at least one "non-reserved-memory" node (with a suitable depth and
> > valid "reg" property)
> > located down the device tree, it will be mistakenly inserted to
> > bootinfo.reserved_mem (as in my case).
> 
> The problem is because we are passing the depth of the parent. Because of
> that, it will look for anything at the same depth (see the check depth >=
> min_depth in device_tree_for_each_node).
> 
> The correct solution here, would be to use the depth of the child (i.e depth +
> 1) when calling device_tree_for_each_node in process_reserved_memory_node.

Yes, that is the right thing to do, together with also passing
address_cells and size_cells of the parent to device_tree_for_each_node,
so that it can be calculate appropriately at all times, regardless of
depth.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel