| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.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>
Annotate endianess of variables and structure members.
Don't reuse variables for both host-endian and little-endian data.
Minor comment changes in affected structures.
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!
|
