These were no longer used but were left around; Transmit Power
Control is done through the lbs_set_tpc_cfg() function.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Convert to a full direct command; previous code rolled a direct
command by hand but left the original indirect command code intact
but disabled.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Convert to a full direct command; previous code rolled a direct
command by handle but left the original indirect command code
lying around.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On our hardware (050d:7050 Belkin Components F5D7050 Wireless G Adapter),
setting any WEP key with non zero index, cause rx frames corruption.

Note: perhaps (I did not check) this can be fixed differently - by using
hw_key_idx the same as true MAC key index. But according to the comment in
rt2x00mac_set_key():

"the hardware requires keys to be assigned in correct order (When key 1
is provided but key 0 is not, then the key is not found by the hardware
during RX)"

this will be quite problematic. Since WEP should not be used, disabling
hardware crypto offload for it will not hurt much. Beside static
one key WEP will still be offloaded.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Without cipher part nullify of TXRX_CSR0 register we can receive
corrupted frames (removed IV or IVC), after reloading rt2500usb module
with nohwcrypt=1 option, if previous some keys were configured into
the hardware.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix rt2500usb hardware encryption broken by commit
96b61baf
"rt2x00: Clean up USB vendor request buffer functions"
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

base index is not used anymore and so remove it.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser
than MCS15 rate. This incorrect rate may affect switching to higher
rates as the rate control algorithm always finds MCS15 is better
than MCS15 ShortGI and results in lower throughput. Fix this by
feeding the correct user ratekbs for MCS15 ShortGI rate.

This issue affects 3 stream case very badly as the 3 stream rates are
not used at all once we scale down to MCS15 from 3 stream rates.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds 3 stream rate control support for AR938X family
chipsets which supports 3 streams.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

replace valid and valid_single_stream in rate table with bit masks
and reorganize the code so adding 3x3 rate control would be easier.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since commit:
     commit f1aa4c54
     Author: Ivo van Doorn <ivdoorn@gmail.com>
     Date:   Tue Jun 29 21:38:55 2010 +0200

     rt2x00: Write the BSSID to register when interface is added

mananged mode in rt2500pci was broken, due to intf->bssid containing
random data rather then the expected 00:00:00:00:00:00

This is corrected by sending the BSSID to rt2x00lib_config_intf
only in AP mode where the bssid is set to a valid value.
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 noisefloor array index always corresponds to the rx chain number it
belongs to (with an offset of 3 for the extension chain).

It's much simpler (and actually more correct) to directly use the
chainmask to calculate the bitmask for the noisefloor array, instead of
using these weird chip revision checks and hardcoded mask values.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the noisefloor array, the extension channel values start at index 3
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the hardware is configured in HT20 mode, noise floor readings for
the extension channel often return invalid values, which keep the
values in the NF history buffer at the hardware-specific maximum limit.
Fix this by discarding the extension channel values when in HT20 mode.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When an aggregation session is being cleaned up, while the tx status
for some frames is being processed, the TID is flushed and its buffers
are sent out.

Unfortunately that left the pending un-acked frames unprocessed, thus
leaking buffers. Fix this by reordering the code so that those frames
are processed first, before the TID is flushed.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Negate has precedence over comparison so the original test was always
false.  (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR).
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Sometimes txq state(txq->stopped) can be marked as started but the actual
queue may not be started (in ATH_WIPHY_SCAN state, for example). Fix this.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

snprintf() returns the number of characters that would have been written
(not counting the NUL character).  So we can't use it as the limiter to
simple_read_from_buffer() without capping it first at sizeof(buf).
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The snprintf() function returns the number of characters that would have
been written (not counting the NUL character on the end).  It could
potentially be larger than the size of the buffer.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use kmemdup when some other buffer is immediately copied into the
allocated region.

A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression from,to,size,flag;
statement S;
@@

-  to = \(kmalloc\|kzalloc\)(size,flag);
+  to = kmemdup(from,size,flag);
   if (to==NULL || ...) S
-  memcpy(to, from, size);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The current practice of checking vif for NULL in one place but not
another seems to confuse some static checkers, smatch in particular.
Since vif will only be NULL in the case of internal scans, adjust the
checks accordingly.
Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

  CHECK   drivers/net/wireless/rtl818x/rtl8180_rtl8225.c
drivers/net/wireless/rtl818x/rtl8180_rtl8225.c:53:33: warning: dubious: x | !y

The existing code is clever and works fine, but it's not worth even a
single line of Sparse warning SPAM...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adapted from Realtek-provided driver...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Tested-by: NPauli Nieminen <suokkos@gmail.com>

  CHECK   drivers/net/wireless/wl12xx/wl1251_tx.c
drivers/net/wireless/wl12xx/wl1251_tx.c:118:32: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_tx.c:118:32:    expected unsigned short [unsigned] [usertype] frag_threshold
drivers/net/wireless/wl12xx/wl1251_tx.c:118:32:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_tx.c:164:24: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_tx.c:164:24:    expected unsigned short [unsigned] [usertype] length
drivers/net/wireless/wl12xx/wl1251_tx.c:164:24:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_tx.c:166:22: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_tx.c:166:22:    expected unsigned short [unsigned] [usertype] rate
drivers/net/wireless/wl12xx/wl1251_tx.c:166:22:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_tx.c:167:29: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_tx.c:167:29:    expected unsigned int [unsigned] [usertype] expiry_time
drivers/net/wireless/wl12xx/wl1251_tx.c:167:29:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_tx.c:200:43: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/wl12xx/wl1251_tx.c:200:43:    expected restricted __le16 [usertype] fc
drivers/net/wireless/wl12xx/wl1251_tx.c:200:43:    got unsigned short [unsigned] [assigned] [usertype] fc
  CHECK   drivers/net/wireless/wl12xx/wl1251_cmd.c
drivers/net/wireless/wl12xx/wl1251_cmd.c:428:39: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_cmd.c:428:39:    expected unsigned int [unsigned] [usertype] rx_config_options
drivers/net/wireless/wl12xx/wl1251_cmd.c:428:39:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_cmd.c:429:39: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_cmd.c:429:39:    expected unsigned int [unsigned] [usertype] rx_filter_options
drivers/net/wireless/wl12xx/wl1251_cmd.c:429:39:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_cmd.c:435:29: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_cmd.c:435:29:    expected unsigned short [unsigned] [usertype] tx_rate
drivers/net/wireless/wl12xx/wl1251_cmd.c:435:29:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_cmd.c:439:47: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_cmd.c:439:47:    expected unsigned int [unsigned] [usertype] min_duration
drivers/net/wireless/wl12xx/wl1251_cmd.c:439:47:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/wl12xx/wl1251_cmd.c:441:47: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/wl1251_cmd.c:441:47:    expected unsigned int [unsigned] [usertype] max_duration
drivers/net/wireless/wl12xx/wl1251_cmd.c:441:47:    got restricted __le32 [usertype] <noident>
  CHECK   drivers/net/wireless/wl12xx/wl1251_boot.c
drivers/net/wireless/wl12xx/wl1251_boot.c:228:22: warning: symbol 'interrupt' shadows an earlier one
/home/linville/git/wireless-next-2.6/arch/x86/include/asm/hw_irq.h:132:13: originally declared here
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"iwlagn: add statistic notification structure for WiFi/BT devices" added
several new '__attribute__ ((packed))' lines.  Change them to the
generic __packed.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

defines shouldn't be terminated with a
semicolon, the code using them should
supply it. Luckily these are not used
in a context where it matters.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since the ibss_beacon variable will only be
filled in the appropriate modes, there's no
reason to be checking the mode again.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Some devices may have multiple MAC
addresses in their EEPROM, read them
and advertise them to cfg80211.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This function is only needed in the same
file it is defined in, i.e. iwl-core.c
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

gcc complains about the firmware loading:

iwl-agn.c: In function ‘iwlagn_load_firmware’:
iwl-agn.c:1860: warning: ‘tlv_len’ may be used uninitialized in this function
iwl-agn.c:1861: warning: ‘tlv_type’ may be used uninitialized in this function
iwl-agn.c:1862: warning: ‘tlv_data’ may be used uninitialized in this function

This is almost correct but we do do break out of the TLV
parsing loop when setting ret. However, the code is hard
to follow, and clearly even the compiler is having issues
with it too.

Additionally, however, the current code is wrong. If there
is a TLV length check error, the code will report
	invalid TLV after parsing: ...
because "len" will still be non-zero as we broke out of
the loop.

So to remove the warning and fix that issue, make the code
easier to read by doing length checking with an error label.
As a result, we can completely remove the "ret" variable.

Also, while at it, remove the "fixed_tlv_size" variable
since each TLV type has its own specified length, it just
happens that we have only variable length, flags (0 length)
and u32 TLVs right now. It should still be checked with more
explicit length checks to make it easier to understand.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Different devices have different size of phy calibration table; add
new TLV to specify the size. If the TLV is not part of uCode header, the
default table size will be used to make sure the backward
compatibilities.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For WiFi/BT combo devices, add bluetooth statistics counter
read function to debugfs.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

WiFi/BT combo devices has different statistics notification
structure, adding the support here to make sure the structure
align correctly.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Only WiFi/BT combo devices need to use bluetooth version of statistics
notification; adding the flag in .cfg file to indicate the need for
using different data structure.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If its WiFi/BT combo device, the statistics notification sent by
uCode will include the additional BT related statistics counters.

Adding new data structure to support the new layout.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

drivers/net/wireless/b43/phy_n.c:512:53: warning: cast truncates bits from constant value (ffff0fff becomes fff)
drivers/net/wireless/b43/phy_n.c:765:66: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/b43/phy_n.c:1012:38: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/phy_n.c:1119:38: warning: cast truncates bits from constant value (ffff0fff becomes fff)
drivers/net/wireless/b43/phy_n.c:2458:56: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/b43/phy_n.c:2933:38: warning: cast truncates bits from constant value (ffff0fff becomes fff)
drivers/net/wireless/b43/phy_n.c:3294:57: warning: cast truncates bits from constant value (ffff3fff becomes 3fff)
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

  CHECK   drivers/net/wireless/b43/main.c
drivers/net/wireless/b43/main.c:111:5: warning: symbol 'b43_modparam_pio' was not declared. Should it be static?
  CHECK   drivers/net/wireless/b43/phy_g.c
drivers/net/wireless/b43/phy_g.c:975:56: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
  CHECK   drivers/net/wireless/b43/phy_lp.c
drivers/net/wireless/b43/phy_lp.c:2701:6: warning: symbol 'b43_lpphy_op_switch_analog' was not declared. Should it be static?
drivers/net/wireless/b43/phy_lp.c:1148:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1525:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1529:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
  CHECK   drivers/net/wireless/b43/wa.c
drivers/net/wireless/b43/wa.c:385:60: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:403:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:405:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:415:71: warning: cast truncates bits from constant value (ffff0fff becomes fff)

AFAICT, none of these amount to real bugs.  But this reduces warning
spam from sparse w/o significantly affecting readability of the code (IMHO).
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>