- 19 2月, 2009 1 次提交
-
-
由 Jie Yang 提交于
Supporting AR8131, and AR8132. Signed-off-by: NJie Yang <jie.yang@atheros.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 16 2月, 2009 1 次提交
-
-
由 Tobias Diedrich 提交于
Commit f55c21fd ("forcedeth: call restore mac addr in nv_shutdown path"), which was introduced to fix the regression tracked at http://bugzilla.kernel.org/show_bug.cgi?id=11358 causes the wake-on-lan mac to be reversed in the shutdown path. Apparently the forcedeth situation is rather messy in that the mac we need to writeback for a subsequent modprobe to work is exactly the reverse of what is needed for proper wake-on-lan. The following patch explains the situation in the comments and makes the call to nv_restore_mac_addr() conditional (only called if we are not really going for poweroff). Tobias Diedrich wrote: > Hmm, I had not tried WOL for some time. > With 2.6.29-rc3 is see the following behaviour: > > State WOL Behaviour > ------------------------------ > shutdown reversed MAC > disk/shutdown reversed MAC > disk/platform OK > > Apparently nv_restore_mac_addr() restores the MAC in the wrong order > for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15). platform > works, because the MAC is not touched in the nv_suspend() path. > > A possible fix might be to only call nv_restore_mac_addr() if > system_state != SYSTEM_POWER_OFF. With the following patch: shutdown OK disk/shutdown OK disk/platform OK kexec OK Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de> Tested-by: NPhilipp Matthias Hahn <pmhahn@titan.lahn.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 2月, 2009 17 次提交
-
-
由 Yang Hongyang 提交于
When compile the latest kernel on IA64 platform,I got a warning: drivers/net/netxen/netxen_nic_main.c:203: warning: label ‘set_32_bit_mask’ defined but not used We do not need label ‘set_32_bit_mask’ on IA64 platform,So move it to #else. Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
If errors are reported on a frame descriptor, we need to account for the buffer pages that may have been used for this error packet and recycle them. Otherwise, we may get the wrong pages for the next packet. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NMatt Carlson <mcarlson@broadcom.com> Signed-off-by: NBenjamin Li <benli@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
New firmware fixes a data corruption issue when receiving and placing jumbo frames into host buffers. In some cases, the buffer descriptor is not updated correctly and this will lead to the driver linking the wrong number of pages into the SKB. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
New firmware fixes a data corruption issue when receiving and placing jumbo frames into host buffers. In some cases, the buffer descriptor is not updated correctly and this will lead to the driver linking the wrong number of pages into the SKB. Signed-off-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Roel Kluin 提交于
Ensure that we do not set pcb->data.raw beyond its size, print an error message and return false if we attempt to. A timout message was printed one too early. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Roel Kluin 提交于
If no prior break occurs, cnt reaches 101 after the loop, so we are still able to change speed when cnt has become 100. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dhananjay Phadke 提交于
Remove workaround for pcie bug in early revisions of NX3031 (rev 41 or earlier). This is taken care of during firmware init. The workaround required writing pcie config reg of every pcie function on a card, not all of which are enabled. Signed-off-by: NDhananjay Phadke <dhananjay@netxen.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Roel Kluin 提交于
With while (--i > 0) { ... } i reaches 0; print when lance_open() fails Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
The large receive buffer queue is not properly tracking the current index in the case where an early exit occurs. This can happen when a page alloc or dma mapping fails. If this occurs the queue will get out of sync and invalid indexes can be written to the hardware. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
Receive packets were only scaling across 2 of the receive queues. The value was hardcoded to 2 instead of being based on how many rx queues were running. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
Moved the buffer mapping to a point after TSO logic has modified the iph->check field. We were seeing stale data on the PCIe bus. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
We put the skb back if we can't get mapping for it. We don't want unmapped buffers on our receive buffer queue. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
We put the page back if we can't get mapping for it. We don't want unmapped buffers on our receive buffer queue. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ron Mercer 提交于
Replace calls to vlan_hwaccel_rx() and netif_rx(). Thanks to Dave Miller for pointing out the the driver was making the wrong upcall for passing packets into the stack. Signed-off-by: NRon Mercer <ron.mercer@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Roel Kluin 提交于
With while (limit--) { ... } limit reaches -1, so 0 means success. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Acked-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 2月, 2009 4 次提交
-
-
由 Reinette Chatre 提交于
Here we do two things: First, revert "iwlwifi: save PCI state before suspend, restore after resume". That misguided patch led to being unable to use iwlwifi devices after resume. Next, indicate to PCI driver that the saved PCI state is valid during suspend. We restore PCI state and enable the device when network interface is created, similarly PCI state is saved and the device is disabled when network interface is removed. Thus, when .suspend is called the PCI state is saved and device is disabled. This is the case even if an interface is never created as PCI state is saved and device disabled during .probe. PCI driver assumes PCI state is saved in .suspend. Saving the state at this time will save state of disabled device and thus cause problems during resume (resuming a disabled device). We thus indicate directly to PCI driver that current PCI saved state is valid. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Tested-by: NAlex Riesen <fork0@users.sf.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hin-Tak Leung 提交于
Three people (Petr Mensik <pihhan@cipis.net> ["si" should be U+0161 U+00ED], Stephen Ho <stephenhoinhk@gmail.com> on zd1211-devs and Ismael Ojeda Perez <iojedaperez@gmail.com> on linux-wireless) reported success in getting TP-Link WN322G/WN422G working by treating MAXIM_NEW_RF(0x08) as UW2453_RF(0x09) for rf chip hardware initialization. Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net> Tested-by: NPetr Mensik <pihhan@cipis.net> Tested-by: NStephen Ho <stephenhoinhk@gmail.com> Tested-by: NIsmael Ojeda Perez <iojedaperez@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hin-Tak Leung 提交于
Christoph Biedl <sourceforge.bnwi@manchmal.in-ulm.de> reported success in the sourceforge zd1211 mailing list on this addition. This product ID was supported by the vendor driver ZD1211LnxDrv 2.22.0.0 (and possibly earlier) and it probably should have been added earlier. Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net> Tested-by: NChristoph Biedl <sourceforge.bnwi@manchmal.in-ulm.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
Under memory pressure, we may not be able to allocate a new skb for new packets. If the allocation fails, ath5k_tasklet_rx will exit but will leave a buffer in the list with a NULL skb, eventually triggering a BUG_ON. Extract the skb allocation from ath5k_rxbuf_setup() and change the tasklet to allocate the next skb before accepting a packet. Changes-licensed-under: 3-Clause-BSD Signed-off-by: NBob Copeland <me@bobcopeland.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 2月, 2009 3 次提交
-
-
由 Meelis Roos 提交于
Currently, the sunhme driver installs SBus Quattro interrupt handler when at least one HME card was initialized correctly and at least one Quattro card is present. This breaks when a Quattro card fails initialization for whatever reason - IRQ is registered and OOPS happens when it fires. The solution, as suggested by David Miller, was to keep track which cards of the Quattro bundles have been initialized, and request/free the Quattro IRQ only when all four devices have been successfully initialized. The patch only touches SBus initialization - PCI init already resets the card pointer to NULL on init failure. The patch has been tested on Sun E3500 with SBus and PCI single HME cards and one PCI Quattro HME card in a situation where any PCI card failed init when the SBus routines tried to init them by mistake. Additionally it replaces Quattro request_irq panic with error return - if this card fails to work, at least let the others work. Tested on E450 with PCI HME and PCI Quad HME. [ Minor coding style fixups -DaveM ] Signed-off-by: NMeelis Roos <mroos@linux.ee> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Meelis Roos 提交于
Fore 200 ATM driver fails to handle request_firmware failures and oopses when no firmware file was found. Fix it by checking for the right return values and propaganting the return value up. Signed-off-by: NMeelis Roos <mroos@linux.ee> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Paulius Zaleckas 提交于
mdc pin should always be output. Initialize it as output, so each board code does not need to do this. Signed-off-by: NPaulius Zaleckas <paulius.zaleckas@teltonika.lt> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 10 2月, 2009 1 次提交
-
-
由 Jarek Poplawski 提交于
Ira Snyder found that commit 8c7396ae "gianfar: Merge Tx and Rx interrupt for scheduling clean up ring" can cause hangs. It's because there was removed clearing of interrupts in gfar_schedule_cleanup() (which is called by an interrupt handler) in case when netif scheduling has been disabled. This patch brings back this action and a comment. Reported-by: NIra Snyder <iws@ovro.caltech.edu> Reported-by: NPeter Korsgaard <jacmet@sunsite.dk> Bisected-by: NIra Snyder <iws@ovro.caltech.edu> Tested-by: NPeter Korsgaard <jacmet@sunsite.dk> Tested-by: NIra Snyder <iws@ovro.caltech.edu> Signed-off-by: NJarek Poplawski <jarkao2@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 2月, 2009 5 次提交
-
-
由 Dhananjay Phadke 提交于
o Cut down msi-x vectors from 8 to 1 since only one is used for now. o Use separate handler for msi-x, that doesn't unnecessarily scrub msi status register. Signed-off-by: NDhananjay Phadke <dhananjay@netxen.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Risto Suominen 提交于
DescOwn should not be set, thus allowing the chip to use the descriptor, before everything else is set up correctly. Signed-off-by: NRisto Suominen <Risto.Suominen@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alex Williamson 提交于
Tap devices can make use of a small MAC filter set via the TUNSETTXFILTER ioctl. The filter has a set of exact matches plus a hash for imperfect filtering of additional multicast addresses. The current code is unbalanced, adding unicast addresses to the multicast hash, but only checking the hash against multicast addresses. This results in the filter dropping unicast addresses that overflow the exact filter. The fix is simply to disable the filter by leaving count set to zero if we find non-multicast addresses after the exact match table is filled. Signed-off-by: NAlex Williamson <alex.williamson@hp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Julia Lawall 提交于
Error handling code following a kmalloc should free the allocated data. The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,l; position p1,p2; expression *ptr != NULL; @@ ( if ((x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...)) == NULL) S | x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S ) <... when != x when != if (...) { <+...x...+> } x->f = E ...> ( return \(0\|<+...x...+>\|ptr\); | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Julia Lawall 提交于
Error handling code following a kmalloc should free the allocated data. The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,l; position p1,p2; expression *ptr != NULL; @@ ( if ((x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...)) == NULL) S | x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S ) <... when != x when != if (...) { <+...x...+> } x->f = E ...> ( return \(0\|<+...x...+>\|ptr\); | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 07 2月, 2009 4 次提交
-
-
由 David S. Miller 提交于
Unfortunately, the OF device tree nodes for SBUS and PCI hme devices have the same device node name on some systems. So if the name of the parent node isn't 'sbus', skip it. Based upon an excellent report and detective work by Meelis Roos and Eric Brower. Signed-off-by: NDavid S. Miller <davem@davemloft.net> Tested-by: NMeelis Roos <mroos@linux.ee>
-
由 Ondrej Zary 提交于
From: Ondrej Zary <linux@rainbow-software.org> last year, I posted a patch which fixed hibernation on 3c509 cards. That was back in 2.6.24. It worked fine in 2.6.25. But then I stopped using hibernation (as it did not work with my new IT8212 RAID controller). Now I fixed it and noticed that 3c509 does not wake up properly anymore (in 2.6.28) - neither in PnP nor in ISA modes. ifconfig down/up makes the card work again in PnP mode. However, in ISA mode, ifconfig up ends with "No such device" error. Comparing the 3c509 driver between 2.6.25 and 2.6.28, there's only some statistics-related change. So the cause of the problem must be somewhere else. This patch makes the resume work in PnP mode, but it's still not enough for ISA mode. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ilkka Virta 提交于
From: Ilkka Virta <itvirta@iki.fi> In the lockup situation the driver seems to go off in an eternal storm of interrupts right after calling request_irq(). It doesn't actually do anything interesting in the interrupt handler. Since connecting the link afterwards works, something later in initialization must fix this. Looking at gem_do_start() and gem_open(), it seems that the only thing done while opening the device after the request_irq(), is a call to napi_enable(). I don't know what the ordering requirements are for the initialization, but I boldly tried to move the napi_enable() call inside gem_do_start() before the link state is checked and interrupts subsequently enabled, and it seems to work for me. Doesn't even break anything too obvious... Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ivan Vecera 提交于
Some Realtek chips (RTL8169sb/8110sb in my case) are unable to retrieve ethtool statistics when the interface is down. The process stays in endless loop in rtl8169_get_ethtool_stats. This is because these chips need to have receiver enabled (CmdRxEnb bit in ChipCmd register) that is cleared when the interface is going down. It's better to update statistics only when the interface is up and otherwise return copy of statistics grabbed when the interface was up (in rtl8169_close). It is interesting that PCI-E NICs (like 8168b/8111b...) are not affected. Signed-off-by: NIvan Vecera <ivecera@redhat.com> Acked-by: NFrancois Romieu <romieu@fr.zoreil.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 05 2月, 2009 4 次提交
-
-
由 Andy Fleming 提交于
SOFT_RESET must be asserted for at least 3 TX clocks in order for it to work properly. The syncs in the gfar_write() commands have been hiding this, but we need to guarantee it. Signed-off-by: NAndy Fleming <afleming@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andy Fleming 提交于
BD_LENGTH_MASK is supposed to catch the low 16-bits of the status field, not the low byte. The old way, we would never be able to clean up tx packets with sizes divisible by 256. Signed-off-by: NAndy Fleming <afleming@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Divy Le Ray 提交于
The LRO switch is always set to 1 in the rx processing loop. It breaks the accelerated iSCSI receive traffic. Fix its computation. Signed-off-by: NDivy Le Ray <divy@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Reinette Chatre 提交于
This is the right thing to do and fixes the following warning: [ 115.012278] ------------[ cut here ]------------ [ 115.012281] WARNING: at drivers/pci/pci-driver.c:370 pci_legacy_suspend+0x85/0xc2() [ 115.012285] Hardware name: Latitude D630 [ 115.012301] PCI PM: Device state not saved by iwl3945_pci_suspend+0x0/0x4c [iwl3945] [ 115.012304] Modules linked in: fuse nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipv6 acpi_cpufreq kvm_intel kvm snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_seq_device snd_pcm_oss snd_mixer_oss ecb snd_pcm cryptomgr aead snd_timer crypto_blkcipher snd snd_page_alloc ohci1394 crypto_hash crypto_algapi ch341 ieee1394 usbserial thermal iwl3945 mac80211 led_class lib80211 tg3 processor i2c_i801 i2c_core sg cfg80211 libphy usbhid battery ac button sr_mod cdrom evdev dcdbas ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd usbcore [last unloaded: microcode] [ 115.012374] Pid: 4163, comm: pm-suspend Not tainted 2.6.29-rc3-00227-gf1dd849-dirty #67 [ 115.012377] Call Trace: [ 115.012382] [<ffffffff8023d04d>] warn_slowpath+0xb1/0xed [ 115.012387] [<ffffffff80450b5e>] ? _spin_unlock_irqrestore+0x5c/0x78 [ 115.012390] [<ffffffff80254f08>] ? up+0x34/0x39 [ 115.012394] [<ffffffff80362319>] ? acpi_ut_release_mutex+0x5d/0x61 [ 115.012397] [<ffffffff803584b2>] ? acpi_get_data+0x5e/0x70 [ 115.012400] [<ffffffff80363dd9>] ? acpi_bus_get_device+0x25/0x39 [ 115.012403] [<ffffffff80363e98>] ? acpi_bus_power_manageable+0x11/0x29 [ 115.012406] [<ffffffff803462f7>] ? acpi_pci_power_manageable+0x17/0x19 [ 115.012410] [<ffffffff8033ddfd>] ? pci_set_power_state+0xcc/0x101 [ 115.012418] [<ffffffffa01f28e9>] ? iwl3945_pci_suspend+0x0/0x4c [iwl3945] [ 115.012422] [<ffffffff803401e6>] pci_legacy_suspend+0x85/0xc2 [ 115.012425] [<ffffffff80340316>] pci_pm_suspend+0x34/0x86 [ 115.012429] [<ffffffff8039d7ce>] pm_op+0x52/0xe5 [ 115.012432] [<ffffffff8039dd78>] device_suspend+0x32a/0x451 [ 115.012436] [<ffffffff80269ec2>] suspend_devices_and_enter+0x3e/0x13a [ 115.012439] [<ffffffff8026a128>] enter_state+0x110/0x164 [ 115.012442] [<ffffffff8026a233>] state_store+0xb7/0xd7 [ 115.012446] [<ffffffff8032f95f>] kobj_attr_store+0x17/0x19 [ 115.012449] [<ffffffff80307d64>] sysfs_write_file+0xe4/0x119 [ 115.012453] [<ffffffff802baa7a>] vfs_write+0xae/0x137 [ 115.012456] [<ffffffff802babc7>] sys_write+0x47/0x70 [ 115.012459] [<ffffffff8020b73a>] system_call_fastpath+0x16/0x1b [ 115.012467] ---[ end trace 829828966f6f24dc ]--- Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Tested-by: NMing Lei <tom.leiming@gmail.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-