Instead of passing a channel pointer and channel type
to all functions and driver methods, pass a new channel
definition struct. Right now, this struct contains just
the control channel and channel type, but for VHT this
will change.

Also, add a small inline cfg80211_get_chandef_type() so
that drivers don't need to use the _type field of the
new structure all the time, which will change.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

As mwifiex (and mac80211 in the software case) are the
only drivers actually implementing remain-on-channel
with channel type, userspace can't be relying on it.
This is the case, as it's used only for P2P operations
right now.

Rather than adding a flag to tell userspace whether or
not it can actually rely on it, simplify all the code
by removing the ability to use different channel types.
Leave only the validation of the attribute, so that if
we extend it again later (with the needed capability
flag), it can't break userspace sending invalid data.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Allow drivers to indicate their mactime is at RX completion and adjust
for this in mac80211. Also rename the existing RX_FLAG_MACTIME_MPDU to
RX_FLAG_MACTIME_START to clarify its intent. Based on similar code by
Johannes Berg.
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
[fix docs, atheros drivers]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

During hardware restart, all interfaces are iterated even
though they haven't been re-added to the driver, document
this behaviour. The same also happens during resume, which
is even more confusing since all of the interfaces were
previously removed from the driver. Make this optional so
drivers relying on the current behaviour can still use it,
but to let drivers that don't want this behaviour disable
it.

Also convert all API users, keeping the old semantics
except in hwsim, where the new normal ones are desired.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The TX power setting is currently per wiphy (hardware
device) but with multi-channel capabilities that doesn't
make much sense any more.

Allow drivers (and mac80211) to advertise support for
per-interface TX power configuration. When the TX power
is configured for the wiphy, the wdev will be NULL and
the driver can still handle that, but when a wdev is
given the TX power can be set only for that wdev now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whenever WLAN receives scheduling msg from BT, it reduces tx power
based on RSSI level. And then BT starts simultaneous transmission
along with WLAN. Sometimes HW MAC compares tx power that is used
prior to power reduction which is causing BT transmission to defer.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reduced the power consumption to half in full and network sleep.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reduced the power consumption to half in full and network sleep.

Cc: stable@vger.kernel.org
Cc: Paul Stewart <pstew@chromium.org>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This driver is for the AR5523 chipset from Atheros. It was created
in 2007 by Christoph Hellwig but it was never finished. I found it a
couple of months ago and after some polishing it's working pretty
fine.

The driver was written with the FreeBSD driver (uath) as reference,
which was written with the reverse-engineered windows driver as
reference, hence the feature set is very limited. Station mode
only, no HW crypto offload.
Signed-off-by: NPontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

carl9170_handle_mpdu is the final part of the
rx path of the driver. It splits the raw data
streams from the device into skb packets and
passes them on to mac80211. As a result of
continuous updates, it grew over the years when
new code was added by the following commits:
	- report A-MPDU status
	- fix HT peer BA session corruption
	- A-MPDU frame type filter
	- ...

This patch splits the routine into two stages.
The first stage only deals with the details
about extracting and verifying the data from
the incoming stream. Whereas the second stage
packs it into skbs and passes it on to mac80211.
Reported-by: NJavier Lopez <jlopex@cozybit.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the BT connection is initiated by headset, it's possible that headset
requests to make one A2DP and one Voice connection over the same link.
BT firmware will send a new profile A2DP_Voice in this case. So WLAN
has to take care of this new profile for tuning BTCOEX parameters.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whenever i_coff of IQ calibration is too high, AR9565 drops max
rx rate to MCS4. Skipping IQ update at this time can avoid this
problem for AR9565.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While resuming from S3, BT host issues HCI reset command and it
causes BT firmware to busy with security key calculation. At this
movement, WLAN detects MCI hardware error of MCI_CONT_INFO_TIMEOUT
and then it starts the recovery sequence repeatedly. Too many
recovery sequences would exhaust the BT kernel message pool. This
patch imposes a duration between consecutive BT recovery procedure.
Thus it solves BT firmware panic issue reported in AR9565.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TXIQ and RXIQ share the same data path to upload the measurement
result, we should turn off RXIQ calibration while re-calibrating radio
Signed-off-by: NBala Shanmugam <bkamatch@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NBala Shanmugam <bkamatch@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Self generated MCI messages is configured to use chain 1. As
ar9565 is 1x1 solution, It can not use Chain 1. Hence fix
Chain 1 for ar9462 alone. Not doing so, could affect WLAN
connectivity in ar9565 as LNA sharing is not informed by BT.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The simulataneous transmission of both WLAN and BT might cause
increase in power levels. To avoid regulatory violation, WLAN tx
power will be adjusted according to BT power index based on avaliability
of BT scheduling messages. WLAN tx power reduction might affect its
performance. So WLAN tx power is only be lowered when the signal strength
is good enough. Otherwise concurrent tx will be disabled and WLAN uses
it default power levels. Also concurrent tx is disabled whenever WLAN is
moving to off-channel which might be used by BT.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is useful to have channel mode in caldata to find out
whether operaing channel is in HT40/20 when we are currently
on offchannel. It will be used by BTCOEX to enable/disable
concurrent tx mechanism later.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This feature enables both WLAN and BT can transmit simultaneously
by setting WLAN and BT to equal priorities. Whenever both are
transmitting, it might violate regulatory power limits. To avoid
regulatory violation, WLAN tx power will be adjusted according to BT
power index based on avaliability of BT scheduling message. If the
combined power exceeds threshold, BT transmission will be held off.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

