Move wl12xx and wl1251 modules into a new drivers/net/wireless/ti
directory.  Add a TI WLAN Kconfig option and Makefile to support this
change.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Cc: John W. Linville <linville@tuxdriver.com>

A special PLT firmware is used for calibration.

Add multiple fw support by introducing a new fw_type member,
representing the currently saved fw (the actual fw state
can be determined by wl->state).
Signed-off-by: NGery Kahn <geryk@ti.com>
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

We should not get an hlid value bigger than WL12XX_MAX_LINKS from
wl1271_rx_handle_data().  We have a WARN_ON in case it happens.  But
despite the warning, we would still go ahead and write the hlid bit
into active_hlids (a stack variable).  This would cause us to
overwrite other data in the stack.

To avoid this problem, we now skip the write when issuing the warning,
so at least we don't corrupt data.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Separate the debugging macros and other definitions to a new debug.h
file.  This is be needed because the sdio and spi modules don't need
to depend on the wl12xx module anymore, but still need to include
wl12xx.h.  Currently they do depend on it, because of the debugging
global that wl12xx exports.  A future patch will remove this
dependency.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Currently, the rx streaming doesn't support multi-vif
(the actual wlvif is taken from wl->vif, and the management
is global).

Make the rx streaming timers/works per-vif, and pass the
the actual vif as param.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

move bss_type into the per-interface data, rather than
being global.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The driver now support HT properly, so we can always have HT enabled.

Remove the WL12XX_HT configuration.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Make it easier to match the driver log against
a sniffer log.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Update the fw status struct according to the new fw api
(fw >= 6/7.0.0.35).
All the roles use the same struct now.

The memory accounting was changed a bit according to
the struct changes.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The new fw doesn't support rx_filtering configuration (as a
stand-alone command. the rx filtering is done automatically
according to the active role).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

In case of QoS packets the packet payload isn't aligned to
4 bytes. In that case the mac80211 layer take care of that
via memmove() in ieee80211_deliver_skb().
Add support of copy packets from aggregation buffer to the
skbs with packet payload aligned care. In case of QoS packets
copy the packets in offset of 2 bytes guarantee payload aligned
to 4 bytes.
Signed-off-by: NShahar Levi <shahar_levi@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

A recently added feature to the firmware enables the driver to retrieve
firmware logs via the host bus (SDIO or SPI).

There are two modes of operation:
1. On-demand: The FW collects its log in an internal ring buffer. This
   buffer can later be read, for example, upon recovery.
2. Continuous: The FW pushes the FW logs as special packets in the RX
   path.

Reading the internal ring buffer does not involve the FW. Thus, as long
as the HW is not in ELP, it should be possible to read the logs, even if
the FW crashes.

A sysfs binary file named "fwlog" was added to support this feature,
letting a monitor process read the FW messages. The log is transferred
from the FW only when available, so the reading process might block.
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

When resuming (after wowlan), we want the rx packets (which is
usually the wake-up packet itself) to be passed to mac80211 only
after the resume notifier was completed, and mac80211 is up and
running (otherwise, the packets will be dropped).

By enqueueing the netstack_work to a freezable workqueue, we can
guarantee the rx processing to occur only after mac80211 was resumed.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

When rx_streaming.interval is non-zero, use automatic rx streaming.
Enable rx streaming on the each rx/tx packet, and disable it
rx_streaming.duration msecs later.

When rx_streaming.always=0 (default), rx streaming is enabled only
when there is a coex operation.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

When packets arrive with a RX descriptor indicating corruption, discard
them.

In general white-list the RX descriptor status to prevent rouge data
from being sent up.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

When debugging, reduce the padding size from each rx packet, to
get the actual packet size (so comparing it against a cap file
will be easier)
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The rx-status passed to mac80211 along with each received frame contains the
band on which the frame was received. Under certain circumstances, this band
information may be incorrect, causing in worst case a WARNING from mac80211,
and causes the received frame to be dropped.

