From: Gianluca Luparini <gianluca.luparini@bugseng.com>

The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline states:
"A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type".

I propose to use "U" as a suffix to explicitly state when an integer constant is represented in an unsigned type.

Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
---
 xen/common/device_tree.c        | 4 ++--
 xen/include/xen/libfdt/fdt.h    | 2 +-
 xen/include/xen/libfdt/libfdt.h | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 8da1052911..0677193ab3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -2115,7 +2115,7 @@ static void __init __unflatten_device_tree(const void *fdt,
     /* Allocate memory for the expanded device tree */
     mem = (unsigned long)_xmalloc (size + 4, __alignof__(struct dt_device_node));
 
-    ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
+    ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeefU);
 
     dt_dprintk("  unflattening %lx...\n", mem);
 
@@ -2125,7 +2125,7 @@ static void __init __unflatten_device_tree(const void *fdt,
     if ( be32_to_cpup((__be32 *)start) != FDT_END )
         printk(XENLOG_WARNING "Weird tag at end of tree: %08x\n",
                   *((u32 *)start));
-    if ( be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef )
+    if ( be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeefU )
         printk(XENLOG_WARNING "End of tree marker overwritten: %08x\n",
                   be32_to_cpu(((__be32 *)mem)[size / 4]));
     *allnextp = NULL;
diff --git a/xen/include/xen/libfdt/fdt.h b/xen/include/xen/libfdt/fdt.h
index f2e68807f2..7c99d838e8 100644
--- a/xen/include/xen/libfdt/fdt.h
+++ b/xen/include/xen/libfdt/fdt.h
@@ -47,7 +47,7 @@ struct fdt_property {
 
 #endif /* !__ASSEMBLY */
 
-#define FDT_MAGIC	0xd00dfeed	/* 4: version, 4: total size */
+#define FDT_MAGIC	0xd00dfeedU	/* 4: version, 4: total size */
 #define FDT_TAGSIZE	sizeof(fdt32_t)
 
 #define FDT_BEGIN_NODE	0x1		/* Start node: full name */
diff --git a/xen/include/xen/libfdt/libfdt.h b/xen/include/xen/libfdt/libfdt.h
index c71689e2be..dd6b649602 100644
--- a/xen/include/xen/libfdt/libfdt.h
+++ b/xen/include/xen/libfdt/libfdt.h
@@ -109,7 +109,7 @@ extern "C" {
 #define FDT_ERR_MAX		19
 
 /* constants */
-#define FDT_MAX_PHANDLE 0xfffffffe
+#define FDT_MAX_PHANDLE 0xfffffffeU
 	/* Valid values for phandles range from 1 to 2^32-2. */
 
 /**********************************************************************/
-- 
2.41.0

On 20.06.2023 12:34, Simone Ballarin wrote:
> From: Gianluca Luparini <gianluca.luparini@bugseng.com>
> 
> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline states:
> "A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type".
> 
> I propose to use "U" as a suffix to explicitly state when an integer constant is represented in an unsigned type.
> 
> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
> ---
>  xen/common/device_tree.c        | 4 ++--
>  xen/include/xen/libfdt/fdt.h    | 2 +-
>  xen/include/xen/libfdt/libfdt.h | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)

I think me and a few other people being on Cc here is attributed to the
(misleading) title. The set of touched files fully maps to "DEVICE TREE"
in ./MAINTAINERS afaict, which the prefix in the title would then also
be nice to express.

That said I'm not sure whether libfdt code actually wants touching this
way.

Jan

Il giorno mar 20 giu 2023 alle ore 14:43 Jan Beulich <jbeulich@suse.com> ha
scritto:

> On 20.06.2023 12:34, Simone Ballarin wrote:
> > From: Gianluca Luparini <gianluca.luparini@bugseng.com>
> >
> > The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
> headline states:
> > "A "u" or "U" suffix shall be applied to all integer constants that are
> represented in an unsigned type".
> >
> > I propose to use "U" as a suffix to explicitly state when an integer
> constant is represented in an unsigned type.
> >
> > Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
> > ---
> >  xen/common/device_tree.c        | 4 ++--
> >  xen/include/xen/libfdt/fdt.h    | 2 +-
> >  xen/include/xen/libfdt/libfdt.h | 2 +-
> >  3 files changed, 4 insertions(+), 4 deletions(-)
>
> I think me and a few other people being on Cc here is attributed to the
> (misleading) title. The set of touched files fully maps to "DEVICE TREE"
> in ./MAINTAINERS afaict, which the prefix in the title would then also
> be nice to express.
>

Yes, my bad. I will fix the commit name.


> That said I'm not sure whether libfdt code actually wants touching this
> way.
>
Yes, you are right. libfdt is out of scope. I will remove the changes in it.

>
> Jan
>


-- 
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com
<http://bugseng.com>)

Hi,

On 20/06/2023 13:43, Jan Beulich wrote:
> On 20.06.2023 12:34, Simone Ballarin wrote:
>> From: Gianluca Luparini <gianluca.luparini@bugseng.com>
>>
>> The xen sources contains violations of MISRA C:2012 Rule 7.2 whose headline states:
>> "A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type".
>>
>> I propose to use "U" as a suffix to explicitly state when an integer constant is represented in an unsigned type.
>>
>> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
>> ---
>>   xen/common/device_tree.c        | 4 ++--
>>   xen/include/xen/libfdt/fdt.h    | 2 +-
>>   xen/include/xen/libfdt/libfdt.h | 2 +-
>>   3 files changed, 4 insertions(+), 4 deletions(-)
> 
> I think me and a few other people being on Cc here is attributed to the
> (misleading) title. The set of touched files fully maps to "DEVICE TREE"
> in ./MAINTAINERS afaict, which the prefix in the title would then also
> be nice to express.
> 
> That said I'm not sure whether libfdt code actually wants touching this
> way.

It doesn't want to be touched because this is code we imported as-is 
from an external project. In fact this is already part of the excluded list.

Simone, please have a look at docs/misra/exclude-list.json to check if a 
file is in-scope for MISRA.

Cheers,

-- 
Julien Grall