[zd1211-devs] [PATCH] [Fwd: Patch for zd1211 endianness-bug]
Status: Beta
Brought to you by:
mayne
From: <oy...@re...> - 2006-05-04 14:15:34
|
Forwarding a patch I recieved from a NSLU2-linux developer. Regards, =D8yvind Repvik -------- Original Message -------- Subject: Patch for zd1211 Date: Mon, 1 May 2006 10:16:08 -0500 From: Mike (mwester) <mw...@dl...> To: <na...@ns...> CC: Mike Westerhof <mw...@dl...> Here's the bug that's been in the driver for some time now. One little overlooked "endian" problem... If you're wondering why "CurFrmLen" instead of "le32_to_cpu(rfd->ActualCount)" -- I went back to the original source from Zydas, and they were using the construct rfd->ActualCount throughout that section of code. When the "endian" fix was performed for the zd1211, the author of the "endian" fix observed that "CurFrmLen" =3D=3D "le32_to_cpu(rfd->ActualCount)" and that using the former was far more efficient. I merely followed that author's approach and used "CurFrmLen" as well. The point of all of this is that I think this patch should be accepted by the zd1211 group as-is --- so if you agree, could you submit it? I fixed it in the r74 version of the driver; so I commited a new .bb file along with the patch. The bug is present in the r67 version as well, but I did not add the patch to that .bb file. I also commited some truely horrible hacks specific to unslung along with this fix. Finally, there remains an alignment issue (per /proc/cpu/alignment). And it locks up badly when put under very heavy load, such as NFS (there's a post in the archives of the zd1211 group mailing list that describes exactly what happens, so this is a known problem). Mike --- zd1211-driver-r67/src/zd1211.c~ 2006-02-16 15:33:51.000000000 -06= 00 +++ zd1211-driver-r67/src/zd1211.c 2006-04-30 22:47:13.000000000 -05= 00 @@ -2228,7 +2228,7 @@ if (CurFrmLen & 0x03) tmpLen +=3D 4; - rfd->ActualCount +=3D macp->rxOffset; + rfd->ActualCount =3D cpu_to_le32(CurFrmLen + macp->rxOffset); } } else { // last_pkt_len =3D 509, 510, 511 |