linux-toradex.git/drivers/net, branch v2.6.33.5

Revert "ath9k: fix lockdep warning when unloading module" on stable kernels

2010-05-26T21:32:12+00:00

Johannes' patch 34e8950 titled:

	mac80211: allow station add/remove to sleep

changed the way mac80211 adds and removes peers. The new
sta_add() / sta_remove() callbacks allowed the driver callbacks
to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
via the patch 4ca7786 titled:

	ath9k: convert to new station add/remove callbacks

but this patch forgot to address a change in locking issue which
Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
build includes code for the 802.11 subsystem for 2.6.34 though so did
already have the above two patches (ath9k_sta_remove() on his trace),
the 2.6.33 kernel did not however have these two patches. Ming eventually
cured his lockdep warnign via the patch a9f042c titled:

	ath9k: fix lockdep warning when unloading module

This went in to 2.6.34 and although it was not marked as a stable
fix it did get trickled down and applied on both 2.6.33 and 2.6.32.

In review, the culprits:

	mac80211: allow station add/remove to sleep
git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
v2.6.34-rc1~233^2~49^2~107

	ath9k: convert to new station add/remove callbacks
git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
v2.6.34-rc1~233^2~49^2~10

	ath9k: fix lockdep warning when unloading module

This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).

git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
v2.6.34-rc2~48^2~77^2~7
git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
v2.6.33.2~125
git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
v2.6.32.11~79

The patch titled "ath9k: fix lockdep warning when unloading module"
should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
actually ended up causing the following warning:

ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
phy0: device now idle
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
Hardware name: 7660A14
Modules linked in: ath9k(-) mac80211 ath cfg80211 
Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
Call Trace:
 [] warn_slowpath_common+0x78/0xb0
 [] warn_slowpath_null+0xf/0x20
 [] local_bh_enable_ip+0x7b/0xa0
 [] _spin_unlock_bh+0x14/0x20
 [] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
 [] ath9k_sta_notify+0x57/0xb0 [ath9k]
 [] __sta_info_unlink+0x15a/0x260 [mac80211]
 [] sta_info_unlink+0x38/0x60 [mac80211]
 [] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
 [] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
 [] ieee80211_deauth+0x19/0x20 [mac80211]
 [] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [] ? init_object+0x50/0x90
 [] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
 [] notifier_call_chain+0x47/0x90
 [] raw_notifier_call_chain+0x11/0x20
 [] call_netdevice_notifiers+0x16/0x20
 [] dev_close+0x4d/0xa0
 [] rollback_registered+0x48/0x120
 [] unregister_netdevice+0x1d/0x70
 [] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
 [] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
 [] ath_detach+0x8e/0x180 [ath9k]
 [] ath_cleanup+0x11/0x50 [ath9k]
 [] ath_pci_remove+0x1c/0x20 [ath9k]
 [] pci_device_remove+0x32/0x60
 [] __device_release_driver+0x53/0xb0
 [] driver_detach+0xc8/0xd0
 [] bus_remove_driver+0x85/0xe0
 [] driver_unregister+0x5a/0x90
 [] pci_unregister_driver+0x40/0xb0
 [] ath_pci_exit+0x10/0x20 [ath9k]
 [] ath9k_exit+0x9/0x2a [ath9k]
 [] sys_delete_module+0x1a8/0x270
 [] ? up_read+0x9/0x10
 [] system_call_fastpath+0x16/0x1b
---[ end trace fad957019ffdd40b ]---
phy0: Removed STA 00:22:6b:56:fd:e8
phy0: Destroyed STA 00:22:6b:56:fd:e8
wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
ath9k 0000:16:00.0: PCI INT A disabled

The original lockdep fixed an issue where due to the new changes
the driver was not disabling the bottom halves but it is incorrect
to do this on the older kernels since IRQs are already disabled.

Cc: Ming Lei 
Cc: Johannes Berg 
Cc: John W. Linville 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: clear all the stop_queue flag after load firmware

2010-05-26T21:32:11+00:00

commit a9e10fb9b1c6ad16e73cf2656951fce3a817611e upstream.

All the queues are awake and ready to use after loading firmware,
for firmware reload case, if any queues was stopped before
reload, mac80211 will wake those queues after restart hardware, so make
sure all the flag used to keep track of the queue status are
reset correctly.

Signed-off-by: Wey-Yi Guy 
Signed-off-by: Reinette Chatre 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: check for aggregation frame and queue

2010-05-26T21:32:11+00:00

commit 45d427001b5eec03cecaacddb53c73af46bb263e upstream.

Error checking for aggregation frames should go into aggregation queue,
if aggregation queue not available, use legacy queue instead.
Also make sure the aggregation queue is available to activate,
if driver and mac80211 is out-of-sync, try to disable the queue and
sync-up with mac80211.

Signed-off-by: Wey-Yi Guy 
Signed-off-by: Reinette Chatre 
Signed-off-by: Greg Kroah-Hartman

WAN: flush tx_queue in hdlc_ppp to prevent panic on rmmod hw_driver.

2010-05-12T22:03:02+00:00

[ Upstream commit 31f634a63de7068c6a5dcb0d7b09b24b61a5cf88 ]

tx_queue is used as a temporary queue when not allowed to queue skb
directly to the hw device driver (which may sleep). Most paths flush
it before returning, but ppp_start() currently cannot. Make sure we
don't leave skbs pointing to a non-existent device.

Thanks to Michael Barkowski for reporting this problem.

Signed-off-by: Krzysztof Hałasa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tun: orphan an skb on tx

2010-05-12T22:03:00+00:00

[ Upstream commit 0110d6f22f392f976e84ab49da1b42f85b64a3c5 ]

The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed. This happens because
tun/tap devices can hang on to skbs undefinitely.

As noted by Herbert, possible solutions include a timeout followed by a
copy/change of ownership of the skb, or always copying/changing
ownership if we're going into a hostile device.

This patch implements the second approach.

Note: one issue still remaining is that since skbs
keep reference to tun socket and tun socket has a
reference to tun device, we won't flush backlog,
instead simply waiting for all skbs to get transmitted.
At least this is not user-triggerable, and
this was not reported in practice, my assumption is
other devices besides tap complete an skb
within finite time after it has been queued.

A possible solution for the second issue
would not to have socket reference the device,
instead, implement dev->destructor for tun, and
wait for all skbs to complete there, but this
needs some thought, probably too risky for 2.6.34.

Signed-off-by: Michael S. Tsirkin 
Tested-by: Yan Vugenfirer 
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

cdc_ether: fix autosuspend for mbm devices

2010-05-12T22:02:56+00:00

[ Upstream commit 55964d72d63b15df49a5df11ef91dc8601270815 ]

Autosuspend works until you bring the wwan interface up, then the
device does not enter autosuspend anymore.

The following patch fixes the problem by setting the .manage_power
field in the mbm_info struct to the same as in the cdc_info struct
(cdc_manager_power).

Signed-off-by: Torgny Johansson 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bnx2: Fix lost MSI-X problem on 5709 NICs.

2010-05-12T22:02:55+00:00

commit c441b8d2cb2194b05550a558d6d95d8944e56a84 upstream.

It has been reported that under certain heavy traffic conditions in MSI-X
mode, the driver can lose an MSI-X vector causing all packets in the
associated rx/tx ring pair to be dropped.  The problem is caused by
the chip dropping the write to unmask the MSI-X vector by the kernel
(when migrating the IRQ for example).

This can be prevented by increasing the GRC timeout value for these
register read and write operations.

Thanks to Dell for helping us debug this problem.

Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Fix INTx fallback when MSI fails

2010-05-12T22:02:53+00:00

commit dc8bf1b1a6edfc92465526de19772061302f0929 upstream.

tg3: Fix INTx fallback when MSI fails

MSI setup changes the value of irq_vec in struct tg3 *tp.
This attribute must be taken into account and restored before
we try to do a new request_irq for INTx fallback.

In powerpc, the original code was leading to an EINVAL return within
request_irq, because the driver was trying to use the disabled MSI
virtual irq number instead of tp->pdev->irq.

Signed-off-by: Andre Detsch 
Acked-by: Michael Chan 
Signed-off-by: David S. Miller 
Cc: Brandon Philips 
Signed-off-by: Greg Kroah-Hartman

ath9k: reorder ieee80211_free_hw behind ath9k_uninit_hw to avoid oops

2010-05-12T22:02:52+00:00

This code only exists in 2.6.33 -- 2.6.32 and 2.6.34 are not affected.

Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

r8169: more broken register writes workaround

2010-05-12T22:02:52+00:00

commit 908ba2bfd22253f26fa910cd855e4ccffb1467d0 upstream.

78f1cd02457252e1ffbc6caa44a17424a45286b8 ("fix broken register writes")
does not work for Al Viro's r8169 (XID 18000000).

Signed-off-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman