linux-stable.git/drivers/net/wireless/intel, branch v4.7.2

iwlwifi: add new 8265

2016-08-20T16:10:53+00:00

commit f24bbae565d279cd90c904fe55b539a45631705e upstream.

Add 6 new 8265 series PCI IDs:
  - (0x24FD, 0x1130)
  - (0x24FD, 0x0130)
  - (0x24FD, 0x0910)
  - (0x24FD, 0x0930)
  - (0x24FD, 0x0950)
  - (0x24FD, 0x0850)

Signed-off-by: Oren Givon 
Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add new 8260 PCI IDs

2016-08-20T16:10:53+00:00

commit 4b79deece5d45396422d469afa11f9d69ccb3d8b upstream.

Add 3 new 8260 series PCI IDs:
  - (0x24F3, 0x10B0)
  - (0x24F3, 0xD0B0)
  - (0x24F3, 0xB0B0)

Signed-off-by: Oren Givon 
Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: fix a race in firmware loading flow

2016-08-20T16:10:53+00:00

commit f16c3ebfa64fdf0e2dc88e6baa72da95ab70ffd7 upstream.

Upon firmware load interrupt (FH_TX), the ISR re-enables the
firmware load interrupt only to avoid races with other
flows as described in the commit below. When the firmware
is completely loaded, the thread that is loading the
firmware will enable all the interrupts to make sure that
the driver gets the ALIVE interrupt.
The problem with that is that the thread that is loading
the firmware is actually racing against the ISR and we can
get to the following situation:

CPU0					CPU1
iwl_pcie_load_given_ucode
	...
	iwl_pcie_load_firmware_chunk
		wait_for_interrupt
					
					ISR handles CSR_INT_BIT_FH_TX
					ISR wakes up the thread on CPU0
	/* enable all the interrupts
	 * to get the ALIVE interrupt
	 */
	iwl_enable_interrupts
					ISR re-enables CSR_INT_BIT_FH_TX only
	/* start the firmware */
	iwl_write32(trans, CSR_RESET, 0);

BUG! ALIVE interrupt will never arrive since it has been
masked by CPU1.

In order to fix that, change the ISR to first check if
STATUS_INT_ENABLED is set. If so, re-enable all the
interrupts. If STATUS_INT_ENABLED is clear, then we can
check what specific interrupt happened and re-enable only
that specific interrupt (RFKILL or FH_TX).

All the credit for the analysis goes to Kirtika who did the
actual debugging work.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: enable interrupts before releasing the NIC's CPU

2016-08-20T16:10:53+00:00

commit 2aabdbdc17b7c53490337bfc58de3409c84d85d2 upstream.

The NIC's CPU gets started after the firmware has been
written to its memory. The first thing it does is to
send an interrupt to let the driver know that it is
running. In order to get that interrupt, the driver needs
to make sure it is not masked. Of course, the interrupt
needs to be enabled in the driver before the CPU starts to
run.
I mistakenly inversed those two steps leading to races
which prevented the driver from getting the alive interrupt
from the firmware.
Fix that.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix a few firmware capability checks

2016-06-10T11:20:08+00:00

My cleanup in "iwlwifi: prepare for higher API/CAPA bits" accidentally
inverted a few tests - fix them.

Fixes: 859d914c8f5c ("iwlwifi: prepare for higher API/CAPA bits")
Reported-by: Sara Sharon 
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho

iwlwifi: mvm: set the encryption type of an IGTK key

2016-06-10T10:48:12+00:00

The FW expect the driver to set the encryption algorithm type when
installing the IGTK key in the HW.
Currently when installing CMAC IGTK key we don't set the algorithm type
and as a result the FW fails to calculate the MIC of multicast management
frames.
Fix it.

Signed-off-by: Ayala Beker 
Signed-off-by: Luca Coelho

iwlwifi: mvm: fix potential NULL-dereference in iwl_mvm_reorder()

2016-06-10T10:34:34+00:00

