From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 2/8] xen/arm: Retrieve the correct number of cells when building dom0 DT Date: Mon, 28 Sep 2015 16:25:24 +0100 Message-ID: <56095BE4.9010400@citrix.com> References: <1442944062-4324-1-git-send-email-julien.grall@citrix.com> <1442944062-4324-3-git-send-email-julien.grall@citrix.com> <1443196906.25250.179.camel@citrix.com> <560955B8.3050202@citrix.com> <1443453563.25250.272.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZgaKE-0005rY-Bv for xen-devel@lists.xenproject.org; Mon, 28 Sep 2015 15:26:46 +0000 In-Reply-To: <1443453563.25250.272.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , xen-devel@lists.xenproject.org Cc: stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org On 28/09/15 16:19, Ian Campbell wrote: > On Mon, 2015-09-28 at 15:59 +0100, Julien Grall wrote: >> Hi Ian, >> >> On 25/09/15 17:01, Ian Campbell wrote: >>> On Tue, 2015-09-22 at 18:47 +0100, Julien Grall wrote: >>>> The function dt_n_*_cells will retrieve the number of cells for a >>>> given >>>> node. Those numbers may not be correct to use for the child "reg" >>>> property if the parent is passed. >>> >>> I think a clearer way to express this is that the functions return the >>> number of cells to use for a reg property in the given node, and so >>> they >>> will naturally not necessarily return the right number if you give them >>> some other node (whether that's the parent or some other node >>> entirely). >> >> I will rework this part into: >> >> "The function dt_n_*_cells return the number of cells to use for a reg >> property in a given node. So those numbers won't be correct if the >> parent of a give node is passed." > > ^n > >> >>> >>>> This is fine today because the parent is always the root node which >>>> means there is no upper parent. >>>> >>>> Introduce new helpers dt_child_n_*_cells to retrieve the number of >>>> cells for the address and size that can be used to create the "reg" >>>> property of a child of a given parent. >>> >>> "of the immediate child of a given" >>> >>> maybe? >> >> I'm not sure to see why "immediate" is necessary here. A child is always >> immediate, otherwise it would be grandchild or else. > > Sadly it's not as unambiguous as that in this kind of context, child could > be taken to mean "somewhere below". I will add the "immediate" to remove the ambiguity. Regards, -- Julien Grall