The beacon filter table configuration ACX structure had certain elements
reversed, resulting in firmware instability in regard of the feature. Fix
the structure.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If re-configuring the SSID while ad-hoc was already enabled, the beacon
template would be properly updated, but the SSID passed in the CMD_JOIN would
not - hence filtering etc would not work properly.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

WEP key index handling was broken: the default key when using key 0 was never
specified to the FW, and if using other default than 0, it would be set on the
TX path for every single TX'd frame.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The new firmware does not allow removal of unicast keys - they will be
automatically removed on the next CMD_JOIN.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of acking RX packets read from the FW once all (of several possible)
buffered packets are retrieved, ack packets one by one as they are read. This
enables the FW to start receiving more packets from the network while the
host read operation is still ongoing.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

elp_wakeup() was missing in op_conf_tx() which caused wakeup problems in
power save. I forgot to add this part when porting the patch from wl1251.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If reverting to a random MAC address, the driver would not update it to the
NVS file, and hence the firmware frame filtering would not work properly.

So update the randomized MAC address to the NVS image.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Our NVS uploading mechanism had a bug that was causing it to pass three extra
zeros at the start of the NVS.  This may be a problem in the NVS generation
application, but for now we fix it in the driver.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to configure PLT mode almost in the same way as normal mode.  Most of
the configuration functions need to be called also when entering PLT, with
the exception of a few RX and TX configuration (which cause mac80211 warnings
if enable while runnning PLT tests).
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of always randomizing the MAC address, retrieve and configure the
MAC address from the device specific nvs file. For now, randomize an address
only if the address in the NVS is zero.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Replace the hardcoded general and radio parameter configuration in the driver
with configuration taken from the NVS file directly. Also remove the driver
dependency to the structures with the parameter data.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that necessary commands for WMM are implemented, implement queue handling
for WMM. But WMM is not enabled yet, only one queue is used.

Based on a similar patch from wl1251.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For WMM we need to configure each tid separately so modify
wl1271_acx_tid_cfg() to take the configuration from function parameters
instead.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For WMM we need to configure each queue separately so modify
wl1271_acx_ac_cfg() to take the configuration from function parameters
instead.
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds code to extract the SSID from the beacon template used for
ad-hoc. The mac80211 currently does not provide the SSID, so this is a
workaround for that, for now.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The channel changing code would a) change the BSSID to a dummy on upon
channel change, breaking connectivity, and b) not update the channel number
at all for ad-hoc, breaking adhoc.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the PSM entry function assumes successful operation, and enables
ELP, BET and beacon filtering right away. This is bad, because the PSM
entry may fail due to environmental issues, which will cause the ELP, BET and
beacon filtering to be illegally enabled (because FW remains in active state.)

Fix this by enabling ELP, BET and beacon filtering only after successful entry,
and by ensuring the firmware is in active mode after the failure.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In wireless-testing, commit 7044cc56 added struct ieee80211_hdr_3addr
to include/linux/ieee80211.h. This definition collides with one that is
in the rtl8192su driver in staging.

The conflict is resolved by changing rtl8192su
to use the definition from include/linux/ieee80211.h.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Yet another USB ID.
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

fix off by one error in the queue size check of p54_tx_qos_accounting_alloc()

Coverity CID: 13314
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

...and use it in hostap_cs and orinoco_cs.

Another PCMCIA device with Intersil Prism chipset has been reported:

Socket 0:
  product info: "Gigabyte", "GN-WLM01_P25L_ADAPTER", "ISL37300P", "Eval-RevA"
  manfid: 0x02e0, 0x1011
  function: 6 (network)

As it's the case with some other Prism based devices, the third ID
string contains a design name that should be sufficient to identify the
card as having Intersil Prism chipset and thus compatible with both
orinoco_cs and hostap_cs.

Introduce PCMCIA_DEVICE_PROD_ID3 that matches the third ID string only.

Use it in orinoco_cs and hostap_cs to match cards with the third ID
string indicating Prism chipset.  Remove corresponding entries that use
PCMCIA_DEVICE_PROD_ID123.
Reported-by: NOzzy <ozzymud@gmail.com>
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of hardcoding the lowest rate for Beacon frames, use the rate
index specified in the mac80211 TX info in AP mode.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use spin_[un]lock_bh in mwl8k_sta_notify().  The sta_notify handler is
required to be atomic, yet it can be called in process context, so make
sure one call won't preempt another.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support for rt30xx- and rt35xx-based devices is currently not functional
in rt2800pci and rt2800usb.
In order to not confuse users we shouldn't claim the PCI and USB device
ID's for these devices. However, to allow for testing it is good to still
have them available, although disabled by default.
Make support for these device configuration options that default to off.

