When mac80211 relays a frame from STA1 to STA2 in AP mode it will get
re-classified in the tx path. Unfortunately the frame protocol field
is always set to ETH_P_8023 while the classification only kicks in
for ETH_P_IP. Hence, a high priority frame from STA1 will be send to
STA2 as best effort.

Instead of running classification on the frame just use the same
priority as STA1 did. Do this by adding 256 to the skb->priority
to allow cfg80211_classify8021d to shortcut frame classification.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Currently due to following issues in the code even if device is
configured in B only, G only or BG mode using iw bitrates command,
ibss is getting created in BGN mode.

1) mwifiex_channels_to_cfg80211_channel_type() routine gives channel
type as NL80211_CHAN_HT20 for non-HT channel as well, because driver
doesn't store HT information provided by stack for the channel.
This issue is fixed by maintaining channel type information in
'adapter->channel_type'.
2) Band configuration is unnecessarily overwritten with BGN/AN while
setting channel.

This patch makes sure that "adapter->config_bands" correctly gets
modified while setting channel.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Replace driver specific macros with the corresponding
IEEE80211_HT_PARAM_CHA_SEC_* macros defined in ieee80211.h.
Also, rename 'adapter->chan_offset' to 'adapter->sec_chan_offset'
for consistency.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

struct mwifiex_ds_band_cfg and mwifiex_set_radio_band_cfg() routine
are unnecessary. It can be done with simple equivalant code.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Please NACK nasty patches.

Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The IBSS merge code calls ieee80211_sta_expire() with a relatively
short expire timeout that purges other clients prematurely. The
expire function has to check that only the clients belonging to
the vif in question are purged.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When stack calls ampdu_action with action = IEEE80211_AMPDU_TX_STOP
for a stream that has already been removed from the driver, call
ieee80211_tx_ba_stop_irqsafe to clear the stream in the stack.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Joe changed ath_dbg() to simpify code but while his patch was
being merged dfs.c was born and as such did not get the change
Joe envisioned. This fixes that. Test compiled with:

 make allmodconfig

Cc: Joe Perches <joe@perches.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: John W. Linville <linville@tuxdriver.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The ICT code erroneously uses PAGE_SIZE. The bug
is that PAGE_SIZE isn't necessarily 4096, so on
such platforms this code will not work correctly
as we'll try to attempt to read an index in the
table that the device never wrote, it always has
4096-byte pages.

Additionally, the manual alignment code here is
unnecessary -- Documentation/DMA-API-HOWTO.txt
states:
  The cpu return address and the DMA bus master address are both
  guaranteed to be aligned to the smallest PAGE_SIZE order which
  is greater than or equal to the requested size.  This invariant
  exists (for example) to guarantee that if you allocate a chunk
  which is smaller than or equal to 64 kilobytes, the extent of the
  buffer you receive will not cross a 64K boundary.

Just use appropriate new constants and get rid of
the alignment code.

Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Just another USB identifier.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The libertas scan thread expects priv->scan_req to be non-NULL.  In theory,
it should always be set.  In practice, we've seen the following oops:

