On 16.05.2024 01:18, Stefano Stabellini wrote: > On Wed, 15 May 2024, 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. >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini <nicola.vetr...@bugseng.com> > > Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> > > >> --- >> xen/arch/x86/hvm/mtrr.c | 2 +- >> xen/arch/x86/hvm/rtc.c | 2 +- >> xen/arch/x86/include/asm/hvm/save.h | 2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c >> index 32f74c1db03b..1079851f70ed 100644 >> --- a/xen/arch/x86/hvm/mtrr.c >> +++ b/xen/arch/x86/hvm/mtrr.c >> @@ -16,7 +16,7 @@ >> #include <public/hvm/e820.h> >> >> /* Get page attribute fields (PAn) from PAT MSR. */ >> -#define pat_cr_2_paf(pat_cr,n) ((((uint64_t)pat_cr) >> ((n)<<3)) & 0xff) >> +#define pat_cr_2_paf(pat_cr, n) ((((uint64_t)(pat_cr)) >> ((n) << 3)) & >> 0xff) > > just a cosmetic change
Not really, as Nicola already pointed out. However, there's an excess pair of parentheses which better would have been re-arranged rather than adding yet another pair: #define pat_cr_2_paf(pat_cr, n) (((uint64_t)(pat_cr) >> ((n) << 3)) & 0xff) Preferably with that (which I'll likely take the liberty of adjusting while committing) Acked-by: Jan Beulich <jbeul...@suse.com> Jan