For rt2800usb a 3rd class of devices is added, which are the unknown
devices. For these devices it is known that they are either based on
rt28xx, rt30xx or rt35xx, but it is not known on what chipset exactly.
These devices are disabled by default as well, until it can be established
on what chipset exactly they are based.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The recent rt2800 devices are no longer really identified by their PCI
ID's, but rather by the contents of their CSR0 register. Also for the
other chipsets is the contents of this CSR0 register important.
Change the chipset determination logic to be more aligned with the rt2800
model.
Preparation for the support of rt3070 / rt3090 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>

Don't set the RT chipset for a device from within the generic PCI/SOC code,
but rather from the individual drivers, so that individual drivers have
more control over what RT chipset is set.
Preparation for chip handling updates for rt2800 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>

Introduce the SoC interface type to detect SoC devices, instead of having
them mimic being PCI devices.
This allows for easier detection of SoC 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>

Signed-off-by: NShimada Hirofumi <hirofumi@flycat.org>
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc:	Michael Buesch <mb@bu3sch.de>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NHin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When WEXT_PRIV is not enabled, airo_cs has build errors.
It needs to include net/iw_handler.h and it should select
WEXT_PRIV, like the airo driver does.

drivers/net/wireless/airo.c:7655: error: unknown field 'num_private' specified in initializer
drivers/net/wireless/airo.c:7655: warning: initialization makes pointer from integer without a cast
drivers/net/wireless/airo.c:7656: error: unknown field 'num_private_args' specified in initializer
drivers/net/wireless/airo.c:7656: warning: excess elements in struct initializer
drivers/net/wireless/airo.c:7656: warning: (near initialization for 'airo_handler_def')
drivers/net/wireless/airo.c:7658: error: unknown field 'private' specified in initializer
drivers/net/wireless/airo.c:7658: warning: initialization makes integer from pointer without a cast
drivers/net/wireless/airo.c:7658: error: initializer element is not computable at load time
drivers/net/wireless/airo.c:7658: error: (near initialization for 'airo_handler_def.num_standard')
drivers/net/wireless/airo.c:7659: error: unknown field 'private_args' specified in initializer
drivers/net/wireless/airo.c:7659: warning: initialization from incompatible pointer type
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding support for setting the coverage class in some cases broke
association and data transfer, as it overwrote the initial ACK timeout
value from the initvals with a smaller value.
I don't know why the new value works in 5 GHz (matches the initval
there), but not in 2.4 GHz (initvals use 64us here), so until the
problem is fully understood, the value should be increased again.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This change monitors the tx statistics to detect the drop in throughput.
When the throughput drops, the ratio of the actual_ack_count and the expected_
ack_count also drops.  At the same time, the aggregated ba_timeout (the number
of ba timeout retries) also rises.  If the actual_ack_count/expected_ack_count
ratio is 0 and the number of ba timeout retries rises to 16, no tx packets
(tcp, udp, or ping - icmp) can be delivered.  The driver recovers from this
situation by reseting the uCode firmware.  If the actual_ack_count/expected_
ack_count ratio drops below 50% (but not 0) and the aggregated ba_timeout
retries just exceed 5 (but not 16), then the driver can reset the radio to
bring the throughput up.
Signed-off-by: NTrieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

All the queues are awake and ready to use after loading firmware,
for firmware reload case, if any queues was stopped before
reload, mac80211 will wake those queues after restart hardware, so make
sure all the flag used to keep track of the queue status are
reset correctly.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Change pci_alloc_consistent() to dma_alloc_coherent() so we can use
GFP_KERNEL flag.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

While testing the station with the NIC 1000 family, it is found that
the plcp error can easily exceed 50 value in 100mSecs.  This creates
unneccessary radio reset/tuning.  This patch raises the PLCP error
threshold of the NIC 1000 from 50 to 200 error count.
Signed-off-by: NTrieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

To ensure that card is in a sane state during probe we add a reset call.
This change was prompted by users of kdump who was not able to bring up the
wireless driver in the kdump kernel. The problem here was that the primary
kernel, which is not running at the time, left the wireless card up and
running. When the kdump kernel starts it is thus possible to immediately
receive interrupts from firmware after registering interrupt, but without
being ready to deal with interrupts from firmware yet.
Reported-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

There is a problem if an "internal short scan" is in progress when a
mac80211 requested scan arrives. If this new scan request arrives within
the "next_scan_jiffies" period then driver will immediately return success
and complete the scan. The problem here is that the scan has not been
fully initialized at this time (is_internal_short_scan is still set to true
because of the currently running scan), which results in the scan
completion never to be sent to mac80211. At this time also, evan though the
internal short scan is still running the state (is_internal_short_scan)
will be set to false, so when the internal scan does complete then mac80211
will receive a scan completion.

Fix this by checking right away if a scan is in progress when a scan
request arrives from mac80211.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Cleanup return values and removes unnecessary code.
Signed-off-by: NAbhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>