These are the remaining knobs in ath9k to support DFS:
* mark AR9280 and AR9580 as DFS tested
* synchronize DFS regulatory domain to reg notifyer
* set required RX filter flags for radar detection
* process radar PHY errors at DFS detector
* notify DFS master on radar detection

DFS support requires CONFIG_ATH9K_DFS_CERTIFIED to be set.
Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This helps testing DFS without radar generating
equipment and is required for certification.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Should make the warning messages more useful.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The messages are currently hard coding "1ms", which does not match
the actual timeout being used.
Signed-off-by: NRobert Shade <robert.shade@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Marco Fonseca reported a issue with his carl9170 device:
"I'm seeing a problem with the carl driver. If I change channels
repeatedly on the 2.4ghz band, monitoring (e.g. tcpdump) will
eventually halt.  I've seen this on various versions of the carl
driver/firmware (both from 1.9.4 to 1.9.7)"
<http://marc.info/?l=linux-wireless&m=136381302428113>

The culprit was identified as "fast channel change feature" which
according to Adrian Chadd is: "... notoriously unreliable and
really only fully debugged on some very later chips."
<http://marc.info/?l=linux-wireless&m=136416984531380>

Therefore, this patch removes the fast channel change feature.
The phy will now always have to go through a cold reset when
changing channels, but it should no longer become deaf.

Cc: Marco Fonseca <marco@tampabay.rr.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The spectral data provided via relay-fs introduces a buffering
latency given by the subbuf_size. To meet the requirements for
delay-sensitive applications (like real-time spectral plotter),
reduce subbuf_size and increase n_subbufs.
Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The following issue was reported.

WARNING: at net/mac80211/util.c:599 ieee80211_can_queue_work.isra.7+0x32/0x40 [mac80211]()
Hardware name: iMac12,1
queueing ieee80211 work while going to suspend
Pid: 0, comm: swapper/0 Tainted: PF          O 3.8.2-206.fc18.x86_64 #1
Call Trace: Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642992]  <IRQ>
[<ffffffff8105e61f>] warn_slowpath_common+0x7f/0xc0
[<ffffffffa0581420>] ? ath_start_rx_poll+0x70/0x70 [ath9k]
<ffffffff8105e716>] warn_slowpath_fmt+0x46/0x50
[<ffffffffa045b542>] ieee80211_can_queue_work.isra.7+0x32/0x40

Fix this by avoiding to queue the work if our device has
already been marked as suspended or stopped.
Reported-by: NParag Warudkar <parag.lkml@gmail.com>
Tested-by: NParag Warudkar <parag.lkml@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My new tracing code for ath6kl introduced these warnings on 64-bit:

trace.h:38:1: warning: format '%d' expects argument of type 'int',
	but argument 4 has type 'size_t' [-Wformat]
trace.h:61:1: warning: format '%d' expects argument of type 'int',
	but argument 4 has type 'size_t' [-Wformat]
trace.h:84:1: warning: format '%d' expects argument of type 'int',
	but argument 6 has type 'size_t' [-Wformat]
trace.h:119:1: warning: format '%d' expects argument of type 'int',
	but argument 7 has type 'size_t' [-Wformat]
trace.h:173:1: warning: format '%d' expects argument of type 'int',
	but argument 3 has type 'size_t' [-Wformat]
trace.h:193:1: warning: format '%d' expects argument of type 'int',
	but argument 5 has type 'size_t' [-Wformat]
trace.h:221:1: warning: format '%d' expects argument of type 'int',
	but argument 5 has type 'size_t' [-Wformat]

Fix them by using %zd.
Reported-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The beacon and multicast-buffer queues are managed by the beacon
tasklet, and the generic tx path hang check does not help in any way
here. Running it on those queues anyway can introduce some race
conditions leading to unnecessary chip resets.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit 'ath9k_hw: fix calibration issues on chainmask that don't
include chain 0' changed the hardware chainmask to the chip chainmask
for the duration of the calibration, but the revert to user
configuration in the reset path runs too early.

That causes some issues with limiting the number of antennas (including
spurious failure in hardware-generated packets).

Fix this by reverting the chainmask after the essential parts of the
calibration that need the workaround, and before NF calibration is run.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com>
Tested-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are a number of situations in which mac80211 only
really needs to flush queues for one virtual interface,
and in fact during this frames might be transmitted on
other virtual interfaces. Calculate and pass a queue
bitmap to the driver so it knows which queues to flush.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Credit distribution stats is currently implemented
only for SDIO. This fixes a crash in debugfs for
USB interface.

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<f91c2048>] read_file_credit_dist_stats+0x38/0x330 [ath6kl_core]
*pde = b62bd067
Oops: 0000 [#1] SMP

EIP: 0060:[<f91c2048>] EFLAGS: 00210246 CPU: 0
EIP is at read_file_credit_dist_stats+0x38/0x330 [ath6kl_core]
EAX: 00000000 EBX: e6f7a9c0 ECX: e7b148b8 EDX: 00000000
ESI: 000000c8 EDI: e7b14000 EBP: e6e09f64 ESP: e6e09f30
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process cat (pid: 4058, ti=e6e08000 task=e50cf230 task.ti=e6e08000)
Stack:
00008000 00000000 e6e09f64 c1132d3c 00004e71 e50cf230 00008000 089e4000
e7b148b8 00000000 e6f7a9c0 00008000 089e4000 e6e09f8c c11331fc e6e09f98
00000001 e6e09f7c f91c2010 e6e09fac e6f7a9c0 089e4877 089e4000 e6e09fac

	Call Trace:
	[<c1132d3c>] ? rw_verify_area+0x6c/0x120
	[<c11331fc>] vfs_read+0x8c/0x160
	[<f91c2010>] ? read_file_war_stats+0x130/0x130 [ath6kl_core]
	[<c113330d>] sys_read+0x3d/0x70
	[<c15755b4>] syscall_call+0x7/0xb
	[<c1570000>] ? fill_powernow_table_pstate+0x127/0x127

Cc: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Signed-off-by: NAndrei Epure <epure.andrei@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Either first 3 bytes of the first received tcp segment or last one
over MTU size file can be loss due to the byte alignment problem.
Although ATH6KL_HTC_ALIGN_BYTES was defined for 'extra bytes for htc header
alignment' in the patch "Fix buffer alignment for scatter-gather
I/O"(1df94a85), there exists the bytes loss issue which means that it will be
truncated 3 bytes in the transmitted file contents if a file which has over MTU
size is transferred through TCP/IP stack.  It doesn't look like TCP/IP stack
bug of 3.5 or the latest version of kernel but the byte alignment issue.  This
patch is to use the roundup() function for the byte alignment rather than the
predefined ATH6KL_HTC_ALIGN_BYTES.

kvalo: fixed indentation
Signed-off-by: NMyoungje Kim <mjei78@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Dan found a check from ath6kl_rx() which doesn't make any sense at all:

"  1327          if (status || !(skb->data + HTC_HDR_LENGTH)) {
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^
skb->data is a pointer.  This pointer math is always going to be false.
Should it be testing "packet->act_len < HTC_HDR_LENGTH" or something?"

I don't know what the check really was supposed to do, but I think Dan's guess
is right. Fix it accordingly.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Dan reported that smatch found a possible issue in ath6kl_wmi_beginscan_cmd()
where we might access sc->supp_rates beyond the end. It shouldn't happen as
ar->wiphy->bands always have just the first two bands set, but add an extra
check just to be sure.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Now all log messages are sent through the tracing infrastruture as well.
Tracing point doesn't follow debug_mask module parameter, instead it sends
all debug messages, so once you enable ath6kl_log_dbg tracing point you will
get a lot of messages. Needs to be discussed if this is sensible or not.
The overhead should be small enough and we anyway include debug level as
well so it's easy to filter in user space.

I wasn't really sure what to do with ath6kl_dbg_dump() and for now decided
that it also sends the buffer to user space. But most likely in the future
ath6kl_dbg_dump() should go away in favor of using proper tracing points, but
we will see.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

All log messages are now sent through tracing interface as well if
ATH6KL_TRACING is enabled.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

After this it's cleaner to add trace calls.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add tracing points for htc layer, just dumping the packets to user space.
I wasn't really sure what to do with the status value, it might not always
be accurate, but I included it anyway.

I skipped htc_pipe (and usb) implementation for now. Need to add those
tracepoints later.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add a tracing point for hif irq and dump the register content to user space.
This is in hif.c as we could use the same code also with SPI but, as ath6kl
doesn't SPI and most likely never will be, this is used just by SDIO so
name the trace point as ath6kl_sdio_irq to make it easier to manage filters.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add tracing points for sdio transfers, just dump the address, flags and the
buffer.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add basic tracing infrastructure support to ath6kl and which can be
enabled with CONFIG_ATH6KL_TRACING.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Julien reported that ar6004 usb device fails to initialise
after host has been rebooted and power is still on for the ar6004 device. He
found out that doing a cold reset fixes the issue.

I wasn't sure what would be the best way to detect if target needs a reset so I
settled on checking a timeout from htc_wait_recv_ctrl_message().
Reported-by: NJulien Massot <jmassot@aldebaran-robotics.com>
Tested-by: NJulien Massot <jmassot@aldebaran-robotics.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It was annoying to debug usb warm reboot initialisation problems as many usb
related functions just ignored errors and it wasn't obvious from the kernel
logs what was failing. Fix all that so that error messages are printed and
errors are handled properly.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Move it to init.c, make it static, remove all useless checks and force it to
always do cold reset.
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Printin the  firmware capabilities during the first firmware boot makes it easier to find out what
features firmware supports.

Obligatory screenshot:

[21025.678481] ath6kl: ar6003 hw 2.1.1 sdio fw 3.2.0.144 api 3
[21025.678667] ath6kl: firmware supports: sched-scan,sta-p2pdev-duplex,rsn-cap-override
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Firmware got support for temperature measurement.
There are 2 temperature sensors: MAC and radio

"not available" temperature - reported by FW as 0 or ~0
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adjust driver for changes in the FW API.
Noticeable changes in the FW are:
- temperature sensing
- infrastructure for multiple connections
- infrastructure for P2P
- signal strength indication

This commit introduces only changes that are required to support same functionality
as previous firmware, no new features.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

New firmware allows for shorter SW reset procedure.
After SW reset, FW raises "fw done" IRQ, at this
moment mailbox control structures are initialized, driver caches it.

New status bit wil_status_reset_done introduced to track completion
of the reset. It is set by "fw ready" irq, and required for WMI rx flow
to access control structures.

WMI Tx flow protected by other status bit, wil_status_fwready. It can't
be set before wil_status_reset_done is set by design.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

user space get notified through kobject_uevent_env(), that might sleep and thus
should run in thread context.

Move user space notification to the thread handler, while mark FW is non-functional
right in the hard IRQ.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pass to cfg80211 all management frames.
Used by wpa_supplicant.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Avoid unnecessary frame parsing
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move wmi_connect_worker() to the main.c and change names for consistency.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Extra reference was taken by mistake.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On the DMG band, there is no 'normal' beacon frame.
Instead, transmitted is short 'DMG beacon' frame, that do not include IE's
So, beacon IE's are not relevant for the DMG band.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Firmware indicated block ack agreement status change.
For now, just log it.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>