On 23/03/20 12:15 pm, George Spelvin wrote: > > On Mon, Mar 23, 2020 at 05:03:02AM +0000, Ajay.Kathat@xxxxxxxxxxxxx wrote: >> On 22/03/20 5:34 pm, George Spelvin wrote: >>> The code in lib/ is the desired polynomial, and even includes >>> the 1-bit left shift in the table rather than needing to code >>> it explicitly. >> >> These changes will break functionality. The crc7 used in 'wilc' is based >> on the previous revision(commit# ad241528c491). The new changes can not >> be adopted from 'wilc' device side because the crc calculation is done >> on hardware IP and it expects the value based the older implementation. > > I'm confused. Both crc7 functions compute the exact same value. > I put them in a test harness and checked that they produce identical > output before submitting. > > The only difference is that the implementation I deleted does > > crc = 0x7f; > while (len--) > crc = crc_cyndrome_table[(crc << 1) ^ *byte++]; > return crc << 1; > > while the lib/crc7.c code maintains its "crc" state value already > shifted left 1 bit, so it can use the simpler loop: > > crc = 0xfe; /* 0x7f << 1 */ > while (len--) > crc = crc_cyndrome_table2[crc ^ *byte++]; > return crc; > > It's not a different CRC-7, it's the *exact same* CRC-7. You can > see that the syndrome tables are identical, just shifted one bit over. > You are right both implementation compute same results. My bad, I didn't use correct data length value while verifying this patch with latest driver. Earlier, I also tried to replace crc7 by using existing library but it gave different results with 'crc7_be()' because I didn't modify '0x7f' to '0xfe'. Could you please modify and submit the patch using the latest staging code so it could be applied to staging. Thanks again for submitting the patch. Regards, Ajay
