All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Nicola Vetrini <nicola.vetrini@bugseng.com>
Cc: sstabellini@kernel.org, michal.orzel@amd.com,
	xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
	consulting@bugseng.com, andrew.cooper3@citrix.com,
	roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org,
	xen-devel@lists.xenproject.org
Subject: Re: [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style
Date: Tue, 26 Mar 2024 11:05:41 +0100	[thread overview]
Message-ID: <f2d393e9-6b70-4998-9d85-e070d6bba556@suse.com> (raw)
In-Reply-To: <c924aa0d5b3b6adbb24cc638f739173cbc41862c.1711118582.git.nicola.vetrini@bugseng.com>

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> While at it, the style of these macros has been somewhat uniformed.

Hmm, yes, but they then still leave more to be desired. I guess I can see
though why you don't want to e.g. ...

> --- a/xen/arch/x86/include/asm/msi.h
> +++ b/xen/arch/x86/include/asm/msi.h
> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
> -#define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
> -#define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> -#define msi_data_reg(base, is64bit)	\
> -	( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
> -#define msi_mask_bits_reg(base, is64bit) \
> -	( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
> +#define msi_control_reg(base)        ((base) + PCI_MSI_FLAGS)
> +#define msi_lower_address_reg(base)  ((base) + PCI_MSI_ADDRESS_LO)
> +#define msi_upper_address_reg(base)  ((base) + PCI_MSI_ADDRESS_HI)
> +#define msi_data_reg(base, is64bit) \
> +    (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + PCI_MSI_DATA_32)
> +#define msi_mask_bits_reg(base, is64bit)                \
> +    (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT       \
> +                      : (base) + PCI_MSI_MASK_BIT - 4)

... drop the bogus == 1 in these two, making them similar to ...

>  #define msi_pending_bits_reg(base, is64bit) \
> -	((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
> -#define msi_disable(control)		control &= ~PCI_MSI_FLAGS_ENABLE
> +    ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))

... this.

> +#define msi_disable(control) (control) &= ~PCI_MSI_FLAGS_ENABLE

Doesn't this need an outer pair of parentheses, too?

>  #define multi_msi_capable(control) \
> -	(1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
> +    (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>  #define multi_msi_enable(control, num) \
> -	control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
> -#define is_64bit_address(control)	(!!(control & PCI_MSI_FLAGS_64BIT))
> -#define is_mask_bit_support(control)	(!!(control & PCI_MSI_FLAGS_MASKBIT))
> +    (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);

And this, together with dropping the bogus semicolon?

There also look to be cases where MASK_EXTR() / MASK_INSR() would want using,
in favor of using open-coded numbers.

> +#define is_64bit_address(control) (!!((control) & PCI_MSI_FLAGS_64BIT))
> +#define is_mask_bit_support(control) (!!((control) & PCI_MSI_FLAGS_MASKBIT))
>  #define msi_enable(control, num) multi_msi_enable(control, num); \
> -	control |= PCI_MSI_FLAGS_ENABLE
> -
> -#define msix_control_reg(base)		(base + PCI_MSIX_FLAGS)
> -#define msix_table_offset_reg(base)	(base + PCI_MSIX_TABLE)
> -#define msix_pba_offset_reg(base)	(base + PCI_MSIX_PBA)
> -#define msix_enable(control)	 	control |= PCI_MSIX_FLAGS_ENABLE
> -#define msix_disable(control)	 	control &= ~PCI_MSIX_FLAGS_ENABLE
> -#define msix_table_size(control) 	((control & PCI_MSIX_FLAGS_QSIZE)+1)
> -#define msix_unmask(address)	 	(address & ~PCI_MSIX_VECTOR_BITMASK)
> -#define msix_mask(address)		(address | PCI_MSIX_VECTOR_BITMASK)
> +                                 (control) |= PCI_MSI_FLAGS_ENABLE

This again is suspiciously missing outer parentheses; really here, with
the earlier statement, it look like do { ... } while ( 0 ) or ({ ... })
are wanted.

> +#define msix_control_reg(base)       ((base) + PCI_MSIX_FLAGS)
> +#define msix_table_offset_reg(base)  ((base) + PCI_MSIX_TABLE)
> +#define msix_pba_offset_reg(base)    ((base) + PCI_MSIX_PBA)
> +#define msix_enable(control)         (control) |= PCI_MSIX_FLAGS_ENABLE
> +#define msix_disable(control)        (control) &= ~PCI_MSIX_FLAGS_ENABLE

Outer parentheses missing for these two again?

Jan


  reply	other threads:[~2024-03-26 10:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-22 16:01 [XEN PATCH 00/11] address some violations of MISRA C Rule 20.7 Nicola Vetrini
2024-03-22 16:01 ` [XEN PATCH 01/11] xen/list: address " Nicola Vetrini
2024-03-25  9:19   ` Jan Beulich
2024-03-22 16:01 ` [XEN PATCH 02/11] xen/xsm: add parentheses to comply with " Nicola Vetrini
2024-03-23  1:29   ` Daniel P. Smith
2024-03-22 16:01 ` [XEN PATCH 03/11] xen/efi: efibind: address violations of " Nicola Vetrini
2024-03-22 16:01 ` [XEN PATCH 04/11] xentrace: address violation " Nicola Vetrini
2024-03-25  9:20   ` Jan Beulich
2024-03-22 16:01 ` [XEN PATCH 05/11] xen: address MISRA C Rule 20.7 violation in generated hypercall Nicola Vetrini
2024-03-25  9:23   ` Jan Beulich
2024-03-22 16:01 ` [XEN PATCH 06/11] xen/efi: address violations of MISRA C Rule 20.7 Nicola Vetrini
2024-03-25  9:25   ` Jan Beulich
2024-03-25 13:07     ` Nicola Vetrini
2024-03-22 16:01 ` [XEN PATCH 07/11] xen/page_alloc: " Nicola Vetrini
2024-03-25  9:27   ` Jan Beulich
2024-03-26 15:27     ` Nicola Vetrini
2024-03-26 15:35       ` Jan Beulich
2024-03-26 15:57         ` Nicola Vetrini
2024-03-22 16:01 ` [XEN PATCH 08/11] x86/altcall: " Nicola Vetrini
2024-03-25  9:38   ` Jan Beulich
2024-03-25 14:47     ` Nicola Vetrini
2024-03-25 14:58       ` Jan Beulich
2024-03-26 10:30         ` Nicola Vetrini
2024-03-22 16:01 ` [XEN PATCH 09/11] x86/msi: address violation of MISRA C Rule 20.7 and coding style Nicola Vetrini
2024-03-26 10:05   ` Jan Beulich [this message]
2024-03-26 14:30     ` Nicola Vetrini
2024-03-26 15:13       ` Jan Beulich
2024-03-26 15:41         ` Nicola Vetrini
2024-03-26 16:06           ` Nicola Vetrini
2024-03-22 16:01 ` [XEN PATCH 10/11] x86/hvm: address violations of Rule 20.7 Nicola Vetrini
2024-03-26 10:13   ` Jan Beulich
2024-03-26 14:31     ` Nicola Vetrini
2024-03-22 16:02 ` [XEN PATCH 11/11] x86/public: hvm: address violations of MISRA C " Nicola Vetrini
2024-03-26 10:15   ` Jan Beulich
2024-03-26 14:34     ` Nicola Vetrini
2024-03-27  8:18   ` Jan Beulich
2024-03-25  8:00 ` [XEN PATCH 00/11] address some " Jan Beulich
2024-03-25  8:07   ` Nicola Vetrini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2d393e9-6b70-4998-9d85-e070d6bba556@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ayan.kumar.halder@amd.com \
    --cc=bertrand.marquis@arm.com \
    --cc=consulting@bugseng.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=nicola.vetrini@bugseng.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xenia.ragiadakou@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.