While mac80211 setup this per HW, set same
rxfilter configuration for all chanctx.
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In case we will get ROC cancel from mac80211 we
should not call ieee80211_remain_on_channel_expired().

In other case I hit such warning on MIPS and
p2p negotiation failed (tested with use_chanctx=1).

ath: phy0: Starting RoC period
ath: phy0: Channel definition created: 2412 MHz
ath: phy0: Assigned next_chan to 2412 MHz
ath: phy0: Offchannel duration for chan 2412 MHz : 506632
ath: phy0: ath_chanctx_set_next: current: 2412 MHz, next: 2412 MHz
ath: phy0: Stopping current chanctx: 2412
ath: phy0: Flush timeout: 200
ath: phy0: ath_chanctx_set_next: Set channel 2412 MHz
ath: phy0: Set channel: 2412 MHz width: 0
ath: phy0: Reset to 2412 MHz, HT40: 0 fastcc: 0
ath: phy0: cur_chan: 2412 MHz, event: ATH_CHANCTX_EVENT_TSF_TIMER, state: ATH_CHANCTX_STATE_IDLE
ath: phy0: ath_offchannel_channel_change: offchannel state: ATH_OFFCHANNEL_ROC_START
ath: phy0: cur_chan: 2412 MHz, event: ATH_CHANCTX_EVENT_SWITCH, state: ATH_CHANCTX_STATE_IDLE
ath: phy0: Cancel RoC
ath: phy0: RoC aborted
ath: phy0: RoC request on vif: 00:03:7f:4e:a0:cd, type: 1 duration: 500
ath: phy0: Starting RoC period
ath: phy0: Channel definition created: 2412 MHz
ath: phy0: Assigned next_chan to 2412 MHz
ath: phy0: Offchannel duration for chan 2412 MHz : 506705
ath: phy0: ath_chanctx_set_next: current: 2412 MHz, next: 2412 MHz
ath: phy0: ath_offchannel_channel_change: offchannel state: ATH_OFFCHANNEL_ROC_START
ath: phy0: cur_chan: 2412 MHz, event: ATH_CHANCTX_EVENT_SWITCH, state: ATH_CHANCTX_STATE_IDLE
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3312 at drivers/net/wireless/ath/ath9k/main.c:2319
Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211
Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This reverts commit 6301566e. Oleksij Rempel
noticed that the randomness doesn't look to be good enough and Stephan Mueller
commented:

"I would say that the discussed RNG does not seem fit for hooking it up with the
hwrandom framework."

http://lkml.kernel.org/g/3945775.m5HblJPgiO@tauon.atsec.com

So let's the revert the patch until we are sure that we can trust this random
generator.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We measured the FFT-based entropy in 3 ways, Shannon entropy,
collision entropy, and directly measured min-entropy. Just to
be conservative, we recommend the estimated min-Entropy to be
10 bits per 16-bit value.

Analysis was done by Jacobson,David(djacobso@qti.qualcomm.com).
Signed-off-by: NMiaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This support is essentially useless as typically networks are encrypted,
frames will be filtered by hardware, and rate scaling will be done with
the intended recipient in mind. For real monitoring of the network, the
monitor mode support should be used instead.

Removing it removes a lot of corner cases.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Use the built-in function instead of memset.

Miscellanea:

Add #include <linux/etherdevice.h> where appropriate
Use ETH_ALEN instead of 6
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Configure the HW with highest TX power among all vif when HW TPC has been
enabled in order to add support to per-vif TX power capability. Use lowest
configured power among all interfaces when TPC is disabled
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The various variables tracking bmiss interrupts
are not really used anywhere except in a debug
message. Remove them since they have no functional
purpose.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

