The local variable 'value' comes from 'extra', a parameter of function
'prism2_ioctl_priv_prism2_param'. If a large number passed to 'value',
there would be an integer overflow in the following line:
	local->passive_scan_timer.expires = jiffies +
		local->passive_scan_interval * HZ
Signed-off-by: NWenliang Fan <fanwlexca@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/iwlwifi/mvm/led.c:106:2-3: Unneeded semicolon

 Removes unneeded semicolon.

Generated by: coccinelle/misc/semicolon.cocci

CC: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Happy new year!
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Found by klocwork analysis.
mvm could be NULL which may cause a NULL dereference
in a theoretical call flow

rs_fill_lq_cmd(mvm = NULL, ...)
rs_build_rates_table
rs_fill_rates_for_column
ucode_rate_from_rs_rate
IWL_ERR(mvm,...)

No real reason for passing NULL to rs_fill_lq_cmd so fix that.
Reported-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently, the MAC context tsf_id assignment and the master/slave
relations are determined only when a new vif is added, as part
of the MAC context resource allocation. However, at this stage, the
beacon interval is not known, and thus could not be taken into account
in the master-slave algorithm.

To fix this, recalculate the MAC context tsf_id assignment,
just before the MAC context is activated, i.e., just before
a station VMAC is configured to associated and before an AP
VMAC is started.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Change the parameters for calculating an AP TBTT to 64/36 instead of
80/20, to increase the interval between a station vif and an AP
vif TBTT events.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The access to the CSR_RESET reg should be done as a complete
DWORD and not by setting a bit. This is the right way to reset
the device.
Signed-off-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Instead of always calling ieee80211_beacon_loss() on every missed
beacons notification, call this function only if the number of
consecutive missed beacons from last rx is higher than a predefined
threshold.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the channel min-width changes, we can update the PHY ctx, even if
it has multiple references.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Reviewed-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This allows to format it at will using external tools.
Since different teams want it in different formats, dump
the raw data and everyone can play with the data the way
they want.

While at it - make this code slightly more robust by making
the required verification on the offsets / length in the
write handler.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This channel inhibition for channel 14 was wrong. Fix it.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Don't check if mvm->fw->cs is NULL since it can't be.
cs is an array member of iwl_fw, it can't be NULL.

Use memset(ptr, 0, sizeof(*ptr)); instead of
memset(ptr, 0, sizeof(struct ptr_type));
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The firmware needs to be stopped quickly (100ms) after the
RFKILL interrupt fired. Failing to do so would allow the
firmware to access the radio registers which would lead to
a hardware error.

Before this change, we would kill the firmware only when
mac80211 stops the device which can take a fair amount of
time. Take a shortcut by stopping the device right away
in the interrupt.

This is not relevant if the current firmware is INIT
firmware since that firmware can run while in RFKILL.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Calling stop_device when start_fw wasn't called would issue:
Stopping tx queues that aren't allocated...

Also allow the op_mode to call stop_device and then to
disable the Tx queues - in that case just silently ignore
the disabling on the Tx queues, since the PRPH registers
aren't reachable any more.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This is useless and introduces a dependency between rfkill
and stop_device - the op_mode can't call stop_device from
the rfkill notification since it would lead to an endless
recursion.
Next patches will need to do so.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Under very specific circumstances, the firmware might
ignore a host command. This was debugged and we ended up
seeing that the power management hardware was faulty.
In order to workaround this issue, we keep the NIC awake
as long as we have host commands in flight. This will avoid
to put the hardware into buggy condition.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In case of invalid section_id, the function returns after
it aleready allocated memory. Fixed by change the order of actions.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The AC / fifo mapping was wrong - BE packets landed in VO
FIFO. The iwl_mvm_tx_fifo enumeration isn't in the same
order as ieee80211_ac_numbers enumeration.
Since the firmware relies on fifo / ac mapping - this led
to wrong behavior. E.g. the firmware sends beacon with the
same QoS parameters as VO, and it actually took the
parameters of BK. There are probably more severe issues.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This lock was never acquired in the primary interrupt
handler, but since it was acquired along with irq_lock
which had to disable interrupts, rxq->lock had to disable
interrupts too.
Now that trans_pcie->irq_lock isn't acquired in the primary
interrupt handler, rxq->lock can let interrupt enabled.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Since we don't take this lock in the primary interrupt
handler, there is no pointin disabling the interrupt
in the critical section protected by trans_pcie->irq_lock.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Handling interrupt with no cause and printing logs doesn't
need to be ICT / non-ICT specific move this to the common
code.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This was useful when the handling was not in the same
context as the interrupt cause retrieval: we could have
several hard interrupts until the handler gets called.
Since we retrieve the interrupt cause in the handler itself,
there is no need to OR the interrupt causes.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

