summaryrefslogtreecommitdiffstats
path: root/drivers/net/natsemi.c
AgeCommit message (Collapse)Author
2006-04-12[PATCH] net drivers: fix section attributes for gccRandy Dunlap
If CONFIG_HOTPLUG=n, gcc doesn't like some __initdata to be const (rodata) and other __initdata not const, so make the non-const __initdata const. gcc errors: drivers/net/bnx2.c:66: error: version causes a section type conflict drivers/net/starfire.c:338: error: version causes a section type conflict drivers/net/typhoon.c:137: error: version causes a section type conflict drivers/net/natsemi.c:241: error: version causes a section type conflict Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-03-29[PATCH] natsemi: Support oversized EEPROMsMark Brown
The natsemi chip can have a larger EEPROM attached than it itself uses for configuration. This patch adds support for user space access to such an EEPROM. Signed-off-by: Mark Brown <broonie@sirena.org.uk> Cc: Tim Hockin <thockin@hockin.org> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-03-04[PATCH] natsemi: NAPI and a bugfixMark Brown
As documented in National application note 1287 the RX state machine on the natsemi chip can lock up under some conditions (mostly related to heavy load). When this happens a series of bogus packets are reported by the chip including some oversized frames prior to the final lockup. This patch implements the fix from the application note: when an oversized packet is reported it resets the RX state machine, dropping any currently pending packets. Signed-off-by: Mark Brown <broonie@sirena.org.uk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-03-04[PATCH] natsemi: NAPI and a bugfixMark Brown
This patch converts the natsemi driver to use NAPI. It was originally based on one written by Harald Welte, though it has since been modified quite a bit, most extensively in order to remove the ability to disable NAPI since none of the other drivers seem to provide that functionality any more. Signed-off-by: Mark Brown <broonie@sirena.org.uk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-03-03Massive net driver const-ification.Arjan van de Ven
2005-06-28[NET]: Remove gratuitous use of skb->tail in network drivers.David S. Miller
Many drivers use skb->tail unnecessarily. In these situations, the code roughly looks like: dev = dev_alloc_skb(...); [optional] skb_reserve(skb, ...); ... skb->tail ... But even if the skb_reserve() happens, skb->data equals skb->tail. So it doesn't make any sense to use anything other than skb->data in these cases. Another case was the s2io.c driver directly mucking with the skb->data and skb->tail pointers. It really just wanted to do an skb_reserve(), so that's what the code was changed to do instead. Another reason I'm making this change as it allows some SKB cleanups I have planned simpler to merge. In those cleanups, skb->head, skb->tail, and skb->end pointers are removed, and replaced with skb->head_room and skb->tail_room integers. Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Jeff Garzik <jgarzik@pobox.com>
2005-05-15[PATCH] Fw: [Bugme-new] [Bug 4482] New: natsemi: incorrect initialization of ↵Herbert Xu
IPv6 Neighbor-discovery multicast On Wed, Apr 13, 2005 at 05:36:42PM +0000, Andrew Morton wrote: > Summary: natsemi: incorrect initialization of IPv6 Neighbor- > discovery multicast I've got a pair of FA312 cards and this problem has bothered me for ages. This has finally prompted me to do something about it :) Turns out that somebody wasn't following the documentation. We were doing 16-bit writes to 32-bit registers which led to some addresses working and others not so lucky. This patch should fix the problem. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
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!