The tx ring index was immediately trimmed with a
bitmask. This discarded the 0xFFFFFFFF error case
(which theoretically can happen when a device is
abruptly disconnected) and led to using an invalid
tx ring index. This could lead to memory
corruption.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

It was possible for tx completion not to be
processed. In that case an old stack pointer was
left on copy engine tx ring. Next bmi exchange
would immediately pop it and use complete() on the
completion struct there causing corruption.

Make sure to wait for both tx and rx completions
properly.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

If firmware probing worker failed it called
device_release_driver() which synchronously called
remove() pci callback. The callback in turn waited
for the worker that called it to finish resulting
in a deadlock.

Waiting for a completion instead of a worker, like
some other drivers do, doesn't seem like the best
idea either:

  Syscall                 Worker

                          probe_fw()
  rmmod
  dev_lock()
  pci->remove()
  wait_for_completion()
                          complete_all()
                          device_release_driver()
                          dev_lock()
                          [sleep]
  free(ar)
  dev_unlock()
                          [resume]

There's no guarantee that Worker upon resuming can
still access any data/code of the module.

Leaving device bound to a driver is not as harmful
as deadlocking so remove the call to
device_release_driver() while a proper solution is
figured out.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

This change enables ath6kl driver to support ar6004 hw3.0. At the same time do
some fixes in firmware initialisation which applies to ar6004 hw1.3 as well.
Signed-off-by: Jessica Wu <wjessica@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Some of the firmware versions support rate tables up to mcs15, add support for
that.
Signed-off-by: Jessica Wu <wjessica@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Needed for ar6004 hw3.0 support.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

rx flush was not implemented for htc pipe, add that now. Doesn't fix any known
issues.

Also free the skb if htc control messages get canceled.
Signed-off-by: Jessica Wu <wjessica@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The functionality defined through these flags were actually firmware features
which can change between firmware versions. To make it possible to support
different firmware versions with the same driver, convert the flags to firmware
feature flags.

For backwards compatibility support for old ar6004 firmware FW
API 3 or smaller images we forcefully set the feature bits in the driver.
Starting from FW API 5 the firmware image needs to set them.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

tmp may be used uninitialized if ath6kl_bmi_read() returns an error.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Allow to setup maximum subframes for AMSDU and AMPDU aggregation
via debugfs htt_max_amsdu_ampdu file.

Eg.
echo "2 64" > htt_max_amsdu_ampdu
will setup maximum amsdu subframes equal 2 and
maximum ampdu subframes equal to 64.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Print Kconfig options enabled/disabled in the build.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

These len variables are not used anywhere.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Print message if no events received. This should not happen.
If it is, it points to the problem in firmware.
Track also cases when multiple events processed in one IRQ

Print information as soon as possible - mbox pointers and
event header right after reading it. This helps to identify potential
problem with memory allocation for the event buffer.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

"NFC: 3.16: Second pull request

This is the 2nd NFC pull request for 3.16. We have:

- Felica (Type3) tags support for trf7970a
- Type 4b tags support for port100
- st21nfca DTS typo fix
- A few sparse warning check fixes"
Signed-off-by: John W. Linville <linville@tuxdriver.com>

A check for CONFIG_AUTOSUSPEND was included in this driver when it was
added in v2.6.39. But that Kconfig symbol doesn't exist. Remove that
check and the single line it hides.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

fw_common.h was included twice.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

phy.h was included twice.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Currently mac80211 does not support WDS and DFS with channel context
drivers. So advertise these features only when the driver is not
supporting channel context and modparam "use_chanctx" is introduced
for preparing channel context support in ath9k.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If host sleep parameter gap is set to 0xff, firmware will wait
for an ack from host to confirm the success of host wakeup.
This prevents firmware from uploading data packet before host
actually wakes up.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Current implementation sets tdls_link flag only while restoring
packets from TDLS queue. If traffic to peer starts after TDLS is
setup, there is no way to set TDLS link flag to true. Do this
while creating RA list and we confirm that there exist a TDLS
peer for which setup is complete.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

[113.967694] Unable to handle kernel NULL pointer dereference
               at virtual address 00000020
............
[113.967859] PC is at mwifiex_update_rxreor_flags+0xfc/0x430
............
[113.968110] mwifiex_update_rxreor_flags+0xfc/0x430
[113.968129] mwifiex_handle_event_ext_scan_report+0x1e4/0x21c
[113.968148] mwifiex_process_sta_event+0x410/0x508
[113.968165] mwifiex_process_event+0x184/0x1e0
[113.968181] mwifiex_main_process+0x220/0x48c
[113.968197] mwifiex_sdio_interrupt+0xc8/0x1cc
[113.968210] sdio_irq_thread+0x11c/0x290

In case of legacy scan, adapter->curr_cmd is guranteed to be
non-NULL in check_next_scan_cmd. This may not be case in
extended scan where scan command response would come earlier and
set curr_cmd to NULL. Extended scan event comes later and while
trying to complete IOCTL for scan, driver would crash in
dereferencing adapter->curr_cmd->wait_q_enabled.

Avoid this by completing IOCTL in case of legacy scans only.
Internal scan would be completed while handling extended scan
command response.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Broadcom's wl 6.30.223.141 has some optimizations for radios 0x205[67].
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

PHY has to be often re-initialized (e.g. during band switching after PHY
reset), however some operations have to be performed only once (only
power reset affects them).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In case of receiving frame with sequence number far greater than current,
wil_release_reorder_frames() will iterate many times over empty buffer.

Optimize this case by checking buffer emptiness and simply update
head_seq_num without iterating.
Suggested-by: Vladimir Shulman <Vladimir.Shulman@Wilocity.com>
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

use proper format %pad for the dma_addr_t arguments;
prefix %p with 0x, as %p don't print is by itself
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If scan has not finished in some reasonable time (10sec), interpret it as
if firmware error occurs but was not reported. Firmware should report
scan completion for every scan request, so it is error condition indeed.
Perform firmware recovery procedure.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Provide clear definition of the watermarks for the vring descriptor space.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In case there is something fundamentally wrong with the firmware
(example: RF cable disconnected), FW will always crash immediately
after reset. This leads to infinite fw error recovery loop.

Count consecutive unsuccessful error recovery attempts in a short period
of time, and stop doing recovery after some reasonable count.
It is still possible to manually reset fw doing
interface down/up sequence.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Obey 802.11 spec that defines max. data size 7920 bytes
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

pm_lock is taken twice while syncing HW TSF of p2p vif.
Fix this by taking the lock at caller side.

Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The USB driver was using a list for firmware info that was
used in suspend/resume scenario. Now that brcmfmac is using
the asynchronous firmware request this is no longer needed.
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>

The USB bus driver always configured an USB intr EP urb. The
driver did not use the result at all and with newer firmware it is
causing continues errors on this EP.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The max buffer size for receiving control message from dongle needs to be
increased considering possible block padding. Otherwise some big control
message can't be received due to buffer overrun check.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Daniel Kim <dekim@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The firmware channel specification is a bitfield using a
16-bit integer, but only 14 lsb are used. Upon encoding
this value assure all 16 bits are cleared.
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>

The function brcmf_fw_nvram_strip() is no longer called so
it does not need to be exposed.
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>

This patch adds use of asynchronous firmware request to
the driver USB layer.
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>

This patch adds use of asynchronous firmware request to
the driver SDIO layer.
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>

The driver needs firmware to be loaded to the device, which
is done through the firmware class API. The synchronous call
request_firmware() need root filesystem to be mounted and/or
user-mode helper. These may not be avaliable on the moment
it is called. Instead use request_firmware_nowait().
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>