These functions are meant to return an interrupt cause and
not an irqreturn_t.
We still return IRQ_HANDLED if we had an error and IRQ_NONE
if our device hasn't fired any interrupt.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

mac80211 guarantees that skb->priority is set to the TID, so use it
instead of trying to parse the QoS header manually.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Dividing the beacon interval by ATH_BCBUF (8) truncates the result for
the default beacon interval of 100.
Fix the calculation by moving the division after conversion from TU to
microseconds.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make that function and ath9k_allow_beacon_config static
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_hw should not depend on any ath9k data structures like ath_softc
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is required so that we give up the last reference to the device.
Signed-off-by: NLevente Kurusa <levex@linux.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Implement set_qos_map() handler for mac80211 to enable QoS mapping
functionality.
Signed-off-by: NKyeyoon Park <kyeyoonp@qca.qualcomm.com>
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows QoS mapping from external networks to be implemented as
defined in IEEE Std 802.11-2012, 10.24.9. APs can use this to advertise
DSCP ranges and exceptions for mapping frames to a specific UP over
Wi-Fi.

The payload of the QoS Map Set element (IEEE Std 802.11-2012, 8.4.2.97)
is sent to the driver through the new NL80211_ATTR_QOS_MAP attribute to
configure the local behavior either on the AP (based on local
configuration) or on a station (based on information received from the
AP).
Signed-off-by: NKyeyoon Park <kyeyoonp@qca.qualcomm.com>
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In addition to vendor-specific commands, also support vendor-specific
events. These must be registered with cfg80211 before they can be used.
They're also advertised in nl80211 in the wiphy information so that
userspace knows can be expected. The events themselves are sent on a
new multicast group called "vendor".
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The scan code creates an iflist_mtx -> mtx locking dependency,
and a few other places, notably radar detection, were creating
the opposite dependency, causing lockdep to complain. As scan
and radar detection are mutually exclusive, the deadlock can't
really happen in practice, but it's still bad form.

A similar issue exists in the monitor mode code, but this is
only used by channel-context drivers right now and those have
to have hardware scan, so that also can't happen.

Still, fix these issues by making some of the channel context
code require the mtx to be held rather than acquiring it, thus
allowing the monitor/radar callers to keep the iflist_mtx->mtx
lock ordering.

While at it, also fix access to the local->scanning variable
in the radar code, and document that radar_detect_enabled is
now properly protected by the mtx.

All this would now introduce an ABBA deadlock between the DFS
work cancelling and local->mtx, so change the locking there a
bit to not need to use cancel_delayed_work_sync() but be able
to just use cancel_delayed_work(). The work is also safely
stopped/removed when the interface is stopped, so no extra
changes are needed.
Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The radar detection code changed a few times, and due to
the changes some iflist_mtx locking stayed in that isn't
actually necessary - remove it.

One version of the code needed it because an AP interface's
VLAN list was changed to use this, but then we moved the
list handling outside of the chanctx handling and thus the
locking was no longer needed.
Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Its address is used as an unsigned long *, so make sure
that the tim u8 array is properly aligned.

Signed-off-by: Joe Perches <joe@perches.com
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The delay that is required after issuing a RTC reset
varies for each chip. Handle this properly.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The small delay that is present between a RTC reset/clear
operation is required for the chip to settle and this is
needed for all chips, not just the AR9002 family.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>