Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757631AbcC2QcG (ORCPT ); Tue, 29 Mar 2016 12:32:06 -0400 Received: from foss.arm.com ([217.140.101.70]:41547 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752517AbcC2QcE (ORCPT ); Tue, 29 Mar 2016 12:32:04 -0400 Date: Tue, 29 Mar 2016 17:31:47 +0100 From: Mark Rutland To: Will Deacon Cc: Shannon Zhao , linux-arm-kernel@lists.infradead.org, stefano.stabellini@citrix.com, david.vrabel@citrix.com, devicetree@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, julien.grall@arm.com, peter.huangpeng@huawei.com, xen-devel@lists.xen.org, zhaoshenglong@huawei.com Subject: Re: [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI Message-ID: <20160329163147.GB27223@leverpostej> References: <1458830676-27075-1-git-send-email-shannon.zhao@linaro.org> <1458830676-27075-13-git-send-email-shannon.zhao@linaro.org> <20160329161837.GH6745@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329161837.GH6745@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2106 Lines: 53 On Tue, Mar 29, 2016 at 05:18:38PM +0100, Will Deacon wrote: > On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote: > > When it's a Xen domain0 booting with ACPI, it will supply a /chosen and > > a /hypervisor node in DT. So check if it needs to enable ACPI. > > > > Signed-off-by: Shannon Zhao > > Reviewed-by: Stefano Stabellini > > Acked-by: Hanjun Guo > > --- > > arch/arm64/kernel/acpi.c | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > > index d1ce8e2..4e92be0 100644 > > --- a/arch/arm64/kernel/acpi.c > > +++ b/arch/arm64/kernel/acpi.c > > @@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node, > > { > > /* > > * Return 1 as soon as we encounter a node at depth 1 that is > > - * not the /chosen node. > > + * not the /chosen node, or /hypervisor node when running on Xen. > > */ > > - if (depth == 1 && (strcmp(uname, "chosen") != 0)) > > - return 1; > > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) { > > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0)) > > + return 1; > > + } > > Hmm, but xen_initial_domain() is false when xen isn't being used at all, > so it feels to me like this is a bit too far-reaching and is basically > claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to > "xen,hypervisor" or something? > > Mark, got any thoughts on this? The node has a compatible string, "xen,xen" per [1], which would tell us absolutely that xen is present. I'd be happy checking for that explicitly. In patch 11 fdt_find_hyper_node checks the compatible string. We could factor that out into a helper like is_xen_node(node) and use it here too. If in future we want to do the same for other hypervisors we can add explicit checks for their compatible strings and/or wrap that in a more generic helper to cater for any hypervisor-specific details. Thanks, Mark. [1] Documentation/devicetree/bindings/arm/xen.txt