This scenario mainly occurs when performing connected-mode scans, when the
received scan results are from the other band than the one currently
associated to.

[Since desc_band doesn't exist anymore, use status->band in the later
call to ieee80211_channel_to_frequency() to fix compilation -- Luca]
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Reduced bus transactions in the Tx & Rx path.

[Removed unnecessary check wl->chip.id != CHIP_ID_1283_PG20 when
checking the quirk -- Luca]
Signed-off-by: NShahar Levi <shahar_levi@ti.com>
Reviewed-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

To achieve maximal throughput, it is very important to react to
interrupts as soon as possible. Currently the interrupt handler wakes up
a worker for handling interrupts in process context. A cleaner and more
efficient design would be to request a threaded interrupt handler.  This
handler's priority is very high, and can do blocking operations such as
SDIO/SPI transactions.

Some work can be deferred, mostly calls to mac80211 APIs
(ieee80211_rx_ni and ieee80211_tx_status). By deferring such work to a
different worker, we can keep the irq handler thread more I/O
responsive. In addition, on multi-core systems the two threads can be
scheduled on different cores, which will improve overall performance.

The use of WL1271_FLAG_IRQ_PENDING & WL1271_FLAG_IRQ_RUNNING was
changed. For simplicity, always query the FW for more pending
interrupts. Since there are relatively long bursts of interrupts, the
extra FW status read overhead is negligible. In addition, this enables
registering the IRQ handler with the ONESHOT option.
Signed-off-by: NIdo Yariv <ido@wizery.com>
Reviewed-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

On newer hardware revisions, there is no need to write the host's
counter at the end of a RX transaction. The same applies to writing the
number of packets at the end of a TX transaction.

It is generally a good idea to avoid unnecessary SDIO/SPI transfers.
Throughput and CPU usage are improved when avoiding these.

Send the host's RX counter and the TX packet count only if needed, based
on the hardware revision.

[Changed WL12XX_QUIRK_END_OF_TRANSACTION to use BIT(0) -- Luca]
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Reviewed-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

for debugging purposes, wl12xx determines whether a rx packet
is a beacon packet.

however, it checks only the frame_control subtype without checking
the actual packet type, which leads to false identification in some
cases.

use ieee80211_is_beacon instead.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

This patch adds support for the new wl12xx firmware (Rev 6.1.3.50.49)

Since this fw is not backward compatible with previous fw versions,
a new fw (with different name) is being fetched.

(the patch is big because it contains all the required fw api changes.
splitting it into multiple patches will result in corrupted intermediate
commits)
Signed-off-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Set filters according to the mode of operation.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Reviewed-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Note that wl1271_write32() calls cpu_to_le32() by itself, so calling
wl1271_write32(addr, cpu_to_le32(val)) is in fact a bug on BE systems.

Fix the following sparse warnings:

drivers/net/wireless/wl12xx/cmd.c:662:16: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/cmd.c:662:16:    expected unsigned short [unsigned] [addressable] [usertype] llc_type
drivers/net/wireless/wl12xx/cmd.c:662:16:    got restricted __be16 [usertype] <noident>
drivers/net/wireless/wl12xx/cmd.c:674:17: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/cmd.c:674:17:    expected unsigned int [unsigned] [addressable] [usertype] sender_ip
drivers/net/wireless/wl12xx/cmd.c:674:17:    got restricted __be32 [usertype] ip_addr
drivers/net/wireless/wl12xx/rx.c:202:4: warning: incorrect type in argument 3 (different base types)
drivers/net/wireless/wl12xx/rx.c:202:4:    expected unsigned int [unsigned] [usertype] val
drivers/net/wireless/wl12xx/rx.c:202:4:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/wl12xx/acx.c:1247:23: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/acx.c:1247:23:    expected restricted __le32 [usertype] ht_capabilites
drivers/net/wireless/wl12xx/acx.c:1247:23:    got unsigned long
drivers/net/wireless/wl12xx/acx.c:1250:24: warning: invalid assignment: |=
drivers/net/wireless/wl12xx/acx.c:1250:24:    left side has type restricted __le32
drivers/net/wireless/wl12xx/acx.c:1250:24:    right side has type unsigned long
drivers/net/wireless/wl12xx/acx.c:1253:24: warning: invalid assignment: |=
drivers/net/wireless/wl12xx/acx.c:1253:24:    left side has type restricted __le32
drivers/net/wireless/wl12xx/acx.c:1253:24:    right side has type unsigned long
drivers/net/wireless/wl12xx/acx.c:1256:24: warning: invalid assignment: |=
drivers/net/wireless/wl12xx/acx.c:1256:24:    left side has type restricted __le32
drivers/net/wireless/wl12xx/acx.c:1256:24:    right side has type unsigned long
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.

