From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH RFC XEN v1 01/14] xen: arm: Add gic_hw_desc Date: Tue, 15 Dec 2015 16:35:13 +0000 Message-ID: <56704141.6070606@citrix.com> References: <1449671507.16124.264.camel@citrix.com> <1449671548-4050-1-git-send-email-ian.campbell@citrix.com> <1450196508.16856.197.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1450196508.16856.197.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 , Stefano Stabellini Cc: julien.grall@citrix.com, wei.liu2@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 15/12/15 16:21, Ian Campbell wrote: > On Tue, 2015-12-15 at 16:15 +0000, Stefano Stabellini wrote: >> On Wed, 9 Dec 2015, Ian Campbell wrote: >>> Because the enum gic_version values do not correspond to the gic >>> version (in order to allow space for variants such as GICv2m, although >>> that is currently not present) logging the raw value is not terribly >>> useful. Provide gic_hw_desc which provides a string describing each >>> GIC version. >>> >>> Will be used in a later patch. >>> >>> Signed-off-by: Ian Campbell >>> --- >>> xen/arch/arm/gic.c | 14 ++++++++++++++ >>> xen/include/asm-arm/gic.h | 1 + >>> 2 files changed, 15 insertions(+) >>> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >>> index 1e1e5ba..bea39d6 100644 >>> --- a/xen/arch/arm/gic.c >>> +++ b/xen/arch/arm/gic.c >>> @@ -62,6 +62,20 @@ enum gic_version gic_hw_version(void) >>> return gic_hw_ops->info->hw_version; >>> } >>> >>> +const char *gic_hw_desc(enum gic_version v) >>> +{ >>> + switch (v) { >>> + case GIC_V2: return "GIC v2"; >>> + case GIC_V3: return "GIC v3"; >>> + } >>> + >>> + /* >>> + * The compiler ought to gripe if the above doesn't cover all enum >>> + * gic_version, in case some version doesn't. >>> + */ >>> + return "Unknown"; >> default: ? > Deliberately not, since that would quash the expected compiler warning. What expected compiler warning? That switch statement, complete or not, is always valid. The only way you can plausibly get a warning is to drop the return "Unknown";, and have the compiler warning about a missing return statement. This, however, will backfire on older compilers which can't/don't check whether the switch statement is complete. ~Andrew