New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.

As not every firmware generates radiotap header this commit introduces
BRCMF_FEAT_MONITOR_FMT_RADIOTAP flag. It has to be has based on firmware
capabilities. If not present brcmf_netif_mon_rx() will assume packet is
a raw 802.11 frame and will prepend it with an empty radiotap header.

This new code is limited to the msgbuf protocol at this point. Adding
support for SDIO/USB devices will require some extra work (possibly a
new firmware release).
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Depending on used build-time options some firmwares may already include
radiotap header in passed monitor frames. Add a new feature flag to
store info about it. It's needed for proper handling of received frames
before passing them up.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Many/most of firmwares support creating monitor interface but only the
most recent ones explicitly /announce/ it using a "monitor" entry in the
list of capabilities.

Check for that entry and store internally info about monitor mode
support using a new feature flag. Once we sort out all details of
handling monitor interface it will be used when reporting available
interfaces to the cfg80211.

Later some fallback detecion method may be added for older firmwares.
For now just stick to the "monitor" capability which should be 100%
reliable.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When switching between low gain (high RSSI) and high gain settings, it
can take a few seconds to adjust to the current environment.
This can lead to short periods of time with extreme packet loss.

When switching from low_gain=1 to low_gain=2, start with the same gain
adjustment value instead of the lowest to avoid spikes of huge numbers
of false CCA events

Also avoid resetting adjustment values on switching between low_gain
values 0 and 1, since it affects only the upper limit of vga adjustment
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This preserves more sensitivity when weak stations are active and avoids
counting signal measurements from other unrelated networks
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Useful for debugging gain adjustment issues triggered by signal strength
changes.
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The range should only be limited to 4 for really weak signals, for all
other gain settings the range is 16.
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

They will be read on the next calibration step without gain change and
must not count earlier events
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Use values based on the vendor driver
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The lowest bit should be set to 0 only for strong links, not for weak
ones.
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The gain should be reduced only for very strong connections, not for mid
range.
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The beacon timer drifts by 1 microsecond every TBTT. After 20 minutes
with a beacon interval of 100, the drift will be almost 12 ms, enough to
cause weird issues for devices in powersave mode.

Since the beacon timer is configured in units of 1/16 TU (64 us), we
need to adjust it once every 64 beacons and only for one beacon.
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

I am removing the
	BUG_ON(!in_interrupt());

check because it serves no purpose. Running the completion callback in
BH context makes in_interrupt() still return true but the interrupts
could be enabled. The important part is that ->driver_lock is acquired
with disabled interrupts which is the case now.

Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

I am removing the
	BUG_ON(!in_interrupt());

check because it serves no purpose. Running the completion callback in
BH context makes in_interrupt() still return true but the interrupts
could be enabled. The important part is that ->driver_lock is acquired
with disabled interrupts which is the case now.

Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The ipw2x00 driver family uses get_seconds() to read the current time
for various purposes. This function is deprecated because of the 32-bit
time_t overflow, and it can cause unexpected behavior when the time
changes due to settimeofday() calls or leap second updates.

In many cases, we want to use monotonic time instead, however ipw2x00
explicitly tracks the time spent in suspend, so this changes the
driver over to use ktime_get_boottime_seconds(), which is slightly
slower, but not used in a fastpath here.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NStanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The get_seconds() function is deprecated because of the y2038 overflow.
In zd1211rw we don't even care about the absolute value, so this is
not a problem, but it's equally trivial to change to the non-deprecated
ktime_get_seconds().
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The BIT macro uses unsigned long which some architectures handle as 32 bit
and therefore might cause macro's shift to overflow when used on a value
equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards).

Since 'filled' member in station_info changed to u64, BIT_ULL macro
should be used with all NL80211_STA_INFO_* attribute types instead of BIT
to prevent future possible bugs when one will use BIT macro for higher
attributes by mistake.

