Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use ENDPOINT_MAX instead of HST_ENDPOINT_MAX.
This fixes a stack corruption issue.

This is based on a patch sent by Dan Carpenter <error27@gmail.com>.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ready message from the target could be processed
before the host HW init has completed. In this case,
htc_process_target_rdy() would assume the target has timed
out, when it hasn't. Fix this by checking if the target
has sent the ready message properly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The HTC state has to be setup before initializing
the target because the ready message could possibly
come before the control endpoints in HTC have been
identified.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The URBs have to be allocated before uploading
the firmware to the target. This is needed to process
the target ready message properly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since ->sta_notify() can sleep, protect
the callback with a mutex.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Check the mode in channel switch ie for either 0 or 1 on transmission.
A channel switch mode set to 1 means that the STA in a BSS to which the
frame containing the element is addressed shall transmit no further
frames 	within the BSS until the scheduled channel switch.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds support for offloading the channel switch
operation to devices that support such, typically
by having specific firmware API for it. The reasons
for this could be that the firmware provides better
timing or that regulatory enforcement done by the
device requires special handling of CSAs.

In order to allow drivers to specify the timing to
the device, the new channel_switch callback will
pass through the received frame's mactime, where
available.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't send them for further processing.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These changes include:

  * For PAPRD, the TXRF3.capdiv5G, TXRF3.rdiv5G and TXRF3.rdiv2G
    are set to 0x0, the TXRF6.capdiv2G is set to 0x2 for all
    three chains.
  * The d2cas5G/d3cas5G/d4cas5G was updated to 4/4/4 in lowest_ob_db
    Tx gain table.
  * To improve DPPM, three parameters were updated (Released from Madhan):
	1. RANGE_OSDAC is set to 0x1 for 2G, 0x0 for 5G
	2. offsetC1 is set to 0xc
	3. inv_clk320_adc is set to 0x1
  * To reduce PHY error(from spur), cycpwr_thr1 and cycpwr_thr1_ext
    are increased to 0x8 at 2G.
  * The 2G Rx gain tables are updated with mixer gain setting 3,1,0.

The new checksums yield:

initvals -f ar9003
0x00000000c2bfa7d5        ar9300_2p0_radio_postamble
0x00000000ada2b114        ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84        ar9300Modes_fast_clock_2p0
0x00000000056eaf74        ar9300_2p0_radio_core
0x0000000000000000        ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5        ar9300_2p0_mac_postamble
0x0000000023235333        ar9300_2p0_soc_postamble
0x0000000054d41904        ar9200_merlin_2p0_radio_core
0x00000000748572cf        ar9300_2p0_baseband_postamble
0x000000009aa5a0a4        ar9300_2p0_baseband_core
0x000000003df9a326        ar9300Modes_high_power_tx_gain_table_2p0
0x000000001cfba124        ar9300Modes_high_ob_db_tx_gain_table_2p0
0x0000000011302700        ar9300Common_rx_gain_table_2p0
0x00000000e3eab114        ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40        ar9300_2p0_mac_core
0x000000001e1d0800        ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980        ar9300_2p0_soc_preamble
0x00000000292e2544        ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544        ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544        ar9300PciePhy_clkreq_disable_L1_2p0

Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.

Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.

This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.

Cc: stable@kernel.org
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The goto and the break are equivelent.  I removed the goto in memory of
Edsger Dijkstra who famously hated gotos and who would have been eighty
years old next Tuesday.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The "(wl == NULL)" test doesn't work here because "wl" is always
non-null.  The intent of the code is to return if the interface
was not supported by the driver.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should start the loop consistently with the "wl_lock" lock held.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During a hw restart, mac80211 will attempt to
reconfigure all stations. Currently, that fails
and leads to warnings because we still have the
stations marked active. Therefore, clear all
stations when doing down.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Remove the check before invoking iwl_set_ht_add_station(),
since neither of the conditions in this check makes sense,
as either we pass in a NULL ht_info (first branch) or in
the IBSS case an ht_info with ht_enabled=false.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

This function is now only used for the special
IBSS BSSID station, so rename it to indicate
this. The new name is iwl_add_bssid_station.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

4965 code is the only thing that now still
needs iwl_find_station(), so move it there
and make it static. Everything else can
rely on the station data passed by mac80211.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