[ 8363.067444] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 8363.067490] pgd = c0004000
[ 8363.078393] [00000004] *pgd=00000000
[ 8363.086711] Internal error: Oops: 17 [#1] PREEMPT
[ 8363.091375] Modules linked in: fuse libertas_sdio libertas psmouse mousedev ov7670 mmp_camera joydev videobuf2_core videobuf2_dma_sg videobuf2_memops [last unloaded: scsi_wait_scan]
[ 8363.107490] CPU: 0    Not tainted  (3.0.0-gf7ccc69 #671)
[ 8363.112799] PC is at lbs_scan_worker+0x108/0x5a4 [libertas]
[ 8363.118326] LR is at 0x0
[ 8363.120836] pc : [<bf03a854>]    lr : [<00000000>]    psr: 60000113
[ 8363.120845] sp : ee66bf48  ip : 00000000  fp : 00000000
[ 8363.120845] r10: ee2c2088  r9 : c04e2efc  r8 : eef97005
[ 8363.132231] r7 : eee0716f  r6 : ee2c02c0  r5 : ee2c2088  r4 : eee07160
[ 8363.137419] r3 : 00000000  r2 : a0000113  r1 : 00000001  r0 : eee07160
[ 8363.143896] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 8363.157630] Control: 10c5387d  Table: 2e754019  DAC: 00000015
[ 8363.163334] Process kworker/u:1 (pid: 25, stack limit = 0xee66a2f8)

While I've not found a smoking gun, there are two places that raised red flags
for me.  The first is in _internal_start_scan, when we queue up a scan; we
first queue the worker, and then set priv->scan_req.  There's theoretically
a 50mS delay which should be plenty, but doing things that way just seems
racy (and not in the good way).

The second is in the scan worker thread itself.  Depending on the state of
priv->scan_channel, we cancel pending scan runs and then requeue a run in
300mS.  We then send the scan command down to the hardware, sleep, and if
we get scan results for all the desired channels, we set priv->scan_req to
NULL.  However, it that's happened in less than 300mS, what happens with
the pending scan run?

This patch addresses both of those concerns.  With the patch applied, we
have not seen the oops in the past two weeks.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

DFS_DEBUG_H is very generic, instead use something more specific
to ath9k such as ATH9K_DFS_DEBUG_H.
Reported-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

stop sched scan isn't an immediate operation
and we need to wait for PERIODIC_SCAN_COMPLETE_EVENT_ID
after sending a stop before changing internal state
and notifying upper layers.
Not doing this caused problems when canceling an existing sched
scan and immediately requesting to start a new one
with a different configuration as the FW was still
in the middle of the previous sched scan.
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

DFS channels weren't scanned properly because
min/max_duration weren't set for these channels
even though they're required by the FW.
The change sets passive_duration and min/max_duration
for all channels as the FW uses the correct parameters
according to the channel type.
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

The wl12xx_platform_data.c file did not have a proper copyright
notice.
Signed-off-by: Luciano Coelho <coelho@ti.com>

The current wl1271_dev_notify implementation sets the
new operstate to all associated stations (while only
a specific vif was changed).

Until we'll have a method to get the actual vif from
the given dev, check the current operstate of each vif.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

When removing a sta/ibss role, the device role has to
stopped (and disabled) as well.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

dev_role_id only indicates whether the dev role
is enabled, not started (e.g. on IBSS merge,
the device role is enabled, but not started).

Checking for any role in ROC (in order to determine
whether dev role was started) is wrong as well,
especially in multi-vif env.

Check for started dev role only by checking the dev_hlid.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

During sta disconnection, a deauth packet is being queued to
the dev role queue. However, the dev role is being stopped
before the packet was sent.

Flush the tx queue before stopping the dev role.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

This flag should be set per-vif, rather than globally.

Rename the flag to indicate IN_USE (rather than IDLE), as
in the default configuration (i.e. flag is clear) the vif
should be idle.

Change all the bit operations (and elp conditions) appropriately.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Since the conf_tx callback passes the vif as param,
we must have been added first (and mac80211 verifies it).

Remove the handling of such case.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Implement the change_interface callback by simply removing the
current vif and adding a new one after updating the vif type.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

Runtime DC calibration was previously conditional. Remove this
behaviour, as new devices support runtime DC calibration,
while older devices ignore the runtime DC calibration request.

This patch addresses low TX throughput issues seen with the 6205.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

instead of doing all the work in IWL_TM_CMD_APP2DEV_GET_DEVICE_ID, just use
the information from bus_get_hw_id()
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Set the hw_version in wiphy structure
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Add function to get hw version in both strind and u32 format
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

At least while debugging, a lot of people use
11n_disable=1 to disable HT completely. To be
able to figure out what parts of HT cause the
problems we see, make the parameter a bitmap,
allowing to disable all of HT and aggregation
(TX/RX) separately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

The legacy IRQs could be read from a trace by their
IO accesses, but reading the ICT doesn't leave any
trace (pun intended ;-) ) so in order to see what
input they get we need to add specific tracepoints.

While at it, fix whitespace in two related places.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

The commit 42624d49
created following sparse warning
>net/mac80211/sta_info.c:965:24: warning: incorrect type in assignment (different address spaces)
>net/mac80211/sta_info.c:965:24:    expected struct tid_ampdu_tx *tid_tx
>net/mac80211/sta_info.c:965:24:    got struct tid_ampdu_tx [noderef] <asn:4>*<noident>

Making use of rcu_dereference_protected to fix the problem.

V2:
 - Replacing rcu_dereference with rcu_dereference_protected
   as suggested by Johannes.
 - Adding mutex_lock/unlock to satisfy the condition at
   rcu_dereference_protected

Cc: Nishant Sarmukadam <nishants@marvell.com>
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The commit "ath9k: simplify tx locking" introduced a soft lockup triggered
by mac80211 sending a BAR frame triggered by a driver call to
ieee80211_tx_send_bar or ieee80211_tx_status.
Fix these issues by queueing processed tx status skbs and submitting them
to mac80211 outside of the lock.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Many systems (e.g. embedded systems) do not have wifi modules connected to
bluetooth modules, so bluetooth coexistence is irrelevant there. With the
addition of MCI support, ath9k picked up quite a bit of extra code that
can be compiled out this way.

This patch redefines ATH9K_HW_CAP_MCI and adds an inline wrapper for
querying the bluetooth coexistence scheme, allowing the compiler to
eliminate code that uses it, with only very little use of #ifdef.

On MIPS this reduces the total size for the modules by about 20k.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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

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

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

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

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

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

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