Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When a station leaves suddenly while ampdu traffic to that station is still
running, there is a possibility that the ampdu pending queues are not freed due
to a race condition leading to memory leaks. In '__sta_info_destroy' when we
attempt to destroy the ampdu sessions in 'ieee80211_sta_tear_down_BA_sessions',
the driver calls 'ieee80211_stop_tx_ba_cb_irqsafe' to delete the ampdu
structures (tid_tx) and splice the pending queues and this job gets queued in
sdata workqueue. However, the sta entry can get destroyed before the above work
gets scheduled and hence the race.

Purging the queues and freeing the tid_tx to avoid the leak. The better solution
would be to fix the race, but that can be taken up in a separate patch.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

It is quite possible to run into a race in bss timeout where
the drivers see the bss entry just before notifying cfg80211
of a roaming event but it got timed out by the time rdev->event_work
got scehduled from cfg80211_wq. This would result in the following
WARN-ON() along with the failure to notify the user space of
the roaming. The other situation which is happening with ath6kl
that runs into issue is when the driver reports roam to same AP
event where the AP bss entry already got expired. To fix this,
move cfg80211_get_bss() from __cfg80211_roamed() to cfg80211_roamed().

[158645.538384] WARNING: at net/wireless/sme.c:586
__cfg80211_roamed+0xc2/0x1b1()
[158645.538810] Call Trace:
[158645.538838]  [<c1033527>] warn_slowpath_common+0x65/0x7a
[158645.538917]  [<c14cfacf>] ? __cfg80211_roamed+0xc2/0x1b1
[158645.538946]  [<c103354b>] warn_slowpath_null+0xf/0x13
[158645.539055]  [<c14cfacf>] __cfg80211_roamed+0xc2/0x1b1
[158645.539086]  [<c14beb5b>] cfg80211_process_rdev_events+0x153/0x1cc
[158645.539166]  [<c14bd57b>] cfg80211_event_work+0x26/0x36
[158645.539195]  [<c10482ae>] process_one_work+0x219/0x38b
[158645.539273]  [<c14bd555>] ? wiphy_new+0x419/0x419
[158645.539301]  [<c10486cb>] worker_thread+0xf6/0x1bf
[158645.539379]  [<c10485d5>] ? rescuer_thread+0x1b5/0x1b5
[158645.539407]  [<c104b3e2>] kthread+0x62/0x67
[158645.539484]  [<c104b380>] ? __init_kthread_worker+0x42/0x42
[158645.539514]  [<c151309a>] kernel_thread_helper+0x6/0xd
Reported-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We recently introduced a new return here but it needs an unlock first.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

in my previous patches of handling MCI interrupt I overlooked
the case of interrupt status/mask variable being zeroed out in
the below code, so ath_isr does not cache the MCI interrupt
in the intrstatus. finally MCI interrupt handling won't be
handled in ath9k_tasklet for the scheduled interrupts.
Fix this by moving the MCI interrupt code in the appropriate
position in ar9003_hw_get_isr

Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

in ar9003_hw_get_isr we bail out if we don't have any primary
interrupts and synchronous interrupts, also make sure we don't
have any asynchronous interrupts
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  It looks like the regression was introduced between 20111202 and
20111205 (linux-next tree). Symptoms: connection to AP seem to be
established, but no data goes though it in any way. Tested on intel
5300.
  Peek at the changes have shown that it looks like at least part of
the code wasn't merged properly. It was originally committed into
iwl_agn.c but code in question was moved to iwl-mac80211.c.
  This patch puts code in place and my card works again.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CC [M]  drivers/net/wireless/wl12xx/tx.o
drivers/net/wireless/wl12xx/tx.c: In function ‘wl1271_tx_fill_hdr’:
drivers/net/wireless/wl12xx/tx.c:288:6: warning: ‘tx_attr’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We track the load only on 8 TIDs, previously this
was TID_MAX_LOAD_COUNT. Since IWL_MAX_TID_COUNT
is now 8 as well, use that to make the code more
easily understandable.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Now that I corrected IWL_MAX_TID_COUNT to be 8
instead of 9, we can use it in WoWLAN suspend.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

The driver everywhere uses max TID count as 9,
which is wrong, it should be 8.

I think the reason it uses 9 here is off-by-one
confusion by whoever wrote this. We do use the
value IWL_MAX_TID_COUNT for "not QoS/no TID"
but that is completely correct even if it is 8
and not 9 since 0-7 are only valid.

As a side effect, this fixes the following bug:

 Open BA session requested for 00:23:cd:16:8a:7e tid 8
 ------------[ cut here ]------------
 kernel BUG at drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h:350!
 ...