This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.

The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
Acked-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All files name prefix removed due to the fact that wl12xx driver supports
wl1271 and wl1273.
Also the definition in Kconfig and header files changed respectively.
Signed-off-by: NShahar Levi <shahar_levi@ti.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

The wl1271_rx function loops through packets in an aggregated buffer. Each
packet in the buffer is handled by a call to wl1271_rx_handle_data, which will
fail if skb memory allocation fails or production mode is enabled. These
failures currently prevent the rx counters to be incremented, thus causing the
rx loop to run forever.

Fix this by ignoring error codes reported wl1271_rx_handle_data function.
This essentially means that frames will be dropped in production mode, which
is the intetion, and frames will be dropped if memory allocation fails, which
is a decent way to recover from that situation.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Tested-by: NTuomas Katila <ext-tuomas.2.katila@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

While scanning, it is possible that beacon and probe response frames are
received on other band than configured to the driver. In rx status
handling this has caused "Unsupported RX rate from HW" warnings. This
patch changes the wl1271_rate_to_index function to take the band of the
received frame as a parameter instead of using value configuret to
wl->band.
Signed-off-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

Add 11n ability in scan, connection and using MCS rates.
The configuration is temporary due to the code incomplete and
still in testing process. That plans to be remove in the future.
Signed-off-by: NShahar Levi <shahar_levi@ti.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

Instead of retrieving one packet at a time from the firmware, try to
retrieve all available packets at once.
This optimization decreases the number of transactions, which saves
CPU cycles and increases network throughput.
Signed-off-by: NIdo Yariv <ido@wizery.com>
Tested-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

copy the rx_status directly to skb->cb (control buffer) instead of copying
it to a local struct and then copying it again (for each rx packet)
Signed-off-by: NEliad Peller <eliad@wizery.com>
Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>

Add functionality to pass the current TSF (mac time) to the mac80211. This is
needed for ad-hoc merging.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The current frame length used by the driver for RX frames is the SPI bus
transfer length. This length has padding bytes, which do not belong to the
WLAN frame.

As there is no other length information in the WLAN frame except the skb
length this problem caused for instance extra ESSID's to be listed at the
end of scan results (IE id 0) with zero length.

Fix the frame length by removing padding.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The noise element in the ieee80211_rx_status struct has been deprecated in
commit "mac80211: deprecate RX status noise".  Remove the usage of this
element from wl1271_rx.c to avoid warnings.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Clean up the code to convert a firmware rate class index into an index
for the rate configuration table.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

This patch will ack RX frames read from the firmware in one single write,
instead of acking all the frames separately. This will reduce the amount of
required communication per frame.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Most probably patch "wl1271: add most of the normal initialization commands
to PLT mode" enabled the RX path in firmware so that now driver received
frames and passed them to mac80211, which warned about them.

Workaround this by not retrieving frames from the hardware, just ignore them.
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>

Removed wl1271_spi.h header as there's no more need to access functions
declared there outside of wl1271_spi.c. Also made those SPI access
functions static.
Signed-off-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@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>