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

linux-riscv-bot · 2025-08-15T18:24:57Z

PR for series 992024 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=992024
Version: 1

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> 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> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>

linux-riscv-bot · 2025-08-15T18:30:10Z

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

linux-riscv-bot · 2025-08-15T18:48:47Z

Patch 1: "[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: 1115.83 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T19:14:59Z

Patch 1: "[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: 1569.83 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T19:15:21Z

Patch 1: "[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: 20.46 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T19:15:44Z

Patch 1: "[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: 21.86 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T19:15:46Z

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

linux-riscv-bot · 2025-08-15T19:17:02Z

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

linux-riscv-bot · 2025-08-15T19:17:04Z

Patch 1: "[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.23 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T19:17:06Z

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

linux-riscv-bot · 2025-08-15T19:17:08Z

Patch 1: "[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-15T19:17:10Z

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

linux-riscv-bot · 2025-08-15T19:17:12Z

Patch 1: "[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-15T19:19:08Z

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

linux-riscv-bot · 2025-08-15T19:55:55Z

Patch 2: "[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: 2206.04 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T20:43:35Z

Patch 2: "[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: 2857.81 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T20:43:57Z

Patch 2: "[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.75 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T20:44:20Z

Patch 2: "[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: 21.79 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T20:44:26Z

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

CHECK: extern prototypes should be avoided in .h files
#32: 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
#33: 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?
#51: 
new file mode 100644

WARNING: Macros with flow control statements should be avoided
#103: FILE: arch/riscv/kernel/csr.c:48:
+#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:51:
+#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:51:
+#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:54:
+#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:54:
+#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:57:
+#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:57:
+#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:60:
+#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:60:
+#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:63:
+#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:63:
+#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:66:
+#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:66:
+#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:69:
+#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:69:
+#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:72:
+#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:72:
+#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
#177: FILE: arch/riscv/kernel/csr.c:122:
+#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
#177: FILE: arch/riscv/kernel/csr.c:122:
+#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
#180: FILE: arch/riscv/kernel/csr.c:125:
+#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
#180: FILE: arch/riscv/kernel/csr.c:125:
+#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
#183: FILE: arch/riscv/kernel/csr.c:128:
+#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
#183: FILE: arch/riscv/kernel/csr.c:128:
+#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
#186: FILE: arch/riscv/kernel/csr.c:131:
+#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
#186: FILE: arch/riscv/kernel/csr.c:131:
+#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
#189: FILE: arch/riscv/kernel/csr.c:134:
+#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
#189: FILE: arch/riscv/kernel/csr.c:134:
+#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
#192: FILE: arch/riscv/kernel/csr.c:137:
+#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
#192: FILE: arch/riscv/kernel/csr.c:137:
+#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
#195: FILE: arch/riscv/kernel/csr.c:140:
+#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
#195: FILE: arch/riscv/kernel/csr.c:140:
+#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
#198: FILE: arch/riscv/kernel/csr.c:143:
+#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
#198: FILE: arch/riscv/kernel/csr.c:143:
+#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 8efc675b8153 ("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-15T20:45:41Z

Patch 2: "[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: 74.25 seconds
Result: PASS

linux-riscv-bot · 2025-08-15T20:45:43Z

Patch 2: "[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-15T20:45:45Z

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

linux-riscv-bot · 2025-08-15T20:45:47Z

Patch 2: "[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-15T20:45:49Z

Patch 2: "[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-15T20:45:51Z

Patch 2: "[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 15, 2025 18:24

linux-riscv-bot closed this Aug 18, 2025

linux-riscv-bot deleted the pw992024 branch August 18, 2025 18:25

Uh oh!

Conversation

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

linux-riscv-bot commented Aug 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants