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

The prism54 driver had an entry in feature-removal-schedule.txt and it
sees very little activity other than API-change "bombing runs".  The
mac80211-based p54 driver should be used instead.
Signed-off-by: John 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: John W. Linville <linville@tuxdriver.com>

Adapted from Realtek-provided driver...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested-by: Pauli 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: John 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: John 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-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: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Johannes 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-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: Wey-Yi Guy <wey-yi.w.guy@intel.com>

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

IBSS has never had locking, instead relying on some
memory barriers etc. That's hard to get right, and
I think we had it wrong too until the previous patch.
Since this is not performance sensitive, it doesn't
make sense to have the maintenance overhead of that,
so add proper locking.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Bob reported a lockdep complaint originating in
the mac80211 IBSS code due to the common work
struct patch. The reason is that the IBSS and
station mode code have different locking orders
for the cfg80211 wdev lock and the work struct
(where "locking" implies running/canceling).

Fix this by simply not canceling the work in
the IBSS code, it is not necessary since when
the REQ_RUN bit is cleared, the work will run
without effect if it runs. When the interface
is set down, it is flushed anyway, so there's
no concern about it running after memory has
been invalidated either.

This fixes
https://bugzilla.kernel.org/show_bug.cgi?id=16419

Additionally, looking into this I noticed that
there's a small window while the IBSS is torn
down in which the work may be rescheduled and
the REQ_RUN bit be set again after leave() has
cleared it when a scan finishes at exactly the
same time. Avoid that by setting the ssid_len
to zero before clearing REQ_RUN which signals
to the scan finish code that this interface is
not active.
Reported-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When WEP is not available, we should reject shared
key authentication because it could never succeed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

device_add() is called before adding the phy to the cfg80211 device
list.

So if a userspace program uses sysfs uevents to detect new phy
devices, and queries nl80211 to get phy info, it can get ENODEV even
though the phy exists in sysfs.

An easy workaround is to hold the cfg80211 mutex until the phy is
present in sysfs/cfg80211/debugfs.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.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: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John 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: John W. Linville <linville@tuxdriver.com>

The existing code seemed to be somewhat based on the datasheet, but
varied substantially from the vendor-provided driver.  This mirrors the
handling of the rtl8185 case from that driver, but still neglects the
specifics for the rtl8180 hardware.  Those details are a bit muddled...
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21:    expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21:    got int
drivers/net/wireless/mwl8k.c:1575:42:    expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42:    got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50:    expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50:    got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50:    expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50:    got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20:    expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20:    got unsigned short [unsigned] [usertype] cap

At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>

"Might as well remove  reg_same_country_ie_hint() completely since we
already dealt with suspend/resume through the regulatory hint
disconnect." -- Luis
Reported-by: Luis R. Rodriguez <mcgrof@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CHECK   drivers/net/wireless/rt2x00/rt2x00debug.c
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28:    expected restricted __le32 [usertype] chip_rev
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28:    got restricted __le16 [usertype] <noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>

  CHECK   drivers/net/wireless/ipw2x00/libipw_module.c
drivers/net/wireless/ipw2x00/libipw_module.c:65:21: warning: symbol 'libipw_config_ops' was not declared. Should it be static?
drivers/net/wireless/ipw2x00/libipw_module.c:66:6: warning: symbol 'libipw_wiphy_privid' was not declared. Should it be static?
  CHECK   drivers/net/wireless/ipw2x00/libipw_wx.c
drivers/net/wireless/ipw2x00/libipw_wx.c:415:17: warning: symbol 'ssid' shadows an earlier one
drivers/net/wireless/ipw2x00/libipw_wx.c:324:9: originally declared here
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CHECK   drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2100.c:177:28: warning: symbol 'ipw2100_pm_qos_req' was not declared. Should it be static?
Signed-off-by: John W. Linville <linville@tuxdriver.com>

drivers/net/wireless/ath/ath9k/main.c:282:26: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/main.c:282:26:    expected restricted __le16 [usertype] duration_id
drivers/net/wireless/ath/ath9k/main.c:282:26:    got int
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CHECK   net/wireless/sme.c
net/wireless/sme.c:38:6: warning: symbol 'cfg80211_is_all_idle' was not declared. Should it be static?

It is not used elsewhere, so mark it static.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CHECK   net/wireless/regdb.c
net/wireless/regdb.c:8:34: warning: symbol 'reg_regdb' was not declared.  Should it be static?
net/wireless/regdb.c:11:5: warning: symbol 'reg_regdb_size' was not declared. Should it be static?

Simply include the also generated regdb.h.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CHECK   net/wireless/wext-compat.c
net/wireless/wext-compat.c:1434:5: warning: symbol 'cfg80211_wext_siwpmksa' was not declared. Should it be static?

Add declaration in cfg80211.h.  Also add an EXPORT_SYMBOL_GPL, since all
the peer functions have it.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

  CHECK   net/wireless/lib80211_crypt_tkip.c
net/wireless/lib80211_crypt_tkip.c:581:27: warning: cast to restricted __le16

Caused by dereferencing a "u8 *" and passing it to le16_to_cpu...
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The meaning and/or usage of the country IE is somewhat poorly defined.
In practice, this means that regulatory rulesets in a country IE are
often incomplete and might be untrustworthy.  This removes the code
associated with interpreting those rulesets while preserving respect
for country "alpha2" codes also contained in the country IE.
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If a station interface is reused as monitor interface it is possible that
the carrier is still set to off. This breaks packet injection on that
monitor interface.
Force the carrier on in monitor interface initialisation like it is also done
for other interface types (e.g. adhoc, mesh point, ap).
Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Ever since

commit e1b3ec1a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Mar 29 12:18:34 2010 +0200

    mac80211: explicitly disable/enable QoS

mac80211 is telling drivers, in particular
iwlwifi, whether QoS is enabled or not.

However, this is only relevant for station mode,
since only then will any device send nullfunc
frames and need to know whether they should be
QoS frames or not. In other modes, there are
(currently) no frames the device is supposed to
send.

When you now consider virtual interfaces, it
becomes apparent that the current mechanism is
inadequate since it enables/disables QoS on a
global scale, where for nullfunc frames it has
to be on a per-interface scale.

Due to the above considerations, we can change
the way mac80211 advertises the QoS state to
drivers to only ever advertise it as "off" in
station mode, and make it a per-BSS setting.
Tested-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When aggregation related action frames are enqueued for further work,
and they originate from a STA that is part of an AP VLAN, they are
currently enqueued for the AP interface. This breaks the sta_info_get()
lookup in the actual work function, and because of that, aggregation
sessions are not established for this STA.

Fix this by replacing the sta_info_get call with a call to
sta_info_get_bss.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

"Recover from tx stall" function is available for all devices except
4965, here add the functionality to 4965.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Display "wait_for_silence_timeout_cnt" for _agn devices
in debugfs as part of uCode statistics
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Add wait_for_silence_timeout_cnt to statistics_dbg structure
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>