To fix invalid hardware accesses, the commit 872b5d81 ("ath9k: do not
access hardware on IRQs during reset") made the irq handler ignore interrupts
emitted after queueing a hardware reset (which disables the IRQ). This left a
small time window for the IRQ to get re-enabled by the tasklet, which caused
IRQ storms.  Instead of returning IRQ_NONE when ATH_OP_HW_RESET is set, disable
the IRQ entirely for the duration of the reset.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Instead of killing interrupts during reset when the first one happens,
kill them before issuing the reset.
This fixes an easy to reproduce crash with multiple cards sharing the
same IRQ.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Closes another small IRQ handler race
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software
based scanning and generate a random MAC address for them for every
scan request with the flag.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If for some reason a beacon with a new NoA is
not sent out, then reset the mgd_prepare_tx flag.
Not doing this will result in a situation where
a GO will send a new NoA when it shouldn't.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch makes sure that pending roc/scan
operations are cancelled properly when a new
context is assigned/unassigned.

The flush_work() call to flush out any scheduled
channel context work is removed, instead, sc->mutex
is dropped to allow any pending work to get a chance
to complete by the channel scheduler. Also, increase
the timeout to allow a switch to an active GO.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On some x86 platforms, the LED gpio is active high
instead of active low. Identify such cards and modify
the GPIO usage to make sure LED works properly.

Cc: Russell Hu <rhu@qca.qualcomm.com>
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use the sw_mgmt_crypto_tx flag to trigger the CCMP encryption
for transmitted management frames to be done in software while
the sw_mgmt_crypto_rx flag is used to trigger the CCMP decryption
for received management frames to be done in software.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to assign the hw queues for mesh interface. Otherwise,
we are not able to bring up the mesh interface due to the
IEEE80211_INVAL_HW_QUEUE error.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit that went into 3.17:

    ath9k: Summarize hw state per channel context

    Group and set hw state (opmode, primary_sta, beacon conf) per
    channel context instead of whole list of vifs. This would allow
    each channel context to run in different mode (STA/AP).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

broke multi-vif configuration due to not properly calculating
the bssid mask.

The test case that caught this was:

 create wlan0 and sta0-4 (6 total), not sure how much that matters.
 associate all 6 (works fine)
 disconnect 5 of them, leaving sta0 up
 Start trying to bring up the other 5 one at a time.  It will
 fail, with iw events looking like this (in these logs, several
 sta are trying to come up, but symptom is the same with just one)

The patch causing the regression made quite a few changes, but
the part I think caused this particular problem was not
recalculating the bssid mask when adding and removing interfaces.

Re-adding those calls fixes my test case.  Fix bad comment
as well.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now we should be ready to make this code common.
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

last preparation before moving ath9k_spectral_scan_ to spectral.c
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

we don't have here any ieee80211_hw dependencies any way.
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Track it per channel context instead of in the softc
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The "goto chip_reset" is a bit misleading, because it does not actually
issue a chip reset. Instead it is bypassing processing of other
interrupts and assumes that the tasklet will issue a chip reset.

In the case of RXORN this does not happen, so bypassing processing of
other interrupts will simply allow them to fire again. Even if RXORN
was triggering a reset, it is not critical enough to need the bypass
here.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 currently has a race which can be hit
with this sequence:

* Start a scan operation.
* TX BA is initiated by ieee80211_start_tx_ba_session().
* Driver sets up internal state and calls
  ieee80211_start_tx_ba_cb_irqsafe().
* mac80211 adds a packet to sdata->skb_queue with
  type IEEE80211_SDATA_QUEUE_AGG_START.
* ieee80211_iface_work() doesn't process the
  packet because scan is in progress.
* ADDBA response timer expires and the sta/tid is
  torn down.
* Driver receives BA stop notification and calls
  ieee80211_stop_tx_ba_cb_irqsafe().
* This is also added to the queue by mac80211.
* Now, scan finishes.

At this point, the queued up packets might be processed
if some other operation schedules the sdata work. Since
the tids have been cleaned up already, warnings are hit.

If this doesn't happen, the packets are left in the queue
until the interface is torn down.

Since initiating a BA session when scan is in progress
leads to flaky connections, especially in MCC mode, we
can drop the TX BA request. This improves connectivity
with legacy clients in MCC mode.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The flush timeout in MCC mode is very small, since
we are constrained by the time slice for each
channel context, but since only the HW queues are
flushed when switching contexts, it is acceptable.

Since the SW queues are also emptied in the mac80211 flush()
callback, a larger duration is needed. Add an override
argument to __ath9k_flush() and set it when flush()
is called in MCC mode. This allows the driver to
drain both the SW and HW queues.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of using ATH_CHANCTX_EVENT_ASSIGN to abort
a HW scan when a new interface becomes active, use the
mgd_prepare_tx() callback. This allows us to make
sure that the GO's channel becomes operational by
using flush_work().
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If a GO interface is active when we receive a
mgd_prepare_tx() call, then we need to send
out a new NoA before switching to a new context.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since both the arguments need to satisfy
the alignment requirements of ether_addr_copy(),
use memcpy() in cases where there will be no
big performance benefit and make sure that
ether_addr_copy() calls use properly aligned
arguments.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ATH_CHANCTX_EVENT_AUTHORIZED is required to trigger
the MCC scheduler when a station interface becomes
authorized. But, since the driver gets station state
notifications when the current operating mode is AP
too, make sure that we send ATH_CHANCTX_EVENT_AUTHORIZED
only when the interface is in station mode.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pending frames in the driver can be present
either in the HW queues or SW. ath9k_has_pending_frames()
currently checks for the HW queues first and then
checks if any ACs are queued in the driver.

In MCC mode, we need to check the HW queues alone, since
the SW queues are just marked as 'stopped' - they will
be processed in the next context switch. But since we
don't differentiate this now, mention whether we want
to check if there are frames in the SW queues.

* The flush() callback checks both HW and SW queues.
* The tx_frames_pending() callback does the same.
* The call to __ath9k_flush() in MCC mode checks HW queues alone.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The timeout value for flushing the TX queues
is hardcoded at 200ms right now. Use a channel
context-specific value instead to allow adjustments
to the timeout in case MCC is enabled.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a chip reset is done, all running timers,
tasklets etc. are stopped but the beacon tasklet
is left running. Fix this.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a HW reset is done, the interrupt tasklet is
disabled before ISRs are disabled in the HW. This
allows a small window where the HW can still generate
interrupts. Since the tasklet is disabled and not killed,
it is not scheduled but deferred for execution at a later
time.

This happens because ATH_OP_HW_RESET is not set when ath_reset()
is called. When the hw_reset_work workqueue is used, this
problem doesn't arise because ATH_OP_HW_RESET is set
and the ISR bails out.

Set ATH_OP_HW_RESET properly in ath_reset() to avoid
this race - all the ath_reset_internal() callers have
been converted to use ath_reset() in the previous patch.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of having ath_reset_internal() and ath_reset()
as two separate calls to perform a HW reset, have
one function. This makes sure that the behavior will
be the same at all callsites.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In MCC mode, currently the decision to enable
the multi-channel state machine is done
based on the association status if one of
the interfaces assigned to a context is in
station mode.

This allows the driver to switch to the other
context before the current station is able to
complete the 4-way handshake in case it is
required and this causes problems.

Instead, enable multi-channel mode when the
station moves to the authorized state. This
disallows an early switch to the other channel.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of using the sta_add()/sta_remove() callbacks,
use the sta_state() callback since this gives
more fine-grained control.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>