This commit cleans up all usages of BIT macro with the above field
in wireless-drivers by changing it to BIT_ULL instead. In addition, there are
some places which don't use BIT nor BIT_ULL macros so align those as well.
Signed-off-by: NOmer Efrat <omer.efrat@tandemg.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This is a static checker fix, not something I have tested.  The issue
is that on the second iteration through the loop, we jump forward by
le32_to_cpu(auth_req->length) bytes.  The problem is that if the length
is more than "buflen" then we end up with a negative "buflen".  A
negative buflen is type promoted to a high positive value and the loop
continues but it's accessing beyond the end of the buffer.

I believe the "auth_req->length" comes from the firmware and if the
firmware is malicious or buggy, you're already toasted so the impact of
this bug is probably not very severe.

Fixes: 030645ac ("rndis_wlan: handle 802.11 indications from device")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

use existing memdup_user() helper function instead of open-coding
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Fix mcs and attempt count estimation in mt76x2_mac_fill_tx_status routine
if the number of tx retries reported by the hw is grater than
IEEE80211_TX_MAX_RATES

Fixes: 7bc04215 ("mt76: add driver code for MT76x2e")
Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Remove extra parentheses and replace NULL comparison with !priv, to fix
clang warning of extraneous parentheses and check patch issue. Following
coccinelle script is used to fix it.

@disable is_null,paren@
expression e;
statement s;
@@
if (
- (e==NULL)
+!e
 )
s
Signed-off-by: NVarsha Rao <rvarsha016@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Do not chock ethernet header for uap bridge data path,
as it is still needed to send skb to dest station.
Signed-off-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Add tests for the bitfield helpers. The constant ones will all
be folded to nothing by the compiler (if everything is correct
in the header file), and the variable ones do some tests against
open-coding the necessary shifts.

A few test cases that should fail/warn compilation are provided
under ifdef.
Suggested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

There's no reason why we shouldn't pack/unpack bits into/from
u8 values/registers/etc., so add u8 helpers.

Use the ____MAKE_OP() macro directly to avoid having nonsense
le8_encode_bits() and similar functions.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

There's a bug in *_encode_bits() in using ~field_multiplier() for
the check whether or not the constant value fits into the field,
this is wrong and clearly ~field_mask() was intended. This was
triggering for me for both constant and non-constant values.

Additionally, make this case actually into an compile error.
Declaring the extern function that will never exist with just a
warning is pointless as then later we'll just get a link error.

While at it, also fix the indentation in those lines I'm touching.

Finally, as suggested by Andy Shevchenko, add some tests and for
that introduce also u8 helpers. The tests don't compile without
the fix, showing that it's necessary.

Fixes: 00b0c9b8 ("Add primitives for manipulating bitfields both in host- and fixed-endian.")
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The function wlc_phy_workarounds_nphy_rev1 is local to the source and
does not need to be in global scope, so make it static.

Cleans up sparse warning:
symbol 'wlc_phy_workarounds_nphy_rev1' was not declared. Should it
be static?
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The last value in the log_table wraps around to a negative value
since s16 has a value range of -32768 to 32767. This is not what
the table intends to represent. Use the closest positive value
32767.

This fixes a warning seen with clang:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:216:2: warning:
      implicit conversion from 'int' to 's16' (aka 'short') changes
value from 32768
      to -32768 [-Wconstant-conversion]
        32768
        ^~~~~
1 warning generated.

Fixes: 4c0bfeaa ("brcmsmac: fix array out-of-bounds access in qm_log10")
Cc: Tobias Regnery <tobias.regnery@gmail.com>
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch fixes the clang warning of extraneous parentheses, with the
following coccinelle script.

@@
identifier i;
expression e;
statement s;
@@
if (
-(i == e)
+i == e
 )
s
Suggested-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: NVarsha Rao <rvarsha016@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Enable support for source MAC address randomization of probe request
frames. Pass addr/mask randomization parameters to firmware.
Signed-off-by: NAndrey Shevchenko <ashevchenko@quantenna.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Implement net_device_ops::ndo_set_mac_address callback to allow for
setting interface MAC address. Implementation is done through existing
CHANGE_INTF firmware command. All validation is to be done by firmware.
Signed-off-by: NIgor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

