- 14 9月, 2006 2 次提交
-
-
由 Jeff Garzik 提交于
Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Jeff Garzik 提交于
Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 12 9月, 2006 1 次提交
-
-
由 Andy Gospodarek 提交于
As I promised last week, here is the first pass at removing all unnecessary printk's that exist in network device drivers currently in promiscuous mode. The duplicate messages are not needed so they have been removed. Some of these drivers are quite old and might not need an update, but I did them all anyway. I am currently auditing the remaining conditional printk's and will send out a patch for those soon. Signed-off-by: NAndy Gospodarek <andy@greyhouse.net> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 20 8月, 2006 1 次提交
-
-
由 Jeff Garzik 提交于
From: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by: NMichal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 06 7月, 2006 1 次提交
-
-
由 Jeff Garzik 提交于
When in-kernel net drivers branched from Donald Becker's vanilla driver set, in the days before BitKeeper and git, a driver changelog was maintained in the driver source code. These days, the kernel's changelog is far superior and much more accurate, so the in-driver changelogs are removed. Another relic of the Becker/kernel split was version numbering, using "foo-LKx.y.z" notation, resulting in weird version numbers like "1.17b-LK1.1.9". These drivers are for older hardware, and see few changes these days, so the version numbers were all bumped to something more simple. Finally, in xircom_tulip_cb specifically, an additional cleanup removes the always-enabled CARDBUS cpp macro. Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 03 7月, 2006 1 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 27 6月, 2006 2 次提交
-
-
由 Jeff Garzik 提交于
* make eeprom size a variable, prepping for future patch * eliminate unused PCI_xxx stuff left over from Becker driver template * convert a few #defines to enum * mark PCI table const, __devinitdata * don't bother with named constant for PCI device id Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Jeff Garzik 提交于
This makes it easier to merge an upcoming patch, and overall makes the code a bit more clean. Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 18 6月, 2006 1 次提交
-
-
由 Herbert Xu 提交于
Various drivers use xmit_lock internally to synchronise with their transmission routines. They do so without setting xmit_lock_owner. This is fine as long as netpoll is not in use. With netpoll it is possible for deadlocks to occur if xmit_lock_owner isn't set. This is because if a printk occurs while xmit_lock is held and xmit_lock_owner is not set can cause netpoll to attempt to take xmit_lock recursively. While it is possible to resolve this by getting netpoll to use trylock, it is suboptimal because netpoll's sole objective is to maximise the chance of getting the printk out on the wire. So delaying or dropping the message is to be avoided as much as possible. So the only alternative is to always set xmit_lock_owner. The following patch does this by introducing the netif_tx_lock family of functions that take care of setting/unsetting xmit_lock_owner. I renamed xmit_lock to _xmit_lock to indicate that it should not be used directly. I didn't provide irq versions of the netif_tx_lock functions since xmit_lock is meant to be a BH-disabling lock. This is pretty much a straight text substitution except for a small bug fix in winbond. It currently uses netif_stop_queue/spin_unlock_wait to stop transmission. This is unsafe as an IRQ can potentially wake up the queue. So it is safer to use netif_tx_disable. The hamradio bits used spin_lock_irq but it is unnecessary as xmit_lock must never be taken in an IRQ handler. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 4月, 2006 1 次提交
-
-
由 Randy 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: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 30 3月, 2006 1 次提交
-
-
由 Mark 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: NMark Brown <broonie@sirena.org.uk> Cc: Tim Hockin <thockin@hockin.org> Cc: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 05 3月, 2006 2 次提交
-
-
由 Mark 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: NMark Brown <broonie@sirena.org.uk> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Mark 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: NMark Brown <broonie@sirena.org.uk> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
- 04 3月, 2006 1 次提交
-
-
由 Arjan van de Ven 提交于
-
- 29 6月, 2005 1 次提交
-
-
由 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: NDavid S. Miller <davem@davemloft.net> Acked-by: NJeff Garzik <jgarzik@pobox.com>
-
- 16 5月, 2005 1 次提交
-
-
由 Herbert Xu 提交于
[PATCH] Fw: [Bugme-new] [Bug 4482] New: natsemi: incorrect initialization of 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: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-