Not all calls to the function brcmf_sdio_addrprep() check
the return value, but it may fail so better verify it.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The function brcmf_sdio_sglist_rw() does a different code path
when packet queue length is 1. Move this to a separate function
reducing overhead in the calling context.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The function brcmf_sdio_buffrw() is intended to be used for
transfering list of packets using scatter-gather functionality.
Rename function to brcmf_sdio_sglist_rw() to clarify this.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Moving a number of assignments outside of the loop as they are
the same for each request.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of determining the limits for scatter-gather MMC transfer
request upon each transmit it is now determined during the probe
of the SDIO function.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The variable max_seg_sz in brcmf_sdio_buffrw() respresents the maximum
number of buffers that can be sent in one MMC transfer request. Rename
it to max_seg_cnt to avoid confusion.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Having the SDPCM header information in the traces is a valuable
piece of information.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The trace function trace_brcmf_hexdump() stores the length, but
having the address of the buffer being dumped helps putting it
in context.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TX99 support enables Specific Absorption Rate (SAR) testing.
SAR is the unit of measurement for the amount of radio frequency(RF)
absorbed by the body when using a wireless device. The RF
exposure limits used are expressed in the terms of SAR, which is a
measure of the electric and magnetic field strength and power density
for transmitters operating at frequencies from 300 kHz to 100 GHz.

Regulatory bodies around the world require that wireless device
be evaluated to meet the RF exposure limits set forth in the
governmental SAR regulations.

In the examples below, for more bit rate options see the iw TX bitrate
setting documentation:

http://wireless.kernel.org/en/users/Documentation/iw#Modifying_transmit_bitrates

Example usage:

iw phy phy0 interface add moni0 type monitor
ip link set dev moni0 up

iw dev moni0 set channel 36 HT40+
iw set bitrates mcs-5 4

echo 10 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99_power
echo 1  > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_get_rts_cts_rate() can return NULL, so don't rely
on its members when it does return NULL.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This enables support for dynamic user regulatory hints.
This is enabled only when CFG80211_CERTIFICATION_ONUS
is selected. For US and JP this is explicitly disabled
unless the systems are being used for strict controlled
testing.
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On the regulatory notifier split up the parsing of the
hints coming from drivers or user. We'll treat these
separately.
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This moves the dynamic regulatory domain selection code into
a helper.
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Drivers can now use this to parse the regulatory request and
be more verbose when needed.
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If the RF chip supports more than 14 channels that
indirectly means that it supports the 5GHz band.
Use this fact to enable 5GHz band support instead
of setting SUPPORT_BAND_5GHZ separately for each
RF chip.

Also move the setup code of the 2GHz band to the
same place.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is much more readable than multiple if-else-if
statements.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The {rx,tx}_chain_num fields of rt2x00dev->default_ant
contains the number of RX and TX chains already when the
rt2800_probe_hw_mode() function runs. Use those values
instead of parsing the EEPROM configuration values again.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move the DFS pattern detector code to the ath module so
the other Atheros drivers can make us of it. This makes
no functional changes.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use CFG80211_CERTIFICATION_ONUS flag in the DFS
detector code. This is required as a preparation
for moving DFS detector code from ath9k to ath
module.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move ath_dfs_pool_stats to dfs_pattern_detector
code to be not specyfic only for ath9k.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Kill of using ath9k_hw_common() function
in dfs detector code.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Previously, each bus type was responsible for freeing the firmware
structure, but some did that badly.  Move responsibility for freeing
firmware into firmware.c so that it's done once and correctly, instead
of happening in multiple places in bus-specific code.

This fixes a use-after-free bug found by Dr. H. Nikolaus Schaller where
the SDIO code forgot to NULL priv->helper_fw after freeing it.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add spectral scan feature on HT40 channels for ath9k. This patch extends
previous capability added by Simon Wunderlich
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Reviewed-by: NSimon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Tested-by: NSimon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add nf parameter to ath9k_hw_getchan_noise() in order to compute NF for EXT
chains with the same scale of noise floor calculated on CTL chains.
ath9k_hw_getchan_noise() will be used in ath_process_fft() for spectral scan on
HT40 channels
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Samuel Ortiz <sameo@linux.intel.com> says:

