"cfg80211: validate channel settings across interfaces"
contained a locking bug -- in the managed-mode SIWFREQ
call it would end up running into a lock recursion.

This fixes it by not checking that particular interface
for a channel that it needs to stay on, which is as it
should be as that's the interface we're setting the
channel for.
Reported-by: NReinette Chatre <reinette.chatre@intel.com>
Reported-by: NKalle Valo <kalle.valo@iki.fi>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Tested-by: NKalle Valo <kalle.valo@iki.fi>
Tested-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Depending on required latency requested by pm_qos (via mac80211)
we can automatically adjust the sleep state. Also, mac80211 has
a user-visible dynamic sleep feature where we are supposed to
stay awake after sending/receiving frames to better receive
response frames to our packets, this can be integrated into the
sleep command.

Currently, and this patch doesn't change that yet, we default
to using sleep level 1 if PS is enabled. With a module parameter
to iwlcore, automatic adjustment to changing network latency
requirements can be enabled -- this isn't yet the default due
to requiring more testing.

The goal is to enable automatic adjustment and then go into the
deepest possible sleep state possible depending on the networking
latency requirements.

This patch does, however, enable IEEE80211_HW_SUPPORTS_DYNAMIC_PS
to avoid the double-timer (one in software and one in the device)
when transmitting -- the exact timeout may be ignored but that is
not of big concern.

Note also that we keep the hard-coded power indices around for
thermal throttling -- the specification of that calls for using
the specified power levels. Those can also be selected in debugfs
to allow easier testing of such parameters.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Do not send CT KILL config command twice and correct critical
temperature informatiom in dmesg
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When compiling without CONFIG_IWLWIFI_DEBUGFS there is a missing
iwl_update_stats symbol. This is fixed by making this function an inline in
the case when CONFIG_IWLWIFI_DEBUGFS is not set due to the hot path in
which it is used.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some of the thermal throttle data structures and code
are really very intermingled with the sleep (power)
control code. They really do belong together in a way
since the thermal throttle code uses powersaving to
achieve its goal, but it's making it hard to work on
the powersave code. Split this up to make that easier.
I've also changed the antenna defines to an enum and
used the same enum for RX and TX.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Modify the power update function, when driver fail to set the power, it
should not continue move forward and try to change the rx chain
configuration.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For legacy thermal throttling, set the new Thermal Throttling
state and change power index when thermal throttling manager detects
temperature changed. The current implementation sets the state to the
previous Thermal Throttling state, which causes system to enter wrong
power index. The worse case, it will trying to set the
lower power index when device reach critical temperature, it will cuase
issue for both system and the device.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move all the thermal throttling functions to background task to make
sure do not change power and rx chain in interrupt handler.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit "iwlwifi: uCode Alive notification with timeout" introduced a more
reliable mechanism for ucode loading. Unfortunately we hit a problem with
it frequently enough to make a 4965 unusable. The problem can be seen in
debug log below. What this code attempts is to set runtime ucode up to
load, start a timer to wait for the alive response from runtime ucode, and
if it times out it tries again. As can be seen below we receive the alive
response and wake the waiting task _before_ the tasks starts waiting. The
task thus times out as the alive response is not received while it is
waiting for it and it restarts the device. This starts the cycle all over
again.

