[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH][for-next v2 5/8] x86/io_apic: address violation of MISRA C:2012 Rule 10.1


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 16 Oct 2023 17:42:10 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OTDC0WfAR+lZCIZrpiMFQMM69m657zcLgvAgFRzBO70=; b=lnfCweaD5byGj3nuTlvRYfk0D61InrwTDBfepD5RoG1rGEmJxRxOHDw7TOCoD4ZYP1lV8G/f0LE/oAekwQ/EgmdZIJx2CgVivS10Bxd9C8BuMAfJO1CMWVZG5pzqUqdsg/SdHArQ6rcJZnpJvAHLYAsuDBaoly6ziTs1dethkEKzGMdXyWugC3vfKO2pF3F6Jbq7P2260RN/7czCFicgSatwKyHi4cG3orbEtmj+m+6UO2uvjsR95Lp/yvkKXBo4Hw7LHDvDdKXmE0DKmeEFdHFGbQ1P3PpWpSB30ZxNYFpX25Bh3+znwGTd9LN/EcRTLVqhZLYV0BqY5u++UOj77A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nBLindH1IeYN7iTfSPmaolQSB4UBKxWQqx7jkK2euDiDuCAOBe9fRnD4Bo5gMoajyu/C41hdI/eSDKHR6hcp0uHd4UWxjrAIVbIvuOS2wUl57IQBwIYV51vHqwn7HFKXA9lrw9heOx/0jw0HRnG3PWYbZwmE5tFNHi/Xdm8Pkvg0b096CkF8MD8S57txaovG1/4Vx9JYiK5dfQHYOZnrw0htrppCaqWcrV3CiDVhYXkc16+4Kw4RrGLuSe3X7TyrNPwCIMmnC1VC73pUz9IbIPoErvrGixg8hA9V9tGJgFP8HA0VhTJEV/cYCjtkB23T3B7ULQu5lnpXjAfJz88Q8w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 16 Oct 2023 15:42:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12.10.2023 17:28, Nicola Vetrini wrote:
> The definition of IO_APIC_BASE contains a sum of an essentially enum
> value (FIX_IO_APIC_BASE_0) that is positive with an index that, in all
> instances, is unsigned, therefore the former is cast to unsigned, so that
> the operands are of the same essential type.
> 
> No functional change.
> ---
>  xen/arch/x86/include/asm/io_apic.h | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/include/asm/io_apic.h 
> b/xen/arch/x86/include/asm/io_apic.h
> index a7e4c9e146de..a0fc50d601fe 100644
> --- a/xen/arch/x86/include/asm/io_apic.h
> +++ b/xen/arch/x86/include/asm/io_apic.h
> @@ -14,9 +14,10 @@
>   * Copyright (C) 1997, 1998, 1999, 2000 Ingo Molnar
>   */
>  
> -#define IO_APIC_BASE(idx)                                               \
> -    ((volatile uint32_t *)(__fix_to_virt(FIX_IO_APIC_BASE_0 + (idx))    \
> -                           + (mp_ioapics[idx].mpc_apicaddr & ~PAGE_MASK)))
> +#define IO_APIC_BASE(idx)                                     \
> +    ((volatile uint32_t *)                                    \
> +     (__fix_to_virt((unsigned int)FIX_IO_APIC_BASE_0 + (idx)) \
> +      + (mp_ioapics[idx].mpc_apicaddr & ~PAGE_MASK)))

Let's assume that down the road we want to make __fix_to_virt() an inline
function (which perhaps it really ought to be already): Won't this trade
one violation for another then? I wonder whether the better course of
action wouldn't be to switch the two enums to be "anonymous", even if that
means adjusting __set_fixmap() and __set_fixmap_x().

As an aside, since you touch the entire construct, it would be nice if the
+ was also moved to the end of the earlier line.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.