With the station ID being stored in the
station struct, which mac80211 gives us
for TKIP phase 1 key updates, we can also
remove the use of iwl_find_station() in
that code path.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

With the station ID being stored in the
station struct, which mac80211 gives us
for aggregation callbacks, we can also
remove the use of iwl_find_station() in
those code paths.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Since we now store the station ID in each station
struct, many places need not look at the station
table any more since they can just pull the station
ID out of the struct. Remove iwl_get_sta_id() and
use iwl_sta_id() instead as appropriate.

This reduces the amount of code needed to find the
right station significantly, and works since
mac80211 passes the station only after it has been
fully initialised, ie. even if TX races with
station addition it will only be passed to TX once
the addition is complete.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

In places where the station struct is
guaranteed to exist (presumably), use
this helper to get the station ID out
of it (and warn if there's no station
struct after all).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

mac80211 allows us to store private data per
station, so put the station ID there. This
allows us to avoid the station ID lookup when
removing regular stations. To also be able to
avoid the lookup to remove the special IBSS
BSSID station, track its ID in the per-vif
private data.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Provide comments for newly added cfg parameters
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Move "tx power per chain" into ucode_tx_stats, it is debugging
information provided by uCode as part of statistics notification.

The "tx power per chain" parameters are optional parameters which only
supported by 6000 series device today; those are reserved fields for all
the other devices.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

When station is using an HT channel to communicate to AP and communication
is lost then driver will first be notified that channel is not an HT
channel anymore before AP station is removed. A consequence of that is that
the driver will know that it is not communicating on HT anymore, but the
rate scaling table is still under the impression it is operating in HT. Any
time after driver has been notified channel is not HT anymore there will
thus be a firmware SYSASSERT when the current active LQ command is sent.

A workaround for this issue is to not send a LQ command in the short time between
being notified channel is not HT anymore and rate scaling table being
updated.

This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2173Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Currently, the broadcast station is managed along
with the interface type, rather than always being
present. That leads to a bug with injection -- it
is currently not possible to inject frames when
the only virtual interface is a monitor, because
in that the required broadcast station is missing.

Additionally, allocating and deallocating the
broadcast station's LQ all the time is wasteful,
and the code to support this is fairly complex.

So this changes completely the way we manage the
broadcast station. Rather than manage it along
with any interface, we now allocate it when we
bring the device up, and remove it again when we
bring the device down. When we bring the device
up, we don't immediately program the broadcast
station into it, instead we just mark it active
and rely on the next restore cycle to upload it
to the device. This works because an unassociated
RXON is always required at least once to set up
device parameters, which implies a reprogramming
of stations into the device.

As we now manage all stations properly, there no
longer is a need for forcing a clearing of them
via iwl_clear_ucode_stations(), which can become
a lot simpler.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Rename iwl_sta_init_lq to iwl_sta_alloc_lq and
move sending it out into the caller.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

The "is_ap" argument to iwl_sta_init_lq is never true,
so it and the corresponding code can be removed. However,
it needs to have the station ID because it is also used
for the IBSS BSSID station, and that doesn't have the
broadcast ID.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

The bssid member of struct iwl_priv is now
only used by 3945 code, so note that. It
shouldn't be used by any other code in the
future.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Pass the virtual interface pointer to iwl_ht_conf()
so it doesn't need to rely on iw_mode and other
global variables.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

This check is not useful, since we now no
longer dereference priv->vif at this spot.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Most of the TX aggregation handling can be passed
the virtual interface directly instead of having
to rely on priv->vif.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Rather than keeping every bit of information
around in priv and the virtual interface, add
a virtual interface to many functions and use
the information directly from it.

This removes beacon_int, assoc_capability and
assoc_id from struct iwl_priv.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Since iwl_configure_filter can now sleep since
the mac80211 callback was changed, we can now
apply filter flags changes directly.

Also, while at it, make the code a bit more
generic with a local macro. There's no need
to check changed_flags since we apply all at
the same time anyway.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

We need not check iw_mode, since we have
the vif pointer available.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

This function is only needed by 4965, so
it need not be in core code and can be
made static.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

We never use that member of struct iwl_priv.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>