From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 1/5] xen: arm: propagate gic's #address-cells property to dom0. Date: Tue, 4 Nov 2014 12:11:44 -0500 Message-ID: <20141104171144.GJ4510@laptop.dumpdata.com> References: <1414144694.15687.31.camel@citrix.com> <1414144717-32328-1-git-send-email-ian.campbell@citrix.com> <54513A08.3000908@linaro.org> <1415096635.11486.15.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1415096635.11486.15.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 Cc: stefano.stabellini@eu.citrix.com, Julien Grall , tim@xen.org, xen-devel@lists.xen.org, Clark Laughlin , Pranavkumar Sawargaonkar List-Id: xen-devel@lists.xenproject.org On Tue, Nov 04, 2014 at 10:23:55AM +0000, Ian Campbell wrote: > On Wed, 2014-10-29 at 19:03 +0000, Julien Grall wrote: > > Hi Ian, > > > > On 24/10/2014 10:58, Ian Campbell wrote: > > > The interrupt-map property requires that the interrupt-parent node > > > must have both #address-cells and #interrupt-cells properties (see > > > ePAPR 2.4.3.1). Therefore propagate the property if it is present. > > > > > > We must propagate (rather than invent our own value) since this value > > > is used to size fields within other properties within the tree. > > > > > > ePAPR strictly speaking requires that the interrupt-parent node > > > always has these properties. However reality has diverged from this > > > and implementations will recursively search parents for #*-cells > > > properties. Hence we only copy if it is present. > > > > > > Signed-off-by: Ian Campbell > > > > Reviewed-by: Julien Grall > > > > Without this patch I can't boot Xen on the Foundation model with GIC-v3. > > Is it possible to push this patch for Xen 4.5 rc1? > > Konrad, I think this is needed for 4.5 since without it dom0 can fail to > parse certain other constructs within the DT (in bits which we don't > generate and can't easily/don't want to rewrite as we pass them > through). Release-Acked-by: Konrad Rzeszutek Wilk > > The risk is that some bit of DT which we do generate relies on this > value being absent (as it was before this patch). I don't believe we > generate any such nodes. The consumers are typically nodes representing > devices which we pass through rather than messing with them. > > Ian. >