"This is the first NFC pull request for the 3.13 kernel.
It's a fairly big one, with the following highlights:

- NFC digital layer implementation: Most NFC chipsets implement the NFC
  digital layer in firmware, but others have more basic functionalities
  and expect the host to implement the digital layer. This layer sits
  below the NFC core.

- Sony's port100 support: This is "soft" NFC USB dongle that expects the
  digital layer to be implemented on the host. This is the first user of
  our NFC digital stack implementation.

- Secure element API: We now provide a netlink API for enabling,
  disabling and discovering NFC attached (embedded or UICC ones) secure
  elements. With some userspace help, this allows us to support NFC
  payments.
  Only the pn544 driver currently supports that API.

- NCI SPI fixes and improvements: In order to support NCI devices over
  SPI, we fixed and improved our NCI/SPI implementation. The currently
  most deployed NFC NCI chipset, Broadcom's bcm2079x, supports that mode
  and we're planning to use our NCI/SPI framework to implement a
  driver for it.

- pn533 fragmentation support in target mode: This was the only missing
  feature from our pn533 impementation. We now support fragmentation in
  both Tx and Rx modes, in target mode."
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

Integers need to be multiplied before division.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The fw_rx_stats entry in debugfs was getting truncated because the
internal buffer used to hold the string was too short.  The
calculation of the needed buffer size was rather bogus.

Simplify the calculation by multiplying the number of entries in the
entire structure by the size of each data line and adding the size of
the header lines.

Additionally, add the mac_id value, which was missing.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The activity grading indication from the firmware should
not be used in this case, but the bt_status in the firwmare
notification.
Fix that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The firmware always expects the Coex Mode to be set.
Moreover, the firmware expects bit 0 is the valid bits to
be set all the times.
I misunderstood the API and didn't set these bits when
commands are sent to update the paramters of the Coex. As
a result, the firmware understood that the BT Coex was
disabled (Coex mode = 0) and ignored all the updates (valid
bit 0 clear).

Fix that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Section size limitation to 6000 is incorrect.
NVM file need to support bigger sections in order
to support PAPD tables.
Signed-off-by: NIdan Kahlon <idanx.kahlon@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: NMaor Perez <maorx.perez@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ath10k_wmi_cmd_send() will now sleep if there are no credits available.
To make it easier to catch callers in atomic context add might_sleep()
to the function.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

ath10k_bss_assoc() was calling ath10k_peer_assoc(), which can sleep, under
atomic rcu_read_lock() and causing scheduing while atomic errors. Workaround
that by delaying the call to ath10k_wmi_peer_assoc().
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

mac80211 interface iteration functions that were
used originally iterated over interfaces that
weren't re-added to the driver during recovery.

Since internal vif list is now used it's safe to
remove the safe-guard as internal vif list is
based on add/remove_interface function which
guarantees that vdev is created in FW before it is
iterated over.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Recent HTC/WMI changes introduced the bug. ath10k
was using _atomic iteration function with
sleepable functions.

mac80211 provides another iteration function but
it cannot be safely called in hw_config() callback
due to local->iflist_mtx being possibly acquired
already.

The patch uses internal vif list for iteration
purposes and removes/refactors no longer necessary
_iter functions.
Reported-By: NKalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

mac80211 interface interations functions have
peculiar locking issues. This patch introduces
internal (to ath10k) vif list that will be used
for vif iteration purposes.

kvalo: remove extra INIT_LIST_HEAD()
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

If something failed along add_interface() setup it
was possible to leak a vdev id, vdev and peer.

This could end up with leaked FW state or FW crash
(assuming add_interface() failure wasn't a result of
a crash).

kvalo: rebased, whitespace fixes
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Recent WMI/HTC changes made it possible for WMI
commands to sleep (if there's not enough HTC TX
credits to submit a command). TX path is in an
atomic context so calling WMI commands in it is
wrong.

This simply moves WEP key index update to a worker
and fixes the 'scheduling while atomic' bug.

This still leaves multiple WEP key handling laggy,
i.e. some frames may be TXed with an old/different
key (although recipient should still be able to RX
them).

kvalo: changed the title
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>