The ROC command asks the fw stay on the channel of the given
hlid. it currently has 2 primary functions:

1. Allow tx/rx from the device role.

In order to tx/rx packets while the stations is not associated
(e.g. auth req/resp), the device role has to be used, along
with ROC on its link.

Keep the logic similiar to the one used in dummy_join. However,
since we can't scan while we ROC, we add CROC before starting
a scan, and ROC again (if needed) on scan complete.

2. Keeping the antenna for a specific link.

We ROC until the connection was completed (after EAPOLs exchange)
in order to prevent BT coex operations from taking the antenna
and failing the connection (after this stage, psm can be used).

During association, we ROC on the station role, and then CROC
the device role, thus assuring being ROC during all the connection
process.

Delete the WL1271_FLAG_JOINED flag, and use a roc bitmap
to indicate what roles are currently ROCed.

Add wl12xx_roc/croc functions in order to wrap the roc/croc
commands while taking care of the roc bitmap.

The current ROC/CROC state-machine is a bit complicated. In
the future we'll probably want to use wpa_supplicant to control
the ROC during connection.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Update the scan command to use the new fw api
(fw 6/7.3.0.0.75).
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>

define wl1271_scan_stop() to cancel an ongoing hw scan.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

During recovery work commands sent to the FW could fail and schedule
additional recovery work. Since the chip is going to be powered off,
avoid recursive recoveries.
Signed-off-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The firmware, in practice, treats the channels in three separate
blocks, one for each band (bg, a and j).  Instead of using a single
array and doing some magic with indices, split the array in 3 to make
it more readable.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Fix kernel oops when trying to use passive scheduled scans.  The
reason was that in passive scans there are no SSIDs, so there was a
NULL pointer dereference.

To solve the problem, we now check the number of SSIDs provided in the
sched_scan request and only access the list if there's one or more
(ie. passive scan is not forced).  We also force all the channels to
be passive by adding the IEEE80211_CHAN_PASSIVE_SCAN flag locally
before the checks in the wl1271_scan_get_sched_scan_channels()
function.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a different value for DFS dwell time when performing a scheduled
scan.  Previously we were using the same value as for normal passive
scans.  This adds some flexibility between these two different types
of passive scan.

For now we use 150 TUs for DFS channel dwell time.  This may need to
be fine-tuned in the future.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

DFS channels were never getting included in the scheduled scans,
because they always contain the passive flag as well and the call was
asking for DFS and active channels.

Fix this by ignoring the passive flag when collecting DFS channels.
Also, move the DFS channels in the channel list before the 5GHz active
channels (this was implemented in the FW differently than specified).
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were comparing bitwise AND results with a boolean, so when the
boolean was set to true, it was not matching as it should.

Fix this by booleanizing the bitwise AND results with !!.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The current firmware only supports scheduled scan in station mode and
when idle.  To prevent the firmware from crashing, return -EOPNOTSUPP
when sched_scan start is called in an invalid state.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

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>