WLAN updates channel bitmap when associated and disassociated. Channel
bitmap will reflect whare are the channels used or affected by WLAN and
BT should avoid using those. Not doing so, could affect BT traffic
as both WLAN and BT is operating on same channel.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently ath9k need to have beacon interval matched
between STA mode and beaconing mode. Advertize this
through interface combinations.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Once the driver advertizes interface combination logic
based on its firmware/hardware limitation, cfg80211
takes care of all the necessary logic such as maximum
beaconing vifs, standlone interface etc.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This will allow us to create virtual interface the driver supports.
Also this ensures multivif support and limitation advertised
by the driver is taken care in cfg80211 itself.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When WLAN is idle ensure we downgrade to FTP_STOMP_LOW weight
(from STOMP_LOW) to provide more bandwidth for BT FTP profile.
WLAN's idleness can be estimated by taking into account of the
rx data packets and just ignore beacons, qos nullfunc etc.

Also update bt_wait_time even if the chip is in NETWORK SLEEP
mode. This should help BT throughput when WLAN is idle.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Several people have complained about an unusual
and undocumented feature of the AR9170 hardware:

In siffer mode, the hardware generates spurious
ACK frames for every received frame... even
broadcasts.

The reason for this malfunction is unknown:
<http://marc.info/?l=linux-wireless&m=134517238506033>
But there's a workaround: Instead of the special
sniffer mode, the hardware will be put into
station mode and all rx filters are disabled.
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Reported-by: NMarco Fonseca <marco@tampabay.rr.com>
Reported-by: NJanusz Dziedzic <janusz.dziedzic@gmail.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

bf->bf_next is only while buffers are chained as part of an A-MPDU
in the tx queue. When a tid queue is flushed (e.g. on tearing down
an aggregation session), frames can be enqueued again as normal
transmission, without bf_next being cleared. This can lead to the
old pointer being dereferenced again later.

This patch might fix crashes and "Failed to stop TX DMA!" messages.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit a240dc7b.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Roger says, Ubiquiti produce 2 versions of their WiFiStation USB adapter.  One
has an internal antenna, the other has an external antenna and
name suffix EXT.  They have separate USB ids and in distribution
openSUSE 12.2 (kernel 3.4.6), file /usr/share/usb.ids shows:

  0cf3  Atheros Communications, Inc.
       ...
       b002  Ubiquiti WiFiStation 802.11n [Atheros AR9271]
       b003  Ubiquiti WiFiStationEXT 802.11n [Atheros AR9271]

Add b002 Ubiquiti WiFiStation in the PID/VID list.
Reported-by: NRoger Price <ath9k@rogerprice.org>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As of now the ANI cycle is executed only when the chip is awake.
On idle state case, the station wakes up from network sleep for
beacon reception. Since most of the time, ANI cycle is not syncing
with beacon wakeup, ANI cycle is ignored. Approx 5 mins once, the
calibration is performed. This could affect the connection stability
when the station is idle for long. Even though the OFDM and CCK phy
error rates are too high, ANI is unable to tune its immunity level
as quick enough due to rare execution.

Here the experiment shows that OFDM and CCK levels are at default
even on higher phy error rate.

listenTime=44 OFDM:3 errs=121977/s CCK:2 errs=440818/s ofdm_turn=1

This change ensures that ANI calibration will be exectued atleast
once for every 10 seconds. The below result shows improvements and
immunity levels are adopted quick enough.

listenTime=557 OFDM:4 errs=752/s CCK:4 errs=125/s ofdm_turn=0
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch changes the way the driver deals with
command responses and traps which are sent through
the special interrupt input endpoint 3.

While the carl9170 firmware does not use this
endpoint for command responses or traps, the
firmware loader on the device does. It uses it
to notify the host about 'watchdog triggered'
in case the firmware/hardware has crashed.

Note:
Even without this patch, the driver is still
able to detect the mishap and reset the device.
But previously it did that because the trap
event caused an out-of-order message sequence
number error, which also triggered a reset.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All defines for REG_WRITE in Atheros wireless drivers use the order "ah",
"register" and "value". hw.c is the only file using the order "ah", "value" and
"register".

drivers/net/wireless/ath/ath9k/hw.h:#define REG_WRITE(_ah, _reg, _val) \
drivers/net/wireless/ath/key.c:#define REG_WRITE(_ah, _reg, _val) (common->ops->write)(_ah, _val, _reg)

This inconsistent definition can easily lead to implementation errors. The
modification doesn't change the behavior of the driver or the generated code.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch remove a semicolon after if(...) that is preventing the
error check to work correctly. Removing this semicolon will change the
code behavior, but this is intended.

The semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r1@
position p;
@@
if (...);@p

@script:python@
p0 << r1.p;
@@
// Emacs org-mode output
cocci.print_main("", p0)
cocci.print_secs("", p0)
// </smpl>
Signed-off-by: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

BT_OP_SCAN is applicable only for pre-MCI WLAN/BT combo chips
and using it for MCI-based cards is incorrect. Fix this by
cleaning up its usage.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>