There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways. Cleared the
confusion and added some documentation.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add RT3390 specific register initializations to rt2x00, based on the latest
Ralink rt3390 vendor driver.

Untested as I don't actually own an RT3390 based device, but given experiences
on rt3070/rt3071 very hopeful that this will actually work..
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add RT3090 specific register initializations to rt2x00, based on the latest
Ralink rt3090 vendor driver.

Untested as I don't actually own an RT3090 based device, but given experiences
on rt3070/rt3071 very hopeful that this will actually work..
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add RT3071 specific register initializations to rt2x00, based on the latest
Ralink rt3070 vendor driver.

With this patch my RT3071 based devices start showing a sign of life.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00 had preliminary support for RT3070 based devices, but the support was
incomplete.
Update the RT3070 register initialization to be similar to the latest Ralink
vendor driver.

With this patch my rt3070 based devices start showing a sign of life.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Align the rt2800 register initializations with the latest versions of the
Ralink vendor driver.
This patch is also preparation for the addition of support for RT3070 /
RT3071 / RT3090 / RT3390 based devices.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The rt2800 version constants are inconsistent, and the version number don't
mean a lot of things anyway. Refactor the constants to have some more
meaningful names, and introduce and use some new helpers to check these
chipset revisions. At the same time rename to revision, as they are more
revision numbers rather than version numbers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Only include definitions for RT chipsets that are also used inside the
Ralink vendor drivers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Definitions taken from the latest rt2860 / rt2870 / rt3070 / rt3090 Ralink
vendor drivers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It seems that the distinction between RF channel switch method is solely based
on the RF chipset that is used.
Refactor the channel switch decision to just take the RF chipset into account,
thereby greatly simplifying the check.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes an old problem, which - under certain
circumstances - could cause the device to become
unresponsive.

most of p54pci's rx-ring management is implemented in just
two distinct standalone functions. p54p_check_rx_ring takes
care of processing incoming data, while p54p_refill_rx_ring
tries to replenish all depleted communication buffers.

This has always worked fine on my fast machine, but
now I know there is a hidden race...

