> 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'. I had an afterthought that maybe documenting this in <linux/crc7.h> would be useful, since you're unlikely to be the last person to make this mistake. Something like: /* * Generate a CRC with the polynomial x^7 + x^3 + 1 and big-endian * bit order. (Thus, the polynomial is 0x89.) The result is in the * most-significant 7 bits of the crc variable. * * This is where most protocols want the CRC (the lsbit is past the * end of CRC coverage and is used for something else), but differs * from most example code, which computes the CRC in the lsbits and * does an explicit 1-bit shift at the end. * * Because the state is maintained left-aligned, the common "preset * to all ones" CRC variant requires the crc be preset to 0xfe. * (Right-aligned example code will show a preset to 0x7f.) */ Feel free to add that to the patch (preserving my S-o-b) if you like. > Thanks again for submitting the patch. Thank you for writing the whole driver! I know it can be a real PITA; Linux kernel developers Really Really Want drivers in a common style and using existing kernel facilities as much as possible, but you're usually starting from some internal driver that has its own, very different, support library. BTW, one thing I noticed at cfg80211.c:1132: *cookie = prandom_u32(); priv->tx_cookie = *cookie; I don't know what the cookie is for, but I notice that *cookie and priv->tx_cookie are both 64-bit data types. Should that be "(u64)prandom_u32() << 32 | prandom_u32()" (since there is no prandom_u64())?
