From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH] ARM: DT: Add binding for GIC virtualization extentions (VGIC) Date: Tue, 03 Apr 2012 09:35:37 -0600 Message-ID: <20120403153538.0D1B83E044A@localhost> References: <1333384217-13441-1-git-send-email-marc.zyngier@arm.com> <4F7AC138.9020308@citrix.com> <4F7AC8A8.9020606@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F7AC8A8.9020606@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Marc Zyngier , David Vrabel Cc: "devicetree-discuss@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "rob.herring@calxeda.com" List-Id: devicetree@vger.kernel.org On Tue, 03 Apr 2012 10:53:44 +0100, Marc Zyngier wrote: > On 03/04/12 10:22, David Vrabel wrote: > > Hi David, > > > On 02/04/12 17:30, Marc Zyngier wrote: > >> The GICv2 can have virtualization extension support, consisting > >> of an additional set of registers and interrupts. Add the necessary > >> binding to the GIC DT documentation. > > > > The Xen hypervisor's device tree support is very much incomplete so I've > > not looked into this is much detail. > > > > Would it make more sense to extend the existing gic binding with the the > > additional information rather than adding a new node? > > I'm actually torn between the two approaches. On one side, the VGIC is > part of the GIC spec, hence should be part of the GIC node. On the other > hand, it is logically handled by a different piece of software (the > hypervisor), and would normally be probed separately. Having a separate > node makes the probing more sensible. Don't get too hung up on the software side of things. Describe it in a way that makes sense for the hardware. There is lots of precidence for two hunks of software initializating from the same node; either by probe kicking off two init hooks, or by early init code going looking for the node manually. g.