For 6050 series device, change the supported API version
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since uCode is responsible for doing DC calibration, there's no need
to let init uCode to do initial DC calibration then send results
back to driver, then driver sends the results to runtime uCode.
Driver can simply tell runtime uCode to do DC calibration.

Actually, this patch does not disable DC calib for init uCode. It just
prevent driver from saving and sending the DC calib results (from init
ucode) to runtime uCode. The driver still uses 0xffffffff in
CALIB_CFG_CMD for init ucode.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For 6050g2 devices driver needs to set a special bit to CSR register
so that uCode can do things correctly in calibration routines.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

iwlwifi driver supports multiple devices. Since some device needs
special configuration we create a new iwl_nic_ops structure which is
configurable per device. Currently there is only one function pointer
inside this structure: additional_nic_config().

The iwl_nic_ops structure is added to the top level in struct iwl_ops,
making it easier to change per device. Duplication of the iwl_lib_ops
structure is no longer needed.

With this new ops the previous function pointer set_calib_version is
no longer needed since it is just a per device nic configuration.

As part of the code restructuring, a bug is addressed. Indication of
calib version to uCode is only needed for 6050 devices, however,
current implementation set calib version for all 6000 devices for
which DC calib is needed. To fix this, create iwl6050_ops for 6050
devices and only populate iwl_nic_ops in this structure.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

add new structures and defines need to identify 100 devices.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

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>

For config bt command, initialize both tx_prio_boost and
rx_prio_boost to "0".
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Adding two new parameters in config bt API. these two parameters
use the 3 reserved bytes, so there is no structure size changes.

Make sure set both parameters to "zero" in order to preserve
previous behavior.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For failure tx status 0x90 and 0x91, give the correct name to reflect
the errors.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

remove duplicate header and clean up format so it is defined once
making changes consolicated ensuring consistancy of output.
no function change to date displayed.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Addition to standard tx frame failure report, adding aggregated
frame failure report to debugfs
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When uCode completed the aggregated frames transmission attempt,
it will send tx command response with aggregated frame status.

Keep track of the failure counter which help indicate any transmission
error condition.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For aggregated frames with block ack, different status flag
will be used as part of tx command response.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Tx command response sent to host by uCode after completed
the transmission attempt. The status parameter indicates
whether the transmission was successful, or else why if failed.

Here we keep the counters to help understand the different failure
cases.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If uCode fail to transmit frame, it will send reply tx back
to driver with failure status; keep the counters of each failure
cases for debugging.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Include bt_status_read function pointer for 5150 device
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.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>

drivers/net/wireless/iwlwifi/iwl-scan.c:386:27: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:386:27:     int enum nl80211_band  versus
drivers/net/wireless/iwlwifi/iwl-scan.c:386:27:     int enum ieee80211_band
drivers/net/wireless/iwlwifi/iwl-scan.c:435:57: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:435:57:     int enum ieee80211_band  versus
drivers/net/wireless/iwlwifi/iwl-scan.c:435:57:     int enum nl80211_band
drivers/net/wireless/iwlwifi/iwl-scan.c:474:53: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:474:53:     int enum ieee80211_band  versus
drivers/net/wireless/iwlwifi/iwl-scan.c:474:53:     int enum nl80211_band
drivers/net/wireless/iwlwifi/iwl-scan.c:588:72: warning: mixing different enum types
drivers/net/wireless/iwlwifi/iwl-scan.c:588:72:     int enum ieee80211_band  versus
drivers/net/wireless/iwlwifi/iwl-scan.c:588:72:     int enum nl80211_band
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Even is someone else complete scanning in mac80211, apply rxon and
tx power settings if gets scan complete notification from hardware.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Replace IWL_DEBUG_{INFO,HC,RC} to IWL_DEBUG_SCAN in iwl-scan.c file. Add
some more IWL_DEBUG_SCAN messages. This will allow to fully debug
scanning using only IWL_DL_SCAN flag.

