On Mon, Aug 10, 2009 at 12:19 PM, Brian Niebuhr<bniebuhr3@xxxxxxxxx> wrote: > On Mon, Aug 10, 2009 at 11:48 AM, Steve Calfee<stevecalfee@xxxxxxxxx> wrote: >> Hi Brian, >> >> This will not work correctly on big-endian cpus like a MIPS or PPC. I >> suggest something like: >> >> crc2 = cpu_to_be32(0xdeadbeef); >> >> Regards, Steve >> > > Steve - > > I may be mistaken, but I believe my fix is correct. The issue is that > the CRC is read from the ethernet frame a few lines before this patch > with get_unaligned_le32(). The reason for this is that if the CRC is > a real CRC, and not the sentinel value, then the CRC is calculated > using crc32_le and compared to the received value. However if the > received frame contained the 0xdeadbeef sentinel value, then > get_unaligned_le32() should have read in 0xefbeadde on little- or > big-endian platforms. > Hi Brian, Your patch may be correct, but it is not clear. I have not looked "outside" the patch, but it would seem the get_unaligned_le32 usage is wrong. If "deadbeef" is the flag and you are looking for something else (efbeadde), clarity is lost. This code forces a fetch of little endian data, which is really big endian. Then you have to do a weird constant to match big endian. Endianness seems to always be a problem. I believe a simple rule simplifies the problem: "Stuff in a buffer (usb, ethernet etc) is in the format specified by the protocol. Stuff in a CPU register or memory is in its native byte order". Things always get nasty when people send structs over an endian sensitive protocol. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
