[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ynl7dXm38FaX/2od@sol.localdomain>
Date: Mon, 9 May 2022 13:37:09 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Xiaoming Zhou <xzhou@...vell.com>
Cc: "kbusch@...nel.org" <kbusch@...nel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"axboe@...nel.dk" <axboe@...nel.dk>, "hch@....de" <hch@....de>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"colyli@...e.de" <colyli@...e.de>
Subject: Re: [PATCHv3 06/10]crypto: add rocksoft 64b crc framework
On Sun, May 08, 2022 at 12:01:21AM +0000, Xiaoming Zhou wrote:
> Hi Keith,
> For the polynomial you used in this path is 0x9A6C9329AC4BC9B5ULL, why it is
> different than the 0xAD93D23594C93659ULL defined in NVMe command set spec
> 5.2.1.3.4 ? Though the crc66 implemented in this patch can pass with test
> cases defined in Figure 121: 64b CRC Test Cases for 4KiB Logical Block with no
> Metadata. Could you explain the discrepancy between the spec and the patch?
>
0x9A6C9329AC4BC9B5 is 0xAD93D23594C93659 with its bits reversed.
0xAD93D23594C93659 maps the polynomial coefficients to bits in the natural way.
However, writing the polynomial in this way isn't useful for this CRC variant,
as it is a bit-reversed CRC.
- Eric
Powered by blists - more mailing lists