Ryder Lee [Thu, 17 Nov 2022 17:09:47 +0000 (01:09 +0800)]
wifi: mt76: mt7915: add support to configure spatial reuse parameter set
The SPR parameter set comprises OBSS PD threshold for SRG and
non SRG and Bitmap of BSS color and partial BSSID. This adds
support to configure fields of SPR element to firmware.
User can disable firmware SR algorithms by turning sr_scene_detect off.
YN Chen [Wed, 16 Nov 2022 14:43:02 +0000 (22:43 +0800)]
wifi: mt76: mt7921: fix wrong power after multiple SAR set
We should update CLC config before SAR set to synchronize all
related settings.
Fixes: 23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support") Signed-off-by: YN Chen <[email protected]> Signed-off-by: Deren Wu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Sean Wang [Tue, 15 Nov 2022 00:11:24 +0000 (08:11 +0800)]
wifi: mt76: mt7921: introduce chanctx support
The firmware can have the capability to manage the channel context
scheduling on multiple roles running on the device including Station,
AP and P2P GC/GO mode (will be extended based on the future patchset)
to help users sharing the network with others on a single device.
The firmware is able to support the channel chanctx up to 2 interface
simultaneously running on the different channels.
Another thing to be noted is that before the driver is going sent out the
management frames, the driver has to get the privilege from the firmware
to occupy the current channel context until the frame handshake is
completed and then get the privilege back to the firmware.
Sean Wang [Tue, 15 Nov 2022 00:11:23 +0000 (08:11 +0800)]
wifi: mt76: mt7921: introduce remain_on_channel support
Introduce remain_on_channel support. Additionally, we add
mt7921_check_offload_capability to disable .remain_on_channel and
.cancel_remain_on_channel and related configuration because those
operations would rely on the fundamental MCU commands that will be only
supported with newer firmware.
Sean Wang [Thu, 10 Nov 2022 21:23:46 +0000 (05:23 +0800)]
wifi: mt76: mt7921: drop ieee80211_[start, stop]_queues in driver
The firmware would be in charge of braking and continuing the traffic while
the channel contexts are switching between different BSS and HW SCAN in the
background.
wifi: mt76: mt7915: Fix chainmask calculation on mt7915 DBDC
mt7915 does not have a per-band number of chains unlike the other chips,
it only has a total number of chains. Yet the current code would
consider the total number as a per-band number.
For example, it would report that a 2x2 + 2x2 DBDC card have 4 chains on
each band and set chainmask to 0b1111 for the first interface and 0b11110000 for the second.
Fixes: 99ad32a4ca3a ("mt76: mt7915: add support for MT7986") Co-developed-by: Felix Fietkau <[email protected]> Signed-off-by: Nicolas Cavallari <[email protected]> Signed-off-by: Felix Fietkau <[email protected]>
Ryder Lee [Wed, 9 Nov 2022 20:36:34 +0000 (04:36 +0800)]
wifi: mt76: mt7915: enable coredump support
Host triggered and catastrophic event triggered firmware core dumping
for basic firmware issues triage, including state reporting, task/irq
info, function calltrace and MCU memory dump.
Ming Yen Hsieh [Mon, 24 Oct 2022 12:45:08 +0000 (20:45 +0800)]
wifi: mt76: fix bandwidth 80MHz link fail in 6GHz band
Due to information missing, the firmware may be fail on bandwidth
related settings in mt7921/mt7922. Add new cmd STA_REC_HE_V2 to apply
additional capabilities in 6GHz band.
Ryder Lee [Fri, 14 Oct 2022 02:57:47 +0000 (10:57 +0800)]
wifi: mt76: mt7915: improve accuracy of time_busy calculation
The MIB INFO command is fetching MIB_BUSY_TIME, MIB_TX_TIME, MIB_RX_TIME and
MIB_OBSS_AIRTIME from the radio and filling out cc_busy, cc_tx, cc_bss_rx
and cc_rx respectively.
busy should be >= tx + rx >= tx + bss_rx but we don’t always quite see this.
Sometimes tx + rx is a bit higher than busy due to inaccurate accounting,
so this patch recalculates numbers to make them more reasonable.
The reverted commit significantly decreases performance when running
a test where two MT7915 radios have 16 station vdevs each, configured
for AC mode, and transmitting UDP traffic to AP.
wifi: mt76: mt7915: add spatial extension index support
In previous, we only allow user to configure tx antenna mask
contiguously (e.g. 0x3, 0xf).
This patch allows user to configure tx antenna mask interleavingly
(e.g. 0x5, 0x8). By setting proper antenna mask and nss, user can
prioritized the signal of different antennas, which helps to test
their performance in normal mode.
Let the configuration of testmode antenna mask on both band0 and band1
become antenna_mask rather than chainmask. This could simplify the
settings for user and get rid of the conversion when sending fw command.
Peter Chiu [Fri, 30 Sep 2022 15:13:11 +0000 (23:13 +0800)]
wifi: mt76: mt7915: deal with special variant of mt7916
A variant of mt7916 supports up to 3 tx/rx paths but with only
2 spatial streams. An example usage of the 3rd path is to server as
an auxiliary for beamforming.
In order to deal with this case, this patch reworks some parts to
correctly use paths or streams.
wifi: mt76: mt7915: rework eeprom tx paths and streams init
Rework tx paths and streams init part to improve readability, and make
sure that the available tx streams should be smaller than or equal to
the available tx paths.
wifi: mt76: mt7915: reserve 8 bits for the index of rf registers
The value of regidx of rf registers is combined with WF selection and
offset. Extend the WF selection field from 4 to 8 bits since the
adie index should also be specified.
Ben Greear [Thu, 29 Sep 2022 15:15:25 +0000 (08:15 -0700)]
wifi: mt76: mt7915: fix bounds checking for tx-free-done command
According to the tx-free-done documentation, the DW4 can be repeated,
so have to be more careful about how we test for walking off the
end of the array.
Sean Wang [Fri, 16 Sep 2022 22:46:45 +0000 (06:46 +0800)]
wifi: mt76: mt7921: fix antenna signal are way off in monitor mode
Group 3 in RxD is disabled in monitor mode. We should use the group 5 in
RxD instead to fix antenna signal way off issue, e.g we would see the
incorrect antenna signal value in wireshark. On the other hand, Group 5
wouldn't be used in STA or AP mode, so the patch shouldn't cause any
harm to those modes.
- remove stbc, because mt76x0 doesn't support it and mt76x2 uses the same
values as HT/VHT
- reduce vht array to 2 elements, because VHT MCS0-7 are the same as HT
Felix Fietkau [Thu, 1 Dec 2022 13:57:30 +0000 (14:57 +0100)]
wifi: mac80211: fix and simplify unencrypted drop check for mesh
ieee80211_drop_unencrypted is called from ieee80211_rx_h_mesh_fwding and
ieee80211_frame_allowed.
Since ieee80211_rx_h_mesh_fwding can forward packets for other mesh nodes
and is called earlier, it needs to check the decryptions status and if the
packet is using the control protocol on its own, instead of deferring to
the later call from ieee80211_frame_allowed.
Because of that, ieee80211_drop_unencrypted has a mesh specific check
that skips over the mesh header in order to check the payload protocol.
This code is invalid when called from ieee80211_frame_allowed, since that
happens after the 802.11->802.3 conversion.
Fix this by moving the mesh specific check directly into
ieee80211_rx_h_mesh_fwding.
Felix Fietkau [Mon, 10 Oct 2022 09:43:38 +0000 (11:43 +0200)]
wifi: mac80211: add support for restricting netdev features per vif
This can be used to selectively disable feature flags for checksum offload,
scatter/gather or GSO by changing vif->netdev_features.
Removing features from vif->netdev_features does not affect the netdev
features themselves, but instead fixes up skbs in the tx path so that the
offloads are not needed in the driver.
Aside from making it easier to deal with vif type based hardware limitations,
this also makes it possible to optimize performance on hardware without native
GSO support by declaring GSO support in hw->netdev_features and removing it
from vif->netdev_features. This allows mac80211 to handle GSO segmentation
after the sta lookup, but before itxq enqueue, thus reducing the number of
unnecessary sta lookups, as well as some other per-packet processing.
Johannes Berg [Fri, 14 Oct 2022 16:56:11 +0000 (18:56 +0200)]
wifi: mac80211: don't parse multi-BSSID in assoc resp
It's not valid to have the multiple BSSID element in the
association response (per 802.11 REVme D1.0), so don't
try to parse it there, but only in the fallback beacon
elements if needed.
The other case that was parsing association requests was
already changed in a previous commit.
Change-Id: I659d2ef1253e079cc71c46a017044e116e31c024 Signed-off-by: Johannes Berg <[email protected]>
The call to ieee80211_do_stop() right after will also do
synchronize_rcu() to ensure the SDATA_STATE_RUNNING bit
is cleared, so we don't need to synchronize_net() here.
Change-Id: Id9f9ffcf195002013e5d9fde288877d219780864 Signed-off-by: Johannes Berg <[email protected]>
Chen Zhongjin [Wed, 9 Nov 2022 09:02:37 +0000 (17:02 +0800)]
wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() fails
In regulatory_init_db(), when it's going to return a error, reg_pdev
should be unregistered. When load_builtin_regdb_keys() fails it doesn't
do it and makes cfg80211 can't be reload with report:
JUN-KYU SHIN [Fri, 11 Nov 2022 02:33:04 +0000 (11:33 +0900)]
wifi: cfg80211: fix comparison of BSS frequencies
If the "channel->freq_offset" comparison is omitted in cmp_bss(),
BSS with different kHz units cannot be distinguished in the S1G Band.
So "freq_offset" should also be included in the comparison.
Juhee Kang [Tue, 29 Nov 2022 16:12:44 +0000 (01:12 +0900)]
r8169: use tp_to_dev instead of open code
The open code is defined as a helper function(tp_to_dev) on r8169_main.c,
which the open code is &tp->pci_dev->dev. The helper function was added
in commit 1e1205b7d3e9 ("r8169: add helper tp_to_dev"). And then later,
commit f1e911d5d0df ("r8169: add basic phylib support") added
r8169_phylink_handler function but it didn't use the helper function.
Thus, tp_to_dev() replaces the open code. This patch doesn't change logic.
Kees Cook [Wed, 30 Nov 2022 21:26:45 +0000 (13:26 -0800)]
wifi: ieee80211: Do not open-code qos address offsets
When building with -Wstringop-overflow, GCC's KASAN implementation does
not correctly perform bounds checking within some complex structures
when faced with literal offsets, and can get very confused. For example,
this warning is seen due to literal offsets into sturct ieee80211_hdr
that may or may not be large enough:
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 'iwl_mvm_rx_mpdu_mq':
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:2022:29: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2022 | *qc &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
In file included from drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h:32,
from drivers/net/wireless/intel/iwlwifi/mvm/sta.h:15,
from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:27,
from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:10:
drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/rx.h:559:16: note: at offset [78, 166] into destination object 'mpdu_len' of size 2
559 | __le16 mpdu_len;
| ^~~~~~~~
Refactor ieee80211_get_qos_ctl() to avoid using literal offsets,
requiring the creation of the actual structure that is described in the
comments. Explicitly choose the desired offset, making the code more
human-readable too. This is one of the last remaining warning to fix
before enabling -Wstringop-overflow globally.
But fixing this appears to be not so simple. The patch set represents my
attempt to address it.
In short, the problem is that dpaa2_mac_connect() and dpaa2_mac_disconnect()
call 2 phylink functions in a row, one takes rtnl_lock() itself -
phylink_create(), and one which requires rtnl_lock() to be held by the
caller - phylink_fwnode_phy_connect(). The existing approach in the
drivers is too simple. We take rtnl_lock() when calling dpaa2_mac_connect(),
which is what results in the deadlock.
Fixing just that creates another problem. The drivers make use of
rtnl_lock() for serializing with other code paths too. I think I've
found all those code paths, and established other mechanisms for
serializing with them.
====================
Vladimir Oltean [Tue, 29 Nov 2022 14:12:21 +0000 (16:12 +0200)]
net: dpaa2-mac: move rtnl_lock() only around phylink_{,dis}connect_phy()
After the introduction of a private mac_lock that serializes access to
priv->mac (and port_priv->mac in the switch), the only remaining purpose
of rtnl_lock() is to satisfy the locking requirements of
phylink_fwnode_phy_connect() and phylink_disconnect_phy().
But the functions these live in, dpaa2_mac_connect() and
dpaa2_mac_disconnect(), have contradictory locking requirements.
While phylink_fwnode_phy_connect() wants rtnl_lock() to be held,
phylink_create() wants it to not be held.
Move the rtnl_lock() from top-level (in the dpaa2-eth and dpaa2-switch
drivers) to only surround the phylink calls that require it, in the
dpaa2-mac library code.
This is possible because dpaa2_mac_connect() and dpaa2_mac_disconnect()
run unlocked, and there isn't any danger of an AB/BA deadlock between
the rtnl_mutex and other private locks.
Vladimir Oltean [Tue, 29 Nov 2022 14:12:20 +0000 (16:12 +0200)]
net: dpaa2-switch: serialize changes to priv->mac with a mutex
The dpaa2-switch driver uses a DPMAC in the same way as the dpaa2-eth
driver, so we need to duplicate the locking solution established by the
previous change to the switch driver as well.
Vladimir Oltean [Tue, 29 Nov 2022 14:12:19 +0000 (16:12 +0200)]
net: dpaa2-eth: serialize changes to priv->mac with a mutex
The dpaa2 architecture permits dynamic connections between objects on
the fsl-mc bus, specifically between a DPNI object (represented by a
struct net_device) and a DPMAC object (represented by a struct phylink).
The DPNI driver is notified when those connections are created/broken
through the dpni_irq0_handler_thread() method. To ensure that ethtool
operations, as well as netdev up/down operations serialize with the
connection/disconnection of the DPNI with a DPMAC,
dpni_irq0_handler_thread() takes the rtnl_lock() to block those other
operations from taking place.
There is code called by dpaa2_mac_connect() which wants to acquire the
rtnl_mutex once again, see phylink_create() -> phylink_register_sfp() ->
sfp_bus_add_upstream() -> rtnl_lock(). So the strategy doesn't quite
work out, even though it's fairly simple.
Create a different strategy, where all code paths in the dpaa2-eth
driver access priv->mac only while they are holding priv->mac_lock.
The phylink instance is not created or connected to the PHY under the
priv->mac_lock, but only assigned to priv->mac then. This will eliminate
the reliance on the rtnl_mutex.
Add lockdep annotations and put comments where holding the lock is not
necessary, and priv->mac can be dereferenced freely.
Vladimir Oltean [Tue, 29 Nov 2022 14:12:18 +0000 (16:12 +0200)]
net: dpaa2-eth: connect to MAC before requesting the "endpoint changed" IRQ
dpaa2_eth_connect_mac() is called both from dpaa2_eth_probe() and from
dpni_irq0_handler_thread().
It could happen that the DPNI gets connected to a DPMAC on the fsl-mc
bus exactly during probe, as soon as the "endpoint change" interrupt is
requested in dpaa2_eth_setup_irqs(). This will cause the
dpni_irq0_handler_thread() to register a phylink instance for that DPMAC.
Then, the probing function will also try to register a phylink instance
for the same DPMAC, operation which should fail (and this will fail the
probing of the driver).
Reorder dpaa2_eth_setup_irqs() and dpaa2_eth_connect_mac(), such that
dpni_irq0_handler_thread() never races with the DPMAC-related portion of
the probing path.
Also reorder dpaa2_eth_disconnect_mac() to be in the mirror position of
dpaa2_eth_connect_mac() in the teardown path.
Vladimir Oltean [Tue, 29 Nov 2022 14:12:16 +0000 (16:12 +0200)]
net: dpaa2: publish MAC stringset to ethtool -S even if MAC is missing
DPNIs and DPSW objects can connect and disconnect at runtime from DPMAC
objects on the same fsl-mc bus. The DPMAC object also holds "ethtool -S"
unstructured counters. Those counters are only shown for the entity
owning the netdev (DPNI, DPSW) if it's connected to a DPMAC.
The ethtool stringset code path is split into multiple callbacks, but
currently, connecting and disconnecting the DPMAC takes the rtnl_lock().
This blocks the entire ethtool code path from running, see
ethnl_default_doit() -> rtnl_lock() -> ops->prepare_data() ->
strset_prepare_data().
This is going to be a problem if we are going to no longer require
rtnl_lock() when connecting/disconnecting the DPMAC, because the DPMAC
could appear between ops->get_sset_count() and ops->get_strings().
If it appears out of the blue, we will provide a stringset into an array
that was dimensioned thinking the DPMAC wouldn't be there => array
accessed out of bounds.
There isn't really a good way to work around that, and I don't want to
put too much pressure on the ethtool framework by playing locking games.
Just make the DPMAC counters be always available. They'll be zeroes if
the DPNI or DPSW isn't connected to a DPMAC.
Vladimir Oltean [Tue, 29 Nov 2022 14:12:15 +0000 (16:12 +0200)]
net: dpaa2-switch: assign port_priv->mac after dpaa2_mac_connect() call
The dpaa2-switch has the exact same locking requirements when connected
to a DPMAC, so it needs port_priv->mac to always point either to NULL,
or to a DPMAC with a fully initialized phylink instance.
Make the same preparatory change in the dpaa2-switch driver as in the
dpaa2-eth one.
Vladimir Oltean [Tue, 29 Nov 2022 14:12:14 +0000 (16:12 +0200)]
net: dpaa2-eth: assign priv->mac after dpaa2_mac_connect() call
There are 2 requirements for correct code:
- Any time the driver accesses the priv->mac pointer at runtime, it
either holds NULL to indicate a DPNI-DPNI connection (or unconnected
DPNI), or a struct dpaa2_mac whose phylink instance was fully
initialized (created and connected to the PHY). No changes are made to
priv->mac while it is being used. Currently, rtnl_lock() watches over
the call to dpaa2_eth_connect_mac(), so it serves the purpose of
serializing this with all readers of priv->mac.
- dpaa2_mac_connect() should run unlocked, because inside it are 2
phylink calls with incompatible locking requirements: phylink_create()
requires that the rtnl_mutex isn't held, and phylink_fwnode_phy_connect()
requires that the rtnl_mutex is held. The only way to solve those
contradictory requirements is to let dpaa2_mac_connect() take
rtnl_lock() when it needs to.
To solve both requirements, we need to identify the writer side of the
priv->mac pointer, which can be wrapped in a mutex private to the driver
in a future patch. The dpaa2_mac_connect() cannot be part of the writer
side critical section, because of an AB/BA deadlock with rtnl_lock().
So the strategy needs to be that where we prepare the DPMAC by calling
dpaa2_mac_connect(), and only make priv->mac point to it once it's fully
prepared. This ensures that the writer side critical section has the
absolute minimum surface it can.
The reverse strategy is adopted in the dpaa2_eth_disconnect_mac() code
path. This makes sure that priv->mac is NULL when we start tearing down
the DPMAC that we disconnected from, and concurrent code will simply not
see it.
No locking changes in this patch (concurrent code is still blocked by
the rtnl_mutex).
Vladimir Oltean [Tue, 29 Nov 2022 14:12:12 +0000 (16:12 +0200)]
net: dpaa2-mac: absorb phylink_start() call into dpaa2_mac_start()
The phylink handling is intended to be hidden inside the dpaa2_mac
object. Move the phylink_start() call into dpaa2_mac_start(), and
phylink_stop() into dpaa2_mac_stop().
Vladimir Oltean [Tue, 29 Nov 2022 14:12:11 +0000 (16:12 +0200)]
net: dpaa2: replace dpaa2_mac_is_type_fixed() with dpaa2_mac_is_type_phy()
dpaa2_mac_is_type_fixed() is a header with no implementation and no
callers, which is referenced from the documentation though. It can be
deleted.
On the other hand, it would be useful to reuse the code between
dpaa2_eth_is_type_phy() and dpaa2_switch_port_is_type_phy(). That common
code should be called dpaa2_mac_is_type_phy(), so let's create that.
The removal and the addition are merged into the same patch because,
in fact, is_type_phy() is the logical opposite of is_type_fixed().
Vladimir Oltean [Tue, 29 Nov 2022 14:12:10 +0000 (16:12 +0200)]
net: dpaa2-eth: don't use -ENOTSUPP error code
dpaa2_eth_setup_dpni() is called from the probe path and
dpaa2_eth_set_link_ksettings() is propagated to user space.
include/linux/errno.h says that ENOTSUPP is "Defined for the NFSv3
protocol". Conventional wisdom has it to not use it in networking
drivers. Replace it with -EOPNOTSUPP.
Dan Carpenter [Tue, 29 Nov 2022 09:43:47 +0000 (12:43 +0300)]
net: microchip: sparx5: Fix error handling in vcap_show_admin()
If vcap_dup_rule() fails that leads to an error pointer dereference
side the call to vcap_free_rule(). Also it only returns an error if the
very last call to vcap_read_rule() fails and it returns success for
other errors.
I've changed it to just stop printing after the first error and return
an error code.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:30 +0000 (16:31 +0800)]
wifi: rtw89: link rtw89_vif and chanctx stuffs
First, introduce struct rtw89_sub_entity for chanctx related stuffs.
Second, add enum rtw89_sub_entity_idx to rtw89_vif for vif operation
to access its/right chanctx stuffs after future multi-channel support.
Besides, RTW89_SUB_ENTITY_0 is the default chanctx entry throughout
driver, i.e. it's used for things which may not have a target chanctx
yet. So, we need to ensure that RTW89_SUB_ENTITY_0 is always working.
If there is at least one alive chanctx, then one of them must take
RTW89_SUB_ENTITY_0. If no alive chanctx, RTW89_SUB_ENTITY_0 will be
filled by rtw89_config_default_chandef().
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:29 +0000 (16:31 +0800)]
wifi: rtw89: fw: implement MCC related H2C
These MCC H2C(s) require to wait for MCC C2H to determine if the
execution is successful. Through rtw89_wait_for_cond(), we make
them wait for either a completion with data from MCC C2H handlers,
which calls rtw89_complete_cond(), or timeout.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:28 +0000 (16:31 +0800)]
wifi: rtw89: mac: process MCC related C2H
Process C2H(s) related to MCC (multi-channel concurrency). These handling,
which either call rtw89_complete_cond() or show message in debug mode, can
be considered atomic/lock-free. So, they should be safe to be processed
directly after C2H pre-check in previous patch.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:27 +0000 (16:31 +0800)]
wifi: rtw89: introduce helpers to wait/complete on condition
MCC (multi-channel concurrency) related H2Cs (host to chip commands)
require to wait for C2H (chip to host events) responses to judge the
execution result and data. We introduce helpers to assist this process.
Besides, we would like the helpers to be generic for use in driver even
outside of MCC H2C/C2H, so we make a independent patch for them.
In the following, I describe the things first.
```
(A) C2H is generated by FW, and then transferred upto driver. Hence,
driver cannot get it immediately without a bit waitting/blocking.
For this, we choose to use wait_for_completion_*() instead of
busy polling.
(B) From the driver management perspective, a scenario, e.g. MCC,
may have mulitple kind of H2C functions requiring this process
to wait for corresponding C2Hs. But, the driver management flow
uses mutex to protect each behavior. So, one scenario triggers
one H2C function at one time. To avoid rampant instances of
struct completion for each H2C function, we choose to use one
struct completion with one condition flag for one scenario.
(C) C2Hs, which H2Cs will be waitting for, cannot be ordered with
driver management flow, i.e. cannot enqueue work to the same
ordered workqueue and cannot lock by the same mutex, to prevent
H2C side from getting no C2H responses. So, those C2Hs are parsed
in interrupt context directly as done in previous commit.
(D) Following (C), the above underline H2Cs and C2Hs will be handled
in different contexts without sync. So, we use atomic_cmpxchg()
to compare and change the condition in atomic.
```
So, we introduce struct rtw89_wait_info which combines struct completion
and atomic_t. Then, the below are the descriptions for helper functions.
* rtw89_wait_for_cond() to wait for a completion based on a condition.
* rtw89_complete_cond() to complete a given condition and carry data.
Each rtw89_wait_info instance independently determines the meaning of
its waitting conditions. But, RTW89_WAIT_COND_IDLE (UINT_MAX) is reserved.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:26 +0000 (16:31 +0800)]
wifi: rtw89: check if atomic before queuing c2h
Before queuing C2H work, we check atomicity of the C2H's handler first now.
If atomic or lock-free, handle it directly; otherwise, handle it with mutex
in work as previous. This prepares for MAC MCC C2Hs which require to be
processed directly. And, their handlers will be functions which can be
considered atomic.
Zong-Zhe Yang [Tue, 29 Nov 2022 08:31:25 +0000 (16:31 +0800)]
wifi: rtw89: rfk: rename rtw89_mcc_info to rtw89_rfk_mcc_info
The `rtw89_mcc_info mcc` is only for RFK MCC stuffs instead of common
MCC management info. Replace it with `rtw89_rfk_mcc_info rfk_mcc` to
avoid confusion and reserve `struct rtw89_mcc_info mcc` for MCC management
code.
8821ce is a combo card, and BT is a USB device that could get card lost
during stress test, and need WiFi firmware to detect and recover it, so
driver sends a H2C to enable this mechanism.
Ping-Ke Shih [Fri, 25 Nov 2022 07:24:16 +0000 (15:24 +0800)]
wifi: rtw89: 8852b: turn off PoP function in monitor mode
PoP stands for Packet on Packet that can improve performance in noisy
environment, but it could get RX stuck suddenly. In normal mode, firmware
can help to resolve the stuck, but firmware doesn't work in monitor mode.
Therefore, turn off PoP to avoid RX stuck.
Ping-Ke Shih [Fri, 25 Nov 2022 07:24:15 +0000 (15:24 +0800)]
wifi: rtw89: add HE radiotap for monitor mode
With basic HE radiotap, we can check data rate in sniffer data. To store
the radiotap data, we reserve headroom of aligned 64 bytes, and then
update HE radiotap in monitor mode, so it doesn't affect performance in
normal mode.
projects / linux.git / log