Commit Graph

481058 Commits

Author SHA1 Message Date
Mark A. Greer 49dbb14e30 NFC: digital: Add NFC-DEP Target-side NACK Support
When an NFC-DEP Target receives a NACK PDU with
a PNI equal to 1 less than the current PNI, it
is supposed to re-send the last PDU.  This is
implied in section 14.12.5.4 of the NFC Digital
Protocol Spec.

The digital layer's NFC-DEP code doesn't implement
Target-side NACK handing so add it.  The last PDU
that was sent is saved in the 'nfc_digital_dev'
structure's 'saved_skb' member.  The skb will have
an additional reference taken to ensure that the skb
isn't freed when the driver performs a kfree_skb()
on the skb.  The length of the skb/PDU is also saved
so the length can be restored when re-sending the PDU
in the skb (the driver will perform an skb_pull() so
an skb_push() needs to be done to restore the skb's
data pointer/length).

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:39:47 +01:00
Mark A. Greer a80509c76b NFC: digital: Add NFC-DEP Initiator-side NACK Support
When an NFC-DEP Initiator receives a frame with
an incorrect CRC or with a parity error, and the
frame is at least 4 bytes long, its supposed to
send a NACK to the Target.  The Initiator can
send up to 'N(retry,nack)' consecutive NACKs
where 2 <= 'N(retry,nack)' <= 5.  When the limit
is exceeded, a PROTOCOL EXCEPTION is raised.
Any other type of transmission error is to be
ignored and the Initiator should continue
waiting for a new frame.  This is described
in section 14.12.5.4 of the NFC Digital Protocol
Spec.

The digital layer's NFC-DEP code doesn't implement
any of this so add it.  This support diverges from
the spec in two significant ways:

a) NACKs will be sent for ANY error reported by the
   driver except a timeout.  This is done because
   there is currently no way for the digital layer
   to distinguish a CRC or parity error from any
   other type of error reported by the driver.

b) All other errors will cause a PROTOCOL EXCEPTION
   even frames with CRC errors that are less than 4
   bytes.

The value chosen for 'N(retry,nack)' is 2.

Targets do not send NACK PDUs.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:39:33 +01:00
Mark A. Greer c12715ab3f NFC: digital: Add NFC-DEP Receive Chaining Support
When the peer in an NFC-DEP exchange has a
packet to send that is larger than the local
maximum payload, it sets the 'MI' bit in the
'I' PDU.  This indicates that NFC-DEP chaining
is to occur.

When such a PDU is received, the local side
responds with an 'ACK' PDU and this continues
until the peer sends an 'I' PDU with the 'MI'
bit cleared.  This indicates that the chaining
sequence is complete and the entire packet has
been transferred.

Receiving chained PDUs is currently not supported
by the digital layer so add that support.  When a
chaining sequence is initiated by the peer, the
digital layer will allocate an skb large enough
to hold 8 maximum sized frame payloads.  The maximum
payload can range from 64 to 254 bytes so 8 * 254 =
2032 seems like a reasonable compromise between
potentially wasting memory and constantly reallocating
new, larger skbs.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:39:21 +01:00
Mark A. Greer 3bd2a5bcc6 NFC: digital: Add NFC-DEP Send Chaining Support
When the NFC-DEP code is given a packet to send
that is larger than the peer's maximum payload,
its supposed to set the 'MI' bit in the 'I' PDU's
Protocol Frame Byte (PFB).  Setting this bit
indicates that NFC-DEP chaining is to occur.

When NFC-DEP chaining is progress, sender 'I' PDUs
are acknowledged with 'ACK' PDUs until the last 'I'
PDU in the chain (which has the 'MI' bit cleared)
is responded to with a normal 'I' PDU.  This can
occur while in Initiator mode or in Target mode.

