iwlwifi: mvm: disable reduced Tx power when not applicable

I forgot to disable the reduced Tx power in a few paths.

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

iwlwifi: mvm: pass force_assoc_off all the way down to avoid hacks

In some cases, we need to force the association to be off in the
MAC_CONTEXT_CMD command we send to the firmware.  Instead of having to
hack the vif->bss_conf.assoc value, pass it all the way down the call
chain.

Additionally, for the iwl_mvm_mac_ctxt_add() case, we *always* set
forced_assoc_off to true, so we can remove the hack in the d3 code
that was forcing it to off by hacking the bss_conf.assoc value.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: don't filter out the first beacon

Enabling beacon filtering should be done only after a beacon
has been received. Doing that too early will cause
disconnections.
This has already been fixed, but the fix didn't take care
about the case where the beacon is received after the
association, it waited only for association which is not
enough.

Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

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

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Conflicts:
drivers/net/wireless/iwlwifi/mvm/mac80211.c

iwlwifi: mvm: disable beacon filtering

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

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: set the MAC_FILTER_IN_BEACON flag also for P2P

There doesn't seem to be a good reason for not enabling the
MAC_FILTER_IN_BEACON flag for P2P client, as we do for station.

This can prevent potential, hard-to-reproduce problems during
association.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: enable MAC_FILTER_IN_BEACON when forced_assoc_off is set

Set the MAC_FILTER_IN_BEACON flag in iwl_mvm_mac_ctxt_cmd_sata() also
when forced_assoc_off is set, so it's aligned with when we are not
associated.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it

We should not allow diversity when BT Coex needs the second
antenna. Thermal Throttling can also request to stop using
the second antenna. Honour those requests.

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

iwlwifi: mvm: Remove redundant initialization

This value is being set few lines under in set_cqm_params.

Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: update power after phy_ctxt is NULL when unassigning chanctx

iwl_mvm_power_update_mac() (more specifically
iwl_mvm_power_iterator()) relies on the phy_ctxt setting to decide
whether the vif is active or not.  When unassigning a chanctx, we
should therefore call iwl_mvm_power_update_mac() after setting
phy_chanctx to NULL.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: fix LED support Kconfig dependencies

If DVM or MVM are built-in but LEDS_CLASS isn't then the current
Kconfig will enable LED support and fail the build. Fix this by
making the LED support depend on LEDS_CLASS being built-in or,
if it is modular, only enabling it if iwlwifi also is.

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

iwlwifi: update nmi register

In the 8000 HW family the register for forcing an NMI has
changed, so this allows to still be able to force an NMI
while taking into account the HW in order to write to the
correct register.

Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: combine p2p and station mac context functions

Instead of having two nearly identical functions to send the mac
context commands, use a single way that can handle both the p2p and
!p2p cases.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: BT Coex - send channel inhibition before association

The firmware needs to know on what channel we run before we
set the association bit in the MAC context. Change a bit the
flow to achieve this.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: add uapsd_disable module parameter

Some APs (e.g. TP-LINK TL-WA801N) are disabling aggregation (downlink
to station) when U-APSD is enabled, resulting in low throughput.
Add a module parameter to allow disabling U-APSD support in the driver.

Also re-enable U-APSD for -9 firmware since the firmare issues were
fixed in this release.

There are devices that won't support U-APSD even with newer
firmware, so bring the TLV flag back to detect those.

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

iwlwifi: allow dynamic configuration of internal memory

New transport need to configure internal memory based on
the data in the (enlarged) alive notification from the
firmware. Add a transport API for this.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: enable RX chain diversity if needed

In some situations (see comment) it makes sense to enable both
chains (if available) to get better throughput by having chain
diversity available.

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

iwlwifi: mvm: prevent sched scan while not idle

Prevent sched scan while not idle (including during association or in AP
mode) instead of while associated only.

This fixes my previous commit which was incomplete:

commit bd5e4744a6ca64299b57a2682c720d00a475a734
Author: David Spinadel <david.spinadel@intel.com>
Date:   Thu Apr 24 13:15:29 2014 +0300

    iwlwifi: mvm: do no sched scan while associated

    Currently the FW doesn't support sched scan while associated,
    Prevent it.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: fix off-by-one in scan channels configuration

tail should be equal to the last valid index, so
decrease it by one.