Also start one message sentence with capital letter, since that
convention in iwl-scan.c file.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove redundant checks and use iwl_is_ready_rf().
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently we force scan complete at the end of iwl_scan_cancel_timeout
function. This cause race condition when we can get a new scan request
from mac80211 and complete it by iwl_bg_complete from older scan. Change
code to force scan complete only when really needed: device goes down,
interface is removed or scan timeout occurs.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Assure we complete scan in mac80211 when we abort scanning (scan_abort
work) or scan timeout occurs (scan_check work). Currently
iwl_scan_cancel_timeout() procedure force scan finish in mac80211
at the end of timeout loop, so we can use it in proper work functions.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we do not get notification from hardware about scan complete, after
timeout do mac80211 scan completion anyway. This assure we end scan
in case of firmware hung.

Patch fix one of the causes of wdev_cleanup_work warning reported at
https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Assure (partially) we call ieee80211_scan_completed() only once when
scan was requested from mac80211.

Code path that first clear STATUS_SCANNING bit is responsible to call
ieee80211_scan_completed(). Before the call, we check if mac80211
really request the scan.

Still persist some cases when we behave wrong, that will be addressed
in the next patches.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since on timeout version of iwl_scan_cancel procedure we can sleep,
do not have to schedule abort_scan work to begin and perform scanning,
can do this directly. Also now, as we do not queue abort_scan from
restart work anymore, we can queue abort_scan to priv->workqueue.

Don't drop mutex when waiting for scan complete. Use STATUS_HW_SCAN bit
to check if scanning is currently pending, because STATUS_SCANNING will
be cleared only with priv->mutex taken.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we are not able to send abort command to firmware, notify mac80211
that we complete scan, as we will newer do it lately. Check for all
possible errors that low level sending command procedure does not check,
to assure we catch all failures cases.

Patch fix one of the causes of wdev_cleanup_work warning reported at
https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Always cancel scan when stooping device and scan is currently pending,
we should newer have scan running after down device.

To assure we start scan cancel from restart work we have to schedule
abort_scan to different workqueue than priv->workqueue.

Patch fix not cancel scanning when restarting firmware, what is
one of the causes of wdev_cleanup_work warning (together with permanent
network connection lost) reported at
https://bugzilla.redhat.com/show_bug.cgi?id=593566Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move the scan completed flags handling so that we
can notify mac80211 about aborted scans with the
correct status. Also queue the scan_completed work
before the BT status update so that it won't see
the bits still set (unless a new scan was started
in which case that's fine.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rather than duplicating all the checks and even
in case of errors accepting the scan request
from mac80211, we can push the checks to the
caller and in all error cases reject the scan
request right away (rather than accepting and
then saying it was aborted).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are a number of conf variables that are
unused, remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move the duplicated code into single static function.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Clear the "start calib" flag only for new association,
The flag will be set in post_associate function to trigger
the runtime calibration. Set this flag to "0" will stop the
runtime sensitivity calibration
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The iwl_adjust_beacon_interval function is a bit
of black magic, so add comments to it describing
what it does. Also, in the case when there's no
beacon interval set, program the default into
the device (instead of adjusting, which results
in the max) since using the max in that case
interacts badly with dual-mode/PAN parameters.

Also update the PAN parameters accordingly and
use the same constant as here.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

In dual-mode, a number of scenarios need to be
considered, and the firmware can be very picky
about them. Adjust the timing (most importantly
the beacon interval) according to the different
modes.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When the PAN context is unused, there's no
need to continually update it in the device.
So track which contexts are active (with the
special case that the WLAN context is always
active ...) and only send their commands to
the device when needed.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Even driver use rts/cts protection mode for aggregation packets by default.
Allow the protection mode to be configure through debugfs
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When the beacon interval needs to be changed,
all we need to do is send updated timing to
the device.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When only the PAN side was active, we gave no
time to the WLAN context, which is OK unless
we are scanning, which always happens on the
WLAN context. Fix this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When sysassert happen, uCode will report the error code,
driver dump the information to dmesg. Here also remember
the last error code for future reference.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>