linux-toradex.git/drivers/net, branch v3.14.7

iwlwifi: mvm: rs: clear per rate stats when aggregation changes

2014-06-07T17:28:28+00:00

commit b804eeb6649d75caeccbeae9f5623fc7b8bdfdfa upstream.

The per rate stats should be cleared when aggregation state changes
to avoid making rate scale decisions based on throughput figures which
were collected prior to the aggregation state change and are now stale.
While at it make sure any clearing of the per rate stats will get logged.

Signed-off-by: Eyal Shapira 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add rs_rate_scale_clear_tbl_windows helper function

2014-06-07T17:28:28+00:00

commit 3ca71f603bb1a0f55e1ba24618ba45617bc36f70 upstream.

instead of duplicating the same loop multiple times,
use a new function for it.

this will be later used also for clearing other
windows in the table.

Signed-off-by: Eliad Peller 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: disable beacon filtering

2014-06-07T17:28:28+00:00

commit 7bacc782270ff7db3b9f29fa5d24ad2ee1e8e81d upstream.

This feature has been causing trouble - disable it for now.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: BT Coex - fix Look Up Table

2014-06-07T17:28:25+00:00

commit a6bc92803e7f765e02c923cf37c8e280e729642a upstream.

A few entries were wrong and this caused throughput issues.

Fixes: dac94da8dba3 ("iwlwifi: mvm: new BT Coex API")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix setting channel in monitor mode

2014-06-07T17:28:23+00:00

commit 1c4abec0baf25ffb92a28cc99d4231feeaa4d3f3 upstream.

There was a deadlock in monitor mode when we were setting the
channel if the channel was not 1.

======================================================
[ INFO: possible circular locking dependency detected ]
3.14.3 #4 Not tainted
-------------------------------------------------------
iw/3323 is trying to acquire lock:
 (&local->chanctx_mtx){+.+.+.}, at: [] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]

but task is already holding lock:
 (&local->iflist_mtx){+.+...}, at: [] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&local->iflist_mtx){+.+...}:
       [] __lock_acquire+0xb3b/0x13b0
       [] lock_acquire+0xb0/0x1f0
       [] mutex_lock_nested+0x78/0x4f0
       [] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm]
       [] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm]
       [] ieee80211_configure_filter+0x153/0x5f0 [mac80211]
       [] ieee80211_reconfig_filter+0x15/0x20 [mac80211]
       [snip]

-> #1 (&mvm->mutex){+.+.+.}:
       [] __lock_acquire+0xb3b/0x13b0
       [] lock_acquire+0xb0/0x1f0
       [] mutex_lock_nested+0x78/0x4f0
       [] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm]
       [] ieee80211_new_chanctx+0x13e/0x410 [mac80211]
       [] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211]
       [] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211]
       [] ieee80211_do_open+0xe6a/0x15a0 [mac80211]
       [] ieee80211_open+0x59/0x60 [mac80211]
       [snip]

-> #0 (&local->chanctx_mtx){+.+.+.}:
       [] check_prevs_add+0x977/0x980
       [] __lock_acquire+0xb3b/0x13b0
       [] lock_acquire+0xb0/0x1f0
       [] mutex_lock_nested+0x78/0x4f0
       [] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
       [] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
       [] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
       [] __nl80211_set_channel+0x122/0x140 [cfg80211]
       [] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
       [snip]

other info that might help us debug this:

Chain exists of:
  &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&local->iflist_mtx);
                               lock(&mvm->mutex);
                               lock(&local->iflist_mtx);
  lock(&local->chanctx_mtx);

 *** DEADLOCK ***

This deadlock actually occurs:
INFO: task iw:3323 blocked for more than 120 seconds.
      Not tainted 3.14.3 #4
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
iw              D ffff8800c8afcd80  4192  3323   3322 0x00000000
 ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8
 00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80
 ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246
Call Trace:
 [] schedule_preempt_disabled+0x31/0x80
 [] mutex_lock_nested+0x19d/0x4f0
 [] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm]
 [] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm]
 [] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm]
 [] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211]
 [] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211]
 [] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
 [] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
 [] __nl80211_set_channel+0x122/0x140 [cfg80211]
 [] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541

Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: disable interrupts upon PCIe alloc

2014-06-07T17:28:22+00:00

commit 83f7a85f1134c6e914453f5747435415a23d516b upstream.

In case RFKILL is in KILL position, the NIC will issue an
interrupt straight away. This interrupt won't be sent
because it is masked in the hardware.
But if our interrupt service routine is called for another
reason (SHARED_IRQ), then we'll look at the interrupt cause
and service it. This can cause bad things if we are not
ready yet.
Explicitly clean the interrupt cause register to make sure
we won't service anything before we are ready to.

Reported-and-tested-by: Alexander Monakov 
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

e1000e: Fix no connectivity when driver loaded with cable out

2014-06-07T17:28:20+00:00

commit b20a774495671f037e7160ea2ce8789af6b61533 upstream.

In commit da1e2046e5, the flow for enabling/disabling an Si errata
workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem
with iAMT connections dropping on interface down with jumbo frames set.
Part of this change was to move the function call disabling the workaround
to e1000e_down() from the e1000_setup_rctl() function.  The mechanic for
disabling of this workaround involves writing several MAC and PHY registers
back to hardware defaults.

After this commit, when the driver is loaded with the cable out, the PHY
registers are not programmed with the correct default values.  This causes
the device to be capable of transmitting packets, but is unable to recieve
them until this workaround is called.

The flow of e1000e's open code relies upon calling the above workaround to
expicitly program these registers either with jumbo frame appropriate settings
or h/w defaults on 82579 and newer hardware.

