summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2008-12-05rtl8187: Add USB ID for Belkin F5D7050 with RTL8187B chipFlorent Fourcot
commit eaca90dab6ab9853223029deffdd226f41b2028c upstream. The Belkin F5D7050rev5000de (id 050d:705e) has the Realtek RTL8187B chip and works with the 2.6.27 driver. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05rtl8187: add device ID 0bda:8198John W. Linville
commit 746db510395e32ff57b9f8582e520df6b3fac618 upstream. Reported by zOOmER.gm@gmail.com to work here: http://bugzilla.kernel.org/show_bug.cgi?id=11728 Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Zoomer <zoomer.gm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05e1000e: Use device_set_wakeup_enableRafael J. Wysocki
commit 6ff68026f4757d68461b7fbeca5c944e1f5f8b44 upstream. Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using e1000_set_wol(). Accordingly, use device_can_wakeup() for checking if wake-up is supported by the device. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05e1000: Use device_set_wakeup_enableRafael J. Wysocki
commit de1264896c8012a261c1cba17e6a61199c276ad3 upstream. Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using e1000_set_wol(). Accordingly, use device_can_wakeup() for checking if wake-up is supported by the device. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05igb: Use device_set_wakeup_enableRafael J. Wysocki
commit e1b86d8479f90aadee57a3d07d8e61c815c202d9 upstream. Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using igb_set_wol(). Accordingly, use device_can_wakeup() for checking if wake-up is supported by the device. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05axnet_cs / pcnet_cs: moving PCMCIA_DEVICE_PROD_ID for Netgear FA411Cord Walter
commit 208fbec5bec1de4fce48aab41efde11ba25ab04c upstream. Hi, after noticing that my Netgear FA411 (PCMCIA-NIC) [1] stopped working with the release of the 2.6.25 kernel (sidux-version), I checked the respective driver sources and noticed that the pcnet_cs driver bailed out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs doesn't claim this ID. I compiled a kernel with the PCMCIA-ID for the netgear card moved to axnet_cs from pcnet_cs which worked. I then contacted sidux-kernel maintainer Stefan Lippers-Hollmann who turned the info into this patch and integrated it into the kernel: <http://svn.berlios.de/svnroot/repos/fullstory/linux-sidux-2.6/trunk/debian/patches/features/2.6.27.4_PCMCIA_move-PCMCIA-ID-for-Netgear-FA411-from-pcnet_cs-to-axnet_cs.patch> This works for me and AFAIK there were no reports of any breakage for other devices on sidux-support. This looks like a trivial patch, but since I have very limited experience with kernel modifications I might be woefully wrong there. But if there are no side effects of this patch, is it possible to get it into the official kernel? I can provide more detailed information on the affected hardware if necessary. -cord [1] Socket 1 Device 0: [axnet_cs] (bus ID: 1.0) Configuration: state: on Product Name: NETGEAR FA411 Fast Ethernet Identification: manf_id: 0x0149 card_id: 0x0411 function: 6 (network) prod_id(1): "NETGEAR" (0x9aa79dc3) prod_id(2): "FA411" (0x40fad875) prod_id(3): "Fast Ethernet" (0xb4be14e3) prod_id(4): --- (---) From: Stefan Lippers-Hollmann <s.l-h@gmx.de> Date: Sat, 1 Nov 2008 23:53:04 +0000 Subject: PCMCIA: move PCMCIA ID for Netgear FA411 from pcnet_cs to axnet_cs: Since kernel 2.6.25, commit 61da96be07ec860e260ca4af0199b9d48d000b80 (pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.), pcnet_cs bails out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs doesn't claim this ID. Socket 1 Device 0: [axnet_cs] (bus ID: 1.0) Configuration: state: on Product Name: NETGEAR FA411 Fast Ethernet Identification: manf_id: 0x0149 card_id: 0x0411 function: 6 (network) prod_id(1): "NETGEAR" (0x9aa79dc3) prod_id(2): "FA411" (0x40fad875) prod_id(3): "Fast Ethernet" (0xb4be14e3) prod_id(4): --- (---) Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Cord Walter <qord@cwalter.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05ath9k: correct expected max RX buffer sizeLuis R. Rodriguez
commit b4b6cda2298b0c9a0af902312184b775b8867c65 upstream We should only tell the hardware its capable of DMA'ing to us only what we asked dev_alloc_skb(). Prior to this it is possible a large RX'd frame could have corrupted DMA data but for us but we were saved only because we were previously also pci_map_single()'ing the same large value. The issue prior to this though was we were unmapping a smaller amount which the prior DMA patch fixed. Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05ath9k: Fix SW-IOMMU bounce buffer starvationLuis R. Rodriguez
commit ca0c7e5101fd4f37fed8e851709f08580b92fbb3 upstream. This should fix the SW-IOMMU bounce buffer starvation seen ok kernel.org bugzilla 11811: http://bugzilla.kernel.org/show_bug.cgi?id=11811 Users on MacBook Pro 3.1/MacBook v2 would see something like: DMA: Out of SW-IOMMU space for 4224 bytes at device 0000:0b:00.0 Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2 so far so its difficult to debug (even with swiotlb=force). We were pci_unmap_single()'ing less bytes than what we called for with pci_map_single() and as such we were starving the swiotlb from its 64MB amount of bounce buffers. We remain consistent and now always use sc->rxbufsize for RX. While at it we update the beacon DMA maps as well to only use the data portion of the skb, previous to this we were pci_map_single()'ing more data for beaconing than what we tell the hardware it can use, therefore pushing more iotlb abuse. Still not sure why this is so easily triggerable on MacBook Pro 3.1, it may be the hardware configuration tends to use more memory > 3GB mark for DMA. Signed-off-by: Maciej Zenczykowski <zenczykowski@gmail.com> Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-12-05atl1e: fix broken multicast by removing unnecessary crc inversionJ. K. Cliburn
commit 7ee0fddfe05f105d3346aa8774695e7130697836 upstream. Inverting the crc after calling ether_crc_le() is unnecessary and breaks multicast. Remove it. Tested-by: David Madore <david.madore@ens.fr> Signed-off-by: Jay Cliburn <jcliburn@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20r8169: select MII in KconfigFrancois Romieu
commit b73724921d906d1642f9f6d054079c6b095903fe upstream. drivers/built-in.o: In function `rtl8169_gset_xmii': r8169.c:(.text+0x82259): undefined reference to `mii_ethtool_gset' Signed-off-by: Hugh Dickins <hugh@veritas.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20rtl8187 : support for Sitecom WL-168 0001 v4Bob Jolliffe
commit f3c769185a28b7947d97b3552a977102c1fac3f2 upstream. the Sitecom 0001 v4 with product id 0x0df6:0028, uses Realtek's RTL8187B and work fine with new 2.6.27 driver. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20rtl8187: Add Abocom USB IDIvan Kuten
commit 8f7c41d4cec91cdbfa89b4a77d5a628938875366 upstream. Signed-off-by: Ivan Kuten <ivan.kuten@promwad.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20hostap: pad the skb->cb usage in lieu of a proper fixJohannes Berg
commit f7cd168645dda3e9067f24fabbfa787f9a237488 upstream. Like mac80211 did, this driver makes 'clever' use of skb->cb to pass information along with an skb as it is requeued from the virtual device to the physical wireless device. Unfortunately, that trick no longer works... Unlike mac80211, code complexity and driver apathy makes this hack the best option we have in the short run. Hopefully someone will eventually be motivated to code a proper fix before all the effected hardware dies. (Above text by me. Johannes officially disavows all knowledge of this hack. -- JWL) Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20bnx2x: Calling netif_carrier_off at the end of the probeEilon Greenstein
commit 12b56ea89e70d4b04f2f5199750310e82894ebbd upstream. netif_carrier_off was called too early at the probe. In case of failure or simply bad timing, this can cause a fatal error since linkwatch_event might run too soon. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Alex Chiang <achiang@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20bnx2x: PCI configuration bug on big-endianEilon Greenstein
commit 7d96567ac0527703cf1b80043fc0ebd7f21a10ad upstream. The current code read nothing but zeros on big-endian (wrong part of the 32bits). This caused poor performance on big-endian machines. Though this issue did not cause the system to crash, the performance is significantly better with the fix so I view it as critical bug fix. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Alex Chiang <achiang@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20bnx2x: Removing the PMF indication when unloadingEilon Greenstein
commit 9a0354405feb0f8bd460349a93db05e4cca8d166 upstream. When the PMF flag is set, the driver can access the HW freely. When the driver is unloaded, it should not access the HW. The problem caused fatal errors when "ethtool -i" was called after the calling instance was unloaded and another instance was already loaded Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Alex Chiang <achiang@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20ath5k: Fix reset sequence for AR5212 in general and RF5111 in particularElias Oltmanns
commit 7d19267b8d1e12c0baebf9be96e04cddffe63f67 upstream Take care to handle register 0xa228 exactly as in the HAL released by Atheros. This change is required to make ath5k work again on my system since commit 2203d6be (ath5k: Misc hw_reset updates), thus fixing a regression in 2.6.27 and therefore hopefully eligible for inclusion into a stable release. v2: Only overwrite initial register values on later revisions of AR5212 chips. v3: Use standard macros to manipulate the register. Signed-off-by: Elias Oltmanns <eo@nebensachen.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20ath5k: fix suspend-related oops on rmmodElias Oltmanns
Cumulative patch backporting the following two commits from upstream: commit 8bdd5b9c6bd53add260756b6673a0545fbdbba21 upstream Author: Bob Copeland <me@bobcopeland.com> Based on a patch by Elias Oltmanns, we call ath5k_init in resume even if we didn't previously open the device. Besides starting up the device unnecessarily, this also causes an oops on rmmod because mac80211 will not invoke ath5k_stop and softirqs are left running after the module has been unloaded. Add a new state bit, ATH_STAT_STARTED, to indicate that we have been started up. commit bc1b32d6bdd2d6f3fbee9a7c01c9b099f11c579c upstream Author: Elias Oltmanns <eo@nebensachen.de> After a s2ram / resume cycle, resetting the key cache does not work unless it is deferred until after the hardware has been reinitialised by a call to ath5k_hw_reset(). This fixes a regression introduced by "ath5k: fix suspend-related oops on rmmod". Reported-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Elias Oltmanns <eo@nebensachen.de> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-20iwlagn: avoid sleep in softirq contextJohn W. Linville
commit 964d2777438bf7687324243d38ade538d9bbfe3c upstream. __ieee80211_tasklet_handler -> __ieee80211_rx -> __ieee80211_rx_handle_packet -> ieee80211_invoke_rx_handlers -> ieee80211_rx_h_decrypt -> ieee80211_crypto_tkip_decrypt -> ieee80211_tkip_decrypt_data -> iwl4965_mac_update_tkip_key -> iwl_scan_cancel_timeout -> msleep Ooops! Avoid the sleep by changing iwl_scan_cancel_timeout with iwl_scan_cancel and simply returning on failure if the scan persists. This will cause hardware decryption to fail and we'll handle a few more frames with software decryption. Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Holger Macht <hmacht@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwl3945: do not send scan command if channel count zeroReinette Chatre
commit 14b5433606289dbc5b6fd70ced11462f80e95003 upstream. Do not send scan command if no channels to scan. This avoids a Microcode error as reported in: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1650 http://bugzilla.kernel.org/show_bug.cgi?id=11806 http://marc.info/?l=linux-wireless&m=122437145211886&w=2 Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwl3945: fix deadlock on suspendZhu Yi
commit d54bc4e3fc5c56600a13c9ebc0a7e1077ac05d59 upstream. This patch fixes iwl3945 deadlock during suspend by moving notify_mac out of iwl3945 mutex. This is a portion of the same fix for iwlwifi by Tomas. Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13zd1211rw: Add 2 device IDsDaniel Drake
commit 0feec9dfe7b8880ab3b4c38d7cc4107dd706ea7f upstream. 07fa/1196 Bewan BWIFI-USB54AR: Tested by night1308, this device is a ZD1211B with an AL2230S radio. 0ace/b215 HP 802.11abg: Tested by Robert Philippe Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwlwifi: generic init calibrations frameworkTomas Winkler
commit 6e21f2c109edd746a10e08186484bae8168cdd0c upstream This patch allows variable number of init calibrations and allows addition new HW. This patch also fixes critical bug. Only last calibration result was applied. On reception of one calibration result all the calibration was freed. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwlwifi: fix suspend to RAM in iwlwifiTomas Winkler
commit 10d0bd56966571d0324dfd9bbb8aa913a60bef5f upstream This patch fixes suspend to RAM after by moving notify_mac out of iwlwifi mutex http://bugzilla.kernel.org/show_bug.cgi?id=11845 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Tested-by: Carlos R. Mafra <crmafra2@gmail.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwlwifi: use correct DMA_MASKTomas Winkler
commit 093d874c02e8d3091aa38596faf0ff2bfd4f0ceb upstream Use correct DMA_MASK: 4964 and 5000 support 36 bit addresses for pci express memory access. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-11-13iwlwifi: don't fail if scan is issued too earlyTomas Winkler
commit 8d09a5e1c36d0dec5728e6c8b0bb5412de09b27b upstream This patch returns success and empty scan on scans requests that were rejected because issued too early. The cached bss list from previous scanning will be returned by mac80211. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwlwifi: remove HT flags from RXON when not in HT anymoreEmmanuel Grumbach
commit 42eb7c644afcdbcd7eac4d862046230856fbf531 upstream. This patch removes the HT flags from RXON when moving from HT to legacy. This avoids keeping those flags set and possibly miss configuring firmware. If we are configured in HT, fat channel: channel 1 above, and move later to legacy channel 11, we need to clear the FAT channel control flags in RXON. If we don't, the firmware will understand this as channel 11 above which is not possible due to regulatory constraints, leading to firmware crash. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwlwifi: allow association on radar channel in power saveEmmanuel Grumbach
commit c90a74bae10dc2a4677d1bd06b6400db229d3e1e upstream This patch disables power save upon association and enables it back after association. This allows to associate to AP on a radar channel if power save is enabled. Radar and passive channels are not allowed for TX (required for association) unless RX is received but PS may close the radio and no RX will be received effectively failing association. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Mohamed Abbas <mohamed.abbas@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13iwlwifi: allow consecutive scans in unassociated stateRon Rindjunsky
commit 681c0050ea3ac2e90c83d5af397d73eed848a372 upstream This patch allows consecutive scans requests when driver is in unassociated state. Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Esti Kummer <ester.kummer@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13r8169: wake up the PHY of the 8168Francois Romieu
Upstream as a2de6b89b74b28052e293fdb39975a5a03c432e0 This is typically needed when some other OS puts the PHY to sleep due to the disabling of WOL options in the BIOS of the system. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Chiaki Ishikawa <chiaki.ishikawa@ubin.jp> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Cc: RyanKao <ryankao@realtek.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13r8169: fix RxMissed register accessFrancois Romieu
Upstream as 523a609496dbc3897e530db2a2f27650d125ea00 - the register is defined for the 8169 chipset only and there is no 8169 beyond RTL_GIGA_MAC_VER_06. - only the lower 3 bytes of the register are valid Fixes: 1. http://bugzilla.kernel.org/show_bug.cgi?id=10180 2. http://bugzilla.kernel.org/show_bug.cgi?id=11062 (bits of) Tested by Hermann Gausterer and Adam Huffman. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-13r8169: get ethtool settings through the generic mii helperFrancois Romieu
Upstream as ccdffb9a88b2907b159538d7bfd6256621db4f84 (post 2.6.27). It avoids to report unsupported link capabilities with the fast-ethernet only 8101/8102. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Martin Capitanio <martin@capitanio.org> Fixed-by: Ivan Vecera <ivecera@redhat.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06bonding: fix panic when taking bond interface down before removing moduleAndy Gospodarek
commit ce39a800ea87c655de49af021c8b20ee323cb40d upstream. A panic was discovered with bonding when using mode 5 or 6 and trying to remove the slaves from the bond after the interface was taken down. When calling 'ifconfig bond0 down' the following happens: bond_close() bond_alb_deinitialize() tlb_deinitialize() kfree(bond_info->tx_hashtbl) bond_info->tx_hashtbl = NULL Unfortunately if there are still slaves in the bond, when removing the module the following happens: bonding_exit() bond_free_all() bond_release_all() bond_alb_deinit_slave() tlb_clear_slave() tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl u32 next_index = tx_hash_table[index].next As you might guess we panic when trying to access a few entries into the table that no longer exists. I experimented with several options (like moving the calls to tlb_deinitialize somewhere else), but it really makes the most sense to be part of the bond_close routine. It also didn't seem logical move tlb_clear_slave around too much, so the simplest option seems to add a check in tlb_clear_slave to make sure we haven't already wiped the tx_hashtbl away before searching for all the non-existent hash-table entries that used to point to the slave as the output interface. Signed-off-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06libertas: fix buffer overrunJohannes Berg
commit 48735d8d8bd701b1e0cd3d49c21e5e385ddcb077 upstream If somebody sends an invalid beacon/probe response, that can trash the whole BSS descriptor. The descriptor is, luckily, large enough so that it cannot scribble past the end of it; it's well above 400 bytes long. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-06atl1: fix vlan tag regressionJay Cliburn
commit dc5596d920b504d263c7ca38bd76326179b13dee upstream Commit 401c0aabec4b97320f962a0161a846d230a6f7aa introduced a regression in the atl1 driver by storing the VLAN tag in the wrong TX descriptor field. This patch causes the VLAN tag to be stored in its proper location. Tested-by: Ramon Casellas <ramon.casellas@cttc.es> Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-22ath9k: fix oops on trying to hold the wrong spinlockLuis R. Rodriguez
commit a477e4e6d48d3ac7c7a75bad40585cb391e5c237 upstream We were trying to hold the wrong spinlock due to a typo on IEEE80211_BAR_CTL_TID_S's definition. We use this to compute the tid number and then hold this this tid number's spinlock. Tested-by: Steven Noonan <steven@uplinklabs.net> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-22ath9k/mac80211: disallow fragmentation in ath9k, report to userspaceJohannes Berg
commit 4233df6b748193d45f79fb7448991a473061a65d upstream As I've reported, ath9k currently fails utterly when fragmentation is enabled. This makes ath9k "support" hardware fragmentation by not supporting fragmentation at all to avoid the double-free issue. The patch also changes mac80211 to report errors from the driver operation to userspace. That hack in ath9k should be removed once the rate control algorithm it has is fixed, and we can at that time consider removing the hw fragmentation support entirely since it's not used by any driver. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-18netdrvr: atl1e: Don't take the mdio_lock in atl1e_probeMatthew Wilcox
commit f382a0a8e9403c6d7f8b2cfa21e41fefb5d0c9bd upstream Lockdep warns about the mdio_lock taken with interrupts enabled then later taken from interrupt context. Initially, I considered changing these to spin_lock_irq/spin_unlock_irq, but then I looked at atl1e_phy_init() and saw that it calls msleep(). Sleeping while holding a spinlock is not allowed either. In the probe path, we haven't registered the interrupt handler, so it can't poke at this card yet. It's before we call register_netdev(), so I don't think any other threads can reach this card either. If I'm right, we don't need a spinlock at all. Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Cc: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-18sky2: Fix WOL regressionRafael J. Wysocki
commit 9d731d77c9794bb0a264f58d35949a1ab6dcc41c upstream Since dev->power.should_wakeup bit is used by the PCI core to decide whether the device should wake up the system from sleep states, set/unset this bit whenever WOL is enabled/disabled using sky2_set_wol(). Remove an open-coded reference to the standard PCI PM registers that is not used any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Tino Keitel <tino.keitel@gmx.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-18b43legacy: Fix failure in rate-adjustment mechanismLarry Finger
commit c6a2afdacccd56cc0be8e9a7977f0ed1509069f6 upstream Date: Sat, 6 Sep 2008 16:51:22 -0500 Subject: b43legacy: Fix failure in rate-adjustment mechanism A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-18libertas: clear current command on card removalDan Williams
commit 71b35f3abeb8f7f7e0afd7573424540cc5aae2d5 upstream If certain commands were in-flight when the card was pulled or the driver rmmod-ed, cleanup would block on the work queue stopping, but the work queue was in turn blocked on the current command being canceled, which didn't happen. Fix that. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-03e1000e: Fix incorrect debug warningLinus Torvalds
Doing 'WARN_ON(preempt_count())' was horribly horribly wrong, and would cause tons of warnings at bootup if PREEMPT was enabled because the initcalls currently run with the kernel lock, which increments the preempt count. At the same time, the warning was also insufficient, since it didn't check that interrupts were enabled. The proper debug function to use for something that can sleep and wants a warning if it's called in the wrong context is 'might_sleep()'. Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: update version from k4 to k6Jesse Brandeburg
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: debug contention on NVM SWFLAGThomas Gleixner
This patch adds a mutex to the e1000e driver that would help catch any collisions of two e1000e threads accessing hardware at the same time. description and patch updated by Jesse Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: drop stats lockJesse Brandeburg
the stats lock is left over from e1000, e1000e no longer has the adjust tbi stats function that required the addition of the stats lock to begin with. adding a mutex to acquire_swflag helped catch this one too. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: remove phy read from inside spinlockJesse Brandeburg
thanks to tglx, we're finding some interesting reentrancy issues. this patch removes the phy read from inside a spinlock, paving the way for removing the spinlock completely. The phy read was only feeding a statistic that wasn't used. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: do not ever sleep in interrupt contextJesse Brandeburg
e1000e was apparently calling two functions that attempted to reserve the SWFLAG bit for exclusive (to hardware and firmware) access to the PHY and NVM (aka eeprom). These accesses could possibly call msleep to wait for the resource which is not allowed from interrupt context. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-02e1000e: reset swflag after resetting hardwareJesse Brandeburg
in the process of debugging things, noticed that the swflag is not reset by the driver after reset, and the swflag is probably not reset unless management firmware clears it after 100ms. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-01e1000e: write protect ICHx NVM to prevent malicious write/eraseBruce Allan
Set the hardware to ignore all write/erase cycles to the GbE region in the ICHx NVM. This feature can be disabled by the WriteProtectNVM module parameter (enabled by default) only after a hardware reset, but the machine must be power cycled before trying to enable writes. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: arjan@linux.intel.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-09-24ath9k: disable MIB interrupts to fix interrupt stormLuis R. Rodriguez
Enabling the MIB interrupts has proven to cause an interrupt storm after 7 hours of run. We will make use of the MIB interrupt once we have ANI supported added so for now to cure this we disable the interrupt. The interrupt storm can be seen as follows after 7 hours of run as reported by Steven Noonan <steven@uplinklabs.net>: 18:28:38 sum 1106.00 18:28:39 sum 1037.62 18:28:40 sum 1069.00 18:28:41 sum 1167.00 18:28:42 sum 1155.00 18:28:43 sum 1339.00 18:28:44 sum 18355.00 18:28:45 sum 17845.45 18:28:46 sum 15285.00 18:28:47 sum 17511.00 18:28:48 sum 17568.69 18:28:49 sum 17704.04 18:28:50 sum 18566.67 18:28:51 sum 18913.13 at 18:28:44 the MIB interrupt kicked off and caused huge latency which can be seen even on a video he submitted: http://www.youtube.com/watch?v=4GeCx1gZMpA Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>