The most likely candidate here is ring_control->device_idx.
Quintin Pitts had already analyzed the culprit and posted
a patch back in Oct 2009. But sadly, no one's picked up on this.
( https://patchwork.kernel.org/patch/53079/ [2 & 3] ).
This patch does the same way, except that it also prioritize
rx data processing, simply because tx routines *can* wait.
Reported-by: NSean Young <sean@mess.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=11386Reported-by: NQuintin Pitts <geek4linux@gmail.com>
Signed-off-by: NQuintin Pitts <geek4linux@gmail.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We used to free all the Tx queues memory when interface is brought
down and reallocate them again in interface up. This requires
order-4 allocation for txq->cmd[]. In situations like s2ram, this
usually leads to allocation failure in the memory subsystem. The
patch fixed this problem by allocating the Tx queues memory only at
the first time. Later iwl_down/iwl_up only initialize but don't
free and reallocate them. The memory is freed at the device removal
time. BTW, we have already done this for the Rx queue.

This fixed bug https://bugzilla.kernel.org/show_bug.cgi?id=15551Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Check return code on iwl_send_cmd_pdu() to get rid of compiler warning.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Fixes:
CC [M]  drivers/net/wireless/iwlwifi/iwl-agn-rs.o
drivers/net/wireless/iwlwifi/iwl-agn-rs.c: In function ‘rs_get_rate’:
drivers/net/wireless/iwlwifi/iwl-agn-rs.c:2419: warning: unused variable ‘priv’
CC [M]  drivers/net/wireless/iwlwifi/iwl-sta.o
drivers/net/wireless/iwlwifi/iwl-sta.c: In function ‘iwl_send_add_sta’:
drivers/net/wireless/iwlwifi/iwl-sta.c:197: warning: unused variable ‘sta_id’

drivers/net/wireless/iwlwifi/iwl-3945.c: In function ‘iwl3945_rx_reply_rx’:
drivers/net/wireless/iwlwifi/iwl-3945.c:601: warning: unused variable ‘rx_stats_noise_diff’
drivers/net/wireless/iwlwifi/iwl-3945.c:600: warning: unused variable ‘rx_stats_sig_avg’
drivers/net/wireless/iwlwifi/iwl-3945-rs.c: In function ‘rs_get_rate’:
drivers/net/wireless/iwlwifi/iwl-3945-rs.c:650: warning: unused variable ‘priv’
Reported-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

REPLY_TX_LINK_QUALITY_CMD was used by 4965, 5000 series and up
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Update to include additional tx command response status for "_agn"
devices.

The following status indicate the transmission was postponed:
  TX_STATUS_POSTPONE_DELAY
  TX_STATUS_POSTPONE_FEW_BYTES
  TX_STATUS_POSTPONE_BT_PRIO
  TX_STATUS_POSTPONE_QUIET_PERIOD
  TX_STATUS_POSTPONE_CALC_TTAK
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

When sys assert happen, driver will dump the error table information
provided by uCode. There are more information available but is not being
display by the driver; adding program counter and last host command the
to log to help uCode debugging.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

The last_phy_res[100] variable is used in an odd
way. The first byte of it is used as a flag, and
the rest as the data. Thus, the array need only
be 61 bytes, since it is just the flag and a
struct iwl_rx_phy_res (which is 60 bytes).

Clean this up by splitting the variable into two:
last_phy_res and last_phy_res_valid, using correct
types for both (struct and bool). While doing all
this also move the variables to the _agn part of
the hw-specific union since they only apply to
A-MPDUs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

lq->sta_id cannot be invalid here since this
function will only be called after the station
has been added properly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Simplify the WEP group key check by checking the
sta pointer instead of the sta_id we calculate
with it; also clean up the comment formatting.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Default WEP keys and regular keys are not allocated
from the same space in the firmware, so we shouldn't
use the same bits to indicate in use.

For default WEP keys, however, mac80211 won't allow
using the same key index twice, so the check is not
necessary at all -- add/remove are perfectly nested
due to those checks.

Other keys are allocated in the device in a global
array that only has a certain number of slots, so
for that we need to keep the allocation bitmap; but
the 802.11 key index isn't relevant there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

The firmware clears default WEP keys on
transitions to !associated, so we need
to restore them just like stations. This
is rather implicit as part of sending a
station right now, which is odd. Make it
explicit instead and only for agn since
3945 doesn't use hw crypto for WEP.

Due to that, iwl_send_static_wepkey_cmd
is now only used in iwl-sta.c and can be
static.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Size of event log is determined by uCode which is different per NICs.
Set the maximum event log size per device to better match uCode
configuration.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

This patch will add support for connection quality monitoring by configuring
rssi triggers to the firmware, and enabling the firmware rssi trigger
functionality.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allow the wl1271 go to ELP mode also in idle. This will reduce current
consumption remarkably in idle mode (~12mA -> ~0.2mA)
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 sends RTS threshold configuration request even if the wl1271 interface
state is WL1271_STATE_OFF. This leads to failures during pm tests.

This patch leaves the configuration function, if the interface is
going down.
Signed-off-by: NSaravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 sends configuration requests even if the wl1271 interface
state is WL1271_STATE_OFF. This creates warnings from mac80211.

This patch leaves the configuration functions, if the interface is
going down.
Signed-off-by: NSaravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes some memory leaks occurring during driver init/de-init.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Resolution of a merge conflict upstream accidentally removed a hunk of
"ath5k: IQ calibration for AR5211 is slightly different", so restore it.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For 4965, need to check it is valid qos frame before free, only valid
QoS frame has the tid used to free the packets.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Simple pre-scan and scan complete callbacks, this at least shows
to me that mac80211 will issue two scans at the same time on the
same wiphy.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We check the bounds on pdadc once when correcting for
negative curves but not when we later copy values from
from the pdadc_tmp array, leading to a potential overrun.

Although we shouldn't hit this case in practice, let's
be consistent.
Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As pointed out by Benoit Papillault, there is a potential
race condition between the host and the hardware in reading
the next link in the transmit descriptor list:

cpu0              hw
                  tx for buf completed
                  raise tx_ok interrupt
process buf
buf->ds_link = 0
                  read buf->ds_link

This change checks txdp before processing a descriptor
(if there are any subsequent descriptors) to see if
hardware moved on.  We'll then process this descriptor on
the next tasklet.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Review spotted a couple of strange invocations to
ieee80211_wake_queues that could potentially cause problems:

 - queues are awakened in the calibration tasklet before
   phy calibration, and then again after calibration

 - queues are awakened inside reset when we're trying to
   drain the ath5k transmit queues, and again after
   reset is completed (in callers to ath5k_reset_wake).

In both cases the first wake is unnecessary, so remove it.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These channels aren't selectable anyway, but our calculations
for 2.5 mhz frequencies are incorrect.  The value is supposed to
be:

  (frequency - reference) * (10/25)

i.e., divide by 2.5, but we were instead doing:

  (10 * frequency - reference) / 25.

Additionally, the check for (frequency % 5 == 2) had an extra
subtraction that wasn't in madwifi HAL.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2872 needs the same rf register setup as rt3070 and rt3090, hence
use rt2800_config_channel_rt3x instead of rt2800_config_channel_rt2x.
This change allows me to actually switch channels and hence scan all
configured channels on the RT305x SoC platform (which uses a rt2872)
here.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Tested-by: NLuis Correia <luis.f.correia@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't modify ah->iniModes, it's supposed to be constant.  Instead, apply
the fixup when the data is written to the registers.

Change ath9k_hw_init_eeprom_fix() to only determine whether the fixup is
needed.

This allows similteneous support for AR9220 cards that need AR_AN_TOP2
fixup (such as Ubiquiti SR71-12) and those that don't need it (D-Link
DWA-552 rev A2).
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Messages that are generated by the HTC layer
don't have any TX callback endpoints assigned to them.
Consequently, the allocated SKBs are never freed.

Fix this issue by handling this case in the HTC layer
itself.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

hif_usb_regout_cb() frees the given URB, which is
borked by design. Use an anchor to simplify URB
management.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The maximum number of packets in a single buffer in
stream mode is 10. The driver currently uses 8 - which
caused stack corruption, in the absence of any kind
of OOB checking.

Fixing this to the correct value of 10 fixes the module
unload issue.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Tested-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>