use code provided by Ashish Patro <patro@cs.wisc.edu>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
use values provided by Ashish Patro <patro@cs.wisc.edu>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For some reason it didn't coused obvious problems.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
not sure why.
Initially provided by Ashish Patro <patro@cs.wisc.edu>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_*
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now we should be ready to make this code common.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
last preparation before moving ath9k_spectral_scan_ to spectral.c
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
we don't have here any ieee80211_hw dependencies any way.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
spectral code mostly depends on ath_hw, not on ath_softc
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this will alow us to make ath_softc independent code.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
and move rfs_chan_spec_scan to this struct. We will need it
for common spectral scan code.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Track it per channel context instead of in the softc
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reduce pulse_rssi threshold to 15 in order to improve radar pattern detection
probability on ext channel
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some devices have multiple bands enables in the EEPROM data, even though
they are only calibrated for one. Allow platform data to disable
unsupported bands.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On some devices (especially little-endian ones), the flash EEPROM data
has a different endian, which needs to be detected.
Add a flag to the platform data to allow overriding that behavior
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes the initial NF calibration less likely to fail.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It can cause inconsistent calibration results or in some cases turn the
radio deaf.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When NF calibration fails, the radio often becomes deaf. The usual
hardware hang checks do not detect this, so it's better to issue a reset
when that happens.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
UB124 is a USB based reference design not supported by ath9k or
ath9k_htc.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The initvals use up quite a bit of space, and PC-OEM support is
typically not needed on embedded systems
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Fix a 11b/EVM issue by adjusting
FIR filter coefficients.
* Fix a problem with receiving probe request
frames sent at 11b rate.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes RX sensitivity issues with AR9580.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch makes sure that a GO interface
sends out a new NoA schedule with 200ms duration
when mgd_prepare_tx() is called.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 has to be notified when a RoC period
expires in the driver. In MCC mode, since the
offchannel/RoC timer is set with the requested
duration, ieee80211_remain_on_channel_expired() needs
to be called when the timer expires.
But, currently it is done after we move back to
the operating channel. This is incorrect - fix this
by calling ieee80211_remain_on_channel_expired() when
the RoC timer expires and in ath_roc_complete() when
the RoC request is aborted.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An offchannel operation also needs to have
a flush timeout that doesn't exceed the NoA
absence duration of a GO context, so use
channel_switch_time. The first offchannel
operation is set a flush timeout of 10ms since
channel_switch_time will be zero.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In MCC mode, the duration for a channel context
is half the beacon interval and having a large
flush timeout will adversely affect GO operation,
since the default value of 200ms will overshoot
the advertised NoA absence duration.
The scheduler initiates a channel context switch
only when the slot duration for the current
context expires, so there is no possibility of
having a fixed timeout for flush.
Since the channel_switch_time is added to the
absence duration when the GO sets up the NoA
attribute, this is the maximum time that we
have to flush the TX queues. The duration is very
small, but we don't have a choice in MCC mode.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
