Agree. The "11199E50_6128D175h" of 64b CRC Check in the Spec also is the AE8B1486_0A799888h with bits reversed. Regards, Xiaoming -----Original Message----- From: Eric Biggers <ebiggers@xxxxxxxxxx> Sent: Monday, May 9, 2022 1:37 PM To: Xiaoming Zhou <xzhou@xxxxxxxxxxx> Cc: kbusch@xxxxxxxxxx; linux-nvme@xxxxxxxxxxxxxxxxxxx; linux-block@xxxxxxxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; axboe@xxxxxxxxx; hch@xxxxxx; martin.petersen@xxxxxxxxxx; colyli@xxxxxxx Subject: [EXT] Re: [PATCHv3 06/10]crypto: add rocksoft 64b crc framework External Email ---------------------------------------------------------------------- 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
