wlcore: Prevent processing of work items during op_stop

The interrupt line is disabled in op_stop using disable_irq. Since
pending interrupts are synchronized, the mutex has to be released before
disabling the interrupt to avoid a deadlock with the interrupt handler.

In addition, the internal state of the driver is only set to 'off'
after the interrupt is disabled. Otherwise, if an interrupt fires after
the state is set but before the interrupt line is disabled, the
interrupt handler will not be able to acknowledge the interrupt
resulting in an interrupt storm.

The driver's operations might be called during recovery. If these
acquire the mutex after it was released by op_stop, but before the
driver's state is changed, they may queue new work items instead of just
failing. This is especially problematic in the case of scans, in which a
new scan may be scheduled after all scan requests were cancelled.

Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
wlcore: change the wait for event mechanism

wlcore needs to wait for certain events for example
for roc complete event. Usually the events are received
from the FW very fast, therefore wlcore can poll with
a short delay and if after a second the event was
not received yet poll with a long (1-5 msec) delay.

This implementation is similar to the sending of
commands to the FW.

Empirically the change reduced the wait for roc event
from ~10-40msec to 100s of usecs.

[replace udelay/msleep with usleep_range - Arik]

Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
mac80211: destroy assoc_data correctly if assoc fails

If association failed due to internal error (e.g. no
supported rates IE), we call ieee80211_destroy_assoc_data()
with assoc=true, while we actually reject the association.

This results in the BSSID not being zeroed out.

After passing assoc=false, we no longer have to call
sta_info_destroy_addr() explicitly. While on it, move
the "associated" message after the assoc_success check.

Cc: stable@vger.kernel.org [3.4+]
Signed-off-by: Eliad Peller <eliad@wizery.com>
mac80211: always set in_reconfig=false on wakeup

If the interfaces were removed just before a restart
work was started, open_count will be 0, and most of
the reconfig work will be skipped, including the
resetting of local->in_reconfig to false.

Leaving local->inconfig = true will result in
dropping any incoming packet.

Fix it by always setting local->in_reconfig = false
(even if there are no active interfaces).

Signed-off-by: Eliad Peller <eliad@wizery.com>
nl80211: accept optional netdev in send_wiphy

When a specific interface is requested in a GET_WIPHY command, propagate
the interface to the send_wiphy. This allows interface specific abilities
to be sent up.

This change requires us to optionally get the netdev when a NEED_WIPHY
flag is specified by an NL command.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
cfg80211: support unused HT-cap-per-band configuration

Allow drivers not to use the HT capabilities given per band in struct
wiphy. This can be indicated by setting ht_cap_invalid to true for the
wiphy.

In any case the band will contain a boolean value indicating if HT is
supported.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
cfg80211: allow driver to implement HT capabilities per netdev

Add a callback allowing drivers to return custom HT capabilities per
interface (netdev). This callback is used when per-band HT capabilities
are marked as invalid.

Use the new callback to return per-netdev HT capabilities where
need by NL80211 commands - namely, GET_WIPHY and SET_TX_BITRATE_MASK.

Signed-off-by: Arik Nemtsov <arik@wizery.com>
mac80211: allow setting HT capabilities per vif

Add an array of HT-cap pointers per band to the vif struct. When an HT-cap
is set in the vif, use it. Otherwise resort to the per-band HT cap in the
wiphy struct.

Signed-off-by: Arik Nemtsov <arik@wizery.com>