when you do
echo "tx start 8" > /sys/kernel/debug/ieee80211/*/*/*/*/agg_status

Cc: stable@vger.kernel.org
Reported-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Move the calib_results list from the upper layer iwl_priv structure
to the lower layer iwl_trans structure.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Move the low level ucode device_pointers structure to iwl_shared.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

The eeprom image is a device level component, move from iwl_priv
to iwl_shared, with associated code changes.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

It is needed by firmware to use the correct rate for BAR frame transmission
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

P2P still under development. it will not enabled by default, but user
always can enable it manually for testing.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Create new tm command to report devce ID information to userspace
- IWL_TM_CMD_APP2DEV_GET_DEVICE_ID
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Change the name to match the works
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

After driver split, no need to reference to legacy devices, remove comments
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Remove the defines only used by legacy devices
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

When uCode encounter problem, it pass a lot of debug data to help debugging
the issue. We only show partial data before, why not display all of those.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Because the testmode support should be the mandatory foundation
of test functionality, it is better to set kernel option
IWLWIFI_DEVICE_SVTOOL automatically instead of user configuration.
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Create new tm command to report uCode version to userspace
- IWL_TM_CMD_APP2DEV_GET_FW_VERSION
Signed-off-by: Kenny Hsu <kenny.hsu@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into wireless-next

The user can pass broadcast SSID (ssid="") in the list of SSIDs for active scan.
In this case the loop was attempting to match SSIDs in the filter
list to this empty entry and marking them as HIDDEN (sending probe
request) by mistake
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

wl1271_tm_cmd_interrogate creates a reply skb, but doesn't
send it (and thus just leaks it).
Add the missing cfg80211_testmode_reply() call.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

During plt init we configure some redundant commands,
which are not needed for plt (specifically, we shouldn't
configure any role-specific params, as there are no
active roles). remove them.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

fix several issues in testmode test/interrogate commands:
1. check the driver state is not OFF.
2. wakeup the chip from elp (if needed)
3. fix memory leak in wl1271_tm_cmd_interrogate()
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>

This code has been on the list to remove for a long
time, so disable it by default, add a warning to its
Kconfig, and schedule it for removal in 3.5.

The only known dependency, hal, has not required it
since its 0.5.12 release, which was in early 2009
and hal has since been deprecated completely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  Enable ANI for ar9100 since it seems to be working fine (and as a
matter of fact ANI was always performed for ar9100 since code which
was supposed to disable it didn't achieve this goal).
  This patch sets config.enable_ani to default (true) value for
ar9100.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  Currently in ath9k code there is an attempt which is meant to
disable ANI for ar9100 and ar9340. But it doesn't really achieve
this. All it does is disable ANI init and setup (i.e. calls to
ath9k_hw_ani_setup and ath9k_hw_ani_init). Since ath9k_hw_ani_setup is
not called ah->config.ani_poll_interval is never initialized (i.e. it
is always zero) and ath_ani_calibrate always executes ANI procedures
(over uninitialized ANI parameters).
  Moreover, ath_ani_calibrate is being called each 1ms because
common->ani.timer is set to zero interval because
ah->config.ani_poll_interval==0 (and thus smallest value of all
intervals). Normally it should not be called this often.
  This patch changes the code so config.enable_ani is used to check if
ANI should be performed.
  config.enable_ani is initialized to true by default. This patch sets
it to false for ar9100 and ar9340.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  To help debugging write a log entry when long calibration, short
calibration or ANI is performed.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  Add missed space and change typo in calibration debugging log.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Recently more places in mac80211 call drv_flush to ensure proper order
for state changes wrt. powersave, channel changes, etc. On some systems
such calls lead to spurious logspam about failing to stop tx dma, as well
as hardware resets that go along with that.
Instead of dropping packets in a place where it's completely unnecessary,
only do it when drop == true.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Turning off the radio when mac80211 tells the driver that it's idle is not
a good idea, as idle interfaces might still occasionally scan or send packets.
The only time the radio can be safely turned off is when drv_stop has been
called. In the mean time, use sc->ps_idle only to indicate network sleep vs
full sleep.
Move the LED GPIO changes out of the PCI suspend/resume path, the start/stop
functions already take care of that.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

After waking up from full sleep, registers are accessible, but rx/tx
typically fails. A fast channel change will not recover from this, so
ensure that a full-sleep -> wake transition is always followed by a full
reset.

The reason why this hasn't created any serious problems yet is that it's
hidden by the (wrong) behavior of enabling/disabling the radio when the
wiphy idle state changes.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

AP interfaces routinely call this logic, so just silently
return when this happens instead of splatting the kernel
logs.
Reported-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>