The MTK connac3 has introduced new hardware, SDO (Software Defined
Offload), to offload the process of filling the TX descriptor. Initially,
there were some issues, but after several fixes, it should now be stable,
allowing us to revert this commit.
Additionally, activating SDO is essential for the proper functioning of
features like TX checksum offload.
Charles Han [Mon, 7 Apr 2025 09:55:51 +0000 (17:55 +0800)]
wifi: mt76: mt7996: Add NULL check in mt7996_thermal_init
devm_kasprintf() can return a NULL pointer on failure,but this
returned value in mt7996_thermal_init() is not checked.
Add NULL check in mt7996_thermal_init(), to handle kernel NULL
pointer dereference error.
StanleyYP Wang [Thu, 20 Mar 2025 01:59:26 +0000 (09:59 +0800)]
wifi: mt76: mt7996: rework radar HWRDD idx
The definition of MT_RX_SEL (for rdd_rx_sel) is mixed with the
definition of HWRDD idx.
For example, MT_RX_SEL2 is for background HWRDD idx, not an
option of rdd_rx_sel.
Additionally, HWRDD idx does not exactly map to band idx for
Connac 3 chips. So, add mt7996_get_rdd_idx as a helper function.
Finally, remove some parts of the code inherited from the legacy chips.
For instance,
1. rdd_state is used for single-band-dual-HWRDD chips (for 80+80),
especially the 76xx series.
2. rdd_rx_sel is also used for single-band-dual-HWRDD chips
rx_sel = 0 => RDD0 for WF0, RDD1 for WF2
rx_sel = 1 => RDD0 for WF1, RDD1 for WF3
StanleyYP Wang [Thu, 20 Mar 2025 01:59:18 +0000 (09:59 +0800)]
wifi: mt76: mt7915: rework radar HWRDD idx
The definition of MT_RX_SEL (for rdd_rx_sel) is mixed with the
definition of HWRDD idx.
For example, MT_RX_SEL2 is for background HWRDD idx, not an option
of rdd_rx_sel.
Therefore, add mt7915_get_rdd_idx as a helper function to get the
HWRDD idx for each variants.
Additionally, remove some parts of the code inherited from the legacy
chips.
For instance,
1. rdd_state is used for single-band-dual-HWRDD chips (for 80+80),
especially the 76xx series.
2. rdd_rx_sel is also used for single-band-dual-HWRDD chips
rx_sel = 0 => RDD0 for WF0, RDD1 for WF2
rx_sel = 1 => RDD0 for WF1, RDD1 for WF3
StanleyYP Wang [Thu, 20 Mar 2025 01:59:09 +0000 (09:59 +0800)]
wifi: mt76: mt7915: set correct background radar capability
Some of the variants do not support background radar, so add a
helper to report background radar capability.
For mt7916, only the variant of 5G 2T2R + 1R supports background
radar.
wifi: mt76: connac: rework TX descriptor and TX free for mt7990
Adjust the TX descriptor and TX free for updated hardware fields.
This is a preliminary patch to support mt7990 chipset.
Co-developed-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Co-developed-by: Benjamin Lin <benjamin-jw.lin@mediatek.com> Signed-off-by: Benjamin Lin <benjamin-jw.lin@mediatek.com> Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Link: https://patch.msgid.link/20250409140750.724437-9-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
Peter Chiu [Wed, 9 Apr 2025 14:07:43 +0000 (22:07 +0800)]
wifi: mt76: mt7996: rework WA mcu command for mt7990
Since mt7990 lacks WA firmware, some WA commands are not supported or
need to be refactored to use the SDO command.
This is a preliminary patch to support mt7990 chipset.
wifi: mac80211: accept probe response on link address as well
If a random MAC address is not requested during scan request, unicast probe
response frames are only accepted if the destination address matches the
interface address. This works fine for non-ML interfaces. However, with
MLO, the same interface can have multiple links, and a scan on a link would
be requested with the link address. In such cases, the probe response frame
gets dropped which is incorrect.
Therefore, add logic to check if any of the link addresses match the
destination address if the interface address does not match.
wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO
When an AP interface is already beaconing, a subsequent scan is not allowed
unless the user space explicitly sets the flag NL80211_SCAN_FLAG_AP in the
scan request. If this flag is not set, the scan request will be returned
with the error code -EOPNOTSUPP. However, this restriction currently
applies only to non-ML interfaces. For ML interfaces, scans are allowed
without this flag being explicitly set by the user space which is wrong.
This is because the beaconing check currently uses only the deflink, which
does not get set during MLO.
Hence to fix this, during MLO, use the existing helper
ieee80211_num_beaconing_links() to know if any of the link is beaconing.
Christian Lamparter [Fri, 16 May 2025 18:41:06 +0000 (20:41 +0200)]
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi
|interface and generates an eeprom_readback message with a large
|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the
|message beyond the end of priv->eeprom.
|
|static void p54_rx_eeprom_readback(struct p54_common *priv,
| struct sk_buff *skb)
|{
| struct p54_hdr *hdr = (struct p54_hdr *) skb->data;
| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data;
|
| if (priv->fw_var >= 0x509) {
| memcpy(priv->eeprom, eeprom->v2.data,
| le16_to_cpu(eeprom->v2.len));
| } else {
| memcpy(priv->eeprom, eeprom->v1.data,
| le16_to_cpu(eeprom->v1.len));
| }
| [...]
The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom().
The device is supposed to provide the same length back to the driver.
But yes, it's possible (like shown in the report) to alter the value
to something that causes a crash/panic due to overrun.
This patch addresses the issue by adding the size to the common device
context, so p54_rx_eeprom_readback no longer relies on possibly tampered
values... That said, it also checks if the "firmware" altered the value
and no longer copies them.
The one, small saving grace is: Before the driver tries to read the eeprom,
it needs to upload >a< firmware. the vendor firmware has a proprietary
license and as a reason, it is not present on most distributions by
default.
Cc: <stable@kernel.org> Reported-by: Robert Morris <rtm@mit.edu> Closes: https://lore.kernel.org/linux-wireless/28782.1747258414@localhost/ Fixes: 7cb770729ba8 ("p54: move eeprom code into common library") Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Link: https://patch.msgid.link/20250516184107.47794-1-chunkeey@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bert Karwatzki [Tue, 20 May 2025 22:34:29 +0000 (00:34 +0200)]
wifi: check if socket flags are valid
Checking the SOCK_WIFI_STATUS flag bit in sk_flags may give wrong results
since sk_flags are part of a union and the union is used otherwise. Add
sk_requests_wifi_status() which checks if sk is non-NULL, sk is a full
socket (so flags are valid) and checks the flag bit.
wifi: mac80211: handle non-MLO mode as well in ieee80211_num_beaconing_links()
Currently, ieee80211_num_beaconing_links() returns 0 when the interface
operates in non-ML mode. However, non-MLO mode is equivalent to having a
single link. Therefore, the function can handle the non-MLO case as well.
This adjustment will also eliminate the need for deflink usage in certain
scenarios.
Hence, implement changes to handle the non-MLO case as well. There is
no change in functionality, and no existing user-visible bug is getting
fixed. This update simply makes the function generic to handle all cases.
Chin-Yen Lee [Tue, 13 May 2025 12:52:03 +0000 (20:52 +0800)]
wifi: rtw89: fix firmware scan delay unit for WiFi 6 chips
The scan delay unit of firmware command for WiFi 6 chips is
microsecond, but is wrong set now and lead to abnormal work
for net-detect. Correct the unit to avoid the error.
Zong-Zhe Yang [Sun, 11 May 2025 03:52:17 +0000 (11:52 +0800)]
wifi: rtw89: mcc: avoid redundant recalculations if no chance to improve
MCC will track the changes of beacon offset, and trigger a recalculation
when the difference is larger than the tolerance. It means that a better
pattern is expected after recalculating. However, in the cases which get
a worse beacon offset, there is no chance to improve the pattern even if
recalculating. So, bypass them.
Zong-Zhe Yang [Sun, 11 May 2025 03:52:16 +0000 (11:52 +0800)]
wifi: rtw89: mcc: deal with non-periodic NoA
Originally, MCC just took periodic NoA into account. When the connected GO
announces non-periodic NoA and GC side is during MCC, sometimes GC cannot
receive beacons well if the MCC scheduling conflicts with the non-periodic
NoA planning. After the loss exceeds the tolerable amount, beacon filter
will report connection loss. However, in this case, the loss is acceptable.
So now, MCC will calculate the range of non-periodic NoA. And then, don't
care beacon loss during the range.
Besides, rtw89_mcc_fill_role_limit() only makes sense for GC. Remove the
redundant check of GO.
Zong-Zhe Yang [Sun, 11 May 2025 03:52:15 +0000 (11:52 +0800)]
wifi: rtw89: mcc: introduce calculation of anchor pattern
In the cases that two MCC roles' TBTTs are too close or too far, original
MCC pattern calculation logic will lead to a result that both roles might
not cover its TBTT with sufficient time. Introduce a new calculation logic
called anchor pattern for these corner cases. It allows to choose one role
as anchor to put its TBTT in the middle of its duration directly. For now,
a P2P role has a higher priority to be chosen as an anchor. Then, if able,
another role might need to depend on courtesy mechanism to take time from
anchor.
Zong-Zhe Yang [Sun, 11 May 2025 03:52:14 +0000 (11:52 +0800)]
wifi: rtw89: mcc: add courtesy mechanism conditions to P2P roles
In one enablement of courtesy mechanism, there is one provider and
one receiver. And, receiver can use the provider's time in a given
period. But, to make P2P NoA protocol work as expected as possible,
GO should be present at the time it doesn't announce absent, and GC
should not use the time when GO announces absent. So, don't enable
courtesy mechanism if provider is GO or receiver is GC.
Zong-Zhe Yang [Sun, 11 May 2025 03:52:13 +0000 (11:52 +0800)]
wifi: rtw89: mcc: drop queued chanctx changes when stopping
When MCC is about to stop, there may be some chanctx changes which are
queued for work but have not yet been run. To avoid these changes from
being processed in a wrong state (e.g. next new MCC instance), cancel
the queued work and drop queued changes.
Zong-Zhe Yang [Sun, 11 May 2025 03:52:12 +0000 (11:52 +0800)]
wifi: rtw89: mcc: pass whom to stop at when pausing chanctx
When stopping MCC, FW can stop at a given MCC role following H2C command.
When pausing chanctx during MCC, in general, the caller expects to process
things with its chanctx. So, pass the caller as target and let FW stop MCC
at it.
Bitterblue Smith [Sat, 10 May 2025 12:22:24 +0000 (15:22 +0300)]
wifi: rtw88: usb: Upload the firmware in bigger chunks
RTL8811AU stops responding during the firmware download on some systems:
[ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0
[ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0
[ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110
[ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110
[ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110
Maybe it takes too long when writing the firmware 4 bytes at a time.
Write 196 bytes at a time for RTL8821AU, RTL8811AU, and RTL8812AU,
and 254 bytes at a time for RTL8723DU. These are the sizes used in
their official drivers. Tested with all these chips.
Bitterblue Smith [Sat, 10 May 2025 12:21:25 +0000 (15:21 +0300)]
wifi: rtw88: usb: Reduce control message timeout to 500 ms
RTL8811AU stops responding during the firmware download on some systems:
[ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0
[ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0
[ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110
[ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110
[ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode
[ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110
Each write takes 30 seconds to fail because that's the timeout currently
used for control messages in rtw_usb_write().
In this scenario the firmware download takes at least 2000 seconds.
Because this is done from the USB probe function, the long delay makes
other things in the system hang.
Reduce the timeout to 500 ms. This is the value used by the official USB
wifi drivers from Realtek.
Of course this only makes things hang for ~30 seconds instead of ~30
minutes. It doesn't fix the firmware download.
Tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8814AU, RTL8811AU,
RTL8812AU, RTL8821AU, RTL8723DU.
Ping-Ke Shih [Fri, 9 May 2025 01:34:33 +0000 (09:34 +0800)]
wifi: rtw89: pci: enlarge retry times of RX tag to 1000
RX tag is sequence number to ensure RX DMA is complete. On platform
Gigabyte X870 AORUS ELITE WIFI7, sometimes it needs longer retry times
to complete RX DMA, or driver throws warnings and connection drops:
rtw89_8922ae 0000:07:00.0: failed to update 162 RXBD info: -11
rtw89_8922ae 0000:07:00.0: failed to update 163 RXBD info: -11
rtw89_8922ae 0000:07:00.0: failed to update 32 RXBD info: -11
rtw89_8922ae 0000:07:00.0: failed to release TX skbs
Fixes: 0bc7d1d4e63c ("wifi: rtw89: pci: validate RX tag for RXQ and RPQ") Reported-by: Samuel Reyes <zohrlaffz@gmail.com> Closes: https://lore.kernel.org/linux-wireless/f4355539f3ac46bbaf9c586d059a8cbb@realtek.com/T/#t Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250509013433.7573-1-pkshih@realtek.com
Dian-Syuan Yang [Wed, 7 May 2025 03:12:03 +0000 (11:12 +0800)]
wifi: rtw89: leave idle mode when setting WEP encryption for AP mode
Due to mac80211 triggering the hardware to enter idle mode, it fails
to install WEP key causing connected station can't ping successfully.
Currently, it forces the hardware to leave idle mode before driver
adding WEP keys.
Ping-Ke Shih [Tue, 6 May 2025 01:53:56 +0000 (09:53 +0800)]
wifi: rtw89: pci: configure manual DAC mode via PCI config API only
To support 36-bit DMA, configure chip proprietary bit via PCI config API
or chip DBI interface. However, the PCI device mmap isn't set yet and
the DBI is also inaccessible via mmap, so only if the bit can be accessible
via PCI config API, chip can support 36-bit DMA. Otherwise, fallback to
32-bit DMA.
Miri Korenblit [Sun, 11 May 2025 16:53:19 +0000 (19:53 +0300)]
wifi: iwlwifi: rename ctx-info-gen3 to ctx-info-v2
Context info was introduced in 22000, and was significantly changed in
ax210. The new version of context info was called 'gen3',
probably because in 22000, the gen2 transport was added.
But this name is just wrong:
- if 'gen' enumerates transports, there was not a gen3 transport, just a
few modifications to gen1/2 transports needed for ax210.
- if 'gen' enumerates devices, then we can just use the device names.
Also, context info will soon become a lib, agnostic of the transport
generations.
Simply replace 'gen3' with 'v2'.
Miri Korenblit [Sun, 11 May 2025 16:53:14 +0000 (19:53 +0300)]
wifi: iwlwifi: use bc entries instead of bc table also for pre-ax210
iwlagn_scd_bc_tbl is used for pre-ax210 devices,
and iwl_gen3_bc_tbl_entry is used for ax210 and on. But there is no
difference between the the 22000 version and the AX210+ one.
In order to unify the two, as first step make iwlagn_scd_bc_tbl an entry
as well, and adjust the code. In a later patch both structures will be
unified.
Miri Korenblit [Sun, 11 May 2025 16:53:12 +0000 (19:53 +0300)]
wifi: iwlwifi: use normal versioning convention for iwl_tx_cmd
We have iwl_tx_cmd for devices older than 22000, iwl_tx_cmd_gen2 for
22000 devices, and iwl_tx_cmd_gen3 ax210 and up.
But the convention for all other APIs is to have the latest version
without any prefix and the older ones - with a _vX prefix,
where X is the highest version that this struct support.
The term 'gen' was introduced as the name of the (back then) new
transport, and should not be used as a device name (for that we have the
actual names: 22000, ax210, etc.)
Now as a new transport, called 'gen3', is going to be written and it can
be confused with this API.
Move iwl_tx_cmd to use the regular versioning convention.
We don't need the CORES() match nor jacket (which really doesn't
even make sense to match to the RF anyway), and since the subdevice
masks we care about are contiguous, we can encode them as highest
and lowest bit set (automatically.) By encoding whether to match or
not as separate flags and taking advantage of the limited range of
the RF type, step and ID we can reduce the amount of memory needed
for the table, while also making the logic (apart perhaps from the
subdevice mask) easier to understand.
This reduces the size of the module by about 1.5KiB on x86-64.
Johannes Berg [Sun, 11 May 2025 16:53:09 +0000 (19:53 +0300)]
wifi: iwlwifi: cfg: clean up dr/br configs
We don't need the configs that won't end up being used, such as
the "br" config for discrete devices, remove them. Also remove
the module firmware for test chips, that's never needed.
For now keep the iwl_dr_mac_cfg even if it's unused, we'll add
platforms with it once we have their PCI IDs.
Pagadala Yesu Anjaneyulu [Sun, 11 May 2025 16:53:08 +0000 (19:53 +0300)]
wifi: iwlwifi: Add helper function to extract device ID
Add iwl_trans_get_device_id() to extract the device ID
from the hw_id member in the iwl_trans structure.
hw_id member contains both sub-device ID and device ID,
with the device ID occupying bits 16 to 31.
Johannes Berg [Sun, 11 May 2025 16:53:07 +0000 (19:53 +0300)]
wifi: iwlwifi: cfg: mark Ty devices as discrete
Looks like these were never marked discrete, since they always
used the iwl_so_mac_cfg (earlier iwl_so_trans_cfg). Mark them
as discrete since they are.
Johannes Berg [Sat, 10 May 2025 18:48:27 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: remove MAC type/step matching
Now that it's all split into MAC and RF configs, remove
the matching on MAC type and step. If we ever need to do
something based on the MAC step, we'll have to find some
new mechanism (since the MAC type is known already from
the PCI IDs table, but not the step), or just handle the
(likely small) differences in code.
Johannes Berg [Sat, 10 May 2025 18:48:26 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: add a couple of older devices
There are some devices that are misidentified, such as 7265-N
and Killer 1435 variants. Add their names, and for some of them
also add the PCI IDs to match at all.
Johannes Berg [Sat, 10 May 2025 18:48:22 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: clean up JF device matching
This really only needs to be distinguished based on the
RF type, bandwidth limit and possibly diversity (JF1).
Some of the names that are defined don't even exist.
Johannes Berg [Sat, 10 May 2025 18:48:19 +0000 (21:48 +0300)]
wifi: iwlwifi: cfg: unify and add some Killer devices
Unify a number of Killer devices now that we no longer
need to distinguish the MAC type, and add a few more
that wouldn't have gotten the right name before.
Pagadala Yesu Anjaneyulu [Fri, 9 May 2025 10:44:50 +0000 (13:44 +0300)]
wifi: iwlwifi: mld: move aux_sta member from iwl_mld_link to iwl_mld_vif
This change reflects the correct ownership of aux_sta,
as it is not a property of the link but rather of the virtual interface.
Updated the initialization, cleanup and access logic for the aux_sta member
to align with its new location within iwl_mld_vif.
Pagadala Yesu Anjaneyulu [Fri, 9 May 2025 10:44:49 +0000 (13:44 +0300)]
wifi: iwlwifi: mld: Fix ROC activity cleanup in iwl_mld_vif
The roc_activity member in the iwl_mld_vif structure was previously
set to zero during cleanup as was present in struct_group, which
incorrectly indicated ROC_ACTIVITY_HOTSPOT.
To fix this issue, remove roc_activity member from struct_group.
Notify mac80211 of ROC expiration during vif cleanup to maintain
synchronization between the driver and mac80211.
While on it, update it's type to enum iwl_roc_activity.
Johannes Berg [Fri, 9 May 2025 10:44:47 +0000 (13:44 +0300)]
wifi: iwlwifi: rename iwl_cfg to iwl_rf_cfg
With all the cleanups now, we can rename the structure to
better indicate the functionality. For older devices this
isn't quite accurate, of course, but it's better to have a
name that reflects future use for maintenance.
Johannes Berg [Fri, 9 May 2025 10:44:46 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: clean up Sc/Dr/Br configs
For now, the WH and PE radios require the same config as
FM, so just add a #define for those instead of copying
the data. Since this is true, Sc/Dr/Br all used the same
configs for all RF types, but that's confusing, so now
use the defined WH/PE names for the correct combinations.
We can also now enable the unit test that ensures we have
no duplicate RF configs.
Johannes Berg [Fri, 9 May 2025 10:44:42 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: unify JF configs
Unify the JF configs to just one JF RF config. This can be
done because the differing fields (thermal and DCCM offsets)
won't be used for Qu MACs (and up) due to firmware support.
Johannes Berg [Fri, 9 May 2025 10:44:41 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: unify num_rbds config
This should depend on both the RF (VHT/HE/EHT support) and
the MAC (<=22000 can put multiple frames into one buffer),
so unify the config in the struct iwl_cfg to just have it
sized according to the RF, and then double it for all the
MACs starting from AX210 (So/Ty).
Johannes Berg [Fri, 9 May 2025 10:44:40 +0000 (13:44 +0300)]
wifi: iwlwifi: cfg: add ucode API min/max to MAC config
In some older devices, the min/max firmware API supported by
the driver depends on the specific device, when sharing the
the same MAC (config). For most newer devices, it really is
dependent on the MAC instead, since the firmware was frozen
for certain MAC types. However, in the future we expect also
freezes for RF types there.
To handle this most generally, add an API min/max to the MAC
config and then use the narrowest range prescribed by both,
if set.
For the newer MACs since 9000, move the configuration, there
was only a freeze on MAC+RF lines so far.
Zong-Zhe Yang [Mon, 5 May 2025 07:24:40 +0000 (15:24 +0800)]
wifi: rtw89: declare MLO support if prerequisites are met
When the following prerequisites are met, driver will enable support_mlo.
It means that driver will declare WIPHY_FLAG_SUPPORTS_MLO, and then deal
with MLO related things.
The main prerequisites are as below.
1. all prerequisites for running with chanctx
2. FW feature NOTIFY_AP_INFO
Zong-Zhe Yang [Mon, 5 May 2025 07:24:39 +0000 (15:24 +0800)]
wifi: rtw89: debug: add mlo_mode dbgfs
Add an dbgfs mlo_mode to get/set MLO mode. And, support to trigger MLSR
switching. Setting it will automatically disable MLO Dynamic Mechanism
(DM). Then MLO things can follow commands via dbgfs mlo_mode instead of
MLO DM. The disabled DM(s) can be checked/cleared via dbgfs disable_dm.
The following is an use example.
Read it to show current MLD status.
$ cat mlo_mode
Po-Hao Huang [Mon, 5 May 2025 07:24:35 +0000 (15:24 +0800)]
wifi: rtw89: add MLO track for MLSR switch decision
Add MLSR switch mechanism based on tracking RSSI. Switch to a 2 GHz link
(if any) when average RSSI is lower than threshold -53. And, switch out
from a 2 GHz link when average RSSI is larger than threshold -38.
The sequence of MLSR switch handling is like the following.
1. initialize target link and configure to PS mode
2. configure current designated link to PS mode
3. configure target link to non-PS mode
4. deinitialize currently active links except target link
The above flow also implies that target link becomes new designated link.
Zong-Zhe Yang [Mon, 5 May 2025 07:24:34 +0000 (15:24 +0800)]
wifi: rtw89: add handling of mlo_link_cfg H2C command and C2H event
The mlo_link_cfg H2C command is used to tell FW to enter/leave PS mode
on a given link. And, need to wait for status of C2H event to ensure if
FW deals with it successfully.
Zong-Zhe Yang [Mon, 5 May 2025 07:24:33 +0000 (15:24 +0800)]
wifi: rtw89: chan: re-calculate MLO DBCC mode during setting channel
Wi-Fi 7 chips have dual HW bands. After impending MLO support, they
can work with HW-[0] / HW-[1] / HW-[0,1] according to active links.
So, during setting channel, also re-calculate the MLO DBCC mode flag.
Then, leaf chip functions of setting channel can configure with HWs
based on current case.
Besides, tweak the initial and idle MLO DBCC mode of Wi-Fi 7 chips to
MLO_1_PLUS_1_1RF to work with dual HW bands. And, after disconnecting,
due to no active links, MLO DBCC mode will re-calculate to idle case,
i.e. MLO_1_PLUS_1_1RF.
Po-Hao Huang [Mon, 5 May 2025 07:24:31 +0000 (15:24 +0800)]
wifi: rtw89: allow driver to do specific band TX for MLO
For data packets that can be sent on any band, fill in main mac_id
and let HW decide. For packets that we wish to transmit on specific
band, fill in sw_mld field so HW would only send it on that band.
Main mac_id is the corresponding mac_id on band 0.
Zong-Zhe Yang [Mon, 5 May 2025 07:24:30 +0000 (15:24 +0800)]
wifi: rtw89: extract link part from core tx write function
Extract core_tx_write_link from core_tx_write to accept given links as
parameters. To make the follow-up changes of TX description more clear,
tweak SW functions to split things ahead.
Bitterblue Smith [Fri, 2 May 2025 11:49:34 +0000 (14:49 +0300)]
wifi: rtw88: Handle RTL8723D(S) with blank efuse
Some users have RTL8723DS chips with nearly blank efuse. Currently these
chips cannot connect when using rtw88, but they do work using the old
out-of-tree driver.
Use reasonable default values for TX power, antenna configuration, and
crystal cap if the chip's efuse is missing these things.
RTL8723D can use the same default values as RTL8703B, so simply move
the code from rtl8703b_read_efuse() to the shared function
__rtl8723x_read_efuse().
Bitterblue Smith [Fri, 2 May 2025 11:49:01 +0000 (14:49 +0300)]
wifi: rtw88: Fix RX aggregation settings for RTL8723DS
Use the same RX aggregation size and timeout used by the out-of-tree
RTL8723DS driver. Also set mystery bit 31 of REG_RXDMA_AGG_PG_TH. This
improves the RX speed from ~44 Mbps to ~67 Mbps.
Johannes Berg [Thu, 8 May 2025 12:13:05 +0000 (15:13 +0300)]
wifi: iwlwifi: cfg: move MAC parameters to MAC data
There are a number of MAC parameters that are in the iwl_cfg
(which is the last config matched to the MAC/RF combination).
This isn't necessary, there are many more of those than MACs,
so move (most of) the data into the MAC family config struct.
Note that DCCM information remains for use by older devices,
and on 9000 series it'll be in struct iwl_cfg but be ignored
when the CRF is in a Qu/So platform.
projects / users / jedix / linux-maple.git / log