Sender NFC-DEP chaining is currently not implemented
in the digital layer so add that support.  Unfortunately,
since sending a frame may require writing the CRC to the
end of the data, the relevant data part of the original
skb must be copied for each intermediate frame.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:39:10 +01:00
Mark A. Greer b08147cbc4 NFC: digital: Implement NFC-DEP max payload lengths
The maximum payload for NFC-DEP exchanges (i.e., the
number of bytes between SoD and EoD) is negotiated
using the ATR_REQ, ATR_RES, and PSL_REQ commands.
The valid maximum lengths are 64, 128, 192, and 254
bytes.

Currently, NFC-DEP code assumes that both sides are
always using 254 byte maximums and ignores attempts
by the peer to change it.  Instead, implement the
negotiation code, enforce the local maximum when
receiving data from the peer, and don't send payloads
that exceed the remote's maximum.  The default local
maximum is 254 bytes.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:38:59 +01:00
Mark A. Greer 485fdc9bb6 NFC: digital: Enforce NFC-DEP PNI sequencing
NFC-DEP DEP_REQ and DEP_RES exchanges using 'I'
and 'ACK/NACK' PDUs have a sequence number called
the Packet Number Information (PNI).  The PNI
is incremented (modulo 4) after every DEP_REQ/
DEP_RES pair and should be verified by the digital
layer code.  That verification isn't always done,
though, so add code to make sure that it is done.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:38:47 +01:00
Mark A. Greer 3e6b0de805 NFC: digital: Ensure no NAD byte in DEP_REQ and DEP_RES frames
According to chapter 14 of the NFC-DEP Digital
Protocol Spec., the NAD byte should never be
present in DEP_REQ or DEP_RES frames.  However,
this is not enforced so add that enforcement code.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:38:36 +01:00
Mark A. Greer 05afedcb89 NFC: digital: Add Target-mode NFC-DEP DID Support
When in Target mode, the Initiator specifies whether
subsequent DEP_REQ and DEP_RES frames will include
a DID byte by the value passed in the ATR_REQ.  If
the DID value in the ATR_REQ is '0' then no DID
byte will be included.  If the DID value is between
'1' and '14' then a DID byte containing the same
value must be included in subsequent DEP_REQ and
DEP_RES frames.  Any other DID value is invalid.
This is specified in sections 14.8.1.2 and 14.8.2.2
of the NFC Digital Protocol Spec.

Checking the DID value (if it should be there at all),
is not currently supported by the digital layer's
NFC-DEP code.  Add this support by remembering the
DID value in the ATR_REQ, checking the DID value of
received DEP_REQ frames (if it should be there at all),
and including the remembered DID value in DEP_RES
frames when appropriate.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:38:24 +01:00
Mark A. Greer 3bc3f88af5 NFC: digital: Ensure no DID in NFC-DEP responses
When in Initiator mode, the digital layer's
NFC-DEP code always sets the Device ID (DID)
value in the ATR_REQ to '0'.  This means that
subsequent DEP_REQ and DEP_RES frames must
never include a DID byte.  This is specified
in sections 14.8.1.1 and 14.8.2.1 of the NFC
Digital Protocol Spec.

Currently, the digital layer's NFC-DEP code
doesn't enforce this rule so add code to ensure
that there is no DID byte in DEP_RES frames.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:38:10 +01:00
Mark A. Greer 6ce306682f NFC: digital: Rearrange NFC-DEP DEP_REQ/DEP_RES Code
Rearrange some of the code in digital_in_recv_dep_res()
and digital_tg_recv_dep_req() so the initial code looks
similar.  The real reason is prepare the code for some
upcoming patches that require these changes.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:37:58 +01:00
Mark A. Greer b15829ba5e NFC: digital: Fix potential skb leaks in NFC-DEP code
When digital_in_send_cmd() or digital_tg_send_cmd()
fail, they do not free the skb that was passed to
them so the routine that allocated the skb should
free it.  Currently, there are several routines in
the NFC-DEP code that don't do this so make them.

Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com>
Tested-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28 12:37:47 +01:00
Amitkumar Karwar 18ca43823f mwifiex: add Tx status support for ACTION frames
ACK status (0/1) for ACTION frames is informed to cfg80211. We
will extend existing logic used for EAPOL frames. The cfg80211
API is different here. Also, we need to explicitly free cloned
skb.

Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:57 -05:00
Amitkumar Karwar 808bbebcc8 mwifiex: add Tx status support for EAPOL packets
Firmware notifies the driver through event if EAPOL data packet
has been acked or not. We will inform this status to userspace
listening on a socket.

Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:56 -05:00
Amitkumar Karwar 381e9fffe6 mwifiex: skip delay main work logic for USB interface.
We had introduced delay main work logic to avoid processing
interrupts when Rx pending packet count reaches high threshold.
interrupt processing is restarted later when packet count
reduces lower threashold. This helped to reduce unnecessary
overhead and improve throughput for SD and PCIe chipsets.

