arm64: sysreg: fix sparse warnings

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by Sergey Matyukevich <[email protected]>

---

Changes v1 -> v2
- use proper type: UL rather than ULL

 arch/arm64/include/asm/sysreg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm64/include/asm/sysreg.h +1 -1

index 0c909c4a932f..842fb9572661 100644
@@ -468,7 +468,7 @@
 			 SCTLR_ELx_SA     | SCTLR_ELx_I    | SCTLR_ELx_WXN | \
 			 SCTLR_ELx_DSSBS | ENDIAN_CLEAR_EL2 | SCTLR_EL2_RES0)
 
-#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xffffffffffffffff
+#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xffffffffffffffffUL
 #error "Inconsistent SCTLR_EL2 set/clear bits"
 #endif
 

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by Sergey Matyukevich <[email protected]>

---

Quoted 6 lines · Sergey Matyukevich

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Quoted 2 lines

Signed-off-by Sergey Matyukevich <[email protected]>

---

I still think this is bogus, but the warning is clearly irritating so:

Acked-by Will Deacon <[email protected]>

Catalin, can you pick this up please?

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by Sergey Matyukevich <[email protected]>

Quoted 7 lines · Sergey Matyukevich

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by Sergey Matyukevich <[email protected]>

I queued the patch for 4.20-rc4 and also changed the constant to ~0UL as per Luc's suggestion. Thanks.

Quoted 11 lines · Catalin Marinas

Quoted 7 lines · Sergey Matyukevich

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by Sergey Matyukevich <[email protected]>

I queued the patch for 4.20-rc4 and also changed the constant to ~0UL as per Luc's suggestion. Thanks.

My vague worry with using ~0UL is that the preprocessor says:

It carries out all calculations in the widest integer type known to the compiler; on most machines supported by GCC this is 64 bits.

which implies to me that if we ever got a 128-bit integer type, then this would break.

Quoted 13 lines · Will Deacon

Quoted 11 lines · Catalin Marinas

Quoted 7 lines · Sergey Matyukevich

Specify correct type for the constants to avoid
the following sparse complaints:

./arch/arm64/include/asm/sysreg.h:471:42: warning: constant 0xffffffffffffffff is so big it is unsigned long ./arch/arm64/include/asm/sysreg.h:512:42: warning: constant 0xffffffffffffffff is so big it is unsigned long

Signed-off-by Sergey Matyukevich <[email protected]>

I queued the patch for 4.20-rc4 and also changed the constant to ~0UL as per Luc's suggestion. Thanks.

Quoted 7 lines

My vague worry with using ~0UL is that the preprocessor says:

It carries out all calculations in the widest integer type known to the compiler; on most machines supported by GCC this is 64 bits.

which implies to me that if we ever got a 128-bit integer type, then this would break.

True, indeed.

Note: since C99, the standard says:
(in the context of #if and #elif) "... all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>."
Which doesn't really change your concern.