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!