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

[Julien Grall <julien.grall@xxxxxxx>]

On 25/07/17 16:27, Andrii Anisov wrote:
> Hello Julien,
Hi Andrii,

> On 25.07.17 17:23, Julien Grall wrote:
> > 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.
>
> > 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.
I have seen work on this board for the past year and it is the first 
time I have seen a complain about memory overlap. So why this sudden 
change? Is that a comment from the vendor or your guess?
> > >  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.
You need to differentiate the device-tree spec itself and Linux 
implementation. memblock is something common to all architecture. It 
does not mean it is something valid to do.
> But let us wait for device tree guys feedback.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel