linux-stable.git/drivers/net, branch v3.2.21

iwlwifi: disable the buggy chain extension feature in HW

2012-06-19T22:18:17+00:00

commit d012d04e4d6312ea157b6cf19e9689af934f5aa7 upstream.

This feature has been reported to be buggy and enabled by
default. We therefore need to disable it manually.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2 as instructed: pass bus(trans) to iwl_write_prph()]
Signed-off-by: Ben Hutchings

iwlwifi: use correct supported firmware for 6035 and 6000g2

2012-06-19T22:18:17+00:00

commit d2c8b15d0cb486f4938ba7f2af349d9d1220cb10 upstream.

My patch

   iwlwifi: use correct released ucode version

did not correctly report supported firmware
for the 6035 device. This patch fixes it. The
minimum supported firmware version for 6035
is v6.

Also correct the minimum supported firmware
version for the 6000g2 series of devices.

Signed-off-by: Meenakshi Venkataraman 
Reviewed-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2:
 - adjust context
 - make IWL_DEVICE_6035 identical for IWL_DEVICE_6030 except for the
   ucode_api_* fields]
Signed-off-by: Ben Hutchings

net: sierra_net: device IDs for Aircard 320U++

2012-06-19T22:18:15+00:00

commit dd03cff23d694cfb0fdae80cb618e7ced05ea696 upstream.

Adding device IDs for Aircard 320U and two other devices
found in the out-of-tree version of this driver.

Cc: linux@sierrawireless.com
Cc: Autif Khan 
Cc: Tom Cassidy 
Signed-off-by: Bjørn Mork 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

iwlwifi: unregister LEDs if mac80211 registration fails

2012-06-19T22:18:13+00:00

commit 0e1fa7ef25004b9c1a14147bce61c15c2f1c6744 upstream.

Otherwise the LEDs stick around and cause issues the
next time around since they're still there but not
really hooked up.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

iwlwifi: disable WoWLAN if !CONFIG_PM_SLEEP

2012-06-19T22:18:12+00:00

commit fcb6ff5e2cb83e1de10631f6621f45ca3401bf61 upstream.

If CONFIG_PM_SLEEP is disabled, then iwlwifi doesn't
support suspend/resume handlers and thus mac80211
(correctly) refuses advertising WoWLAN. Disable
WoWLAN in the driver in this case.

Reported-by: Sebastian Kemper 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

rt2x00: use atomic variable for seqno

2012-06-19T22:18:12+00:00

commit e5851dac2c95af7159716832300b9f50c62c648e upstream.

Remove spinlock as atomic_t can be used instead. Note we use only 16
lower bits, upper bits are changed but we impilcilty cast to u16.

This fix possible deadlock on IBSS mode reproted by lockdep:

=================================
[ INFO: inconsistent lock state ]
3.4.0-wl+ #4 Not tainted
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/u:2/30374 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&intf->seqlock)->rlock){+.?...}, at: [] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
{IN-SOFTIRQ-W} state was registered at:
  [] __lock_acquire+0x47b/0x1050
  [] lock_acquire+0x84/0xf0
  [] _raw_spin_lock+0x33/0x40
  [] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
  [] rt2x00queue_write_tx_frame+0x1a/0x300 [rt2x00lib]
  [] rt2x00mac_tx+0x7f/0x380 [rt2x00lib]
  [] __ieee80211_tx+0x1b3/0x300 [mac80211]
  [] ieee80211_tx+0x105/0x130 [mac80211]
  [] ieee80211_xmit+0xad/0x100 [mac80211]
  [] ieee80211_subif_start_xmit+0x2d9/0x930 [mac80211]
  [] dev_hard_start_xmit+0x307/0x660
  [] sch_direct_xmit+0xa1/0x1e0
  [] dev_queue_xmit+0x183/0x730
  [] neigh_resolve_output+0xfa/0x1e0
  [] ip_finish_output+0x24a/0x460
  [] ip_output+0xb7/0x100
  [] ip_local_out+0x20/0x60
  [] igmpv3_sendpack+0x4f/0x60
  [] igmp_ifc_timer_expire+0x29f/0x330
  [] run_timer_softirq+0x15c/0x2f0
  [] __do_softirq+0xae/0x1e0
irq event stamp: 18380437
hardirqs last  enabled at (18380437): [] __slab_alloc.clone.3+0x67/0x5f0
hardirqs last disabled at (18380436): [] __slab_alloc.clone.3+0x33/0x5f0
softirqs last  enabled at (18377616): [] __do_softirq+0x123/0x1e0
softirqs last disabled at (18377611): [] do_softirq+0x9d/0xe0

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&intf->seqlock)->rlock);
  
    lock(&(&intf->seqlock)->rlock);

 *** DEADLOCK ***

4 locks held by kworker/u:2/30374:
 #0:  (wiphy_name(local->hw.wiphy)){++++.+}, at: [] process_one_work+0x109/0x3f0
 #1:  ((&sdata->work)){+.+.+.}, at: [] process_one_work+0x109/0x3f0
 #2:  (&ifibss->mtx){+.+.+.}, at: [] ieee80211_ibss_work+0x1b/0x470 [mac80211]
 #3:  (&intf->beacon_skb_mutex){+.+...}, at: [] rt2x00queue_update_beacon+0x24/0x50 [rt2x00lib]

stack backtrace:
Pid: 30374, comm: kworker/u:2 Not tainted 3.4.0-wl+ #4
Call Trace:
 [] print_usage_bug+0x1f6/0x220
 [] mark_lock+0x2c2/0x300
 [] ? check_usage_forwards+0xc0/0xc0
 [] __lock_acquire+0x4bc/0x1050
 [] ? __kmalloc_track_caller+0x1c0/0x1d0
 [] ? copy_skb_header+0x26/0x90
 [] lock_acquire+0x84/0xf0
 [] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
 [] _raw_spin_lock+0x33/0x40
 [] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
 [] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
 [] rt2x00queue_update_beacon_locked+0x5f/0xb0 [rt2x00lib]
 [] rt2x00queue_update_beacon+0x2d/0x50 [rt2x00lib]
 [] rt2x00mac_bss_info_changed+0x1ca/0x200 [rt2x00lib]
 [] ? rt2x00mac_remove_interface+0x70/0x70 [rt2x00lib]
 [] ieee80211_bss_info_change_notify+0xe0/0x1d0 [mac80211]
 [] __ieee80211_sta_join_ibss+0x3b8/0x610 [mac80211]
 [] ? mark_held_locks+0x64/0xc0
 [] ? virt_efi_query_capsule_caps+0x12/0x50
 [] ieee80211_sta_join_ibss+0xf9/0x140 [mac80211]
 [] ieee80211_ibss_work+0x416/0x470 [mac80211]
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? skb_dequeue+0x4b/0x70
 [] ieee80211_iface_work+0x13f/0x230 [mac80211]
 [] ? process_one_work+0x109/0x3f0
 [] process_one_work+0x185/0x3f0
 [] ? process_one_work+0x109/0x3f0
 [] ? ieee80211_teardown_sdata+0xa0/0xa0 [mac80211]
 [] worker_thread+0x116/0x270
 [] ? manage_workers+0x1e0/0x1e0
 [] kthread+0x84/0x90
 [] ? __init_kthread_worker+0x60/0x60
 [] kernel_thread_helper+0x6/0x10

Signed-off-by: Stanislaw Gruszka 
Acked-by: Helmut Schaa 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

can: c_can: fix race condition in c_can_open()

2012-06-19T22:18:10+00:00

commit f461f27a4436dbe691908fe08b867ef888848cc3 upstream.

Fix the issue of C_CAN interrupts getting disabled forever when canconfig
utility is used multiple times. According to NAPI usage we disable all
the hardware interrupts in ISR and re-enable them in poll(). Current
implementation calls napi_enable() after hardware interrupts are enabled.
If we get any interrupts between these two steps then we do not process
those interrupts because napi is not enabled. Mostly these interrupts
come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable()
happens before HW interrupts enabled then c_can_poll() function will be
called eventual re-enabling.

This patch moves the napi_enable() call before interrupts enabled.

Signed-off-by: AnilKumar Ch 
Acked-by: Wolfgang Grandegger 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

can: c_can: fix an interrupt thrash issue with c_can driver

2012-06-19T22:18:09+00:00

commit 148c87c89e1a8863d3d965179f3ab1a06490569e upstream.

This patch fixes an interrupt thrash issue with c_can driver.

In c_can_isr() function interrupts are disabled and enabled only in
c_can_poll() function. c_can_isr() & c_can_poll() both read the
irqstatus flag. However, irqstatus is always read as 0 in c_can_poll()
because all C_CAN interrupts are disabled in c_can_isr(). This causes
all interrupts to be re-enabled in c_can_poll() which in turn causes
another interrupt since the event is not really handled. This keeps
happening causing a flood of interrupts.

To fix this, read the irqstatus register in isr and use the same cached
value in the poll function.

Signed-off-by: AnilKumar Ch 
Acked-by: Wolfgang Grandegger 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

can: c_can: fix "BUG! echo_skb is occupied!" during transmit

2012-06-19T22:18:09+00:00

commit 617caccebe451716df21c069b079d5936ed7b0f3 upstream.

This patch fixes an issue with transmit routine, which causes
"can_put_echo_skb: BUG! echo_skb is occupied!" message when
using "cansequence -p" on D_CAN controller.

In c_can driver, while transmitting packets tx_echo flag holds
the no of can frames put for transmission into the hardware.

As the comment above c_can_do_tx() indicates, if we find any packet
which is not transmitted then we should stop looking for more.
In the current implementation this is not taken care of causing the
said message.

Also, fix the condition used to find if the packet is transmitted
or not. Current code skips the first tx message object and ends up
checking one extra invalid object.

While at it, fix the comment on top of c_can_do_tx() to use the
terminology "packet" instead of "package" since it is more
standard.

Signed-off-by: AnilKumar Ch 
Acked-by: Wolfgang Grandegger 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Ben Hutchings

iwlwifi: don't mess up the SCD when removing a key

2012-06-19T22:18:07+00:00

commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream.

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
The message is the log that was printed is:

Queue 2 stuck for 10000ms

This doesn't seem to fix the higher queues that get stuck
from time to time.

Reviewed-by: Meenakshi Venkataraman 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings