summaryrefslogtreecommitdiffstats
path: root/drivers/net
Commit message (Collapse)AuthorAgeFilesLines
* e1000: Silence sparse warnings by correcting typeAndrei Emeltchenko2012-05-041-2/+2
| | | | | | | | | | | | | | Silence sparse warnings shown below: ... drivers/net/ethernet/intel/e1000/e1000_main.c:3435:17: warning: cast to restricted __le64 drivers/net/ethernet/intel/e1000/e1000_main.c:3435:17: warning: cast to restricted __le64 ... Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* igb, ixgbe: netdev_tx_reset_queue incorrectly called from tx init pathJohn Fastabend2012-05-043-4/+6
| | | | | | | | | | | | | | | | | | igb and ixgbe incorrectly call netdev_tx_reset_queue() from i{gb|xgbe}_clean_tx_ring() this sort of works in most cases except when the number of real tx queues changes. When the number of real tx queues changes netdev_tx_reset_queue() only gets called on the new number of queues so when we reduce the number of queues we risk triggering the watchdog timer and repeated device resets. So this is not only a cosmetic issue but causes real bugs. For example enabling/disabling DCB or FCoE in ixgbe will trigger this. CC: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: John Bishop <johnx.bishop@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* ixgbe: dcb: BIT_APP_UPCHG not set by ixgbe_copy_dcb_cfg()John Fastabend2012-05-033-28/+22
| | | | | | | | | | | | | | | | | | | | | | | | After this commit: commit aacc1bea190d731755a65cb8ec31dd756f4e263e Author: Multanen, Eric W <eric.w.multanen@intel.com> Date: Wed Mar 28 07:49:09 2012 +0000 ixgbe: driver fix for link flap The BIT_APP_UPCHG bit is no longer set when ixgbe_dcbnl_set_all() is called. This results in the FCoE app user priority never getting set and the driver will not configure the tx_rings correctly for FCoE packets which use the SAN MTU and FCoE offloads. We resolve this regression by fixing ixgbe_copy_dcb_cfg() to also check for FCoE application changes. Additionally, we can drop the IEEE variants of get_dcb_app() because this path is never called with the IEEE mode enabled. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* ixgbe: fix race condition with shutdownDon Skidmore2012-05-031-0/+2
| | | | | | | | | | | It was possible for shutdown to pull the rug out from other driver entry points. Now we just grab the rtnl lock before taking everything apart. Thanks to Hariharan for noticing this tight race condition. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Cc: Hariharan Nagarajan <hanagara@cisco.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* sungem: Fix WakeOnLanGerard Lledo2012-05-031-1/+1
| | | | | | | | | | WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5). gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting gp->wake_on_lan to bool. Tested on an iBook G4. Signed-off-by: Gerard Lledo <gerard.lledo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* usbnet: fix failure handling in usbnet_probetom.leiming@gmail.com2012-05-021-1/+3
| | | | | | | | If register_netdev returns failure, the dev->interrupt and its transfer buffer should be released, so just fix it. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* usbnet: fix leak of transfer buffer of dev->interrupttom.leiming@gmail.com2012-05-021-0/+1
| | | | | | | | | | The transfer buffer of dev->interrupt is allocated in .probe path, but not freed in .disconnet path, so mark the interrupt URB as URB_FREE_BUFFER to free the buffer when the URB is destroyed. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* ucc_geth: Add 16 bytes to max TX frame for VLANsJoakim Tjernlund2012-05-021-3/+3
| | | | | | | | | | | Creating a VLAN interface on top of ucc_geth adds 4 bytes to the frame and the HW controller is not prepared to TX a frame bigger than 1518 bytes which is 4 bytes too small for a full VLAN frame. Add 16 bytes which will handle the a simple VLAN and leaves 12 bytes for future expansion. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ucc_geth, increase no. of HW RX descriptorsJoakim Tjernlund2012-05-021-1/+1
| | | | | | | | | In a busy network we see ucc_geth is dropping RX pkgs every now and then. Increase the RX queues HW descriptors from 16 to 32 to deal with this. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵John W. Linville2012-05-017-18/+71
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
| * wl1251: fix crash on remove due to leftover work itemGrazvydas Ignotas2012-04-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Cc: stable@vger.kernel.org # v2.6.37+ Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * wl1251: fix crash on remove due to premature kfreeGrazvydas Ignotas2012-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Cc: stable@vger.kernel.org # v2.6.37+ Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * b43: only reload config after successful initializationSeth Forshee2012-04-271-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 2a19032 (b43: reload phy and bss settings after core restarts) introduced an unconditional call to b43_op_config() at the end of b43_op_start(). When firmware fails to load this can wedge the system. There's no need to reload the configuration after a failed initialization anyway, so only make the call if initialization was successful. BugLink: http://bugs.launchpad.net/bugs/950295 Cc: Felix Fietkau <nbd@openwrt.org> Cc: <stable@vger.kernel.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * iwlwifi: use 6000G2B for 6030 device seriesWey-Yi Guy2012-04-271-2/+2
| | | | | | | | | | | | | | | | | | | | "iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Cc: stable@vger.kernel.org #3.3+ Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath5k: add missing iounmap to AHB probe removalJonathan Bither2012-04-271-0/+1
| | | | | | | | | | | | | | | | When our driver device is removed on the AHB bus, our IO memory is never unmapped. Signed-off-by: Jonathan Bither <jonbither@gmail.com> Reviewed-by: Pavel Roskin <proski@gnu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * brcm80211: fmac: fix missing completion events issueFranky Lin2012-04-271-12/+51
| | | | | | | | | | | | | | | | | | | | | | | | dpc takes care of all data packets transmissions for sdio function 2. It is possible that it misses some completion events when the traffic is heavy or it's running on a slow cpu. A linked list is introduced to make sure dpc is invoked whenever needed. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * brcm80211: fmac: fix SDIO function 0 register r/w issueFranky Lin2012-04-271-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | SDIO stack doesn't have a structure for function 0. The structure pointer stored in card->sdio_func[0] is actually for function 1. With current implementation the register read/write is applied to function 1. This pathch fixes the issue. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Arend van Spriel <arend@broadcom.com> Reviewed-by: Florian Fainelli <florian@openwrt.org> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | sky2: fix receive length error in mixed non-VLAN/VLAN trafficstephen hemminger2012-05-012-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older supported chips. Sometimes the VLAN bit is not set for valid VLAN packets and also sometimes the VLAN bit is set for non-VLAN packets that came after a VLAN packet. This results in a receive length error when VLAN hardware tagging is enabled. Fix: Variation on original fix proposed by Mirko. The VLAN information is decoded in the status loop, and can be applied to the received SKB there. This eliminates the need for the separate tag field in the interface data structure. The tag has to be copied and cleared if packet is copied. This version checked out with vlan and normal traffic. Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that is outside scope of this. Reported-by: Mirko Lindner <mlindner@marvell.com> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | sky2: propogate rx hash when packet is copiedstephen hemminger2012-05-011-0/+3
| | | | | | | | | | | | | | | | | | | | When a small packet is received, the driver copies it to a new skb to allow reusing the full size Rx buffer. The copy was propogating the checksum offload but not the receive hash information. The bug is impact was mostly harmless and therefore not observed until reviewing this area of code. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | cxgb3: Don't call cxgb_vlan_mode until q locks are initializedRoland Dreier2012-04-301-46/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver calls cxgb_vlan_mode() from init_one(). This calls into synchronize_rx(), which locks all the q locks, but the q locks are not initialized until cxgb_up() -> setup_sge_qsets(). So move the call to cxgb_vlan_mode() into cxgb_up(), after the call to setup_sge_qsets(). We also move the body of these functions up higher to avoid having to a forward declaration. This was found because of the lockdep warning: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 323, comm: work_for_cpu Not tainted 3.4.0-rc5 #28 Call Trace: [<ffffffff8106e767>] register_lock_class+0x108/0x2d0 [<ffffffff8106ff42>] __lock_acquire+0xd3/0xd06 [<ffffffff81070fd0>] lock_acquire+0xbf/0xfe [<ffffffff813862a6>] _raw_spin_lock_irq+0x36/0x45 [<ffffffffa01e71aa>] cxgb_vlan_mode+0x96/0xcb [cxgb3] [<ffffffffa01f90eb>] init_one+0x8c4/0x980 [cxgb3] [<ffffffff811fcbf0>] local_pci_probe+0x3f/0x70 [<ffffffff81042206>] do_work_for_cpu+0x10/0x22 [<ffffffff810482de>] kthread+0xa1/0xa9 [<ffffffff8138e234>] kernel_thread_helper+0x4/0x10 Contrary to what lockdep says, the code is not fine: we are locking an uninitialized spinlock. Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'master' of ↵David S. Miller2012-04-303-6/+8
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net
| * | ixgbe: fix calling skb_put on nonlinear skb assertion bugYi Zou2012-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the support to bounce buffer added, the skb is coming as nonlinear in the case of non-DDPed data frames for FCoE, which is mostly ok as the FCoE stack would take care of that. However, for target mode, we have to set the FC CRC and FC EOF field to allow the protocol stack to not drop the frame for the last data frame of that sequence. So fix this by linearizing the skb first before doing skb_put(). Signed-off-by: Yi Zou <yi.zou@intel.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | ixgbe: Fix a memory leak in IEEE DCBAlexander Duyck2012-04-301-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver was freeing memory in shutdown instead of remove. As a result we were leaking memory if IEEE DCB was enabled and we loaded/unloaded the driver. This change moves the freeing of the memory into the remove routine where it belongs. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | igbvf: fix the bug when initializing the igbvfSamuel Liao2012-04-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Maybe it's a typo, but it cause that igbvf can't be initialized successfully. Set perm_addr value using valid dev_addr, although which is equal to hw.mac.addr. Signed-off-by: Samuel Liao <samuelliao@tencent.com> Signed-off-by: Shan Wei <davidshan@tencent.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | smsc75xx: enable mac to detect speed/duplex from phySteve Glendinning2012-04-301-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch sets the automatic speed and duplex detection bits in MAC_CR to enable the mac to determine its speed automatically from the phy. Note this must be done BEFORE the receiver or transmitter is enabled. Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | smsc75xx: declare smsc75xx's MII as GMII capableSteve Glendinning2012-04-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | also explicitly set the phy to advertise 1000 speeds Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | smsc75xx: fix phy interrupt acknowledgeSteve Glendinning2012-04-301-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | smsc75xx phy interrupt acknowledge needs an mdio_write to clear PHY_INT_SRC instead of just a read like in smsc95xx. Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | smsc75xx: fix phy init reset loopSteve Glendinning2012-04-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | fix bug in phy_init loop that was ignoring BMCR reset bit, akin to smsc95xx's d946092000698fd204d82a9d239103c656fb63bf Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | smsc75xx: add more information to register io failure warningsSteve Glendinning2012-04-301-2/+2
| | | | | | | | | | | | | | | | | | Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | smsc75xx: fix mdio reads and writesSteve Glendinning2012-04-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | smsc75xx needs MII_ACCESS_BUSY to be set to correctly trigger mdio I/O. Note smsc75xx is different from smsc95xx in this regard. Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | smsc75xx: mark link down on startup and let PHY interrupt deal with carrier ↵Steve Glendinning2012-04-301-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changes This patch fixes the same issue as reported on smsc95xx, where the usb device is connected with no ethernet cable plugged-in. Without this patch sysfs reports the cable as present flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier 1 while it's not: flag@flag-desktop:~$ sudo mii-tool eth0 eth0: no link Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | smsc95xx: mark link down on startup and let PHY interrupt deal with carrier ↵Paolo Pisati2012-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changes Without this patch sysfs reports the cable as present flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier 1 while it's not: flag@flag-desktop:~$ sudo mii-tool eth0 eth0: no link Tested on my Beagle XM. v2: added mantainer to the list of recipient Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | dl2k: Clean up rio_ioctlJeff Mahoney2012-04-262-50/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dl2k driver's rio_ioctl call has a few issues: - No permissions checking - Implements SIOCGMIIREG and SIOCGMIIREG using the SIOCDEVPRIVATE numbers - Has a few ioctls that may have been used for debugging at one point but have no place in the kernel proper. This patch removes all but the MII ioctls, renumbers them to use the standard ones, and adds the proper permission check for SIOCSMIIREG. We can also get rid of the dl2k-specific struct mii_data in favor of the generic struct mii_ioctl_data. Since we have the phyid on hand, we can add the SIOCGMIIPHY ioctl too. Most of the MII code for the driver could probably be converted to use the generic MII library but I don't have a device to test the results. Reported-by: Stephan Mueller <stephan.mueller@atsec.com> Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'master' of ↵David S. Miller2012-04-262-47/+54
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net
| * | e1000e: Fix default interrupt throttle rate not set in NIC HWJeff Kirsher2012-04-241-46/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the original patch from Ying Cai <ycai@google.com> This change ensures that the itr/itr_setting adjustment logic is used, even for the default/compiled-in value. Context: When we changed the default InterruptThrottleRate value from default (3 = dynamic mode) to 8000 for example, only adapter->itr_setting (which controls interrupt coalescing mode) was set to 8000, but adapter->itr (which controls the value set in NIC register) was not updated accordingly. So from ethtool, it seemed the interrupt throttling is enabled at 8000 intr/s, but the NIC actually was running in dynamic mode which has lower CPU efficiency especially when throughput is not high. CC: Ying Cai <ycai@google.com> CC: David Decotigny <david.decotigny@google.com> Signed-off-by: Jeff Kirsher <jeffrey.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
| * | e1000e: MSI interrupt test failed, using legacy interruptPrasanna S Panchamukhi2012-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following logs where seen on Systems with multiple NICs, while using MSI interrupts as shown below: Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0d.0: lan0_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: wan0_1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: lan0_1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:32 (none) user.warn kernel: 0000:40:0e.0: wan4_0: MSI interrupt test failed, using legacy interrupt. Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0e.0: wan1_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0e.0: lan1_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: wan2_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: lan2_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: wan3_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: lan3_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0e.0: lan4_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: wan5_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: lan5_0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX This patch fixes this problem by increasing the msleep from 50 to 100. Signed-off-by: Prasanna S Panchamukhi <ppanchamukhi@riverbed.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ehea: fix promiscuous modeThadeu Lima de Souza Cascardo2012-04-261-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a4910b744486254cfa61995954c118fb2283c4fd has broken promiscuous mode, which is never set. port->promisc just reflects the last setting of PROMISCUOUS mode to avoid doing an extra hypercall when it's already set. However, since it may fail because of hypervisor permissions, we should still respect the multicast settings and not simply exit after setting promiscuous mode. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Cc: Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | ehea: fix allmulticast supportThadeu Lima de Souza Cascardo2012-04-262-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a bug in the mask of regtype parameter for registering a multicast filter. It was ignoring the scope bit, which was wrongly being used for all filters. The SCOPE_ALL value adds a filter that allows all multicast packets and ignores the MAC parameter, just what allmulticast needs. The normals filters, however, should not use SCOPE_ALL. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | Merge branch 'for-davem' of ↵David S. Miller2012-04-2517-41/+105
|\ \ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
| * \ \ Merge branch 'master' of ↵John W. Linville2012-04-2517-41/+105
| |\ \ \ | | |/ / | |/| / | | |/ git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
| | * iwlwifi: use correct released ucode versionMeenakshi Venkataraman2012-04-244-18/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Cc: stable@vger.kernel.org #3.3+ Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * iwlwifi: fix hardware queue programmingJohannes Berg2012-04-242-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * brcmsmac: "INTERMEDIATE but not AMPDU" only when tracingEldad Zack2012-04-231-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I keep getting the following messages on the log buffer: [ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU From the code comment I understand that this something that can - and does, quite frequently - happen. Signed-off-by: Eldad Zack <eldad@fogrefinery.com> Acked-by: Franky Lin<frankyl@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * rtlwifi: Fix oops on unloadLarry Finger2012-04-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58> Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by: Dave Airlie <airlied@gmail.com> Tested-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ipw2200: Fix race condition in the command completion acknowledgeStanislav Yakovlev2012-04-231-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Cc: stable@kernel.org Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * iwlwifi: do not nulify ctx->vif on resetStanislaw Gruszka2012-04-232-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ath9k: fix tx power settings for AR9287Gabor Juhos2012-04-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'ath9k_hw_update_regulatory_maxpower' helper function has been introduced by commit a55f858852e4345d0a31af593c46738ca8614bff (ath9k_hw: Cleanup TX power calculation for AR9287). Updating of the max_power_level value has been moved into the helper function in that change, however the removed code from 'ath9k_hw_ar9287_set_txpower' has not been replaced with a call of the new helper function. Due to that missing call, retrieving tx power for 2x2 and 3x3 chainmask is not handled properly. During the calculation of the tx power for 2x2 and 3x3 chainmasks the values are reduced. Those reductions must be compensated during retrieving. Fix this by adding the missing call of the helper function. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Acked-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ath9k: add an extra boolean parameter to ath9k_hw_apply_txpowerGabor Juhos2012-04-235-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to unifying regulatory limit handling commit ca2c68cc7bc80fc4504fb420df04cce99c9ee6ec (ath9k_hw: clean up tx power handling) introduced a new helper function 'ath9k_hw_apply_txpower', and the direct calls of 'ah->eep_ops->set_txpower' has been replaced by a call of the helper function. This caused a change in the behaviour of the 'ath9k_hw_set_txpowerlimit' function. The purpose of that function is to calculate and store the rate txpower table and the regulatory limit without touching the hardware registers. Before the commit, the 'test' parameter of the function was passed to the 'ah->eep_ops->set_txpower'. Now the calling of the 'set_txpower' function happens indirectly through 'ath9k_hw_apply_txpower', so the 'test' argument of the 'set_txpower' is always 'false'. This patch restores the original behaviour of 'ath9k_hw_set_txpowerlimit' by adding a new argument to 'ath9k_hw_apply_txpower.' Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | tg3: Avoid panic from reserved statblk field accessMatt Carlson2012-04-251-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When RSS is enabled, interrupt vector 0 does not receive any rx traffic. The rx producer index fields for vector 0's status block should be considered reserved in this case. This patch changes the code to respect these reserved fields, which avoids a kernel panic when these fields take on non-zero values. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | tlan: add cast needed for proper 64 bit operationBenjamin Poirier2012-04-251-1/+1
|/ / | | | | | | | | | | | | | | Changes this beauty into a statement that actually has an effect on amd64. Tested-by: Per Jessen <per@opensuse.org> Signed-off-by: Benjamin Poirier <bpoirier@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-27 12:15:45 +0000