Commit graph

4 commits

Author SHA1 Message Date
Alan Cox
aa95abefcc [PATCH] skb_padto()-area fixes in 8390, wavelan
Ar Iau, 2006-06-22 am 21:29 +1000, ysgrifennodd Herbert Xu:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > The 8390 change (corrected version) also makes 8390.c faster so should
> > be applied anyway, and the orinoco one fixes some code that isn't even
> > needed and someone forgot to remove long ago. Otherwise the skb_padto
>
> Yeah I agree totally.  However, I haven't actually seen the fixed 8390
> version being posted yet or at least not to netdev :)

Ah the resounding clang of a subtle hint ;)

Signed-off-by: Alan Cox <alan@redhat.com>

- Return 8390.c to the old way of handling short packets (which is also
faster)

- Remove the skb_padto from orinoco. This got left in when the padding bad
write patch was added and is actually not needed. This is fixing a merge
error way back when.

- Wavelan can also use the stack based buffer trick if you want
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-06-22 23:32:02 -04:00
Paul Gortmaker
9389d79fbf [PATCH] 8390 Tx fix for non i386 machines
While this is true, E8390_CMD is zero on i386, and thus there should be no
effect for these machines.  Machines like Mac, Amiga etc. which use Alan's
clever register mapping may have a non-zero E8390_CMD and result in bogus
"transmitter busy" type messages from this bug.

Fixes BUG# 3991.
2005-09-23 05:18:45 -04:00
Hirokazu Takata
0adbb44a14 [PATCH] m32r: Remove include/asm-m32r/m32102peri.h
This patch removes an obsolete header file include/asm-m32r/m32102peri.h.
In this header, there are some undesirable single character types, like V.
And the header is almost no longer used.

Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org>
Signed-off-by: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 19:07:31 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00