From: David Laight <david.laight.linux@gmail.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Guenter Roeck <linux@roeck-us.net>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Yury Norov <yury.norov@gmail.com>,
Kuan-Wei Chiu <visitorckw@gmail.com>
Subject: Re: [PATCH RFT v2 1/5] bitops: add generic parity calculation for u8
Date: Sun, 29 Dec 2024 11:11:29 +0000 [thread overview]
Message-ID: <20241229111129.2602d219@dsl-u17-10> (raw)
In-Reply-To: <20241229101234.2896-2-wsa+renesas@sang-engineering.com>
On Sun, 29 Dec 2024 11:12:29 +0100
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> There are multiple open coded implementations for getting the parity of
> a byte in the kernel, even using different approaches. Take the pretty
> efficient version from SPD5118 driver and make it generally available by
> putting it into the bitops header. As long as there is just one parity
> calculation helper, the creation of a distinct 'parity.h' header was
> discarded. Also, the usage of hweight8() for architectures having a
> popcnt instruction is postponed until a use case within hot paths is
> desired. The motivation for this patch is the frequent use of odd parity
> in the I3C specification and to simplify drivers there.
>
> Changes compared to the original SPD5118 version are the addition of
> kernel documentation, switching the return type from bool to int, and
> renaming the argument of the function.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Tested-by: Guenter Roeck <linux@roeck-us.net>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Yury Norov <yury.norov@gmail.com>
> Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> Tested-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> Changes since v1:
>
> * renamed from 'get_parity8' to 'parity8'
> * use XOR instead of OR in the kdoc example (Thanks, Rasmus, for both)
> * rebased to 6.13-rc4
>
> include/linux/bitops.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index ba35bbf07798..c1cb53cf2f0f 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -229,6 +229,37 @@ static inline int get_count_order_long(unsigned long l)
> return (int)fls_long(--l);
> }
>
> +/**
> + * parity8 - get the parity of an u8 value
> + * @value: the value to be examined
> + *
> + * Determine the parity of the u8 argument.
> + *
> + * Returns:
> + * 0 for even parity, 1 for odd parity
I think I'd return 0x80 for even and 0 for odd.
That just need the 'magic constant' changing and masking with 0x80.
Also rename to parity8_even() - since it returns non-zero for even parity.
> + *
> + * Note: This function informs you about the current parity. Example to bail
> + * out when parity is odd:
> + *
> + * if (parity8(val) == 1)
> + * return -EBADMSG;
> + *
> + * If you need to calculate a parity bit, you need to draw the conclusion from
> + * this result yourself. Example to enforce odd parity, parity bit is bit 7:
> + *
> + * if (parity8(val) == 0)
> + * val ^= BIT(7);
That then becomes:
val ^= parity8_even(val);
which is what a lot of the code seems to want to do.
With your definition you could do:
val ^= (parity8(val) << 7) ^ 0x80;
(and I'm sorry, but IMHO 0x80 is better than BIT(7))
David
> + */
> +static inline int parity8(u8 val)
> +{
> + /*
> + * One explanation of this algorithm:
> + * https://funloop.org/codex/problem/parity/README.html
> + */
> + val ^= val >> 4;
> + return (0x6996 >> (val & 0xf)) & 1;
> +}
> +
> /**
> * __ffs64 - find first set bit in a 64 bit word
> * @word: The 64 bit word
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <david.laight.linux@gmail.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Guenter Roeck <linux@roeck-us.net>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Yury Norov <yury.norov@gmail.com>,
Kuan-Wei Chiu <visitorckw@gmail.com>
Subject: Re: [PATCH RFT v2 1/5] bitops: add generic parity calculation for u8
Date: Sun, 29 Dec 2024 11:11:29 +0000 [thread overview]
Message-ID: <20241229111129.2602d219@dsl-u17-10> (raw)
In-Reply-To: <20241229101234.2896-2-wsa+renesas@sang-engineering.com>
On Sun, 29 Dec 2024 11:12:29 +0100
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
> There are multiple open coded implementations for getting the parity of
> a byte in the kernel, even using different approaches. Take the pretty
> efficient version from SPD5118 driver and make it generally available by
> putting it into the bitops header. As long as there is just one parity
> calculation helper, the creation of a distinct 'parity.h' header was
> discarded. Also, the usage of hweight8() for architectures having a
> popcnt instruction is postponed until a use case within hot paths is
> desired. The motivation for this patch is the frequent use of odd parity
> in the I3C specification and to simplify drivers there.
>
> Changes compared to the original SPD5118 version are the addition of
> kernel documentation, switching the return type from bool to int, and
> renaming the argument of the function.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Tested-by: Guenter Roeck <linux@roeck-us.net>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Yury Norov <yury.norov@gmail.com>
> Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> Tested-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> Changes since v1:
>
> * renamed from 'get_parity8' to 'parity8'
> * use XOR instead of OR in the kdoc example (Thanks, Rasmus, for both)
> * rebased to 6.13-rc4
>
> include/linux/bitops.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index ba35bbf07798..c1cb53cf2f0f 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -229,6 +229,37 @@ static inline int get_count_order_long(unsigned long l)
> return (int)fls_long(--l);
> }
>
> +/**
> + * parity8 - get the parity of an u8 value
> + * @value: the value to be examined
> + *
> + * Determine the parity of the u8 argument.
> + *
> + * Returns:
> + * 0 for even parity, 1 for odd parity
I think I'd return 0x80 for even and 0 for odd.
That just need the 'magic constant' changing and masking with 0x80.
Also rename to parity8_even() - since it returns non-zero for even parity.
> + *
> + * Note: This function informs you about the current parity. Example to bail
> + * out when parity is odd:
> + *
> + * if (parity8(val) == 1)
> + * return -EBADMSG;
> + *
> + * If you need to calculate a parity bit, you need to draw the conclusion from
> + * this result yourself. Example to enforce odd parity, parity bit is bit 7:
> + *
> + * if (parity8(val) == 0)
> + * val ^= BIT(7);
That then becomes:
val ^= parity8_even(val);
which is what a lot of the code seems to want to do.
With your definition you could do:
val ^= (parity8(val) << 7) ^ 0x80;
(and I'm sorry, but IMHO 0x80 is better than BIT(7))
David
> + */
> +static inline int parity8(u8 val)
> +{
> + /*
> + * One explanation of this algorithm:
> + * https://funloop.org/codex/problem/parity/README.html
> + */
> + val ^= val >> 4;
> + return (0x6996 >> (val & 0xf)) & 1;
> +}
> +
> /**
> * __ffs64 - find first set bit in a 64 bit word
> * @word: The 64 bit word
next prev parent reply other threads:[~2025-01-10 11:19 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-29 10:12 [PATCH RFT v2 0/5] i3c: introduce and use generic parity helper Wolfram Sang
2024-12-29 10:12 ` Wolfram Sang
2024-12-29 10:12 ` [PATCH RFT v2 1/5] bitops: add generic parity calculation for u8 Wolfram Sang
2024-12-29 10:12 ` Wolfram Sang
2024-12-29 11:11 ` David Laight [this message]
2024-12-29 11:11 ` David Laight
2025-01-02 8:55 ` Wolfram Sang
2025-01-02 8:55 ` Wolfram Sang
2024-12-29 10:12 ` [PATCH RFT v2 2/5] hwmon: (spd5118) Use generic parity calculation Wolfram Sang
2024-12-29 10:12 ` Wolfram Sang
2024-12-29 10:12 ` [PATCH RFT v2 3/5] i3c: dw: use get_parity8 helper instead of open coding it Wolfram Sang
2024-12-29 10:12 ` Wolfram Sang
2024-12-29 10:12 ` [PATCH RFT v2 4/5] i3c: mipi-i3c-hci: " Wolfram Sang
2024-12-29 10:12 ` Wolfram Sang
2025-01-01 12:14 ` David Laight
2025-01-01 12:14 ` David Laight
2025-01-02 9:01 ` Wolfram Sang
2025-01-02 9:01 ` Wolfram Sang
2025-01-02 18:51 ` David Laight
2025-01-02 18:51 ` David Laight
2025-01-03 10:02 ` Wolfram Sang
2025-01-03 10:02 ` Wolfram Sang
2025-01-03 13:49 ` David Laight
2025-01-03 13:49 ` David Laight
2025-01-03 21:17 ` Wolfram Sang
2025-01-03 21:17 ` Wolfram Sang
2025-01-02 14:19 ` Jarkko Nikula
2025-01-02 14:19 ` Jarkko Nikula
2025-01-02 14:46 ` Wolfram Sang
2025-01-02 14:46 ` Wolfram Sang
2024-12-29 10:12 ` [PATCH RFT v2 5/5] i3c: cdns: " Wolfram Sang
2024-12-29 10:12 ` Wolfram Sang
2024-12-29 10:49 ` Geert Uytterhoeven
2024-12-29 10:49 ` Geert Uytterhoeven
2024-12-29 11:33 ` David Laight
2024-12-29 11:33 ` David Laight
2025-01-02 9:04 ` Wolfram Sang
2025-01-02 9:04 ` Wolfram Sang
2025-01-02 9:28 ` Geert Uytterhoeven
2025-01-02 9:28 ` Geert Uytterhoeven
2025-01-02 9:34 ` Wolfram Sang
2025-01-02 9:34 ` Wolfram Sang
2025-01-03 22:08 ` Alexandre Belloni
2025-01-03 22:08 ` Alexandre Belloni
2025-01-03 22:11 ` [PATCH RFT v2 0/5] i3c: introduce and use generic parity helper Alexandre Belloni
2025-01-03 22:11 ` Alexandre Belloni
2025-01-03 22:16 ` Wolfram Sang
2025-01-03 22:16 ` Wolfram Sang
2025-01-05 3:38 ` Yury Norov
2025-01-05 3:38 ` Yury Norov
2025-01-05 9:35 ` Wolfram Sang
2025-01-05 9:35 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241229111129.2602d219@dsl-u17-10 \
--to=david.laight.linux@gmail.com \
--cc=geert+renesas@glider.be \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@roeck-us.net \
--cc=visitorckw@gmail.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.