This patch adds the mac80211 operations for scheduled scan and the
scheduled scan results reporting.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Add firmware command structures, definitions and code to to configure,
start and stop scheduled scans.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

We were using an array of booleans to mark the channels we had already
scanned.  This was causing a sparse error, because bool is not a type
with defined size.  To fix this, use bitmasks instead, which is much
cleaner anyway.

Thanks Johannes Berg for the idea.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Commands are sometimes sent to FW on scan completion. Make sure the chip
is awake to receive them. Sending commands while the chip is in ELP
can cause SDIO read errors and/or crash the FW.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The probe-request template used in the hardware connection monitoring feature
thus far has been an empty one, without the SSID IE and without supported rate
IEs. This causes problems with some AP's.

Additionally, after connected scans, the template for connection maintenance
would remain to be the one last used for scanning - potentially incorrect.

Fix these by getting a pre-filled directed probe-request template for the
associated-to AP from mac80211.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.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>

In scan_complete_work, because the mutex is released before accessing the
scan->failed flag, it is possible for unfounded hardware recovery rounds
to be executed.

Fix this.
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>

Currently then dwell times for each channel in scans is set to an overly
long value, and excessive number of probe-requests are transmitted on each
channel (for active scans.)

Based on testing, comparable results can be received with smaller dwell-time,
and, with fever probe-requests - in fact, reducing the number of probe-requests
to 2 seems to increase the number of found results.

Configure more optimal values for per channel dwell times. Comparison for the
different scan configurations (in my current office environment):

dwell-time 60000   3x probe-req == ~60 results
           40000   3x probe-req == ~50 results
           30000   3x probe-req == ~40 results

dwell-time 60000   2x probe-req == ~70 results
           40000   2x probe-req == ~60 results
           30000   2x probe-req == ~58 results

The above are results for a cumulative 3 scan run. For individual scans, the
number of results drop slightly more.
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>

Currently, the driver does not handle a failing hardware command to scan in
any way - effectively, the scan machine will jam until the driver is shut down,
and future scan requests will just return -EBUSY to user space, resulting in
a type of busy-loop. The same problem occurs if the firmware fails to deliver
the scan completion event - add timeout for this.
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>

Do this so the interface removal can be triggered from an upcoming hardware
failure recovery mechanism.
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>

The current scan implementation can jam, if the scan request ends up
containing no work. This can especially happen if there is a scan request
with only 11a band channels for HW that does not support 11a.
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>

Instead of hardcoding 11a support, enable/disable driver support based on
the dual-mode-select parameter in the nvs-file general paramters.
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>

When we get no SSIDs in the scan request, we should force a passive scan in
all channels.  This patch adds code to force the passive scan flag to be set
in that case.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>

In the scan state machine, the wl1271_mutex is unlocked first then relocked,
and then the scan state variables are modified.

This makes it possible for ieee80211_scan_complete to be called twice in some
scenarios, as the scan completion event from the firmware may be processed
while the mutex is unlocked.

To fix the issue, move the ieee80211_scan_complete call last in the function.
This is generally safer, but there still may be issues is functions calling
the scan state machine rely on states checked before the unlocking of the
global mutex.

(forward ported from 2.6.32 -- this is not strictly needed anymore, because
the mutex doesn't need to be unlocked anymore, but I'm applying this change
anyway, so that the call to ieee80211_scan_complete is in the same place)
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NSaravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

With the scan callback now being callable from
any context, these unlocks/locks can go away.
This makes the code easier to understand, since
callers of these functions must no longer be
aware that the mutex may be dropped.

As Stanislaw is working on iwlwifi scanning, I
didn't change it to take advantage of the new
mac80211 semantics.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These changes may be slightly safer in some instances.

There are other kzalloc calls with a multiply, but those
calls are typically "small fixed #" * sizeof(some pointer)"
and those are not converted.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We were always using the max transmit power when scanning.  Now we use the
values passed to the driver by the mac80211 stack, so that we comply with
regulations.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NSaravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch is a complete rewrite of the scanning code.  It now includes a
state machine to scan all four possible sets of channels independently:
2.4GHz active, 2.4GHz passive, 5GHz active and 5GHz passive.  The wl1271
firmware doesn't allow these sets to be mixed, so up to several scan commands
have to be issued.  This patch also allows scanning more than 24 channels per
set, by breaking the sets into smaller parts if needed (the firmware can scan
a maximum of 24 channels at a time).

Previously, the scanning code was erroneously scanning all channels possible
actively, not complying with the CRDA values.  This is also fixed with this
patch.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NSaravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The scanning code is going to get a bit more complex, with proper support for
active/passive scans together with 2.4GHz and 5GHz.  In the future, also a
new type of scan (periodic scan) will be added.  When all this is
implemented, the code is going to be much more complex, so we'd better
separate it into a separate file.

This patch doesn't have any impact on functionality.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: NSaravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>