With runtime PM tested working for wlcore with no autosuspend, we can
now enable autosuspend to cut down on enable/disable for interrupts.
Basically we just replace pm_runtime_put() with the autosuspend variants.

Let's use autosuspend delay of 50ms that MMC drivers typically use.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We have wl12xx_boot() call wl12xx_enable_interrupts() and if we have
wl1271_op_add_interface() call pm_runtime_get_sync() before the interrupts
are enabled. And then we get the following error during boot:

wlcore: ERROR ELP wakeup timeout!

Let's fix this by first checking if we need to boot the firmware. And
only after that call pm_runtime_get_sync() when interrupts are enabled.
And only after that do the check for wl12xx_need_fw_change().
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

With runtime PM enabled, we can now use calls to pm_runtime_force_suspend
and pm_runtime_force_resume for enabling elp during suspend when wowlan
is enabled and waking the chip from elp on resume.

Remove the custom API that was used to ensure that the command
that is used to allow ELP during suspend is completed before the system
suspend.
Signed-off-by: NEyal Reizer <eyalr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

After enabling runtime PM, if we force hardware reset multiple times with:

# echo 1 > /sys/kernel/debug/ieee80211/phy0/wlcore/start_recovery

We will after few tries get the following error:

wlcore: ERROR timeout waiting for the hardware to complete initialization

And then wlcore is unable to reconnect until after the wlcore related modules
are reloaded.

Let's fix this by moving pm_runtime_put() earlier before we restart the hardware.
And let's use the sync version to make sure we're done before we restart.

Note that we still will get -EBUSY warning from wl12xx_sdio_set_power() but let's
fix that separately once we know exactly why we get the warning.
Reported-by: NEyal Reizer <eyalr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

With runtime PM enabled, we now need to have wlcore enabled longer
until after we're done calling wlcore_cmd_regdomain_config_locked():

scan_complete_work()
 wlcore_cmd_regdomain_config_locked()
   wlcore_cmd_send_failsafe()
     wl12xx_sdio_raw_read()

Note that this is not needed before runtime PM support as the
custom PM code had it's own timer. We have not yet enabled runtime
PM autosuspend for wlcore and this is why this issue now shows up.

Let's fix the issues first before we enable runtime PM autosuspend.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We can update wlcore to use PM runtime by adding functions for
wlcore_runtime_suspend() and wlcore_runtime_resume() and replacing
calls to wl1271_ps_elp_wakeup() and wl1271_ps_elp_sleep() with calls
to pm_runtime_get_sync() and pm_runtime_put().

Note that the new wlcore_runtime_suspend() and wlcore_runtime_resume()
functions are based on simplified versions of wl1271_ps_elp_sleep() and
wl1271_ps_elp_wakeup().

We don't want to use the old functions as we can now take advantage of
the runtime PM usage count. And we don't need the old elp_work at all.
And we can also remove WL1271_FLAG_ELP_REQUESTED that is no longer needed.

Pretty much the only place where we are not just converting the existing
functions is wl1271_op_suspend() where we add pm_runtime_put_noidle()
to keep the calls paired.

As the next step is to implement runtime PM autosuspend, let's not add
wrapper functions for the generic runtime PM calls. We would be getting
rid of any wrapper functions anyways.

After autoidle we should be able to start using Linux generic wakeirqs
for the padconf interrupt.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Otherwise we can get:

WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84

I've only seen this few times with the runtime PM patches enabled
so this one is probably not needed before that. This seems to
work currently based on the current PM implementation timer. Let's
apply this separately though in case others are hitting this issue.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

ath.git patches for 4.19. Major changes:

ath10k

* support channel 173

* fix spectral scan for QCA9984 and QCA9888 chipsets

ath6kl

* add support for Dell Wireless 1537