There's no need to check for NULL before
calling dev_kfree_skb() since it is valid
to call it on NULL -- it becomes a no-op.

There's also no need to initialise the
beacon_skb variable to NULL just after
the memory it is in has been kzalloc'ed.

Some minor whitespace cleanups, and a
lock assertion in a function that needs
the mutex (to access the beacon_skb var)
complete the patch.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since we're also going to support AP (GO) mode,
the variable isn't used for just IBSS beacons
any more -- rename it to not mislead readers.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There are two passive 2.4 GHz channels: 12 and 13.
If you have a hidden SSID on those, you will not
be able to connect to it because we don't send out
probe requests there. We can allow this by using
the firmware's probe-after-rx functionality on
those channels as well.

This fixes
https://bugzilla.kernel.org/show_bug.cgi?id=16462Reported-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For BT/WiFi combo devices, need longer tx stuck queue
timer, so those devices won't reload firmware too often.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The ath_debug_stat_tx references bf->bf_mpdu, which
is the skb consumed by 	ath_tx_complete.  So, call
the ath_debug_stat_tx method first.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It looks like I submitted a different patch
than I tested, because clearly the code in
mac80211 is missing actually propagating the
requested SMPS mode. Fix that!
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This allows mac80211 to enable receiving of Probe Request frames in
station mode which is needed for P2P.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using the frame registration notification, we
can see when probe requests are requested and
notify the low-level driver via filtering. The
flag is also set in AP and IBSS modes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Drivers may need to adjust their filters according
to frame registrations, so notify them about them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fix updates the documenation in Rate Control Table structure
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This automatically keeps things proper when wiphy
is renamed.

Based on patch by Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NBen Greear <greearb@candelatech.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wext: fix alignment problem in serializing 'struct iw_point'

This fixes a typo in the definition of the serialized length of struct iw_point:
 a) wireless.h is exported to userspace, the typo causes IW_EV_POINT_PK_LEN
    to be 12 on 64-bit, and 8 on 32-bit systems (causing misalignment);
 b) in compat-64 mode iwe_stream_add_point() memcpys overlap (see below).

The second case in  in compat-64 mode looks like (variable names are as in
include/net/iw_handler.h:iwe_stream_add_point()):

 point_len = IW_EV_COMPAT_POINT_LEN = 8
 lcp_len   = IW_EV_COMPAT_LCP_LEN   = 4
 2nd memcpy: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 12 - 4 = 8

 IW_EV_LCP_PK_LEN
 <-------------->                *---> 'extra' data area
 +-------+-------+-------+-------+---------------+------- ...-+
 | len   | cmd   |length | flags |  (empty) -> extra      ... |
 +-------+-------+-------+-------+---------------+------- ...-+
    2       2       2       2          4

     lcp_len
 <-------------->                <-!! OVERLAP !!>
 <--1st memcpy--><------- 2nd memcpy ----------->
                                 <---- 3rd memcpy ------- ... >
 <--------- point_len ---------->

This case could cause overrun whenever iw_point.length < 4.
The other two cases are -
 * 32-bit systems: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN =  8 - 4 = 4,
   the second memcpy copies exactly the 4 required bytes;
 * 64-bit systems: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 12 - 4 = 8,
   the second memcpy copies a superfluous (but non overlapping) 4 bytes.

The patch changes IW_EV_POINT_PK_LEN to be 8, so that in all 3 cases always only
the requested iw_point.{length,flags} (both __u16) are copied, avoiding overrrun
(compat-64) and superfluous copy (64-bit). In addition, the userspace header is
sanitized (in agreement with version 30 of the wireless tools).

Many thanks to Johannes Berg for help and review with this patch.
Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Also improve ath_opmode_to_string usage by having it return UNKNOWN
rather than NULL in the event of failure to map the opmode value to a
representative string.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The index cannot be used to reliably reconstruct a phy
name, so explicitly add the phy name to sysfs so that scripts
can figure out the parent phy device for a particular
wireless interface.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6

commit 6f98613258b966ffe0e6def18129b386514d10e0
Author: Jay Sternberg <jay.e.sternberg@intel.com>
Date:   Sat Sep 18 09:07:04 2010 -0700

    iwlagn: reduce redundant parameter definitions

broke 3945 because Jay accidentally removed the
num_of_queues parameter for 3945, so that we now
attempt to allocate a zero-sized queue array,
which leads to SLUB returning ZERO_SIZE_PTR (0x10)
which we then try to dereference thus crashing the
system. Restore the necessary num_of_queues param.

This fixes
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2254Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For WiFi/BT combo devices, priority table always need to download
before perform any calibration operation.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For advance BT/WiFi co-exist, always download bt priority table
before sending bt_config command
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

kill_urb guarentees that when the function returns, the URB has
been fully killed. This means we don't need the extra sleeping
after the call to kill_urb.

kill_urb can however also guarentee the submit_urb to fail, as
a result, we must catch the return value from submit_urb an
correctly mark the entry as owned by the driver, and the
status as broken.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The currently used watchdog functions cannot be applied
to empty queues.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All access to the queue_entry->flags can be done concurrently,
so all flags must use the atomic operators. On most locations
this was already done, so just fix the last few non-atomic
versions.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the RX skb allocation failed, we should recycle
the previously allocated skbuffer. By calling return
we would kill the RX queue completely since the
entry would be invalidated.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Similar to the PLCP signal and bitrates values,
we should validate the MCS value from the RX descriptor
before sending it to mac80211.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The watchdog function must run on a work_queue
which is independent of any other work inside rt2x00.

