linux/drivers/net, branch v3.2.7

net: enable TC35815 for MIPS again

2012-02-20T20:46:16Z

commit a1728800bed3b93b231d99e97c756f622b9991c2 upstream. 8<---------------------------------------------------------------------- From: Ralf Roesch Date: Wed, 16 Nov 2011 09:33:50 +0100 Subject: net: enable TC35815 for MIPS again TX493[8,9] MIPS SoCs support 2 Ethernet channels of type TC35815 which are connected to the internal PCI controller. And JMR3927 MIPS board has a TC35815 chip on board. These dependencies were lost on movement to drivers/net/ethernet/toshiba. Signed-off-by: Ralf Roesch Signed-off-by: Atsushi Nemoto Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix a RTS/CTS timeout regression

2012-02-20T20:46:15Z

commit 55a2bb4a6d5e8c7b324d003e130fd9aaf33be4e6 upstream. commit adb5066 "ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts" reduced the hardware CTS timeout to the normal values specified by the standard, but it turns out while it doesn't need the same extra time that it needs for the ACK timeout, it does need more than the value specified in the standard, but only for 2.4 GHz. This patch brings the CTS timeout value in sync with the initialization values, while still allowing adjustment for bigger distances. Signed-off-by: Felix Fietkau Reported-by: Seth Forshee Reported-by: Marek Lindner Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: fix a WEP crypto related regression

2012-02-20T20:46:14Z

commit f88373fa47f3ce6590fdfaa742d0ddacc2ae017f upstream. commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag" fixed the interpretation of the KeyMiss flag for keycache based lookups, however WEP encryption uses a static index, so KeyMiss is always asserted for it, even though frames are decrypted properly. Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based lookup was performed. Signed-off-by: Felix Fietkau Reported-by: Laurent Bonnans Reported-by: Jurica Vukadin Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ath9k: Fix kernel panic during driver initilization

2012-02-20T20:46:14Z

commit 07445f688218a48bde72316aed9de4fdcc173131 upstream. all works need to be initialized before ieee80211_register_hw to prevent mac80211 call backs such as drv_start, drv_config getting started. otherwise we would queue/cancel works before initializing them and it leads to kernel panic. this issue can be recreated with the following script in Chrome laptops with AR928X cards, with background scan running (or) Network manager is running while true do sudo modprobe -v ath9k sleep 3 sudo modprobe -r ath9k sleep 3 done EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70 ---[ end trace 4f86d6139a9900ef ]--- Registered led device: ath9k-phy0 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000, irq=16 Kernel panic - not syncing: Fatal exception Pid: 456, comm: wpa_supplicant Tainted: G D 3.0.13 #1 Call Trace: [<81379e21>] panic+0x53/0x14a [<81004a30>] oops_end+0x73/0x81 [<81004b53>] die+0x4c/0x55 [<81002710>] do_trap+0x7c/0x83 [<81002855>] ? do_bounds+0x58/0x58 [<810028cc>] do_invalid_op+0x77/0x81 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1 [<810489ec>] ? sched_clock_cpu+0x81/0x11f [<8103f809>] ? wait_on_work+0xe2/0xf7 [<8137f807>] error_code+0x67/0x6c [<810300d8>] ? wait_consider_task+0x4ba/0x84c [<81040a47>] ? __cancel_work_timer+0xb8/0xe1 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67 [<81040a91>] cancel_work_sync+0xf/0x11 [] ath_set_channel+0x62/0x25c [ath9k] [] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k] [] ath_radio_disable+0x3f1/0x68e [ath9k] [] ieee80211_hw_config+0x111/0x116 [mac80211] [] __ieee80211_recalc_idle+0x919/0xa37 [mac80211] [] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211] [<812dbed8>] __dev_open+0x82/0xab Cc: Gary Morain Cc: Paul Stewart Cc: Vasanthakumar Thiagarajan Tested-by: Mohammed Shafi Shajakhan Signed-off-by: Rajkumar Manoharan Signed-off-by: Mohammed Shafi Shajakhan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

igb: fix vf lookup

2012-02-20T20:46:13Z

commit 0629292117572a60465f38cdedde2f8164c3df0b upstream. Recent addition of code to find already allocated VFs failed to take account that systems with 2 or more multi-port SR-IOV capable controllers might have already enabled VFs. Make sure that the VFs the function is finding are actually subordinate to the particular instance of the adapter that is looking for them and not subordinate to some device that has previously enabled SR-IOV. This is applicable to 3.2+ kernels. Reported-by: David Ahern Signed-off-by: Greg Rose Tested-by: Robert E Garrett Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

ixgbe: fix vf lookup

2012-02-20T20:46:12Z

commit a4b08329c74985e5cc3a44b6d2b2c59444ed8079 upstream. Recent addition of code to find already allocated VFs failed to take account that systems with 2 or more multi-port SR-IOV capable controllers might have already enabled VFs. Make sure that the VFs the function is finding are actually subordinate to the particular instance of the adapter that is looking for them and not subordinate to some device that has previously enabled SR-IOV. This bug exists in 3.2 stable as well as 3.3 release candidates. Reported-by: David Ahern Signed-off-by: Greg Rose Tested-by: Robert E Garrett Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

8139cp: fix missing napi_gro_flush.

2012-02-13T19:16:56Z

commit b189e810619a676e6b931a942a3e8387f3d39c21 upstream. The driver uses __napi_complete and napi_gro_receive. Without it, the driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete. Signed-off-by: Francois Romieu Tested-by: Marin Glibic Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

macvlan: fix a possible use after free

2012-02-03T17:22:19Z

[ Upstream commit 4ec7ac1203bcf21f5e3d977c9818b1a56c9ef40d ] Commit bc416d9768 (macvlan: handle fragmented multicast frames) added a possible use after free in macvlan_handle_frame(), since ip_check_defrag() uses pskb_may_pull() : skb header can be reallocated. Signed-off-by: Eric Dumazet Cc: Ben Greear Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bonding: fix enslaving in alb mode when link down

2012-02-03T17:22:19Z

[ Upstream commit b924551bed09f61b64f21bffe241afc5526b091a ] bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC address. This is done differently for TLB and ALB modes. bond->alb_info.rlb_enabled is used to discriminate between the two modes but this flag may be uninitialized if the slave is being enslaved prior to calling bond_open() -> bond_alb_initialize() on the master. It turns out all the callers of alb_set_slave_mac_addr() pass bond->alb_info.rlb_enabled as the hw parameter. This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and makes the function decide based on the bonding mode instead, which fixes the above problem. Reported-by: Narendra K Signed-off-by: Jiri Bohac Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix PCI-E transport "inta" race

2012-02-03T17:22:07Z

commit b49ba04a3a0382e7314d990707c21094c410425a upstream. When an interrupt comes in, we read the reason bits and collect them into "trans_pcie->inta". This happens with the spinlock held. However, there's a bug resetting this variable -- that happens after the spinlock has been released. This means that it is possible for interrupts to be missed if the reset happens after some other interrupt reasons were already added to the variable. I found this by code inspection, looking for a reason that we sometimes see random commands time out. It seems possible that this causes such behaviour, but I can't say for sure right now since it happens extremely infrequently on my test systems. Signed-off-by: Johannes Berg Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman