[PW_SID:992656] Common csr_read_num() and csr_write_num() for RISC-V by linux-riscv-bot · Pull Request #796 · linux-riscv/linux

linux-riscv-bot · 2025-08-18T17:49:25Z

PR for series 992656 applied to workflow__riscv__fixes

Name: Common csr_read_num() and csr_write_num() for RISC-V
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=992656
Version: 2

The cppc_ffh_csr_read() and cppc_ffh_csr_write() returns Linux error code in "data->ret.error" so cpc_read_ffh() and cpc_write_ffh() must not use sbi_err_map_linux_errno() for FFH_CPPC_CSR. Fixes: 30f3ffb ("ACPI: RISC-V: Add CPPC driver") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>

In RISC-V, there is no CSR read/write instruction which takes CSR number via register so add common csr_read_num() and csr_write_num() functions which allow accessing certain CSRs by passing CSR number as parameter. These common functions will be first used by the ACPI CPPC driver and RISC-V PMU driver. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>

linux-riscv-bot · 2025-08-18T17:54:59Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 106.64 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:13:55Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 1134.34 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:41:04Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 1627.25 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:41:29Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 23.61 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:41:53Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 22.54 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:41:56Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 0.74 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:43:13Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 75.76 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:43:15Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.22 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:43:17Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
kdoc
Desc: Detects for kdoc errors
Duration: 0.86 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:43:19Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
module-param
Desc: Detect module_param changes
Duration: 0.24 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:43:21Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.26 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:43:22Z

Patch 1: "[v2,1/2] ACPI: RISC-V: Fix FFH_CPPC_CSR error handling"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.29 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T18:45:23Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
build-rv32-defconfig
Desc: Builds riscv32 defconfig
Duration: 105.52 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T19:22:58Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
build-rv64-clang-allmodconfig
Desc: Builds riscv64 allmodconfig with Clang, and checks for errors and added warnings
Duration: 2253.48 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:12:07Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
build-rv64-gcc-allmodconfig
Desc: Builds riscv64 allmodconfig with GCC, and checks for errors and added warnings
Duration: 2945.92 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:12:30Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
build-rv64-nommu-k210-defconfig
Desc: Builds riscv64 defconfig with NOMMU for K210
Duration: 20.72 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:12:54Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
build-rv64-nommu-k210-virt
Desc: Builds riscv64 defconfig with NOMMU for the virt platform
Duration: 22.35 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:12:59Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
checkpatch
Desc: Runs checkpatch.pl on the patch
Duration: 3.01 seconds
Result: WARNING
Output:

CHECK: extern prototypes should be avoided in .h files
#34: FILE: arch/riscv/include/asm/csr.h:578:
+extern unsigned long csr_read_num(unsigned long csr_num, int *out_err);

CHECK: extern prototypes should be avoided in .h files
#35: FILE: arch/riscv/include/asm/csr.h:579:
+extern void csr_write_num(unsigned long csr_num, unsigned long val, int *out_err);

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#53: 
new file mode 100644

