iwlwifi: unlock on error path

We introduced a lock here in ff1ffb850b ("iwlwifi: fix dynamic
loading").  But we missed an error path which needs an unlock.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless

Conflicts:
drivers/net/wireless/ath/ath9k/main.c
net/bluetooth/hci_event.c

Merge branch 'for-upstream' of git://git./linux/kernel/git/bluetooth/bluetooth-next

ath9k_hw: remove MCI_STATE_SET_BT_SLEEP

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: remove MCI_STATE_CONT_* state

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: remove MCI_STATE_BT

remove MCI_STATE_BT and use bt_state instead.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: remove p_data argument from ar9003_mci_state

As p_data is unuse, lets remove it from ar9003_mci_state.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: remove MCI_STATE_NEED_FLUSH_BT_INFO

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: remove MCI_STATE_SEND_WLAN_CHANNELS

Add a MCI util function to send wlan channel info to BT.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: add utility function to set BT version

Add a utility function to set bluetooth version and remove
MCI_STATE_SET_BT_COEX_VERSION.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: cleanup MCI gpm offset state

Add utility functions to get and test GPM offset and
remove MCI_STATE*_GPM_OFFSET states.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Fix softlockup in AR9485

steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

Call Trace:
[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
[<ffffffff810744fe>] process_one_work+0x11e/0x470
[<ffffffff8107530f>] worker_thread+0x15f/0x360
[<ffffffff810751b0>] ? manage_workers+0x230/0x230
[<ffffffff81079af3>] kthread+0x93/0xa0
[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff815fd3a0>] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142

Reported-by: Rolf Offermanns <rolf.offermanns@gmx.net>
Cc: stable@vger.kernel.org
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: fix btcoex duty cycle

* Reset duty cycle before updating btcoex scheme. Otherwise duty cycle
  reaches max limit and never be reduced again
* Adjust duty cycle with proper BDR profile value

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: defer btcoex scheme update

As btcoex scheme updation might sleep, remove the function call
from tasklet context and queue it up as a separate work.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: keep btcoex period in milliseconds

btcoex periord is converted into micro seconds during initialization
and converted back to milli seconds while starting timer. As MCI code
handles btcoex period in msec, lets keep the btcoex timer in msec and
convert them into other form whenever needed.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: simplify btcoex profile management

This patch simplifies profile management utility functions.

* Separate find_profile from add/del functions
* Return correct values when the profile list is empty or
  profile is ot found
* flush the profiles when there are entries in the list

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: process MCI interrupts only when btcoex is enabled

let us process MCI interrupts only when BTCOEX is enabled to avoid
processing bogus interrupts.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: program OBS register only when MCI is disabled

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: fix incorrect LNA register settings

After a full reset, mci_reset will put LNA update to the setting
for 2G mode. Those registers need to be forced to update when
the channel is in 5G.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: check GPM HW write pointer before chip reset

Both "MAC Warm Reset" and "MCI Reset Rx" will reset GPM HW write_ptr.
We should check software cached write_ptr against HW write_ptr before
reset. Otherwise the pending DMA data will be lost.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Fix AR9462 power consumption on idle associated

The HW statemachine is sometimes found stuck in the state
WL_LNA_CTRL_DISABLE when BT is in sleep, which will cause
TX_HOLD always asserted and resmgr stuck in PENDING_TX state

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: restore power state on set channel failure

Not doing so, could cause imbalance in powersave count.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: choose legacy rate as last rate of MRR series

Choose legacy rate as the last rate of Multi Rate Retry series
if and only if the last selected rate is MCS and having higher
PER rate. The current code fills a legacy rate as last one even
though the previous rates in the series are having good PER value.
This could limit the aggregation that affects the uplink performance.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Update initvals for AR9462

Adjust quick_drop value in the baseband AGC register to
improve RX in HT20 mode.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

brcmfmac: expose sdio internal counters in debugfs

The structure brcmf_sdio contains a number of counters that are useful
for debugging. These were not available in user-space. This patch
exposes them in debugfs under the filename 'counters'.

Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

brcmfmac: add debugfs helper functions

This patch adds debugfs support to brcmfmac. It provide helper functions
to setup the debugfs folder structure for the driver, which has following
hierarchy:

<debugfs_mount>/brcmfmac/<dev_name>/

ie.: /sys/kernel/debug/brcmfmac/mmc0:0001:2/

The new source file provides functions to create and remove the two
folders and a function to retrieve the device-specific folder so files
can be created in it.

Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

brcmsmac: fix smatch warning found in ampdu.c

This patch fixes potential NULL pointer dereference in ampdu. This
was found running smatch static code checker. Smatch warning says:

drivers/net/wireless/brcm80211/brcmsmac/ampdu.c:741 brcms_c_sendampdu()
 warn: variable dereferenced before check 'p'

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

brcmsmac: remove brcms_set_hint() function

The function brcms_set_hint() does not add any functionality
so regulatory_hint() can be called directly. The error value
has been removed from the message when regulatory_hint() fails.

Reported-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Fix softlockup in AR9485

steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

Call Trace:
[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
[<ffffffff810744fe>] process_one_work+0x11e/0x470
[<ffffffff8107530f>] worker_thread+0x15f/0x360
[<ffffffff810751b0>] ? manage_workers+0x230/0x230
[<ffffffff81079af3>] kthread+0x93/0xa0
[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
[<ffffffff815fd3a0>] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142

Reported-by: Rolf Offermanns <rolf.offermanns@gmx.net>
Cc: stable@vger.kernel.org [3.0+]
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'for-john' of git://git./linux/kernel/git/jberg/mac80211

mac80211: stop polling in disassociation

Stop connection monitor poll during disassociation.
This clears the polling flags and if a scan was
deferred it will be run.

Without this fix, if a scan was deferred due to
connection monitoring while disassociation happens,
this scan blocks further scan requests until interface
down/up which causes problems connecting to another AP.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: check sdata_running on ieee80211_set_bitrate_mask

Otherwise, we might call the driver callback before
the interface was uploaded.

Solves the following warning:
WARNING: at net/mac80211/driver-ops.h:12 ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]()
wlan0:  Failed check-sdata-in-driver check, flags: 0x0
Modules linked in: wlcore_sdio wl12xx wl18xx wlcore mac80211 cfg80211 [last unloaded: cfg80211]
[<c001b964>] (unwind_backtrace+0x0/0x12c) from [<c0495550>] (dump_stack+0x20/0x24)
[<c0495550>] (dump_stack+0x20/0x24) from [<c003ee28>] (warn_slowpath_common+0x5c/0x74)
[<c003ee28>] (warn_slowpath_common+0x5c/0x74) from [<c003eefc>] (warn_slowpath_fmt+0x40/0x48)
[<c003eefc>] (warn_slowpath_fmt+0x40/0x48) from [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211])
[<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]) from [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211])
[<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211]) from [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8)
[<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8) from [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0)
[<c03e9164>] (netlink_rcv_skb+0x5c/0xc0) from [<c03e9ce0>] (genl_rcv+0x28/0x34)
[<c03e9ce0>] (genl_rcv+0x28/0x34) from [<c03e8e74>] (netlink_unicast+0x158/0x234)
[<c03e8e74>] (netlink_unicast+0x158/0x234) from [<c03e93e0>] (netlink_sendmsg+0x218/0x298)
[<c03e93e0>] (netlink_sendmsg+0x218/0x298) from [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0)
[<c03b4e5c>] (sock_sendmsg+0xa4/0xc0) from [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254)
[<c03b5af4>] (__sys_sendmsg+0x1d8/0x254) from [<c03b5ca8>] (sys_sendmsg+0x4c/0x70)
[<c03b5ca8>] (sys_sendmsg+0x4c/0x70) from [<c0013980>] (ret_fast_syscall+0x0/0x3c)