We try to access sta before we check for IS_ERR_OR_NULL(), so we may
end up accessing a NULL pointer.  To prevent that, move the conversion
from sta to mvm_sta below the check.

Fixes: b915c10174fb ("iwlwifi: mvm: add reorder buffer per queue")
Reported-by: Dan Carpenter 
Signed-off-by: Luca Coelho

iwlwifi: mvm: fix RCU splat in TKIP's update_key

2016-06-10T10:32:25+00:00

The commit below mistakenly changed an rcu_dereference_check
to a rcu_dereference_protected which introduced the
following RCU warning:

[ INFO: suspicious RCU usage. ]
 4.6.0-rc7-next-20160513-dbg-00004-g8de8b92-dirty #655 Not tainted
 -------------------------------
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:1069 suspicious rcu_dereference_protected() usage!
 Call Trace:
  [] lockdep_rcu_suspicious+0xf7/0x100
  [] iwl_mvm_get_key_sta.part.0+0x5d/0x80 [iwlmvm]
  [] iwl_mvm_update_tkip_key+0xd3/0x162 [iwlmvm]
  [] iwl_mvm_mac_update_tkip_key+0x17/0x19 [iwlmvm]
  [] ieee80211_tkip_decrypt_data+0x22c/0x24b [mac80211]
  [] ieee80211_crypto_tkip_decrypt+0xc5/0x110 [mac80211]
  [] ieee80211_rx_handlers+0x9bb/0x1fe1 [mac80211]

Fixes: 13303c0fb148 ("iwlwifi: mvm: use helpers to get iwl_mvm_sta")
Reported-by: Sergey Senozhatsky 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho

iwlwifi: mvm: increase scan timeout to 20 seconds

2016-06-10T09:50:53+00:00

The 16 seconds timeout we were using turned out to be too short.
Recalculations by system show that the total time in both bands should
be < 18.5 seconds, even in the slowest cases (e.g. DCM P2P with
DTIM=2).  Rounding it up to 20 seconds for a bit more safety.

Fixes: 728e825f81b1 ("iwlwifi: mvm: add a scan timeout for regular scans")
Signed-off-by: Luca Coelho

Merge tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2016-05-21T04:26:15+00:00

Pull driver core updates from Greg KH:
 "Here's the "big" driver core update for 4.7-rc1.

  Mostly just debugfs changes, the long-known and messy races with
  removing debugfs files should be fixed thanks to the great work of
  Nicolai Stange.  We also have some isa updates in here (the x86
  maintainers told me to take it through this tree), a new warning when
  we run out of dynamic char major numbers, and a few other assorted
  changes, details in the shortlog.

  All have been in linux-next for some time with no reported issues"

* tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits)
  Revert "base: dd: don't remove driver_data in -EPROBE_DEFER case"
  gpio: ws16c48: Utilize the ISA bus driver
  gpio: 104-idio-16: Utilize the ISA bus driver
  gpio: 104-idi-48: Utilize the ISA bus driver
  gpio: 104-dio-48e: Utilize the ISA bus driver
  watchdog: ebc-c384_wdt: Utilize the ISA bus driver
  iio: stx104: Utilize the module_isa_driver and max_num_isa_dev macros
  iio: stx104: Add X86 dependency to STX104 Kconfig option
  Documentation: Add ISA bus driver documentation
  isa: Implement the max_num_isa_dev macro
  isa: Implement the module_isa_driver macro
  pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS
  isa: Decouple X86_32 dependency from the ISA Kconfig option
  driver-core: use 'dev' argument in dev_dbg_ratelimited stub
  base: dd: don't remove driver_data in -EPROBE_DEFER case
  kernfs: Move faulting copy_user operations outside of the mutex
  devcoredump: add scatterlist support
  debugfs: unproxify files created through debugfs_create_u32_array()
  debugfs: unproxify files created through debugfs_create_blob()
  debugfs: unproxify files created through debugfs_create_bool()
  ...