These macros are leftover of previous cleanup patches.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

struct mwifiex_802_11_fixed_ies is not necessary.
struct mwifiex_event_wep_icv_err is not used any more.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

remove redundant structures and unused macros

Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

IEEE Std 802.11n, Oct. 29, 2009:
7.3.2.56.5 HT Extended Capabilities field

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

These definitions are no longer used after previous cleanups.

Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The radio_on variable is defined but never used.

Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

replace them with NL80211_AUTHTYPE_ macros

Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

replace them with NL80211_IFTYPE_ macros

Also remove redundant functions mwifiex_drv_get_mode()
and mwifiex_bss_ioctl_mode().

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We already tell mac80211 to stop the queue when we hit a certain
threshold. Hence, it shouldn't happen at all that a frame gets queued
for tx on a full queue. Add an error message for this case.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Some clients seem to rely upon the reception of BlockAckReqs to flush
their rx reorder buffer. In order to fix aggregation for these clients
rt2x00 should send a BlockAckReq if the transmission of an AMPDU
subframe fails.

Introduce a new flag TXDONE_AMPDU to indicate that this is an AMPDU
subframe and pass IEEE80211_TX_STAT_AMPDU_NO_BACK to mac80211 if an
AMPDU subframe failed during transmission.

This fixes aggregation problems with Intel 5100 Windows STAs (and maybe
others as well).

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

Add new USB ID

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

For STBC transmissions rt2x00 used the number of RxSTBC streams the
destination STA indicates in its HT capabilities as STBC value in
the TXWI.

However, the legacy drivers and our own comment in rt2800.h suggest
that the STBC field in the TXWI only allows a value of 0 or 1.
The values 2 and 3 are reserved (probably for future devices).

And indeed, STBC transmissions to STAs indicating more then 1
RxSTBC stream fail when the STBC field is set to something >1.

Fix this by only setting the STBC field to 1 when STBC should be
used.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2800 devices should adjust their tx power in accordance with the
eeproms temperature calibration values. Add a new driver callback
gain_calibration that is called every 4 seconds.

The rt2800 gain calibration routine simply runs the tx power
configuration that takes care of calculating the temperature
compensation delta.

We don't need to synchronize the calls to rt2800_config_txpower
as they should all happen from mac80211's single threaded workqueue.

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

Since commit d1c3a37c ("mac80211:
clarify alignment docs, fix up alignment") removed the requirement
for a 4-byte aligned payload rt2x00queue_align_payload is obsolete
as mac80211 will align the payload when it passes the frame to the
net stack.

As a result we can remove the call to rt2x00queue_align_payload in the
rx path and since that's the last user we can remove
rt2x00queue_align_payload altogether.

One advantage is that we save some alignment operations for frames
that don't need to be aligned (for example beause they are not passed
to the net stack).

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

Fix the indention in rt2800_compesate_txpower and also fix a typo in
the function name rt2800_compesate_txpower -> rt2800_compensate_txpower.

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

Previously the HT40 tx power compensation value was calculated for each
rate. However, the calculation is independent of the tx rate and as such
can be precalculated and just passed in for each rate.

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

Move the HT40 check inside the calculation function to make it easier
for a later cleanup.

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

We can simply check if the driver registered the watchdog callback.
There's no need to have an additional flag for that.

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

Instead of hardcoding the tx status fifo size as 512 calculate it based
on the number of tx queues and the number of entries per queue. Also
round the size up to a power of 2 as kfifo would otherwise round it
down.

On rt2800pci this will increase the kfifo size from 512 bytes to 1024
bytes which is then able to hold the tx status for all entries in all
tx queues.

Furthermore, if the number of tx queues or tx entries changes in the
future (use of the MGMT queue for example) the kfifo size doesn't need
to be updated.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Instead of reporting an unlimited number of tx status reports to
mac80211 stop after 16 frames and reschedule the tx status tasklet.
This allows other tasklets to be run inbetween.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Instead of receiving an unlimited number of frames, stop after 16
entries and reschedule the rxdone tasklet. This allows other tasklets
to be run inbetween.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Remove some unused variables and correct spelling errors.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The hw_dot_11n_dev_cap reported by firmware hw_spec
has different format than the 11n capabilities.
Hence a lot of SET_ and RESET_ bit operation macros
were used to convert the dev_cap format to 11n
capability format. However the locally defined 11n
ht_cap macros are not necessary as we can use
IEEE80211_HT_CAP_ macros directly.

The 32-bit dev_cap bitmap is added as comment to
explain the mapping between firmware and 11n spec.

Some unused macros and unnecessary adapter variables
are also removed.

Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

and SHORT_SLOT_TIME_ENABLED.
Use WLAN_CAPABILITY_SHORT_SLOT_TIME instead.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The only thing that using crypto_blkcipher with ecb does over just using
arc4 directly is wrapping the encrypt/decrypt function into a for loop,
looping over each individual character.
To be able to do this, it pulls in around 40 kb worth of unnecessary
kernel modules (at least on a MIPS embedded device).
Using arc4 directly not only eliminates those dependencies, it also makes
the code smaller.

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

mwifiex_set_encrypt_mode()
mwifiex_set_auth_mode()
mwifiex_set_auth()
These functions are confusing and misleading.
And they are really not needed at all.

Some unused definitions are also removed.

Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

'iw list' is sufficient to retrieve the information which
was displayed by these functions.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The commit "mac80211: reply to directed probes in IBSS" changed ad-hoc
specific code to respond to unicast probe requests, even if
drv_tx_last_beacon returns false, however due to confusion over the
meaning of the IEEE80211_RX_RA_MATCH flag, it also unconditionally
enabled responding to multicast probe requests.
Fix this by explicitly checking for a multicast destination address
instead.

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

This function is nowhere used.

Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This does not seems to be used anywhere so remove it.

Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Aids debugging wifi behaviour.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add iwlegacy driver to MAINTAINERS.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John 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

It has the same purpose (and value) as ah->config.max_txtrig_level

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

It is not used anywhere

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

Similar to the number of tx queue, the number of keycache entries depends
on the chip and shouldn't be messed with based on EEPROM data.
Remove this field and stick to using AR_KEYTABLE_SIZE

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

It is not used anywhere and seems pointless

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

It is only used in one place, and the device id check that it's based on
can be moved there as well.

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

The EEPROM contains a field that can restrict the number of hardware queues,
however this is not only useless (all the known chips contain the same
number of hardware queues), but also potentially dangerous in case of a
misprogrammed EEPROM (could trigger driver crashes), so let's just ignore
it completely.

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