As there are no interrupts for USB, we will skip this logic for
USB chipsets.

Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:56 -05:00
Amitkumar Karwar 798ea8eec1 mwifiex: fix scan problem on big endian platforms
This patch adds missing endian conversion for beacon size while
processing scan response.

Reported-by: Daniel Mosquera <daniel.mosquera@ctag.com>
Tested-by: Daniel Mosquera <daniel.mosquera@ctag.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:56 -05:00
Amitkumar Karwar 5197461115 mwifiex: fix sparse warning
This patch fixes following sparse warnings:

drivers/net/wireless/mwifiex/util.c:152:19: warning: cast from restricted __le16
drivers/net/wireless/mwifiex/util.c:152:19: warning: restricted __le16 degrades to integer

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:56 -05:00
Lorenzo Bianconi 8b537686a1 ath9k: add TPC capability to TX descriptor path
Add TPC capability to TX descriptor path. Cap per-packet TX power according to
TX power per-rate tables. Currently TPC is supported just by AR9003 based chips

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:56 -05:00
Lorenzo Bianconi 23f53dd306 ath9k: add TX power per-rate tables
Add TX power per-rate tables for different MIMO modes (e.g STBC) in order to
cap the maximum TX power value per-rate in the TX descriptor path.
Cap TX power for self generated frames (ACK, RTS/CTS).
Currently TPC is supported just by AR9003 based chips

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-25 14:09:56 -05:00
Arend van Spriel 4f3fff1486 brcmfmac: correct .disconnect() callback while connecting
When the driver has sent a join iovar to the firmware it waits
for the events to report result of the connection. However, the
wpa_supplicant will request a .disconnect() after a timeout. So
upon calling .disconnect() the interface state may still be
CONNECTING. Clear the CONNECTING bit as well.

Reviewed-by: Hante Meuleman <meuleman@broadcom.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>
2014-11-25 14:09:55 -05:00
Andreas Ruprecht b880c6deab net: wireless: rtlwifi: rtl8192ee: Fix compilation of the driver
In the Makefile for this driver, the wrong Kconfig option is used
to trigger the compilation of the object file. This leads to the
driver only being included into the kernel when both CONFIG_RTL8821AE
and CONFIG_RTL8192AE are set to "y".

Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-24 16:51:26 -05:00
Andreas Ruprecht 927a70874c net: wireless: rtlwifi: Do not always include drivers in obj-m
In four of the rtlwifi drivers, the Makefile contains superfluous
statements indicating the compilation of the driver as an LKM
regardless of the corresponding Kconfig option.

If the corresponding option is set to 'y', the build system will then
see the object file in obj-m and obj-y, which leads to a compilation
as a built-in only. Even though this leads to the desired behavior,
the unconditional appearance in obj-m is confusing for someone reading
the Makefile.

This patch removes the superfluous Makefile statements.

Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-24 16:51:25 -05:00
Vivek Natarajan 34b5d778b5 ath: Fix a false radar detection pattern
For FCC and JP, in one of the radar patterns, PPB and PRF seems to be
interchanged leading to frequent incorrect radar detections.

