hermes_bap_pwrite() supports odd-sized packets now. There is no
minimal packet size for 802.11. Also, hermes_bap_pwrite() supports
odd-sized packets now. This removes all reasons to pad the Tx data.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The new function can write an odd number of bytes, thus making padding
unnecessary.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
hermas_bap_pread, hermes_bap_pwrite, and hermes_bap_pwrite_pad all have a parameter "len" that is declared unsigned,
but checked for a value less than zero. Auditing the callers, it is possible for len to be passed a negative value, so len should be an int.
Thanks to LinuxICC (http://linuxicc.sf.net)
Signed-off-by: Gabriel A. Devenyi <ace@staticwave.ca>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
The latest kernel added a pretty ugly fix for the orinoco etherleak bug
which contains bogus skb->len checks already done by the caller and causes
copies of all odd sized frames (which are quite common)
While the skb->len check should be ripped out the other fix is harder to do
properly so I'm proposing for this the -mm tree only until next 2.6.x so
that it gets tested.
Instead of copying buffers around blindly this code implements a padding
aware version of the hermes buffer writing function which does padding as
the buffer is loaded and thus more cleanly and without bogus 1.5K copies.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
Remove inneeded system includes.
Most system includes are not needed. In particular, the hardware
backends don't need anything network related. Some includes have been
moved from local headers to the C files where they are actually used.
Includes that have to be in the local headers are no longer from the C
sources.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Pavel Roskin