Fix this issue by adding logic to e1000_setup_rctl() that not only calls
e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the
workaround, but also calls this function to explicitly disable the workaround
in the case that jumbo frames are not set.

Signed-off-by: Dave Ertman 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Cc: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

brcmsmac: fix deadlock on missing firmware

2014-06-07T17:28:18+00:00

commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream.

When brcm80211 firmware is not installed networking hangs.
A deadlock happens because we call ieee80211_unregister_hw()
from the .start callback of struct ieee80211_ops. When .start
is called we are under rtnl lock and ieee80211_unregister_hw()
tries to take it again.

Function call stack:

dev_change_flags()
	__dev_change_flags()
		__dev_open()
			ASSERT_RTNL() <-- Assert rtnl lock
			ops->ndo_open()

.ndo_open = ieee80211_open,

ieee80211_open()
	ieee80211_do_open()
		drv_start()
			local->ops->start()

.start = brcms_ops_start,

brcms_ops_start()
	brcms_remove()
		ieee80211_unregister_hw()
			rtnl_lock() <-- Here we deadlock

Introduced by:
commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e
("brcmsmac: request firmware in .start() callback")

This patch fixes the bug by removing the call to brcms_remove()
and moves the brcms_request_fw() call to the top of the .start
callback to not initiate anything unless firmware is installed.

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

igb: Unset IGB_FLAG_HAS_MSIX-flag when falling back to msi-only

2014-06-07T17:28:18+00:00

commit b709323d2477614823a38c2f2a9a206e087e28fc upstream.

Prior to cd14ef54d25 (igb: Change to use statically allocated array for
MSIx entries), having msix_entries different from NULL was an indicator
that MSIX is enabled.
In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to
the above patch msix_entries was set to NULL by
igb_reset_interrupt_capability.

However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the
stack gets completly confused:

[   42.659791] ------------[ cut here ]------------
[   42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb()
[   42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
[   42.923253] Modules linked in:
[   42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437
[   43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[   43.119215]  0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108
[   43.208165]  ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8
[   43.297120]  ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008
[   43.386071] Call Trace:
[   43.415303]    [] dump_stack+0x49/0x62
[   43.484174]  [] warn_slowpath_common+0x77/0x91
[   43.556049]  [] ? dev_watchdog+0x15c/0x1fb
[   43.623759]  [] warn_slowpath_fmt+0x41/0x43
[   43.692511]  [] dev_watchdog+0x15c/0x1fb
[   43.758141]  [] ? __netdev_watchdog_up+0x64/0x64
[   43.832091]  [] call_timer_fn+0x17/0x6f
[   43.896682]  [] run_timer_softirq+0x162/0x1a2
[   43.967511]  [] __do_softirq+0xcd/0x1cc
[   44.032104]  [] irq_exit+0x3a/0x48
[   44.091492]  [] smp_apic_timer_interrupt+0x43/0x50
[   44.167525]  [] apic_timer_interrupt+0x6a/0x70
[   44.239392]    [] ? default_idle+0x6/0x8
[   44.310343]  [] arch_cpu_idle+0x13/0x18
[   44.374934]  [] cpu_startup_entry+0xa7/0x101
[   44.444724]  [] start_secondary+0x1b2/0x1b7
[   44.513472] ---[ end trace a5a075fd4e7f854f ]---
[   44.568753] igb 0000:04:00.0 eth0: Reset adapter
[   46.206945] random: nonblocking pool is initialized
[   46.465670] irq 44: nobody cared (try booting with the "irqpoll" option)
[   46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G        W    3.14.0-rc2-mptcp #437
[   46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[   46.716641]  ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d
[   46.805598]  ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400
[   46.894539]  ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8
[   46.983484] Call Trace:
[   47.012714]    [] dump_stack+0x49/0x62
[   47.081585]  [] __report_bad_irq+0x35/0xc1
[   47.149295]  [] note_interrupt+0x16e/0x1ea
[   47.217006]  [] handle_irq_event_percpu+0x116/0x12e
[   47.294075]  [] handle_irq_event+0x33/0x4f
[   47.361787]  [] handle_fasteoi_irq+0x83/0xd1
[   47.431577]  [] handle_irq+0x1f/0x28
[   47.493047]  [] do_IRQ+0x4e/0xd4
[   47.550358]  [] common_interrupt+0x6a/0x6a
[   47.618066]    [] ? default_idle+0x6/0x8
[   47.689016]  [] arch_cpu_idle+0x13/0x18
[   47.753605]  [] cpu_startup_entry+0xa7/0x101
[   47.823397]  [] start_secondary+0x1b2/0x1b7
[   47.892146] handlers:
[   47.919301] [] igb_intr

So, this patch unsets the flag to indicate that we are not using MSIX.
This patch does exactly this: Unsetting the flag when falling back to MSI.

Fixes: cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries)
Cc: Carolyn Wyborny 
Signed-off-by: Christoph Paasch 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

igb: Fix Null-pointer dereference in igb_reset_q_vector

2014-06-07T17:28:18+00:00

commit cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream.

When igb_set_interrupt_capability() calls
igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset),
num_q_vectors has been set but no vector has yet been allocated.

igb_reset_interrupt_capability() will then call igb_reset_q_vector,
which assumes that the vector is allocated. As this is not the case, we
are accessing a NULL-pointer.

This patch fixes it by checking that q_vector is indeed different from
NULL.

Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime)
Cc: Carolyn Wyborny 
Signed-off-by: Christoph Paasch 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman