Re: Duplicated memory node in the Device-Tree (WAS [XEN] Re: Duplicated memory nodes cause the BUG())

On Tue, Jul 25, 2017 at 06:27:31PM +0300, Andrii Anisov wrote:

On 25.07.17 17:23, Julien Grall wrote:

quoted

I think this is by chance rather than by design. The first
question to answer is why a Firmware would specify twice the same
memory banks? Is it valid from the specification?

Yep, that is the question.

I beleive that all memory regions described in any memory node's reg
entries should be disjoint (i.e. should not overlap). Per IEEE-1275, reg
entries (within a node) are supposed to be disjoint, and I would expect
this requirement to extend across nodes in the case of memory nodes.

Currently, the DT spec is somewhat sparse in wording, but this can be
corrected.

quoted

Regardless that, it looks like to me that the device-tree you give
to the board should not contain the memory nodes.

The device-tree is provided by vendor in that form, and u-boot is
theirs. It seems to me that they do not really care since the kernel
tolerates duplication.

quoted

quoted

ps. Linux kernel does tolerate duplicated memory nodes by
merging memory blocks. I.e. memblock_add_range() function is
commented as following:
/**
    * memblock_add_range - add new memblock region
    * @type: memblock type to add new region into
    * @base: base address of the new region
    * @size: size of the new region
    * @nid: nid of the new region
    * @flags: flags of the new region
    *
    * Add new memblock region [@base,@base+@size) into @type. The new
region
    * is allowed to overlap with existing ones - overlaps don't affect
already
    * existing regions.  @type is guaranteed to be minimal (all
neighbouring
    * compatible regions are merged) after the addition.
    *
    * RETURNS:
    * 0 on success, -errno on failure.
    */

IMO the function description is pretty straight-forward.
But let us wait for device tree guys feedback.

This might be the designed of *memblock*, but that does not mean that it
is a deliberate part of the DT handling. I beleive this is simply an
implementation detail that happens to mask a DT bug.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html