include/linux/crc-itu-t.h | 2 +- lib/crc-itu-t.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The code comment says that the polynom is x^16 + x^12 + x^15 + 1, but the
correct polynom is x^16 + x^12 + x^5 + 1.
Quote from page 2 in the ITU-T V.41 specification:
"2 Encoding and checking process
The service bits and information bits, taken in conjunction, correspond
to the coefficients of a message polynomial having terms from x^(n-1)
(n = total number of bits in a block or sequence) down to x^16. This
polynomial is divided, modulo 2, by the generating polynomial
x^16 + x^12 + x^5 + 1. [...]"
Source: https://www.itu.int/rec/T-REC-V.41-198811-I/en)
The hex polynom 0x1021 and CRC code implementation are correct.
Signed-off-by: Roger Knecht <roger@norberthealth.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
---
Changes:
v5: Clean up patch description and added acked-by
v4: Changed comment from /** to /* (the comment is not a kernel doc comment)
v3: Moved "changes and thanks" out of the commit message.
v2: Extended patch description
include/linux/crc-itu-t.h | 2 +-
lib/crc-itu-t.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/crc-itu-t.h b/include/linux/crc-itu-t.h
index a4367051e192..2f991a427ade 100644
--- a/include/linux/crc-itu-t.h
+++ b/include/linux/crc-itu-t.h
@@ -4,7 +4,7 @@
*
* Implements the standard CRC ITU-T V.41:
* Width 16
- * Poly 0x1021 (x^16 + x^12 + x^15 + 1)
+ * Poly 0x1021 (x^16 + x^12 + x^5 + 1)
* Init 0
*/
diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c
index 1974b355c148..1d26a1647da5 100644
--- a/lib/crc-itu-t.c
+++ b/lib/crc-itu-t.c
@@ -7,7 +7,7 @@
#include <linux/module.h>
#include <linux/crc-itu-t.h>
-/** CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^15 + 1) */
+/* CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^5 + 1) */
const u16 crc_itu_t_table[256] = {
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
--
2.17.1
Hi Roger,
On 5/21/22 05:47, Roger Knecht wrote:
> The code comment says that the polynom is x^16 + x^12 + x^15 + 1, but the
> correct polynom is x^16 + x^12 + x^5 + 1.
>
> Quote from page 2 in the ITU-T V.41 specification:
> "2 Encoding and checking process
>
> The service bits and information bits, taken in conjunction, correspond
> to the coefficients of a message polynomial having terms from x^(n-1)
> (n = total number of bits in a block or sequence) down to x^16. This
> polynomial is divided, modulo 2, by the generating polynomial
> x^16 + x^12 + x^5 + 1. [...]"
>
> Source: https://www.itu.int/rec/T-REC-V.41-198811-I/en)
> The hex polynom 0x1021 and CRC code implementation are correct.
>
> Signed-off-by: Roger Knecht <roger@norberthealth.com>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
I don't know which maintainer will merge this since no one is Cc:ed on it.
You will probably need to choose some maintainer to send the patch to.
But let's add the people who merged the header file in the first place
for their comments/review. (done)
> ---
> Changes:
> v5: Clean up patch description and added acked-by
> v4: Changed comment from /** to /* (the comment is not a kernel doc comment)
> v3: Moved "changes and thanks" out of the commit message.
> v2: Extended patch description
>
> include/linux/crc-itu-t.h | 2 +-
> lib/crc-itu-t.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/crc-itu-t.h b/include/linux/crc-itu-t.h
> index a4367051e192..2f991a427ade 100644
> --- a/include/linux/crc-itu-t.h
> +++ b/include/linux/crc-itu-t.h
> @@ -4,7 +4,7 @@
> *
> * Implements the standard CRC ITU-T V.41:
> * Width 16
> - * Poly 0x1021 (x^16 + x^12 + x^15 + 1)
> + * Poly 0x1021 (x^16 + x^12 + x^5 + 1)
> * Init 0
> */
>
> diff --git a/lib/crc-itu-t.c b/lib/crc-itu-t.c
> index 1974b355c148..1d26a1647da5 100644
> --- a/lib/crc-itu-t.c
> +++ b/lib/crc-itu-t.c
> @@ -7,7 +7,7 @@
> #include <linux/module.h>
> #include <linux/crc-itu-t.h>
>
> -/** CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^15 + 1) */
> +/* CRC table for the CRC ITU-T V.41 0x1021 (x^16 + x^12 + x^5 + 1) */
> const u16 crc_itu_t_table[256] = {
> 0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
> 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
--
~Randy
On Sat, May 21, 2022 at 5:44 PM Randy Dunlap <rdunlap@infradead.org> wrote: > I don't know which maintainer will merge this since no one is Cc:ed on it. > You will probably need to choose some maintainer to send the patch to. > > But let's add the people who merged the header file in the first place > for their comments/review. (done) Thanks Randy. The CRC implementation seems to be unmaintained (no entry in the MAINTAINER file). Any idea which maintainer I can send the patch to? The kernel doc mentions Andrew Morton as last resort (added to CC): > You should always copy the appropriate subsystem maintainer(s) on any patch to > code that they maintain; look through the MAINTAINERS file and the source code > revision history to see who those maintainers are. The script scripts/get_maintainer.pl > can be very useful at this step. If you cannot find a maintainer for the subsystem you > are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer > of last resort. source: https://www.kernel.org/doc/html/latest/process/submitting-patches.html Roger
On 6/2/22 07:24, Roger Knecht wrote: > On Sat, May 21, 2022 at 5:44 PM Randy Dunlap <rdunlap@infradead.org> wrote: >> I don't know which maintainer will merge this since no one is Cc:ed on it. >> You will probably need to choose some maintainer to send the patch to. >> >> But let's add the people who merged the header file in the first place >> for their comments/review. (done) > > Thanks Randy. > > The CRC implementation seems to be unmaintained (no entry in the > MAINTAINER file). > Any idea which maintainer I can send the patch to? Yes, the 2 people who signed off on its merger are not active AFAICT. > The kernel doc mentions Andrew Morton as last resort (added to CC): >> You should always copy the appropriate subsystem maintainer(s) on any patch to >> code that they maintain; look through the MAINTAINERS file and the source code >> revision history to see who those maintainers are. The script scripts/get_maintainer.pl >> can be very useful at this step. If you cannot find a maintainer for the subsystem you >> are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer >> of last resort. > source: https://www.kernel.org/doc/html/latest/process/submitting-patches.html Yes, Andrew can merge it. Or possibly Jason (also Cc-ed). thanks. -- ~Randy
Hi Randy, On Thu, Jun 02, 2022 at 09:31:24AM -0700, Randy Dunlap wrote: > > > On 6/2/22 07:24, Roger Knecht wrote: > > On Sat, May 21, 2022 at 5:44 PM Randy Dunlap <rdunlap@infradead.org> wrote: > >> I don't know which maintainer will merge this since no one is Cc:ed on it. > >> You will probably need to choose some maintainer to send the patch to. > >> > >> But let's add the people who merged the header file in the first place > >> for their comments/review. (done) > > > > Thanks Randy. > > > > The CRC implementation seems to be unmaintained (no entry in the > > MAINTAINER file). > > Any idea which maintainer I can send the patch to? > > Yes, the 2 people who signed off on its merger are not active AFAICT. > > > The kernel doc mentions Andrew Morton as last resort (added to CC): > >> You should always copy the appropriate subsystem maintainer(s) on any patch to > >> code that they maintain; look through the MAINTAINERS file and the source code > >> revision history to see who those maintainers are. The script scripts/get_maintainer.pl > >> can be very useful at this step. If you cannot find a maintainer for the subsystem you > >> are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer > >> of last resort. > > source: https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > Yes, Andrew can merge it. > Or possibly Jason (also Cc-ed). Sure, I can take this. Jason > > thanks. > > -- > ~Randy
On Thu, Jun 2, 2022 at 7:17 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > On Thu, Jun 02, 2022 at 09:31:24AM -0700, Randy Dunlap wrote: > > Yes, Andrew can merge it. > > Or possibly Jason (also Cc-ed). > > Sure, I can take this. > > Jason Great, thanks Jason
© 2016 - 2026 Red Hat, Inc.