This error causes in "a gap" in some cases (as well as
some possible out-of-bound write), finally resulting in
ucode assertion.

Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: revisit the NVM handling code

Fix a bug in nvm_read_section function if size of the section
is a multiple of 2K:

   - if the size of the section is *not* multiple of 2K,
   then we will have: read(2K) - return 2K ... read(2K) - return 2K
   read(2K) - return the rest (in bytes) and exit the while loop.
   - else, if the size of the section is a multiple of 2K,
   then we have: read(2K) - return 2K read(2K) - return 2K read(2K) -
   return 2K read(2K) - return 0 and exit the while with an error.

We should not return an error in the latter case, because it
might well be that the section was completely read.

Also, we try now to read all the sections as this is needed
for new devices.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: BT Coex - fix boost register / LUT values

These values are used to give preference to WiFi according
to a certain pattern.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: set SKIP_OVER_DTIM flag only if needed

setting SKIP_OVER_DTIM when skip_dtim_periods is 0
causes a ucode assert. set the flag only if needed.

Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: pcie: disable BHs in iwl_pcie_txq_check_wrptrs

This fixes:

=================================
[ INFO: inconsistent lock state ]
3.14.3+ #5 Tainted: G           O
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/3/0 [HC0[0]:SC1[3]:HE1:SE0] takes:
 (&(&txq->lock)->rlock){+.?...}, at: [<ffffffffa059803c>] iwl_pcie_enqueue_hcmd+0x12c/0x1000 [iwlwifi]
{SOFTIRQ-ON-W} state was registered at:
  [<ffffffff810d9071>] __lock_acquire+0x5f1/0x13b0
  [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
  [<ffffffff817ef80e>] _raw_spin_lock+0x3e/0x80
  [<ffffffffa0598f7a>] iwl_pcie_txq_check_wrptrs+0x6a/0xb0 [iwlwifi]
  [<ffffffffa0594b5a>] iwl_pcie_irq_handler+0xdba/0x2670 [iwlwifi]
  [<ffffffff810ef1e0>] irq_thread_fn+0x20/0x50
  [<ffffffff810ef77f>] irq_thread+0x11f/0x150
  [<ffffffff810a04f0>] kthread+0xf0/0x110
  [<ffffffff817fa4bc>] ret_from_fork+0x7c/0xb0
irq event stamp: 1142192
hardirqs last  enabled at (1142192): [<ffffffff817efb6c>] _raw_spin_unlock_irq+0x2c/0x40
hardirqs last disabled at (1142191): [<ffffffff817ef9ef>] _raw_spin_lock_irq+0x1f/0x80
softirqs last  enabled at (1142188): [<ffffffff81079082>] _local_bh_enable+0x22/0x50
softirqs last disabled at (1142189): [<ffffffff8107ad35>] irq_exit+0xe5/0xf0

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

       CPU0
       ----
  lock(&(&txq->lock)->rlock);
  <Interrupt>
    lock(&(&txq->lock)->rlock);

Fixes: ea68f46070c7 ("iwlwifi: pcie: clarify TX queue need_update handling")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: use dev_printk instead of dev_dbg for debug logs

When calling IWL_DEBUG_*() dev_dbg() is currently used, and this
could result in the log being ignored no matter the internal
loglevel, since dev_dbg() may get turned on or off based on the
dynamic debug mechanism.

Replace the dev_dbg() with dev_printk() since dynamic printing
is pointless as we use our own debug level mechanism and there
is just a single dev_dbg() call in the code.

Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
[rephrase commit message a bit]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: remove CMD_SYNC

CMD_SYNC is really 0 which is confusing:

if (cmd.flags & CMD_SYNC) is always false.
Fix this by simply removing its definition.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Merge remote-tracking branch 'iwlwifi-fixes/master' into HEAD

iwlwifi: remove spurious newline in Kconfig

There's an extra newline that shouldn't be there - remove it.

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

iwlwifi: cause build error on missing newline

If a (debug) message is missing a newline, cause build error
so we don't keep reintroducing this problem.

This also prevents using a non-constant argument as the format
string which is a good idea anyway (e.g. for security reasons.)

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

iwlwifi: mvm: Disable uAPSD for a DCM client

A binding object associates virtual MACs to a Phy.
Binding object can ask (and get) air time, thus
allowing several MACs to share the medium.
A binding object can be in either one of 3 states:
1) standalone - A single active MAC
2) Different Channel Mode (DCM) - There are 2 active
   MACs or more (not necessarily just clients), but each
   has its own channel.