The main reasons, being that a broken work on the mac80211
work_queue can otherwise prevent the watchdog to run (while
in fact the watchdog could fix the issue). And on the other
hand because the watchdog relies on the completion of the
completion handlers for RX/TX which for the USB case, occur
on the mac80211 workqueue.

This fixes some "Queue %d failed to flush" errors, which were
caused by the watchdog function waiting on the completion
handler which was scheduled to run right after the watchdog.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A lot of functions accept a struct rt2x00_dev combined with
either a struct queue_entry or struct data_queue argument.
This can be simplified by only passing on the queue/entry
argument.

In cases where rt2x00_dev and a sk_buff are send together,
we can send the queue_entry instead.

rt2x00usb_alloc_urb and rt2x00usb_free_urb have a bit
of vague naming. Instead they allocate all the data which
belongs to a rt2x00 data queue entry.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Stanse found that urb cannot be NULL in at76_rx_tasklet because it is
dereferenced earlier, so remove the unneeded check.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch attempts to ensure that ath9k's built-in rate control algorithm
does not rely on the value of the ampdu_len and ampdu_ack_len tx status
fields unless the IEEE80211_TX_STAT_AMPDU flag is set.

This patch has not been tested.

Cc: <stable@kernel.org>
Signed-off-by: NBjörn Smedman <bjorn.smedman@venatech.se>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes the following problems with the rate control feedback
generated by ath9k for A-MPDU frames:

1. Rate control feedback is carried on the first frame of an aggregate
that is either ACKed, or has execeeded the software retry count and is
considered failed. However, ath9k would incorrectly assume the aggregate
had the length 1 if one of these conditions did not apply to the first
frame of the aggregate, but instead a later frame. This fix therefor
copies the bf_nframes field of the buffer in the same manner as the rates
field of the tx status.

2. Sometimes the ampdu_len and ampdu_ack_len fields of the tx status was
left uninitialized eventhough the IEEE80211_TX_STAT_AMPDU flag was set.
This is now avoid by setting flag and fields in the same place.

3. Even if a frame has been selected for aggregation by mac80211 and
marked with the IEEE80211_TX_CTL_AMPDU flag it can sometimes happen that
ath9k transmits the frame without aggregation. In these cases the
ampdu_ack_len field could be incorrectly computed because the nbad
parameter to ath_tx_rc_status was incorrect.

Cc: <stable@kernel.org>
Signed-off-by: NBjörn Smedman <bjorn.smedman@venatech.se>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes two problems with the minstrel_ht rate control
algorithms handling of A-MPDU frames:

1. The ampdu_len field of the tx status is not always initialized for
non-HT frames (and it would probably be unreasonable to require all
drivers to do so). This could cause rate control statistics to be
corrupted. We now trust the ampdu_len and ampdu_ack_len fields only when
the frame is marked with the IEEE80211_TX_STAT_AMPDU flag.

2. Successful transmission attempts where only recognized when the A-MPDU
subframe carrying the rate control status information was marked with the
IEEE80211_TX_STAT_ACK flag. If this information happed to be carried on a
frame that failed to be ACKed then the other subframes (which may have
succeeded) where not correctly registered. We now update rate control
statistics regardless of whether the subframe carrying the information was
ACKed or not.

Cc: <stable@kernel.org>
Signed-off-by: NBjörn Smedman <bjorn.smedman@venatech.se>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since this small buffer isn't used for DMA,
we can simply allocate it on the stack, it
just needs to be 16 bytes of which only 8
will be used for WEP40 keys.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl1251 is grown up now and can have its own room^H^H^H^Hdirectory.
Signed-off-by: NKalle Valo <kvalo@adurom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl1271 driver is under heavy development but on the other hand the older
wl1251 driver is currently considered more as a legacy driver. To make it
easier to develop wl1271 features move wl1251 to it's own directory,
drivers/net/wireless/wl1251.

There are no functional changes, only moving of files. One regression
is that Kconfig won't be updated automatically and user needs to enable
wl1251 manually with an older config file.
Signed-off-by: NKalle Valo <kvalo@adurom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In preparation of moving wl1251 out from drivers/net/wireless/wl12xx
create a separate copy of wl12xx_80211.h.

This file should not even exist, we should instead use generic ieee80211
definitions. This will be fixed in the future so that the file can
be removed.
Signed-off-by: NKalle Valo <kvalo@adurom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the past, carl9170 has been plagued by mysterious
ghosts.

e.g.:
 wlan4: deauthenticated from 02:04:d8:3c:ac:c1 (Reason: 0)

Apparently, the AP sent us a bogus deauthentication
notification. But upon closer inspection the
"management frame" turned out to be a corrupted
scrap of an unsuccessful A-MPDU.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The total/fatal error bit was erroneously prefixed
with AR9170_RX_ERROR instead of AR9170_RX_STATUS.
Luckily, the hardware specification confirmed that
the 0x80 flag will never be set for mac->error.
So, it was always just a dead branch.

This patch also imports the latest version of
shared wlan.h header from the firmware git.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch replaces several identical frame drop
paths with a single shared rx frame error handler.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>