WARNING: Macros with flow control statements should be avoided
#103: FILE: arch/riscv/kernel/csr.c:46:
+#define switchcase_csr_read(__csr_num)				\
+	case (__csr_num):					\
+		return csr_read(__csr_num)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#106: FILE: arch/riscv/kernel/csr.c:49:
+#define switchcase_csr_read_2(__csr_num)			\
+	switchcase_csr_read(__csr_num + 0);			\
+	switchcase_csr_read(__csr_num + 1)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#106: FILE: arch/riscv/kernel/csr.c:49:
+#define switchcase_csr_read_2(__csr_num)			\
+	switchcase_csr_read(__csr_num + 0);			\
+	switchcase_csr_read(__csr_num + 1)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#109: FILE: arch/riscv/kernel/csr.c:52:
+#define switchcase_csr_read_4(__csr_num)			\
+	switchcase_csr_read_2(__csr_num + 0);			\
+	switchcase_csr_read_2(__csr_num + 2)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#109: FILE: arch/riscv/kernel/csr.c:52:
+#define switchcase_csr_read_4(__csr_num)			\
+	switchcase_csr_read_2(__csr_num + 0);			\
+	switchcase_csr_read_2(__csr_num + 2)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#112: FILE: arch/riscv/kernel/csr.c:55:
+#define switchcase_csr_read_8(__csr_num)			\
+	switchcase_csr_read_4(__csr_num + 0);			\
+	switchcase_csr_read_4(__csr_num + 4)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#112: FILE: arch/riscv/kernel/csr.c:55:
+#define switchcase_csr_read_8(__csr_num)			\
+	switchcase_csr_read_4(__csr_num + 0);			\
+	switchcase_csr_read_4(__csr_num + 4)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#115: FILE: arch/riscv/kernel/csr.c:58:
+#define switchcase_csr_read_16(__csr_num)			\
+	switchcase_csr_read_8(__csr_num + 0);			\
+	switchcase_csr_read_8(__csr_num + 8)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#115: FILE: arch/riscv/kernel/csr.c:58:
+#define switchcase_csr_read_16(__csr_num)			\
+	switchcase_csr_read_8(__csr_num + 0);			\
+	switchcase_csr_read_8(__csr_num + 8)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#118: FILE: arch/riscv/kernel/csr.c:61:
+#define switchcase_csr_read_32(__csr_num)			\
+	switchcase_csr_read_16(__csr_num + 0);			\
+	switchcase_csr_read_16(__csr_num + 16)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#118: FILE: arch/riscv/kernel/csr.c:61:
+#define switchcase_csr_read_32(__csr_num)			\
+	switchcase_csr_read_16(__csr_num + 0);			\
+	switchcase_csr_read_16(__csr_num + 16)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#121: FILE: arch/riscv/kernel/csr.c:64:
+#define switchcase_csr_read_64(__csr_num)			\
+	switchcase_csr_read_32(__csr_num + 0);			\
+	switchcase_csr_read_32(__csr_num + 32)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#121: FILE: arch/riscv/kernel/csr.c:64:
+#define switchcase_csr_read_64(__csr_num)			\
+	switchcase_csr_read_32(__csr_num + 0);			\
+	switchcase_csr_read_32(__csr_num + 32)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#124: FILE: arch/riscv/kernel/csr.c:67:
+#define switchcase_csr_read_128(__csr_num)			\
+	switchcase_csr_read_64(__csr_num + 0);			\
+	switchcase_csr_read_64(__csr_num + 64)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#124: FILE: arch/riscv/kernel/csr.c:67:
+#define switchcase_csr_read_128(__csr_num)			\
+	switchcase_csr_read_64(__csr_num + 0);			\
+	switchcase_csr_read_64(__csr_num + 64)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#127: FILE: arch/riscv/kernel/csr.c:70:
+#define switchcase_csr_read_256(__csr_num)			\
+	switchcase_csr_read_128(__csr_num + 0);			\
+	switchcase_csr_read_128(__csr_num + 128)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#127: FILE: arch/riscv/kernel/csr.c:70:
+#define switchcase_csr_read_256(__csr_num)			\
+	switchcase_csr_read_128(__csr_num + 0);			\
+	switchcase_csr_read_128(__csr_num + 128)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#172: FILE: arch/riscv/kernel/csr.c:115:
+#define switchcase_csr_write_2(__csr_num, __val)		\
+	switchcase_csr_write(__csr_num + 0, __val);		\
+	switchcase_csr_write(__csr_num + 1, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#172: FILE: arch/riscv/kernel/csr.c:115:
+#define switchcase_csr_write_2(__csr_num, __val)		\
+	switchcase_csr_write(__csr_num + 0, __val);		\
+	switchcase_csr_write(__csr_num + 1, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#175: FILE: arch/riscv/kernel/csr.c:118:
+#define switchcase_csr_write_4(__csr_num, __val)		\
+	switchcase_csr_write_2(__csr_num + 0, __val);		\
+	switchcase_csr_write_2(__csr_num + 2, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#175: FILE: arch/riscv/kernel/csr.c:118:
+#define switchcase_csr_write_4(__csr_num, __val)		\
+	switchcase_csr_write_2(__csr_num + 0, __val);		\
+	switchcase_csr_write_2(__csr_num + 2, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#178: FILE: arch/riscv/kernel/csr.c:121:
+#define switchcase_csr_write_8(__csr_num, __val)		\
+	switchcase_csr_write_4(__csr_num + 0, __val);		\
+	switchcase_csr_write_4(__csr_num + 4, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#178: FILE: arch/riscv/kernel/csr.c:121:
+#define switchcase_csr_write_8(__csr_num, __val)		\
+	switchcase_csr_write_4(__csr_num + 0, __val);		\
+	switchcase_csr_write_4(__csr_num + 4, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#181: FILE: arch/riscv/kernel/csr.c:124:
+#define switchcase_csr_write_16(__csr_num, __val)		\
+	switchcase_csr_write_8(__csr_num + 0, __val);		\
+	switchcase_csr_write_8(__csr_num + 8, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#181: FILE: arch/riscv/kernel/csr.c:124:
+#define switchcase_csr_write_16(__csr_num, __val)		\
+	switchcase_csr_write_8(__csr_num + 0, __val);		\
+	switchcase_csr_write_8(__csr_num + 8, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#184: FILE: arch/riscv/kernel/csr.c:127:
+#define switchcase_csr_write_32(__csr_num, __val)		\
+	switchcase_csr_write_16(__csr_num + 0, __val);		\
+	switchcase_csr_write_16(__csr_num + 16, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#184: FILE: arch/riscv/kernel/csr.c:127:
+#define switchcase_csr_write_32(__csr_num, __val)		\
+	switchcase_csr_write_16(__csr_num + 0, __val);		\
+	switchcase_csr_write_16(__csr_num + 16, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#187: FILE: arch/riscv/kernel/csr.c:130:
+#define switchcase_csr_write_64(__csr_num, __val)		\
+	switchcase_csr_write_32(__csr_num + 0, __val);		\
+	switchcase_csr_write_32(__csr_num + 32, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#187: FILE: arch/riscv/kernel/csr.c:130:
+#define switchcase_csr_write_64(__csr_num, __val)		\
+	switchcase_csr_write_32(__csr_num + 0, __val);		\
+	switchcase_csr_write_32(__csr_num + 32, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#190: FILE: arch/riscv/kernel/csr.c:133:
+#define switchcase_csr_write_128(__csr_num, __val)		\
+	switchcase_csr_write_64(__csr_num + 0, __val);		\
+	switchcase_csr_write_64(__csr_num + 64, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#190: FILE: arch/riscv/kernel/csr.c:133:
+#define switchcase_csr_write_128(__csr_num, __val)		\
+	switchcase_csr_write_64(__csr_num + 0, __val);		\
+	switchcase_csr_write_64(__csr_num + 64, __val)

WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
#193: FILE: arch/riscv/kernel/csr.c:136:
+#define switchcase_csr_write_256(__csr_num, __val)		\
+	switchcase_csr_write_128(__csr_num + 0, __val);		\
+	switchcase_csr_write_128(__csr_num + 128, __val)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
#193: FILE: arch/riscv/kernel/csr.c:136:
+#define switchcase_csr_write_256(__csr_num, __val)		\
+	switchcase_csr_write_128(__csr_num + 0, __val);		\
+	switchcase_csr_write_128(__csr_num + 128, __val)

total: 0 errors, 18 warnings, 18 checks, 284 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

Commit 916f8329fe4b ("RISC-V: Add common csr_read_num() and csr_write_num() functions") has style problems, please review.

NOTE: Ignored message types: ALLOC_SIZEOF_STRUCT CAMELCASE COMMIT_LOG_LONG_LINE GIT_COMMIT_ID MACRO_ARG_REUSE NO_AUTHOR_SIGN_OFF

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.
total: 0 errors, 18 warnings, 18 checks, 284 lines checked
CHECK: Macro argument '__csr_num' may be better as '(__csr_num)' to avoid precedence issues
CHECK: extern prototypes should be avoided in .h files
WARNING: Macros with flow control statements should be avoided
WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?

linux-riscv-bot · 2025-08-18T20:14:16Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
dtb-warn-rv64
Desc: Checks for Device Tree warnings/errors
Duration: 76.05 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:14:18Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
header-inline
Desc: Detects static functions without inline keyword in header files
Duration: 0.25 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:14:21Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
kdoc
Desc: Detects for kdoc errors
Duration: 0.88 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:14:22Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
module-param
Desc: Detect module_param changes
Duration: 0.27 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:14:24Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
verify-fixes
Desc: Verifies that the Fixes: tags exist
Duration: 0.23 seconds
Result: PASS

linux-riscv-bot · 2025-08-18T20:14:26Z

Patch 2: "[v2,2/2] RISC-V: Add common csr_read_num() and csr_write_num() functions"
verify-signedoff
Desc: Verifies that Signed-off-by: tags are correct
Duration: 0.31 seconds
Result: PASS

avpatel added 2 commits August 18, 2025 17:49

linux-riscv-bot closed this Aug 26, 2025

linux-riscv-bot deleted the pw992656 branch August 26, 2025 01:03

Uh oh!

Conversation

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

linux-riscv-bot commented Aug 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants