iwl3945's scan_completed calls into the mac80211 stack which triggers a
warn on if there is no scan outstanding.

This can be avoided by not calling scan_completed but abort_scan in
iwl3945_request_scan  in the done: branch of the function which is used
as an error out.

The done: branch seems to be an error-out branch, as, for example, if
iwl_is_ready(priv) returns false  the done: branch is executed.

NOTE:
I'm not familiar with the driver at all.
I just quickly scanned as a reaction to

https://bugzilla.kernel.org/show_bug.cgi?id=17722

the users of scan_completed in the  iwl3945 driver and noted the odd
discrepancy between the comment above this instance and the comment in
mac80211 scan_completed function.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When uCode error condition detected, driver try to perform either
rf reset or firmware reload in order bring device back to
working condition.

If rf reset is required and scan is in process, there is no need
to issue rf reset since scan already reset the rf.

If firmware reload is required and scan is in process, skip the
reload request. There is a possibility firmware reload during
scan cause problem.

[  485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62()
[  485.804049] Hardware name: Latitude E6400
[  485.804052] ieee80211_restart_hw called with hardware scan in progress
[  485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore]
[  485.804069] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
[  485.804072] Call Trace:
[  485.804079]  [<c103019a>] warn_slowpath_common+0x60/0x75
[  485.804084]  [<c1030213>] warn_slowpath_fmt+0x26/0x2a
[  485.804089]  [<c145da67>] ieee80211_restart_hw+0x28/0x62
[  485.804102]  [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn]
[  485.804108]  [<c10415d5>] process_one_work+0x181/0x25c
[  485.804119]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
[  485.804124]  [<c104190a>] worker_thread+0xf9/0x1f2
[  485.804128]  [<c1041811>] ? worker_thread+0x0/0x1f2
[  485.804133]  [<c10451b0>] kthread+0x64/0x69
[  485.804137]  [<c104514c>] ? kthread+0x0/0x69
[  485.804141]  [<c1002df6>] kernel_thread_helper+0x6/0x10
[  485.804145] ---[ end trace 3d4ebdc02d524bbb ]---
[  485.804148] WG> 1
[  485.804153] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
[  485.804156] Call Trace:
[  485.804161]  [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62
[  485.804172]  [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn]
[  485.804177]  [<c10415d5>] process_one_work+0x181/0x25c
[  485.804188]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
[  485.804192]  [<c104190a>] worker_thread+0xf9/0x1f2
[  485.804197]  [<c1041811>] ? worker_thread+0x0/0x1f2
[  485.804201]  [<c10451b0>] kthread+0x64/0x69
[  485.804205]  [<c104514c>] ? kthread+0x0/0x69
[  485.804209]  [<c1002df6>] kernel_thread_helper+0x6/0x10
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For 5000 series of devices, use long monitor timer to check
stuck tx queues.

This modification apply to all the 5000 series including 5300 and others.

Cc: stable@kernel.org [2.6.35]
Reported-by: Ndrago01 <drago01@gmail.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Applying the filter flags directly as done since

commit 3474ad63
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 29 04:43:05 2010 -0700

    iwlwifi: apply filter flags directly

broke 3945 under some unknown circumstances, as
reported by Alex.

Since I want to keep the direct application of
filter flags on iwlagn, duplicate the code into
both 3945 and agn and remove committing the
RXON that broke things from the 3945 version.

Cc: stable@kernel.org [2.6.35]
Reported-by: NAlex Romosan <romosan@sycorax.lbl.gov>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For 5000 and 6000g2b series of devices, use long monitor timer to check
stuck tx queues.

.6000g2b series device, it is WiFi/BT combo device, there are some cases,
tx queues are not move for a period of time because the WiFi/BT coex.

.5000 series device, it is being reported firmware got reload more
often than necessary, so extend the timer to avoid un-necessary reload.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Change the name for monitor timer, also adding define for long monitor
timer; long monitor timer can be used for the type of devices require longer
time to determine the uCode is stuck on tx and needed reload.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Currently the driver will try to protect all frames,
which leads to a lot of odd things like sending an
RTS with a zeroed RA before multicast frames, which
is clearly bogus.

In order to fix all of this, we need to take a step
back and see what we need to achieve:
 * we need RTS/CTS protection if requested by
   the AP for the BSS, mac80211 tells us this
 * in that case, CTS-to-self should only be
   enabled when mac80211 tells us
 * additionally, as a hardware workaround, on
   some devices we have to protect aggregated
   frames with RTS

To achieve the first two items, set up the RXON
accordingly and set the protection required flag
in the transmit command when mac80211 requests
protection for the frame.

To achieve the last item, set the rate-control
RTS-requested flag for all stations that we have
aggregation sessions with, and set the protection
required flag when sending aggregated frames (on
those devices where this is required).

Since otherwise bugs can occur, do not allow the
user to override the RTS-for-aggregation setting
from sysfs any more.

Finally, also clean up the way all these flags get
set in the driver and move everything into the
device-specific functions.

Cc: stable@kernel.org [2.6.35]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

spin_is_locked() can return zero on some (UP?)
configurations because locks don't exist, and
that causes an endless amount of warnings. Use
lockdep_assert_held() instead, which has two
advantages:
 1) it verifies the current task is holding
    the lock or mutex
 2) it compiles away completely when lockdep
    is not enabled

Cc: stable@kernel.org [2.6.34+, maybe only parts of patch]
Reported-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TX tracing code copies with the wrong length,
which will typically copy too little data. Fix
this by using the correct length variable.

Cc: stable@kernel.org [2.6.32+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

82ca9341 added scary looking
but harmless error messages.  Make them clearer and make the
actual failure message show up with the same severity as the
harmless one.
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

small typo fix in ucode_bt_stats_read debugfs file
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is a uCode bug which cause the tx queue id not match scd_flow
in compressed block ack frame, and it need to be addressed in uCode.
Currently, driver will log the information when it happen.

Since it is possible happen very often and we do not want to fill the syslog,
so don't enable the logging by default.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When iwlwifi is compiled w/o debug, we get
this warning:
iwl-agn.c: In function ‘iwlagn_load_firmware’:
iwl-agn.c:2014: warning: passing argument 3 of ‘iwl_print_hex_dump’ discards qualifiers from pointer target type
iwl-debug.h:73: note: expected ‘void *’ but argument is of type ‘const u8 *’

because the const qualifier is missing in the
inline stub. Fix this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit f84b29ec
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 18 02:29:13 2010 -0700

    iwlwifi: queue user-initiated scan when doing internal scan

introduced a potential deadlock because it calls
ieee80211_scan_completed() with the priv->mutex
held, but mac80211 may call back into iwlwifi
which would lead to recursive locking. Move this
out from under the mutex.

Cc: stable@kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix possible double priv->mutex lock introduced by commit
a69b03e9
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&priv->scan_check) with
priv->mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.

We do not need to synchronize when canceling priv->scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Standardize the logging macros used.
Signed-off-by: NJoe Perches <joe@perches.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>

"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>

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: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn 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: NWey-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: NWey-Yi Guy <wey-yi.w.guy@intel.com>

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

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

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we stop the Tx DMA channels, we poll bits 16:31 in
FH_TSSR_RX_STATUS_REG. From 4965 and up, only the bits 16:26 are legal.
Bits 27:31 are not used and are always unset.
Polling them will lead to fail on timeout but since the timeout is quite
small, the stall was not felt.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Intel Wireless WiFi Next Gen AGN support two major categories:
 1. Intel Wireless WiFi 4965 AGN device
 2. Intel Wireless-N/Advanced-N/Ultimate-N family
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

ucode errors were redefined in new ucode images and all new errors
were showing as advanced sysasserts which was misleading. new errors
are not sequential so additional lookup table added.  errors do not
overlap so both are used to support older and newer ucode images.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

To enable 6050 series Gen 2 devices:
1) new PCI_IDs are added;
2) new EEPROM version and calibration version numbers defined;
3) new hardware REV number defined;
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For newer devices (6000g2a and 6000g2b), the sensitivity table send to
uCode require additional table entries to help sensitivity calibration.

All the additional entries has fix data for now, but do expect the value
will be change in the future when device become more stable.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Code clean up to change name from having 5000 as part of name which easy
to confuse and think it is for 5000 series devices to more
generic _agn name since it is being used by multiple _agn devices.

No functional changes.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>