3) Same Channel Mode (SCM) - There are 2 active
   MACs or more (not necessarily just clients), that
   share the same channel.
This patch introduces an additional condition for enabling uAPSD:
uAPSD should be disabled for a client in DCM.
The reason for that is a low latency issue in Miracast.

Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: Add power management support for P2P DCM

If two clients are active while each one is alone on its channel,
and the applicable flags are set, power management should be enabled.
This condition is referred to as Different Channel Mode (DCM).
Up to now, in DCM power management was supported only on BSS.
This patch adds support for P2P power management in DCM as well.

Signed-off-by: Avri Altman <avri.altman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: fix setting channel in monitor mode

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: [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]

but task is already holding lock:
 (&local->iflist_mtx){+.+...}, at: [<ffffffffa0609e0a>] 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){+.+...}:
       [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
       [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
       [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
       [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa0518189>] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm]
       [<ffffffffa051822e>] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm]
       [<ffffffffa05e6d43>] ieee80211_configure_filter+0x153/0x5f0 [mac80211]
       [<ffffffffa05e71f5>] ieee80211_reconfig_filter+0x15/0x20 [mac80211]
       [snip]

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

-> #0 (&local->chanctx_mtx){+.+.+.}:
       [<ffffffff810d6cb7>] check_prevs_add+0x977/0x980
       [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
       [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
       [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
       [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
       [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
       [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
       [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
       [<ffffffffa0581374>] 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:
 [<ffffffff817ea841>] schedule_preempt_disabled+0x31/0x80
 [<ffffffff817ebaed>] mutex_lock_nested+0x19d/0x4f0
 [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [<ffffffffa052a680>] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm]
 [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
 [<ffffffffa0529357>] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm]
 [<ffffffffa0516eb1>] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm]
 [<ffffffffa062d3ff>] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211]
 [<ffffffffa062e2fa>] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211]
 [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
 [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
 [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
 [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]

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

Cc: <stable@vger.kernel.org> [3.13+]
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: stop sched scan before association

Stop sched scan on bss_info_changed if !idle to avoid sched scan
during association.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: notify sched scan complete from stop routine

Add an option to notify mac80211 about sched scan complete from
iwl_mvm_stop_sched_scan(), to enable this notification when the
stop was called from within the driver.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: add channel 14 to the low band list

in family 8000: additional channel 14 added to the low
band list. now the number of channels in the low band
is 15.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Dor Shaish <dor.shaish@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: pcie: try to get ownership several times

Some races with the hardware can happen when we take
ownership of the device. Don't give up after the first try.

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

iwlwifi: 8000: add default NVM file name in family 8000

The 8000 family products need a file on the file system
which is used as NVM. This file is a must, if no filename
is supplied as module parameter, use a default filename.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Dor Shaish <dor.shaish@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: dvm: don't use _ni mac80211's callbacks

This is not needed since the PCIe layer disables the
bottom halves before it calls the op_mode.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: add missing trailing newlines to debug messages

All messages should have a trailing newline, add all the
missing ones. Also make all messages constants, replacing
the single one that pointlessly used a variable.

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

iwlwifi: pcie: disable interrupts upon PCIe alloc

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.

Cc: <stable@vger.kernel.org> [3.14]
Reported-and-tested-by: Alexander Monakov <amonakov@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: rs: enable MCS9 for Tx

After fixes to the rs algorithm reenable MCS9.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: fix sparse warning when _DEBUGFS isn't set

Since the declaration of iwl_mvm_fw_error_rxf_dump and
iwl_mvm_fw_error_sram_dump is under
ifdef CONFIG_IWLWIFI_DEBUGFS, do the same for their
implementation.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: implement mac80211's flush callback

This allows mac80211 to flush the Tx queues before it sends
critical management frames.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi:mvm: Add AP/GO channel switch support

Publish WIPHY_FLAG_HAS_CHANNEL_SWITCH if the fw supports
newly introduced IWL_UCODE_TLV_API_CSA_FLOW.
When CSA starts, save the switching vif inside mvm and during the CSA period
configure fw with a new beacon after each beacon transmission in order to
update the csa counters.
Also, handle correctly the CSA unbind-bind flow which is triggered by mac80211
when the actual channel switch happens.

Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: wait for d0i3 exit in some more ampdu actions

Some ampdu actions change queues by direct target access.

Since the bus is disabled in d0i3, make sure to exit d0i3
before handling these actions.

Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm/pcie: capture last commands on firmware error

When a firmware error occurs, capture the last 32 commands
(which are still in memory) in the error dump debugfs file.

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

iwlwifi: mvm: do no sched scan while associated

Currently the FW doesn't support sched scan while associated,
Prevent it.

Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: pcie: get rid of q->n_bd

This variable always tracks a constant value (256) so there's
no need to have it. Removing it simplifies code generation,
reducing the .text size (by about 240 bytes on x86-64.)

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

iwlwifi: pcie: use bool for iwl_pcie_txq_build_tfd() argument

The 'reset' argument is clearly a boolean, so use bool instead
of u8 with 0/1 values.

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

iwlwifi: make LED support optional

If there's no LED on the system, it doesn't make a lot of sense
to include close to 4k of LED-related code (mostly in mac80211),
so instead of forcing LED support into the kernel, don't build
iwlwifi/mac80211 LED support if there's no LED class support.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: EliadX Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: fix bug in parse_nvm_sections

The old code checks if hw_section_num is valid while the
right thing to do is to check if section[hw_section_num].data
is valid.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: select the MAC address according to priority

For family 8000 products, the driver should take the MAC
address from the mac_override section and only if this
section is empty it should take it from the HW section.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: Prioritize external nvm values on top of the OTP values

Read first the nvm sections from the OTP, then read the nvm
sections from the external file and override the OTP values
(if there were any values in the OTP).

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: prevent nic to powered up at driver load

A few devices aren't allowed to be powered up at driver
load time. Add "power_up_nic_in_init" flag to iwl_cfg
structure to customize the load flow according to the
device.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: fix bug with OTP memory size

OTP size changed in family 7000 and in family 8000.

Signed-off-by: Eran Harary <eran.harary@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: remove useless variable

There's no need to use a variable just to return the result
of another function call at the end of a function, remove it.

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

iwlwifi: mvm: rs: choose correct expected tpt table

The expected throughput table used when estimating a new column
depends on the channel bandwidth. When switching from legacy to
siso or mimo the wrong expected throughput table was used as it
was chosen based on the the channel bandwidth in legacy which is
always 20Mhz. Instead it should be chosen based on the current sta
bandwidth which could be also 40Mhz or 80Mhz.
When enabling MCS9 this bug leads to a problem where the max
expected throughput of the siso or mimo column is 0 as MCS9 isn't
supported in 20Mhz. This in turns prevents switching to siso or mimo.

Fix this by using the sta bandwidth when deciding which table to choose.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: rs: avoid TPC while in search cycle

TPC is a power optimization which should only be attempted when
we're in the "stay in column" state after we've locked onto an optimal
rate.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: rs: don't allow TPC when power save is disabled

Currently we were checking only if the driver power_scheme is set
to CAM. TPC shouldn't be enabled also when disabling powersave on the
interface (e.g. iw wlan0 set power_save off)
which may occur even if power_scheme wasn't set to CAM.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: rs: overhaul rs_get_best_rate

rs_get_best_rate determines the optimal rate to try in a
new Tx column. Currently we were sometimes trying a too high
rate which would lead us to fail and avoid switching to the
new column despite it having a potential to be better.
Change the logic to try and find the first rate which would
exceed the current actual throughput or be more aggressive
if the success ratio is good.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: rs: revert changes to search cycle rules

Adding more options in the search cycle causes longer
search cycles with additional wondering off to non optimal Tx
configurations. Reduce the Tx configurations searched to
improve throughput in non optimal attenuations.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

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

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

iwlwifi: mvm: rs - s/CPTCFG/CONFIG

My bad - I forgot to update this when sending the patch
upstream.

Fixes: 87d5e4155c00 ("iwlwifi: mvm: rs: reinit rs if no tx for a long time")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

iwlwifi: mvm: BT Coex - fix validity flags during init

The commit below introduced a bug in the validity bits in
init. Due to that, all the Coex mechanism stopped sending
kills to the BT side. Fix that.

Fixes: b9fae2d54c9f ("iwlwifi: mvm: BT Coex add support for Co-running block")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

rsi: Changing opcode for sta mode according to changes in firmware

Signed-off-by: Jahnavi Meher <jahnavi.meher@redpinesignals.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: fix worse EVM for 11b rates

Adjust FIR filter co-efficients to improve EVM for 11b rates.

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

ath9k_hw: update ar9300 initvals

 * rfsat gainchange hysteresis of rf_gain stuck with large
   interference present.

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

b43: N-PHY: complete radio 0x2056 setup

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath5k: Fix AR5K_PHY_TXPOWER_RATE_MAX register value setting.

I was reading ath5k power setting code and
noticed typing error in ath5k_hw_txpower function.
Invalid value was written to AR5K_PHY_TXPOWER_RATE_MAX
register.

Signed-off-by: Nikolay Ledovskikh <nledovskikh@gmail.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: Convert /n to \n

Use a newline character appropriately.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

wlcore: fix usage of platform_device_add_data()

Coverity CID 986698 reports leakage of struct wlcore_platdev_data in the
probe functions of both the SPI/SDIO interfaces. The structure passed to
platform_device_add_data() is dynamically allocated and only freed in the
error paths, however, platform_device_add_data() adds a copy of the platform
specific data to the device. Move the temporary struct that is kmemdup'ed
to the stack. This issue exists since afb43e6d (wlcore: remove if_ops from
platform_data).

Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rtlwifi: rtl8723be: disable MSI interrupts mode

94010fa0dd07e8b904e7c6b6589f15573008ab15 ("rtlwifi: add MSI interrupts
mode support") introduced MSI interrupts mode support, which seemed
safe enough with RTL8188EE and RTL8723BE as RealTek's testing results,
but some users reported their RTL8188EE modules could not connect to
any wireless network after the MSI mode was enabled by Ubuntu 14.04.

So, let's fallback to pin-based mode until rtlwifi's MSI support get
good compatibility.

BugLink: https://bugs.launchpad.net/bugs/1310512
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Revert "rtlwifi: rtl8188ee: enable MSI interrupts mode"

This reverts commit 2a54eb5e1476426ee639bbfbe179b52342a0d82c
("rtlwifi: rtl8188ee: enable MSI interrupts mode").

94010fa0dd07e8b904e7c6b6589f15573008ab15 ("rtlwifi: add MSI interrupts
mode support") introduced MSI interrupts mode support, which seemed
safe enough with RTL8188EE and RTL8723BE as RealTek's testing results,
but some users reported their RTL8188EE modules could not connect to
any wireless network after the MSI mode was enabled by Ubuntu 14.04.

So, let's fallback to pin-based mode until rtlwifi's MSI support get
good compatibility.

BugLink: https://bugs.launchpad.net/bugs/1310512
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: don't pre-set radio_on variable to true

Setting it to true during init doesn't seem to be any workaround while
it can cause problems (not enabling radio due to belief it's enabled).

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: use b43_software_rfkill helper

This removes dealing with pointers directly and allows tracking radio
state with radio_on variable.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: bcma: respect GMODE (band choice) during core reset

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

Conflicts:
net/mac80211/chan.c

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

mac80211_hwsim: Advertise support for AP mode channel width changes

mac80211 takes care of all the needed steps for hwsim, so indicate
support for this capability.

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: Support dynamic AP mode channel width changes

Implement the new cfg80211 capability to enable mac80211-based drivers
to support for dynamic channel bandwidth changes (e.g., HT 20/40 MHz
changes).

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: Dynamic channel bandwidth changes in AP mode

This extends NL80211_CMD_SET_CHANNEL to allow dynamic channel bandwidth
changes in AP mode (including P2P GO) during a lifetime of the BSS. This
can be used to implement, e.g., HT 20/40 MHz co-existence rules on the
2.4 GHz band.

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: remove unnecessary assignment

P2P_DEVICE doesn't support ieee80211_bss_info_change_notify() for now,
so it's not needed to set changed flags for P2P_DEVICE.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: avoid calling useless channel context code

ieee80211_assign_chanctx() checks if local->use_chanctx is true, so
the two code block related to ieee80211_assign_chanctx() can be moved
into above if clause, emphasize that these code are executed only if
local->use_chanctx is true.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
[change subject]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: Use 5MHz bandwidth by default when checking usable channels

Current code checks if the 20MHz bandwidth is allowed for
particular channel -- if it is not, the channel is disabled.
Since we need to use 5/10 MHz channels, this code is modified in
the way that the default bandwidth to check is 5MHz. If the
maximum bandwidth allowed by the channel is smaller than 5MHz,
the channel is disabled. Otherwise the channel is used and the
flags are set according to the bandwidth allowed by the channel.

Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: Add attributes describing prohibited channel bandwidth

Since there are frequency bands (e.g. 5.9GHz) allowing channels
with only 10 or 5 MHz bandwidth, this patch adds attributes that
allow keeping track about this information.

When channel attributes are reported to user-space, make sure to
not break old tools, i.e. if the 'split wiphy dump' is enabled,
report the extra attributes (if present) describing the bandwidth
restrictions.  If the 'split wiphy dump' is not enabled,
completely omit those channels that have flags set to either
IEEE80211_CHAN_NO_10MHZ or IEEE80211_CHAN_NO_20MHZ.

Add the check for new bandwidth restriction flags in
cfg80211_chandef_usable() to comply with the restrictions.

Signed-off-by: Rostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: change return value of notifier function

Return NOTIFY_DONE if we don't care this time's notification, return
NOTIFY_OK if we successfully handled this time's notification. That's
the formal way to do it.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: change return value of notifier function

Return NOTIFY_DONE if we don't care this time's notification, return
NOTIFY_OK if we successfully handled this time's notification. That's
the formal way to do it.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: change wiphy_to_dev function name

Name wiphy_to_rdev is more accurate to describe what the function
does, i.e., return a pointer pointing to struct
cfg80211_registered_device.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

cfg80211: change registered device pointer name

Name "dev" is too common and ambiguous, let all the pointer name
pointing to struct cfg80211_registered_device be "rdev". This can
improve code readability and consistency(since other places have
already called it rdev).

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: remove unnecessary BUG_ON()

The BUG_ON(!err) can't be triggered in the code path, so remove
it.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: return bool instead of numbers in yes/no function

And some code style changes in the function, and correct a typo in
comment.

Signed-off-by: Zhao, Gang <gamerh2o@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: add option to generate CCMP IVs only for mgmt frames

Some chips can encrypt managment frames in HW, but
require generated IV in the frame. Add a key flag
that allows us to achieve this.

Signed-off-by: Marek Kwaczynski <marek.kwaczynski@tieto.com>
[use BIT(0) to fill that spot, fix indentation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

mac80211: compute chanctx refcount on-the-fly

It doesn't make much sense to store refcount in
the chanctx structure. One still needs to hold
chanctx_mtx to get the value safely. Besides,
refcount isn't on performance critical paths.

This will make implementing chanctx reservation
refcounting a little easier.

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

mac80211: fix racy usage of chanctx->refcount

Channel context refcount is protected by
chanctx_mtx. Accessing the value without holding
the mutex is racy. RCU section didn't guarantee
anything here.

Theoretically ieee80211_channel_switch() could
fail to see refcount change and read "1" instead
of, e.g. "2". This means mac80211 could accept CSA
even though it shouldn't have.

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

mac80211: split ieee80211_free_chanctx()

The function did a little too much. Split it up so
the code can be easily reused in the future.

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

mac80211: split ieee80211_new_chanctx()

The function did a little too much. Split it up so
the code can be easily reused in the future.

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

mac80211: improve chanctx reservation lookup

Use a separate function to look for reservation
chanctx. For multi-interface/channel reservation
search sematics differ slightly.

The new routine allows reservations to be merged
with chanctx that are already reserved by other
interface(s).

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

mac80211: improve find_chanctx() for reservations

This allows new vifs to be assigned to a chanctx
as long as chanctx's reservation chandefs (if any)
and chanctx's current chandef (implied by assigned
vifs at the time, if any) and the new vif chandef
are all compatible.

This implies it is impossible to assign a new vif
to an in-place reservation chanctx.

This gives no advantages for single-channel
hardware. It makes sense for multi-channel
hardware only.

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

mac80211: track reserved vifs in chanctx

This can be useful. Provides a more straghtforward
way to iterate over interfaces taking part in
chanctx reservation and allows tracking chanctx
usage explicitly.

The structure is protected by local->chanctx_mtx.

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

mac80211: track assigned vifs in chanctx

This can be useful. Provides a more straghtforward
way to iterate over interfaces bound to a given
chanctx and allows tracking chanctx usage
explicitly.

The structure is protected by local->chanctx_mtx.

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