On March 7, 2025 4:13:26 AM PST, Ingo Molnar [off-list ref] wrote:

* Jiri Slaby [off-list ref] wrote:

quoted

On 07. 03. 25, 12:38, Ingo Molnar wrote:

quoted

* Jiri Slaby [off-list ref] wrote:

quoted

On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:

quoted

Change return type to bool for better clarity. Update the kernel doc
comment accordingly, including fixing "@value" to "@val" and adjusting
examples. Also mark the function with __attribute_const__ to allow
potential compiler optimizations.

Co-developed-by: Yu-Chun Lin <redacted>
Signed-off-by: Yu-Chun Lin <redacted>
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
   include/linux/bitops.h | 10 +++++-----
   1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index c1cb53cf2f0f..44e5765b8bec 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h

@@ -231,26 +231,26 @@ static inline int get_count_order_long(unsigned long l)
   /**
    * parity8 - get the parity of an u8 value
- * @value: the value to be examined
+ * @val: the value to be examined
    *
    * Determine the parity of the u8 argument.
    *
    * Returns:
- * 0 for even parity, 1 for odd parity
+ * false for even parity, true for odd parity

This occurs somehow inverted to me. When something is in parity means that
it has equal number of 1s and 0s. I.e. return true for even distribution.
Dunno what others think? Or perhaps this should be dubbed odd_parity() when
bool is returned? Then you'd return true for odd.

OTOH:

  - '0' is an even number and is returned for even parity,
  - '1' is an odd  number and is returned for odd  parity.

Yes, that used to make sense for me. For bool/true/false, it no longer does.
But as I wrote, it might be only me...

No strong opinion on this from me either, I'd guess existing practice 
with other parity functions should probably control. (If a coherent 
praxis exists.).

Thanks,

Ingo

Instead of "bool" think of it as "bit" and it makes more sense