Signed-off-by: Vivek Natarajan <nataraja@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-24 16:51:24 -05:00
Ricardo Ribalda Delgado a831f20b6d wireless/p54: Remove duplicated net2280 header
The usb gadget driver net2280 has exported a header file with the
register definition of the net2280 chip.

Remove the custom/duplicated header file in favor of that header file
in include/linux

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-24 16:51:24 -05:00
Lorenzo Bianconi 99958588fc rtlwifi: update RCR register in rtl_op_configure_filter()
Reconfigure RCR register in rtl_op_configure_filter() in order to apply RX
filter configuration

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-24 16:51:23 -05:00
Arend van Spriel c15d789e3c brcmfmac: fix static checker warning in pmklist handling
The patch fixes a static checker warning:

   drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c:2965
      brcmf_cfg80211_set_pmksa()
	warn: can 'pmkid_len' be negative?

The answer to the question above is likely no so changing its
type to unsigned is sufficient.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.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>
2014-11-24 14:01:09 -05:00
John W. Linville ef16ea32db Major works are CSA and TDLS. On top of that I have a new
firmware API for scan and a few rate control improvements.
 Johannes find a few tricks to improve our CPU utilization
 and adds support for a new spin of 7265 called 7265D.
 Along with this a few random things that don't stand out.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJUc0DaAAoJEC0Llv5uNjIBNooP/Rha/45hJVmH+Wz2sLTOwssl
 jRDKnVT0uWlwUCZPhptxXF3u6hIwo7lcjHd4XUWUjEy/FuFRPFv71AwNxB1psxjL
 Ej+tZHrpFu1W58IYEuFuH6nw+FTt2sCcHqI276jldm0nm1CQyVjUja4Vw1uOuk2k
 dMgizYaWGGb4l5va+Pw6/N3Z3iinVhRc6keLAkW5FkuftMBeOYfg4qG3BIYxJU5P
 w5EeBj+ILW3uoPMZ76VV76KuwPNEL2ykNInXWYvfL20zTMiIef/XlM8JRgKAImIl
 a8YlrNSLNsFVQW75dcdNWBECmiQG7bE2QhlJYX7mlD4cIIVXPFH6a5BtF70YcIP/
 e3uTIi4OzKQBrGq4uE1nijMoHP+iCrPYJmBIbni5x95gy1MNStKHeuOHI5uDP+yc
 fyws9iQGxIy5d520vmwfLX/kAvRhUShI9eARkQxHeSirdF3W8pfXo5x2U2KO9NcJ
 UhUzpIZe9+CJVmRzdhG5v49H1w+nQeBpiLKJE0WmoN9Abk5m7mlSFLRrEQQbtQG5
 28pDUss6op2wxrOXgI6Z4GChDqbojle3bYQA/wR0g0cAO2SlW41FOuLzpEdQ0OuO
 aBpiTBKHuYNKizJVkR/qQv/8xR6lVqS1GNcaL+tn68MdKZAWb5J7VfDSpjQzTEzZ
 cfsVyD2BJtIHJupo12ei
 =yCnR
 -----END PGP SIGNATURE-----

Merge tag 'iwlwifi-next-for-john-2014-11-24' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next

Emmanuel Grumbach <egrumbach@gmail.com> says:

