Toby Milne wrote:
Hi,
I've been experimenting with the Zaurus support and have come across two problems.
Good to hear from you, and great to see the results of your debugging!
The first (patch against 2.4.20 included) is that the tx_fixup adds 6 bytes for the CRC and padding, but the logic to pad the packet if it is a multiple of the block size in usbnet_start_xmit is working off the old buffer size. This meant an occasional packet having an extra byte, which then failed the CRC on the Z.
Good catch. That'd affect other drivers that want special framing; I wonder if that explains some of the GL-620A problems folk have been reporting off and on. I've got updates almost ready for 2.4 and 2.5 (use the standard crc32 code, for starters), and I'll merge this patch with them.
The second is that if the Z sends packets of length equal to the MTU size, the receive buffer allocated in rx_submit doesn't include room for the 4 byte CRC. I've hacked a +4 onto the buffer size, and that works fine for me, but that's not a public fix. Is this the right place in the code to fix this?Hmm, the other drivers that do their own framing address this issue
in the usbnet_change_mtu() and rx_submit() logic by checking a flag
and handling MTU issues that way. I'll add a FLAG_FRAMING_Z and
ask you to verify that the updated driver resolves both problems.
(Why add four bytes not six, if the tx side can add six?)
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