Note that calling the driver can also result
in undefined behaviour since it doesn't have
to deal with calls while down.

Signed-off-by: Eliad Peller <eliad@wizery.com>
[removed timestamps, added note - Johannes]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: fix potential deadlock in regulatory

reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.

reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.

Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.

This is the relevant lockdep warning:

cfg80211: Calling CRDA for country: XX

======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
 (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]

but task is already holding lock:
 ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((reg_timeout).work){+.+...}:
       [<c008fd44>] validate_chain+0xb94/0x10f0
       [<c0090b68>] __lock_acquire+0x8c8/0x9b0
       [<c0090d40>] lock_acquire+0xf0/0x114
       [<c005b600>] wait_on_work+0x4c/0x154
       [<c005c000>] __cancel_work_timer+0xd4/0x11c
       [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
       [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
       [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
       [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
       [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
       [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
       [<c03c7584>] genl_rcv+0x28/0x34
       [<c03c6720>] netlink_unicast+0x15c/0x228
       [<c03c6c7c>] netlink_sendmsg+0x218/0x298
       [<c03933c8>] sock_sendmsg+0xa4/0xc0
       [<c039406c>] __sys_sendmsg+0x1e4/0x268
       [<c0394228>] sys_sendmsg+0x4c/0x70
       [<c0013840>] ret_fast_syscall+0x0/0x3c

-> #1 (reg_mutex){+.+.+.}:
       [<c008fd44>] validate_chain+0xb94/0x10f0
       [<c0090b68>] __lock_acquire+0x8c8/0x9b0
       [<c0090d40>] lock_acquire+0xf0/0x114
       [<c04734dc>] mutex_lock_nested+0x48/0x320
       [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
       [<c0059f44>] process_one_work+0x2a0/0x480
       [<c005a4b4>] worker_thread+0x1bc/0x2bc
       [<c0061148>] kthread+0x98/0xa4
       [<c0014af4>] kernel_thread_exit+0x0/0x8

-> #0 (cfg80211_mutex){+.+.+.}:
       [<c008ed58>] print_circular_bug+0x68/0x2cc
       [<c008fb28>] validate_chain+0x978/0x10f0
       [<c0090b68>] __lock_acquire+0x8c8/0x9b0
       [<c0090d40>] lock_acquire+0xf0/0x114
       [<c04734dc>] mutex_lock_nested+0x48/0x320
       [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
       [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
       [<c0059f44>] process_one_work+0x2a0/0x480
       [<c005a4b4>] worker_thread+0x1bc/0x2bc
       [<c0061148>] kthread+0x98/0xa4
       [<c0014af4>] kernel_thread_exit+0x0/0x8

other info that might help us debug this:

Chain exists of:
  cfg80211_mutex --> reg_mutex --> (reg_timeout).work

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((reg_timeout).work);
                               lock(reg_mutex);
                               lock((reg_timeout).work);
  lock(cfg80211_mutex);

 *** DEADLOCK ***

2 locks held by kworker/0:2/1391:
 #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
 #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480

stack backtrace:
[<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
[<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
[<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
[<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
[<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
[<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
[<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
[<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
[<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
[<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
[<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Cc: stable@kernel.org
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: WARN only once when we have trouble in reclaim

This flow can actually happen due to a corner case in
mac80211: the station is deleted before we get a chance
to reclaim all the packets in flight in AGG queue.
The tid_data for this station is zeroed, and we lose
the match with the Tx queue.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: use request_module instead of _nowait

Since request_module_nowait() can't be backported
use request_module() instead -- we don't need the
asynchronous behaviour of request_module_nowait()
here since we're running in the firmware request
work struct.

Tested-by: Donald H Fry <donald.h.fry@intel.com>
Reviewed-by: Donald H Fry <donald.h.fry@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: fix 6035 device parameters

Due to commit 26a7ca9a71a ("iwlwifi: refactor EEPROM
reading/parsing") adding a new parameter, while commit
d2c8b15d0cb ("iwlwifi: use correct supported firmware
for 6035 and 6000g2") added a new device structure we
need to add the parameter to the new device structure
to make 6035 device work.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next

iwlwifi: warn if TFD index and WiFi Seq don't match

For AGG queues, we must match between the WiFi sequence
number and the TFD number. This is a HW (SCD) requirement.

This is a take two of my

    iwlwifi: add debug in Tx path in AGG flow

    This will allow us to catch bad cases in which the packets aren't in
    the right place on the ring.

which disappeared during code move.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: don't modify the timer if we don't Tx

In fragmentation we don't update the write pointer of the
HW immediately. So we shouldn't modify the timer in that
case.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: turn on a lockdep assertion

CMD_SYNC is zero so the if (cmd->flags & CMD_SYNC) is never true and we
never check the assertion.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: print even more info when a queue is stuck

Since the queue gets stuck from time to time, we are trying
to get as much information as we can when this occurs.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: Fix Makefile build order for built-in driver

When the driver is built into the kernel instead of a module
when the system boots it results in a panic. The order things are built in
results in their initialization order when built into the kernel. Wifi
has to be initialized before mvm or dvm.

Reviewed-by: Donald H Fry <donald.h.fry@intel.com>
Tested-by: Donald H Fry <donald.h.fry@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Brandon Misemer <brandon.misemer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: comment that setting driver_data overrides info->control

Using the driver_data area in ieee80211_tx_info which
resides in the CB overrides the info->control field.
Add a comment to prevent mistakes.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: remove lock around txq_enable

This locking isn't needed. The only locking we need is when
we access prph registers but there is already a separate
lock for that.
Since we haven't returned from the mac80211's
IEEE80211_AMPDU_TX_OPERATIONAL ampdu_action, we cannot
receive any Tx frame for that sta / tid while enabling the
queue.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: don't configure a txq that is being disabled

This is not needed, we just need to tell the SCD not to use
that queue. We will reconfigure that queue when we will use
it again.

Clean up a bit the code on the way.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: print more info when a queue is stuck

Print some more info from the SCD's SRAM and dump the TRB
from the FH.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: iwl_{read,write}_targ_mem_words takes dwords

Change its name to better reflect this.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: s/iwl_read_targ_mem_words/iwl_read_targ_mem_bytes

This macro gets the bufsize in bytes.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: fix dynamic loading

Add locking to the dynamic loading code to prevent
corrupting the list if multiple device ever init at
the same time (which cannot happen for multiple PCI
devices, but could happen when different busses init
concurrently.)

Also remove a device from the list when it stops so
the list isn't left corrupted, including a fix from
Don to not crash when it was never added.

Reviewed-by: Donald H Fry <donald.h.fry@intel.com>
Tested-by: Donald H Fry <donald.h.fry@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mwifiex: fix incorrect privacy setting in beacon and probe response

Test procedure:
1. Start AP with security setting (e.g. WPA2)
2. Stop AP
3. Start AP with open security

Here it's observed that privacy is enabled in beacons and
probe responses.

This patch fixes it by checking the privacy parameter from
cfg80211_ap_settings. If privacy is not set in cfg80211_ap_settings,
set open authentication and no encryption in FW.

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless

Conflicts:
MAINTAINERS
drivers/net/wireless/iwlwifi/pcie/trans.c

mac80211: add missing kernel-doc

Add a few kernel-doc descriptions that were missed
during mesh development.

Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Ashok Nagarajan <ashok@cozybit.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

ssb: add missing PCI ID for b/g/n single band BCM4322

14e4:432c is found on some bcm63xx devices. The device is working fine
with b43.

Reported-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Initvals update for AR9462

MSI is enabled by default for most of the 4th generation
chips. Add this for AR9462 - this fixes PowerSave operation,
the chip was not entering Network-Sleep mode earlier.
With proper powering down of the MAC now, power consumption
in associated state is reduced considerably.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: scan less channels per scan command to improve Tx traffic

Currently 4 channels are scanned per scan command. if scan request
is issued by user during Tx traffic, radio will be out of channel
for "4 * per_chan_scan_time" for each scan command and will not be
able to receive Rx packets. This adds delay in data traffic. We can
minimize it by reducing number of channels scanned per scan command
in this scenario.

We can not always scan 1 channel per scan command due to limitation
of number of command buffers. So we add code to decide number of
channels scanned per scan command in associated state.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: fix simultaneous scan and Tx traffic problem

If scan operation is started when Tx traffic is already running,
driver locks Tx queue until it gets completed. With this logic
there is a delay for Tx packets.

This patch implements new approach to give Tx path higher priority
in this case. Driver internally sends multiple synchronous scan
commands to firmware when scan is requested by user. Now we will
make sure that Tx queue is empty everytime before sending next scan
command. If Tx queue isn't empty scan command will be postponsed by
20msec. This rule will be followed until Tx queue becomes empty or
timeout of 1 second happens. In case of timeout scan operation will
be aborted.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: shorten per channel scan time

Currently the scan time per channel for active scanning is set to
200ms. It takes quite a while to finsh scanning on all channels,
especially with a dual band configuration.

Change the per channel scan time settings to the following values:

passive scan: 110ms
active scan: 30ms
specific scan: 30ms

Above settings have been tested on x86 and arm platforms.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'for-john' of git://git./linux/kernel/git/iwlwifi/iwlwifi-next

Conflicts:
drivers/net/wireless/iwlwifi/iwl-eeprom.c

Merge tag 'nfc-next-3.6-1' of git://git./linux/kernel/git/sameo/nfc-3.0

Merge branch 'for-upstream' of git://git./linux/kernel/git/bluetooth/bluetooth

rndis_wlan: fix matching bssid check in rndis_check_bssid_list()

rndis_check_bssid_list() originally tried to check if bssid->mac and
match_bssid are equal using compare_ether_addr() when it should use
!compare_ether_addr(). This check was added by commit
b5257c952dda24df7078c74b7b811b44c6e49206 as part of workaround for
hardware issue.

Commit 2e42e4747ea72943c21551d8a206b51a9893b1e0 that replaced
compare_ether_addr with ether_addr_equal relieved that this compare
to be inverse of what it should be.

Compare was added as response to hardware bug, where bssid-list does
not contain BSSID and other information of currently connected AP
(spec insists that device must provide this information in the list
when connected). Lack bssid-data on current connection then causes
WARN_ON somewhere in cfg80211. Workaround was to check if bssid-list
returns current bssid and if it does not, manually construct bssid
information in other ways. And this workaround worked, with inverse
check. Which must mean that when hardware is experiencing the problem,
it's actually returning empty bssid-list and this check didn't make
any difference for workaround.

However inverse check causes workaround be activated when bssid-list
returns only entry, currently connected BSSID. That does not cause
problems in itself, just slightly more inaccurate information in
scan-list.

Cc: Joe Perches <joe@perches.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: remove incompatible IBSS interface check in change_iface

'cfg80211: fix interface combinations' ensures that if an interface
type is not advertised by the driver in any of the interface combinations
(via ieee80211_iface_combination) then it shall be treated as a single
incompatible interface. if there are more than one interfaces present
and changing them to incompatible interface type is not possible.
These checks will be properly handled by cfg80211_change_iface ->
cfg80211_can_change_interface.

this patch is dependent on 'cfg80211: fix interface combinations'

Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Fix a WARNING on suspend/resume with IBSS

this patch is dependent on the patch "cfg80211: fix interface
combinations"

In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC.  we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.

The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.

        ath: phy0: Cannot create ADHOC interface when other
        interfaces already exist.
        WARNING: at net/mac80211/driver-ops.h:12
        ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
        Hardware name: 2842RK1
        wlan2:  Failed check-sdata-in-driver check, flags: 0x0

        Call Trace:
        [<c01361b2>] warn_slowpath_common+0x72/0xa0
        [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [<c0136283>] warn_slowpath_fmt+0x33/0x40
        [<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
        [<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
        [<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
        [<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]

Cc: stable@vger.kernel.org
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: decouple testmode and iwl-test

The iwl-test flows were based on the cfg80211 testmode APIs.

To remove this coupling, the op mode (during the initialization
of the iwl_test object) is responsible to set the callbacks that
should be used by iwl-test to allocate skbs for events and replies
and to send events and replies.

The current op modes implement these callbacks based on the cfg80211
testmode APIs.

Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

iwlwifi: refactor testmode

Create an object that will enacpsulate the testmode functionality
that is common to all op modes.

 * Copy definitions from dvm/dev.h
 * Copy the testmode logic from dvm/testmode.c
 * Link iwl-test object into the iwlwifi module
 * Modify DVM to use iwl-test object

Reviewed-by: Amit Beka <amit.beka@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Bluetooth: Fix style in hidp code

Follow the net rules.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

cfg80211: check iface combinations only when iface is running

Don't validate interface combinations on a stopped
interface. Otherwise we might end up being able to
create a new interface with a certain type, but
won't be able to change an existing interface
into that type.

This also skips some other functions when
interface is stopped and changing interface type.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: add some missing kernel-doc

Add a few kernel-doc descriptions that were missed
during development.

Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Bluetooth: Add support for encryption key refresh

With LE/SMP the completion of a security level elavation from medium to
high is indicated by a HCI Encryption Key Refresh Complete event. The
necessary behavior upon receiving this event is a mix of what's done for
auth_complete and encryption_change, which is also where most of the
event handling code has been copied from.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

wl18xx: avoid some -Wformat warnings

  CC      drivers/net/wireless/ti/wl18xx/main.o
drivers/net/wireless/ti/wl18xx/main.c: In function ‘wl18xx_conf_init’:
drivers/net/wireless/ti/wl18xx/main.c:1024:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat]
drivers/net/wireless/ti/wl18xx/main.c:1024:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Wformat]

Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: add back channel change flag

commit 24398e39c8ee4a9d9123eed322b859ece4d16cac
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 28 10:58:36 2012 +0200

    mac80211: set HT channel before association

removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config,
which is required by iwl4965 driver, otherwise that driver does not
configure channel properly and is not able to associate.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

NFC: Fix possible NULL ptr deref when getting the name of a socket

llcp_sock_getname() might get called before the LLCP socket was created.
This condition isn't checked, and llcp_sock_getname will simply deref a
NULL ptr in that case.

This exists starting with d646960 ("NFC: Initial LLCP support").

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: disable the buggy chain extension feature in HW

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

Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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.

Cc: stable@vger.kernel.org [2.6.27+]
Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

bcma: fix null pointer in bcma_core_pci_irq_ctl

pc could be null if hosttype != BCMA_HOSTTYPE_PCI.
If we are on a device without a pci core this function is called with
pc = null by b43 and brcmsmac. If the host type is PCI we have a pci
core as well and pc can not be null.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: do not call ieee80211_unregister_hw if we are not registred

this patch fixes kernel Oops on "rmmod b43" if firmware was not loaded:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
IP: [<ffffffff8104e988>] drain_workqueue+0x25/0x142
PGD 153ac6067 PUD 153b82067 PMD 0
Oops: 0000 [#1] SMP

Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: use correct supported firmware for 6035 and 6000g2

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.

Cc: stable@kernel.org
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

wireless: add my new trees to MAINTAINERS

Add my new trees to the MAINTAINERS file
for the components that I maintain in the
new trees.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211_hwsim: Set IEEE80211_STAT_ACK flag when userspace indicates that the frame has been acknowledged.

The station fail average is not updated correctly since the
IEEE80211_STAT_ACK flag is not set when using wmediumd with
mac80211_hwsim. Set this flag when wmediumd indicates that the frame
was successfully transmitted (eventually).

Signed-off-by: Qasim Javed <qasimj@gmail.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rtl8187: ->brightness_set can not sleep

Fix:

BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
2 locks held by wpa_supplicant/629:
 #0:  (rtnl_mutex){+.+.+.}, at: [<c08b2b84>] rtnl_lock+0x14/0x20
 #1:  (&trigger->leddev_list_lock){.+.?..}, at: [<c0867f41>] led_trigger_event+0x21/0x80
Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
Call Trace:
 [<c046a9f6>] __might_sleep+0x126/0x1d0
 [<c0457d6c>] wait_on_work+0x2c/0x1d0
 [<c045a09a>] __cancel_work_timer+0x6a/0x120
 [<c045a160>] cancel_delayed_work_sync+0x10/0x20
 [<f7dd3c22>] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
 [<c0867f7c>] led_trigger_event+0x5c/0x80
 [<f7ff5e6d>] ieee80211_led_radio+0x1d/0x40 [mac80211]
 [<f7ff3583>] ieee80211_stop_device+0x13/0x230 [mac80211]

Removing _sync is ok, because if led_on work is currently running
it will be finished before led_off work start to perform, since
they are always queued on the same mac80211 local->workqueue.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

net/wireless: ipw2100: Fix WARN_ON occurring in wiphy_register called by ipw2100_pci_init_one

The problem was found by Larry Finger:
http://marc.info/?l=linux-wireless&m=133702401700614&w=2

The problem is identical to the one for ipw2200 which is already fixed:
http://marc.info/?l=linux-wireless&m=133457257407196&w=2

[   17.766431] ------------[ cut here ]------------
[   17.766467] WARNING: at net/wireless/core.c:562 wiphy_register+0x34c/0x3c0 [cfg80211]()
[   17.766471] Hardware name: Latitude D600
[   17.766474] Modules linked in: ipw2100(+) libipw pcmcia cfg80211 ppdev parport_pc yenta_socket sr_mod pcmcia_rsrc parport iTCO_wdt cdrom sg rfkill pcmcia_
core lib80211 tg3 video button battery ac iTCO_vendor_support joydev shpchp pcspkr pciehp pci_hotplug autofs4 radeon ttm drm_kms_helper uhci_hcd ehci_hcd rtc
_cmos thermal drm hwmon i2c_algo_bit i2c_core processor usbcore usb_common ata_generic ata_piix ahci libahci libata
[   17.766525] Pid: 474, comm: modprobe Not tainted 3.4.0-rc7-wl+ #6
[   17.766528] Call Trace:
[   17.766541]  [<c066ad08>] ? printk+0x28/0x2a
[   17.766552]  [<c0230edd>] warn_slowpath_common+0x6d/0xa0
[   17.766563]  [<e0b253bc>] ? wiphy_register+0x34c/0x3c0 [cfg80211]
[   17.766573]  [<e0b253bc>] ? wiphy_register+0x34c/0x3c0 [cfg80211]
[   17.766578]  [<c0230f2d>] warn_slowpath_null+0x1d/0x20
[   17.766588]  [<e0b253bc>] wiphy_register+0x34c/0x3c0 [cfg80211]
[   17.766605]  [<e0b5b0d6>] ipw2100_wdev_init+0x196/0x1c0 [ipw2100]
[   17.766616]  [<e0b5d962>] ipw2100_pci_init_one+0x2b2/0x694 [ipw2100]
[   17.766632]  [<c047ce52>] local_pci_probe+0x42/0xb0
[   17.766637]  [<c047e2b0>] pci_device_probe+0x60/0x90
[   17.766645]  [<c0376de2>] ? sysfs_create_link+0x12/0x20
[   17.766654]  [<c050f1f6>] really_probe+0x56/0x2e0
[   17.766659]  [<c037636d>] ? create_dir+0x5d/0xa0
[   17.766667]  [<c0518c6b>] ? pm_runtime_barrier+0x3b/0xa0
[   17.766672]  [<c050f5e4>] driver_probe_device+0x44/0xa0
[   17.766677]  [<c047e227>] ? pci_match_device+0x97/0xa0
[   17.766681]  [<c050f6c9>] __driver_attach+0x89/0x90
[   17.766686]  [<c050f640>] ? driver_probe_device+0xa0/0xa0
[   17.766691]  [<c050da2a>] bus_for_each_dev+0x3a/0x70
[   17.766695]  [<c050ee6c>] driver_attach+0x1c/0x30
[   17.766699]  [<c050f640>] ? driver_probe_device+0xa0/0xa0
[   17.766704]  [<c050ea77>] bus_add_driver+0x187/0x280
[   17.766710]  [<c045b9cd>] ? kset_find_obj+0x2d/0x60
[   17.766715]  [<c047e2e0>] ? pci_device_probe+0x90/0x90
[   17.766719]  [<c047e2e0>] ? pci_device_probe+0x90/0x90
[   17.766724]  [<c050fb85>] driver_register+0x65/0x110
[   17.766729]  [<c047e09d>] __pci_register_driver+0x3d/0xa0
[   17.766738]  [<e09f705c>] ipw2100_init+0x5c/0x1000 [ipw2100]
[   17.766743]  [<c020110f>] do_one_initcall+0x2f/0x170
[   17.766749]  [<e09f7000>] ? 0xe09f6fff
[   17.766757]  [<c0287ce8>] sys_init_module+0xa8/0x210
[   17.766766]  [<c067a075>] syscall_call+0x7/0xb
[   17.766769] ---[ end trace 559898c6bb0d1c75 ]---
[   17.767093] ipw2100: probe of 0000:02:03.0 failed with error -5

This warning appears only if we apply Ben Hutchings' fix
http://marc.info/?l=linux-wireless&m=132720204412667&w=2
for the bug reported by Cesare Leonardi
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813
with cfg80211 warning during device registration
("cfg80211: failed to add phy80211 symlink to netdev!").

We separate device bring up and registration with network stack
to avoid the problem.

Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'wl12xx-next' into for-linville

Bluetooth: Fix SMP security elevation from medium to high

If we have an unauthenticated key it is not sufficient to acheive high
security. Therefore, when deciding whether to encrypt the link or
request pairing, it is essential to in addition to checking the
existence of a key to also check whether it is authenticated or not.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

wlcore/wl12xx/wl18xx: make NVS file optional for wl18xx

Don't spew errors when we can't find the NVS file in wlcore. Instead
fail the wl12xx boot HW op if the NVS isn't found.

Take this opportunity to remove some dead code from register_hw()
which looks for the NVS again needlessly.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

wl18xx: clean up phy module parameters

Give all wl18xx phy module paramters -1 as a default value, indicating
the paramter was not set. Add previous default values to the default
18xx priv conf structure.

Remove the board_type field from wl18xx priv. The field with the same
name inside the phy conf is good enough for our purposes.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

wl18xx: align wl18xx_conf_phy with FW variant and remove it

wl18xx_conf_phy represents part of the FW native wl18xx_mac_and_phy_params
structure. Remove it and replace the phy part of the wl18xx conf with the
FW bound structure. This allows us to set/override all members.

Increment the wlconf version to ensure compatibility with the new
structure

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

wl18xx: update fw statistics

Aligned to the struct in FW 8.2.0.0.91 and updated the debugfs entries
accordingly.

Signed-off-by: Ido Reis <idor@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Bluetooth: Fix deadlock and crash when SMP pairing times out

The l2cap_conn_del function tries to cancel_sync the security timer, but
when it's called from the timeout function itself a deadlock occurs.
Subsequently the "hcon->l2cap_data = NULL" that's supposed to protect
multiple calls to l2cap_conn_del never gets cleared and when the
connection finally drops we double free's etc which will crash the
kernel.

This patch fixes the issue by using the HCI_CONN_LE_SMP_PEND for
protecting against this. The same flag is also used for the same purpose
in other places in the SMP code.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

wl18xx: allow FW-log by default for PG2.0

This is supported by new FW versions (.88+).

Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

wl18xx: read configuration structure from a binary file

Instead of using the hardcoded configuration structure, try to read it
from a "firmware" file called wl18xx-conf.bin.  If the file doesn't
exist, fall back to the hardcoded version.  If the file exists but is
illegal, bail out.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore/wl18xx: export conf struct in a debugfs file

Add conf file header structure, magic and version values and export
the entire conf struct in debugfs.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore/wl18xx: the conf structs must be packed so they can be exported

Since we are now going to export the conf structure and read it from a
file, it should be packed to avoid surprises with padding bytes.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore: use u8 instead of enum for bcn_filt_mode

Since we will export the conf structure as a file, we need to use well
defined types.  Instead of using enum, whose size may vary, use u8 for
bcn_filt_mode instead.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore/wl18xx/wl12xx: use u8 instead of bool for host_fast_wakeup_support

The conf structure is going to be exported to a file, so we should use
only well defined types.  bool is not well defined and may vary from
platform to platform, so change the host_fast_wakeup_support type to
u8 instead.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore: export raw binary with the FW statistics in debugfs

Instead of parsing all the binary data returned by the firmware, we
should simply export the binary and let the userspace do the parsing.

This commit adds a new file to debugfs to do that.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wl18xx: add support to clear FW statistics

This patch calls ACX_CLEAR_STATISTICS to clear the firmware
statistics.  The trigger is a new debugfs file called
clear_fw_statistics in the fw_stats directory.

Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore: add debugfs control over rx interrupt pacing

Add control over several conf fields which combined
control the rx interrupt pacing mechanism, that is avoiding
getting an interrupt following a single frame rx but instead
have the FW trigger the interrupt only after a certain
amount of frames received or a timeout.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

wlcore: add support macros to easily add conf debugfs entries

The current debugfs code contains too much code duplication
of bolierplate code. Add some macro magic to avoid this and
enable adding new debugfs entries by using just a few lines.

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Bluetooth: Fix LE pairing completion on connection failure

For BR/EDR pairing is assumed to be finished when connection is
done. For LE if connection is successful it did not necessarily
mean that pairing is also done but if the connection is unsuccessful
it should be assumed that pairing procedure is also finished.
This patch registers a new function with connect_cfm_cb callback for
LE link which sends the pairing complete signal to user space if
connection is unsuccessful.

Signed-off-by: Vishal Agarwal <vishal.agarwal@stericsson.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Bluetooth: Fix SMP pairing method selection

The tk_request function takes the local IO capability as the second last
parameter and the remote IO capability as the last parameter. They were
previously swapped: when we receive a pairing response
req->io_capability contains the local one and rsp->io_capability the
remote one.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>