"Major works are CSA and TDLS. On top of that I have a new
firmware API for scan and a few rate control improvements.
Johannes find a few tricks to improve our CPU utilization
and adds support for a new spin of 7265 called 7265D.
Along with this a few random things that don't stand out."

Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-24 13:59:37 -05:00
Emmanuel Grumbach dcad8e4299 iwlwifi: update the secure mem space and for the CPUs
Also update the timeout for the data verification.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-11-24 08:30:44 +02:00
Oren Givon 3c4e2998a4 iwlwifi: sdio: new SDIO card id for 4165 series
Add a new SDIO card id intended for the new 4165 series.

Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-11-24 08:30:44 +02:00
Eliad Peller 47abce8f2d iwlwifi: declare d0i3 support for IWL_DEVICE_8000
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-11-24 08:30:43 +02:00
Arik Nemtsov e198f5e76f iwlwifi: mvm: disconnect TDLS peers before channel switch
In case of channel switch, we need to teardown the TDLS peers.

Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-11-24 08:30:42 +02:00
Eyal Shapira 339b30864e iwlwifi: mvm: declare support for VHT BF info in radiotap
The driver knows whether an rx frame was beamformed and marks
it in the radiotap VHT flags. However it should also declare
that it knows to extract this info otherwise this gets discarded
by sniffers like Wireshark.

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>
2014-11-24 08:30:41 +02:00
Chaya Rachel Ivgy 30269c125b iwlwifi: mvm: add support to MFUART loading notification
Add support to MFUART loading notification (print notification
data with IWL_DEBUG_INFO)