[29739.000819] ieee80211 phy0: U iwl_mac_start enter
[29739.005751] ieee80211 phy0: U iwl_prepare_card_hw iwl_prepare_card_hw enter
[29739.012798] ieee80211 phy0: U iwl_set_hw_ready hardware ready
[29739.057200] ieee80211 phy0: U iwl4965_load_bsm Begin load bsm
[29739.063366] ieee80211 phy0: U iwl4965_verify_bsm Begin verify bsm
[29739.072485] ieee80211 phy0: U iwl4965_verify_bsm BSM bootstrap uCode image OK
[29739.079671] ieee80211 phy0: U iwl4965_load_bsm BSM write complete, poll 0 iterations
[29739.257019] ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x9
[29739.260964] ieee80211 phy0: I iwl_rx_reply_alive Initialization Alive received.
[29739.260964] ieee80211 phy0: U __iwl_up iwlagn is coming up
[29739.278571] ieee80211 phy0: U iwl_mac_start Start UP work done.
[29739.284509] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 788
[29739.292432] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 10312
[29739.302004] ieee80211 phy0: U iwl_verify_ucode Initialize uCode is good in inst SRAM
[29739.309746] ieee80211 phy0: U iwl4965_hw_get_temperature Running temperature calibration
[29739.317833] ieee80211 phy0: U iwl4965_hw_get_temperature Calib values R[1-3]: -36 13522 -13496 R4: -2726
[29739.327337] ieee80211 phy0: U iwl4965_hw_get_temperature Calibrated temperature: 310K, 37C
[29739.335598] ieee80211 phy0: U iwl4965_init_alive_start Initialization Alive received.
[29739.343477] ieee80211 phy0: U iwl4965_set_ucode_ptrs Runtime uCode pointers are set.
[29739.351283] ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x0
[29739.355210] ieee80211 phy0: I iwl_rx_reply_alive Runtime Alive received.
[29739.366731] iwlagn 0000:03:00.0: Runtime uCode already alive? Waiting for alive anyway
[29743.284110] iwlagn 0000:03:00.0: START_ALIVE timeout after 4000ms.
[29743.290337] ieee80211 phy0: U iwl_mac_add_interface enter: type 2
[29744.364089] iwlagn 0000:03:00.0: Runtime timeout after 5000ms
[29744.370882] ieee80211 phy0: U iwl_alive_start Runtime Alive received.
[29744.377347] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 788
[29744.385287] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 10312
[29744.393397] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 94720
[29744.415835] ieee80211 phy0: U iwl_verify_ucode Runtime uCode is good in inst SRAM
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Display sensitivity and chain noise data to help understand the current
environment and RF condition.

The data is feeded by statistics notification and Beacon from uCode;
then used by sensitivity calibration and chain noise calibration to
determine how DSP should react to the environment changes
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Display statistics notification information
The information break down into
    uCode_tx_stats
    uCode_rx_stats
    uCode_general_stats
and can be found in /sys/kernel/debug/ieee80211/phy0/iwlagn/debug
directory

The statistic information display in debugFs is based on the last
statistics notification from uCode; it might not reflect the current
uCode activity. Using "watch" command to monitor the uCode
activity should give up-to-date statistics provided by uCode.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding debugfs function to show current TxFifo/RxFifo read/write
pointer, plus the current tx queue status (wake/stop) for both real and
virtual queue.
This is part of debug feature set to help debugging driver/uCode.

use tx_queue and rx_queue in
/sys/kernel/debug/ieee80211/phy0/iwlagn/debug directory to show the
current read/write pointer for both TxFifo and RxFifo queue
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Break down the traffic type and counter for both Tx and Rx.
Enhance the tx_statistics and rx_statistics debugfs function and move
to /sys/kernel/debug/ieee80211/phy0/iwlagn/debug directory to help
better debugging both driver and uCode related problems.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The traffic buffer will only beallocated and used if either bit 23
(IWL_DX_TX) or bit 24 (IWL_DL_RX) of "debug" is set;
example: "debug=0x800000" - log tx data traffic
         "debug=0x1000000" - log rx data traffic
         "debug=0x1800000" - log both tx and rx traffic

The traffic log will store the beginning portion (64 bytes)  of the
latest 256 of tx and rx packets in the round-robbin buffer for
debugging,
user can examine the log through debugfs file.

How to display the current logged tx/rx traffic and txfifo and rxfifo
read/write point:
"cat traffic_log" in /sys/kernel/debug/ieee80211/phy0/iwlagn/debug
directory

By echo "0" to traffic_log file will empty the traffic log buffer and
reset both tx and rx taffic log index to 0.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rename "fat" to "ht40"
The term "fat channel" is deprecated in favor of "HT40"
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit "iwlwifi: make debug level more user friendly" cleaned up the
debug level handling. In doing so it created a single global debug
level for all devices. Some setups do consits of more that one iwlwifi
device and in these setups there is a requirement that debug levels
should be unique per device.

We now re-introduce the per device debugging while maintaining the
cleanup effort of the previous patch.

The maintain the global debug level and now introduce a per-device debug
level that will be used if it (the per-device debug level) is set. The
per-device debug level can be controlled via the debug_level sysfs file
while the global debug level is controlled by the debug module parameter.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Acked-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Added file patterns drivers/net/wireless and net/mac80211
(and net/rfkill -- JWL)
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch implements a basic rfkill support for p54 hardware and
removes a rfkill related WARNING:

fwio.c: In function ‘p54_setup_mac’:
fwio.c:323: warning: ‘radio_enabled’ is deprecated.

by abandoning radio_enable in flavour for IEEE80211_CONF_CHANGE_IDLE.
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a coding error which allowed the to upper-layer to
corrupt limited portions of the phy data.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes the hardware encryption keys index and array size handling.

Thanks to Gregor Kowski for reporting this issue.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The memory layout for scan requests was rather wrong,
we put the scan SSIDs before the channels which could
lead to the channel pointers being unaligned in memory.
It turns out that using a pointer to the channel array
isn't necessary anyway since we can embed a zero-length
array into the struct.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we have a lot of frames to transmit at once, for
instance with fragmentation, it can be an optimisation
to only tell the DMA engine about them on the last
fragment/frame to avoid banging the IO too much. This
patch allows implementation such an optimisation by
telling the driver when more frames can be expected.

Currently, this is used by mac80211 only on fragmented
frames, but could also be used in the future on other
frames when the queue was full and there are multiple
frames pending.

Note that drivers need to be careful when using this
flag, they need to kick their DMA engines not just
when this flag is clear, but also when the queue gets
full so that progress can be made.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This documents what's required to implement that TX powersave
filter properly wrt. handling hardware queues.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add some more documentation including an example so that
it's clearer what should be done for TX retries.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In order for userspace to be able to figure out whether
it obtained a consistent snapshot of data or not when
using netlink dumps, we need to have a generation number
in each dump message that indicates whether the list has
changed or not -- its value is arbitrary.

This patch adds such a number to all dumps, this needs
some mac80211 involvement to keep track of a generation
number to start with when adding/removing mesh paths or
stations.

The wiphy and netdev lists can be fully handled within
cfg80211, of course, but generation numbers need to be
stored there as well.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With the move of everything related to the SME from
mac80211 to cfg80211, we lost the ability to send
reassociation frames. This adds them back, but only
for wireless extensions. With the userspace SME, it
shall control assoc vs. reassoc (it already can do
so with the nl80211 interface).

I haven't touched the connect() implementation, so
it is not possible to reassociate with the nl80211
connect primitive. I think that should be done with
the NL80211_CMD_ROAM command, but we'll have to see
how that can be handled in the future, especially
with fullmac chips.

This patch addresses only the immediate regression
we had in mac80211, which previously sent reassoc.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently, there's a problem that affects regulatory
enforcement and connection stability, in that it is
possible to switch the channel while connected to a
network or joined to an IBSS.

The problem comes from the fact that we only validate
the channel against the current interface's type, not
against any other interface. Thus, you have any type
of interface up, additionally bring up a monitor mode
interface and switch the channel on the monitor. This
will obviously also switch the channel on the other
interface.

The problem now is that if you do that while sending
beacons for IBSS mode, you can switch to a disabled
channel or a channel that doesn't allow beaconing.
Combined with a managed mode interface connected to
an AP instead of an IBSS interface, you can easily
break the connection that way.

To fix this, this patch validates any channel change
with all available interfaces, and disallows such
changes on secondary interfaces if another interface
is connected to an AP or joined to an IBSS.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit 9cef8737 "mac80211: fix managed mode BSSID handling" broke
association in wl1251, most probably because the driver configured
the bssid filter incorrectly. Workaround this by disabling filter
altogether. This needs to be fixed properly soon.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The logs currently don't show when hw scan has completed, fix that.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Luciano is maintaining wl1271 part.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that wl1271 doesn't use reg.h anymore, it can be renamed to
wl1251_reg.h.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl1251 should use workqueue created by mac80211 to not block the events
workqueue too long.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It should not be hidden inside wl1251_cmd_ps_mode().
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is a bug in wl1251_op_config(). It was calling join with previous
channel. Fix it by setting assigning wl->channel before calling join command.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Better to use wl1251_cmd_join() only for sending the command and move
the logic to wl1251_join().
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Because join channel tunes to a channel, better to make it more obvious
by adding a parameter for it.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Because wl->channel was initialised to one, the first join command in
wl1251_op_config() always failed.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should wait everytime for the join command to finish, not waiting for
it might create problems.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl1251 was using hardcoded beacon intervals and dtim periods, use the ones
provided by mac80211 instead.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It's more common to have beacon interval before dtim period. Also use
bool instead of u8.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NVidhya Govindan <vidhya.govindan@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>