Signed-off-by: Chaya Rachel Ivgy <chaya.rachel.ivgi@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-11-24 08:30:41 +02:00
Eliad Peller 465921c841 iwlwifi: mvm: call iwl_trans_suspend/resume
call the appropriate iwl_trans_suspend/resume ops
on iwl_mvm_suspend/resume calls.

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>
2014-11-24 08:30:40 +02:00
Eliad Peller 8e551e503b iwlwifi: trans: add suspend/resume ops
Add suspend/resume trans ops that will be called from
mac80211's suspend/resume ops.

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>
2014-11-24 08:30:39 +02:00
Luciano Coelho 2021a89d7b iwlwifi: mvm: treat netdetect wake up separately
When the device wakes up due to netdetect, we need to query different
things from the firmware than when it wakes up with a normal WoWLAN.
To make this easier, separate the netdetect wake up handling from the
rest.  For now, we don't send netdetect as a wake up reason, treating
it as a non-wireless wake up.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2014-11-24 08:30:38 +02:00
Luciano Coelho ec12f457d6 iwlwifi: mvm: refactor iwl_mvm_query_wakeup_reasons()
Refactor the iwl_mvm_query_wakeup_reasons() function to split the part
that gets the firmware status from the part that sets up the WoWLAN
status.  This will allow netdetect to reuse the code.

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>
2014-11-24 08:30:38 +02:00
Luciano Coelho 3acc952b03 iwlwifi: mvm: refactor wowlan and netdetect configuration when suspending
We need to send a WOWLAN_CONFIGURATION command also for netdetect and
configure the rfkill release trigger if needed.  To do so, refactor
the code that configures wowlan and netdetect when suspending and send
the WOWLAN_CONFIGURATION command also for net_detect.

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>
2014-11-24 08:30:37 +02:00
Luciano Coelho c55385f55c iwlwifi: mvm: add support for net detect
Add the net detect WoWLAN flag to indicate support and use the
nd_config from the WoWLAN configuration to start net detect, if it is
set.  The WoWLAN configuration takes precedence over the debugfs
configuration.

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>
2014-11-24 08:30:36 +02:00
Luciano Coelho 686e7fe1c4 iwlwifi: mvm: protect session during CSA
When another vif is also running during a channel switch, we need to
use a session protection when we move to the new channel, so that we
don't miss the beacons.  Without this, sometimes the other vif
repeatedly gets time exactly when we should be hearing the beacons,
preventing channel switch from completing.  Adding a session
protection that lasts from the moment the channel changes until 2
TBTTs later, ensures that we will hear the beacons on the destination
channel.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:35 +02:00
Luciano Coelho 0c6505c6ed iwlwifi: mvm: clear TE data if CSA time event fails to start
If setting the CSA time event fails, we must clear the TE data,
otherwise we'll try to remove it when, for instance, a disconnection
occurs, causing a SYSASSERT.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:35 +02:00
Luciano Coelho c6e0a3e044 iwlwifi: mvm: disable beacon filtering during CSA
After a channel switch, transmission on the new channel is only
started once we see a beacon on it.  Thus, beacon filtering needs to
be disabled during channel switch so that mac80211 receives this
beacon and finishes the process.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:34 +02:00
Luciano Coelho 622e3f9b71 iwlwifi: mvm: add a channel_switch op to bypass mac80211 timer
We need to call ieee80211_chswitch_done() ourselves just when the
absence TE started, so we perform the actual context switch early
enough.  To do so, add a dummy channel_switch op, which will cause
mac80211 to skip the countdown timer and allow us to call
ieee80211_chswitch_done() to complete the operation.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:33 +02:00
Luciano Coelho a57c688d34 iwlwifi: mvm: finalize on post_switch instead of unassign
Now that mac80211 waits for the first beacon on the new channel before
calling post_channel_switch, the reconfiguration of the firmware
should be done in the post_channel_switch operation instead of when
assigning the vif to the new context.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:32 +02:00
Luciano Coelho 4500e13376 iwlwifi: mvm: schedule CSA time event a bit before beacon 1
Instead of using a hardcoded number of TUs before beacon 0 as the time
to start the absence and actual channel switch, calculate it in
relation to the beacon interval.  We use 10 TUs + beacon interval
before beacon 0 to target a bit before beacon 1.  This gives us enough
time to switch to the new channel before the AP/GO switches.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:32 +02:00
Luciano Coelho dc88b4baa9 iwlwifi: mvm: add CSA absent time event for clients
Add an absent time event when pre_channel_switch is called and use the
time event started indication to set the disable_tx bit instead of
doing it in unassign_vif().  This is done so that the firmware queues
are stopped before the actual switch takes place to avoid losing
packets while the AP/GO is performing its actual switch.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:31 +02:00
Luciano Coelho 4741dd049a iwlwifi: mvm: use switching_chanctx argument instead of csa_active
Now that all CSA flows are using the switch_vif_chanctx op, we can
rely on the switching_chanctx boolean that is passed to the
__iwl_mvm_assign_vif_chanctx() and __iwl_mvm_unassign_vif_chanctx()
functions to decide whether the context switch flows need to be
executed.  In this way we make the chanctx switch flow more generic,
without having to rely on the csa_active flag being set.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:30 +02:00
Luciano Coelho f6c34820d3 iwlwifi: mvm: disable PS during channel switch
Disable PS when pre_channel_switch is called and add the
post_channel_switch operation to re-enable PS when the channel switch
is completed.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:29 +02:00
Andrei Otcheretianski 7ef0aab66b iwlwifi: mvm: Handle failed beacon transmissions during CSA
The spec requires to decrement the CSA counters based on TBTT,
regardless if the beacon was actually transmitted. Previously, the fw
would send beacon notifications only for successfully transmitted
beacons. This behavior resulted in inaccurate CSA countdown. In order
to address this issue, the fw was changed to send beacon
notifications also for not transmitted beacons. Such notifications
have TX_STATUS_INTERNAL_ABORT (0x92).
Don't start the CSA countdown before first successfully transmitted
beacon, in order to guarantee that the CSA is announced for a
required period.

Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
2014-11-24 08:30:29 +02:00
Luciano Coelho 6fd1fb63ab iwlwifi: mvm: return the actual error code when switch_vif_chanctx fails
We have code to recover and go back to the original channel context if
something fails in the middle of switch_vif_chanctx, but we return the
error code of the recover calls instead of the original code, so if
the recovery succeeds, we will return 0 (success).  Fix this by not
assigning the return value of the recovery calls to ret.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:28 +02:00
Luciano Coelho 48a256e8ae iwlwifi: mvm: add support for CHANCTX_SWMODE_REASSIGN_VIF
Add support to reassign vif in switch_vif_chanctx.  This is similar to
the existing CHANCTX_SWMODE_SWAP_CONTEXTS mode, but doesn't delete the
old context nor creates a new one, doing to switch between two
existing contexts.

Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
2014-11-24 08:30:27 +02:00