rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
|
|
|
|
/* Copyright(c) 2019-2020 Realtek Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "cam.h"
|
wifi: rtw89: concentrate chandef setting to stack callback
Originally, we didn't support mac80211 chanctx, so it's expected that
ieee80211_hw::conf::chandef would be filled by mac80211. And then, we
could just query it whenever we need the current chandef.
However, we are planing to support mac80211 chanctx. After that, the
above assumption would be broken. So, we adjust a bit ahead to reduce
future works about mac80211 chanctx.
After this, we don't query ieee80211_hw::conf::chandef directly, and
we add a map, entity_map, to HAL to indicate which chandef came from
stack. And it will later be used to recalcate entity mode.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-9-pkshih@realtek.com
2022-08-09 18:49:47 +08:00
|
|
|
#include "chan.h"
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
#include "coex.h"
|
|
|
|
#include "debug.h"
|
|
|
|
#include "fw.h"
|
|
|
|
#include "mac.h"
|
|
|
|
#include "phy.h"
|
|
|
|
#include "ps.h"
|
|
|
|
#include "reg.h"
|
|
|
|
#include "sar.h"
|
|
|
|
#include "ser.h"
|
2022-09-14 11:50:32 +08:00
|
|
|
#include "util.h"
|
2022-10-27 13:27:06 +08:00
|
|
|
#include "wow.h"
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
static void rtw89_ops_tx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_tx_control *control,
|
|
|
|
struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
|
|
|
|
struct ieee80211_vif *vif = info->control.vif;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
struct ieee80211_sta *sta = control->sta;
|
2023-04-11 20:48:30 +08:00
|
|
|
u32 flags = IEEE80211_SKB_CB(skb)->flags;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
int ret, qsel;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (rtwvif->offchan && !(flags & IEEE80211_TX_CTL_TX_OFFCHAN) && sta) {
|
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
2023-04-11 20:48:30 +08:00
|
|
|
|
|
|
|
rtw89_debug(rtwdev, RTW89_DBG_TXRX, "ops_tx during offchan\n");
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
skb_queue_tail(&rtwsta->roc_queue, skb);
|
2023-04-11 20:48:30 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
ret = rtw89_core_tx_write(rtwdev, vif, sta, skb, &qsel);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_err(rtwdev, "failed to transmit skb: %d\n", ret);
|
|
|
|
ieee80211_free_txskb(hw, skb);
|
2021-12-01 17:38:16 +08:00
|
|
|
return;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
rtw89_core_tx_kick_off(rtwdev, qsel);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_wake_tx_queue(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_txq *txq)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
|
|
|
ieee80211_schedule_txq(hw, txq);
|
|
|
|
queue_work(rtwdev->txq_wq, &rtwdev->txq_work);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_start(struct ieee80211_hw *hw)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
return rtw89_core_start(rtwdev);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2024-06-18 19:25:56 +03:00
|
|
|
static void rtw89_ops_stop(struct ieee80211_hw *hw, bool suspend)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_core_stop(rtwdev);
|
|
|
|
}
|
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
static int rtw89_ops_config(struct ieee80211_hw *hw, int radio_idx, u32 changed)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2022-02-25 11:08:50 +08:00
|
|
|
/* let previous ips work finish to ensure we don't leave ips twice */
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_work_cancel(hw->wiphy, &rtwdev->ips_work);
|
2022-02-25 11:08:50 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
if ((changed & IEEE80211_CONF_CHANGE_IDLE) &&
|
|
|
|
!(hw->conf.flags & IEEE80211_CONF_IDLE))
|
|
|
|
rtw89_leave_ips(rtwdev);
|
|
|
|
|
wifi: rtw89: concentrate chandef setting to stack callback
Originally, we didn't support mac80211 chanctx, so it's expected that
ieee80211_hw::conf::chandef would be filled by mac80211. And then, we
could just query it whenever we need the current chandef.
However, we are planing to support mac80211 chanctx. After that, the
above assumption would be broken. So, we adjust a bit ahead to reduce
future works about mac80211 chanctx.
After this, we don't query ieee80211_hw::conf::chandef directly, and
we add a map, entity_map, to HAL to indicate which chandef came from
stack. And it will later be used to recalcate entity mode.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-9-pkshih@realtek.com
2022-08-09 18:49:47 +08:00
|
|
|
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
|
2024-07-27 16:06:46 +08:00
|
|
|
rtw89_config_entity_chandef(rtwdev, RTW89_CHANCTX_0,
|
wifi: rtw89: concentrate chandef setting to stack callback
Originally, we didn't support mac80211 chanctx, so it's expected that
ieee80211_hw::conf::chandef would be filled by mac80211. And then, we
could just query it whenever we need the current chandef.
However, we are planing to support mac80211 chanctx. After that, the
above assumption would be broken. So, we adjust a bit ahead to reduce
future works about mac80211 chanctx.
After this, we don't query ieee80211_hw::conf::chandef directly, and
we add a map, entity_map, to HAL to indicate which chandef came from
stack. And it will later be used to recalcate entity mode.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-9-pkshih@realtek.com
2022-08-09 18:49:47 +08:00
|
|
|
&hw->conf.chandef);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_set_channel(rtwdev);
|
wifi: rtw89: concentrate chandef setting to stack callback
Originally, we didn't support mac80211 chanctx, so it's expected that
ieee80211_hw::conf::chandef would be filled by mac80211. And then, we
could just query it whenever we need the current chandef.
However, we are planing to support mac80211 chanctx. After that, the
above assumption would be broken. So, we adjust a bit ahead to reduce
future works about mac80211 chanctx.
After this, we don't query ieee80211_hw::conf::chandef directly, and
we add a map, entity_map, to HAL to indicate which chandef came from
stack. And it will later be used to recalcate entity mode.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-9-pkshih@realtek.com
2022-08-09 18:49:47 +08:00
|
|
|
}
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if ((changed & IEEE80211_CONF_CHANGE_IDLE) &&
|
2023-04-15 11:48:55 +08:00
|
|
|
(hw->conf.flags & IEEE80211_CONF_IDLE) &&
|
|
|
|
!rtwdev->scanning)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_enter_ips(rtwdev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
static int __rtw89_ops_add_iface_link(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_vif_link *rtwvif_link)
|
|
|
|
{
|
|
|
|
struct ieee80211_bss_conf *bss_conf;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
rtw89_vif_type_mapping(rtwvif_link, false);
|
|
|
|
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_work_init(&rtwvif_link->update_beacon_work, rtw89_core_update_beacon_work);
|
2025-06-05 19:42:05 +08:00
|
|
|
wiphy_delayed_work_init(&rtwvif_link->csa_beacon_work, rtw89_core_csa_beacon_work);
|
wifi: rtw89: mcc: solve GO's TBTT change and TBTT too close to NoA issue
For some implementation acting as GO under MCC(GO+STA), the GO's TBTT
might change after STA roams to another AP. This could result the new GO
beacon TX at the STA timeslot of GC+STA, causing GC beacon loss.
Therefore, if the GC detects beacon loss, it will pause MCC and remain
on the GO side for 100 TU to detect the new TBTT beacon.
Additionally, some implementation acting as GO under MCC might TX beacon
too close to the NoA period. The GC calculates timeslot pattern the TOB
(time offset behind) or TOA(time offset ahead) less than the minimum
RX beacon time, which leads to beacon loss. Therefore, disable the
beacon filter in this case. Then, if the GO's TBTT changed, the pattern
TOB/TOA greater than the minimum RX beacon time, the beacon filter should
be retriggered during MCC update.
Moreover, if the beacon filter is disabled initially but the GO timeslot
change, causing QoS null data detection fail, also pause MCC to detect new
TBTT beacon.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-7-pkshih@realtek.com
2025-07-10 12:24:15 +08:00
|
|
|
wiphy_delayed_work_init(&rtwvif_link->mcc_gc_detect_beacon_work,
|
|
|
|
rtw89_mcc_gc_detect_beacon_work);
|
2025-06-05 19:42:05 +08:00
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
INIT_LIST_HEAD(&rtwvif_link->general_pkt_list);
|
|
|
|
|
2025-05-11 11:52:16 +08:00
|
|
|
rtw89_p2p_noa_once_init(rtwvif_link);
|
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
rtwvif_link->hit_rule = 0;
|
|
|
|
rtwvif_link->bcn_hit_cond = 0;
|
|
|
|
rtwvif_link->chanctx_assigned = false;
|
|
|
|
rtwvif_link->chanctx_idx = RTW89_CHANCTX_0;
|
|
|
|
rtwvif_link->reg_6ghz_power = RTW89_REG_6GHZ_POWER_DFLT;
|
2025-04-22 09:46:14 +08:00
|
|
|
rtwvif_link->rand_tsf_done = false;
|
wifi: rtw89: mcc: solve GO's TBTT change and TBTT too close to NoA issue
For some implementation acting as GO under MCC(GO+STA), the GO's TBTT
might change after STA roams to another AP. This could result the new GO
beacon TX at the STA timeslot of GC+STA, causing GC beacon loss.
Therefore, if the GC detects beacon loss, it will pause MCC and remain
on the GO side for 100 TU to detect the new TBTT beacon.
Additionally, some implementation acting as GO under MCC might TX beacon
too close to the NoA period. The GC calculates timeslot pattern the TOB
(time offset behind) or TOA(time offset ahead) less than the minimum
RX beacon time, which leads to beacon loss. Therefore, disable the
beacon filter in this case. Then, if the GO's TBTT changed, the pattern
TOB/TOA greater than the minimum RX beacon time, the beacon filter should
be retriggered during MCC update.
Moreover, if the beacon filter is disabled initially but the GO timeslot
change, causing QoS null data detection fail, also pause MCC to detect new
TBTT beacon.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-7-pkshih@realtek.com
2025-07-10 12:24:15 +08:00
|
|
|
rtwvif_link->detect_bcn_count = 0;
|
2024-09-16 13:31:56 +08:00
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
bss_conf = rtw89_vif_rcu_dereference_link(rtwvif_link, true);
|
|
|
|
ether_addr_copy(rtwvif_link->mac_addr, bss_conf->addr);
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
ret = rtw89_mac_add_vif(rtwdev, rtwvif_link);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
rtw89_btc_ntfy_role_info(rtwdev, rtwvif_link, NULL, BTC_ROLE_START);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __rtw89_ops_remove_iface_link(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_vif_link *rtwvif_link)
|
|
|
|
{
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(rtwdev->hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_work_cancel(rtwdev->hw->wiphy, &rtwvif_link->update_beacon_work);
|
2025-06-05 19:42:05 +08:00
|
|
|
wiphy_delayed_work_cancel(rtwdev->hw->wiphy, &rtwvif_link->csa_beacon_work);
|
wifi: rtw89: mcc: solve GO's TBTT change and TBTT too close to NoA issue
For some implementation acting as GO under MCC(GO+STA), the GO's TBTT
might change after STA roams to another AP. This could result the new GO
beacon TX at the STA timeslot of GC+STA, causing GC beacon loss.
Therefore, if the GC detects beacon loss, it will pause MCC and remain
on the GO side for 100 TU to detect the new TBTT beacon.
Additionally, some implementation acting as GO under MCC might TX beacon
too close to the NoA period. The GC calculates timeslot pattern the TOB
(time offset behind) or TOA(time offset ahead) less than the minimum
RX beacon time, which leads to beacon loss. Therefore, disable the
beacon filter in this case. Then, if the GO's TBTT changed, the pattern
TOB/TOA greater than the minimum RX beacon time, the beacon filter should
be retriggered during MCC update.
Moreover, if the beacon filter is disabled initially but the GO timeslot
change, causing QoS null data detection fail, also pause MCC to detect new
TBTT beacon.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250710042423.73617-7-pkshih@realtek.com
2025-07-10 12:24:15 +08:00
|
|
|
wiphy_delayed_work_cancel(rtwdev->hw->wiphy,
|
|
|
|
&rtwvif_link->mcc_gc_detect_beacon_work);
|
2024-09-16 13:31:56 +08:00
|
|
|
|
2025-05-11 11:52:16 +08:00
|
|
|
rtw89_p2p_noa_once_deinit(rtwvif_link);
|
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
rtw89_btc_ntfy_role_info(rtwdev, rtwvif_link, NULL, BTC_ROLE_STOP);
|
|
|
|
|
|
|
|
rtw89_mac_remove_vif(rtwdev, rtwvif_link);
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
static int rtw89_ops_add_interface(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2024-09-16 13:31:56 +08:00
|
|
|
u8 mac_id, port;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
int ret = 0;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2022-09-22 09:04:31 +08:00
|
|
|
rtw89_debug(rtwdev, RTW89_DBG_STATE, "add vif %pM type %d, p2p %d\n",
|
|
|
|
vif->addr, vif->type, vif->p2p);
|
|
|
|
|
2023-04-11 20:48:30 +08:00
|
|
|
rtw89_leave_ips_by_hwflags(rtwdev);
|
|
|
|
|
2023-04-11 20:48:28 +08:00
|
|
|
if (RTW89_CHK_FW_FEATURE(BEACON_FILTER, &rtwdev->fw))
|
|
|
|
vif->driver_flags |= IEEE80211_VIF_BEACON_FILTER |
|
|
|
|
IEEE80211_VIF_SUPPORTS_CQM_RSSI;
|
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
mac_id = rtw89_acquire_mac_id(rtwdev);
|
2025-01-22 14:03:08 +08:00
|
|
|
if (mac_id == RTW89_MAX_MAC_ID_NUM)
|
|
|
|
return -ENOSPC;
|
2024-09-16 13:31:56 +08:00
|
|
|
|
|
|
|
port = rtw89_core_acquire_bit_map(rtwdev->hw_port, RTW89_PORT_NUM);
|
|
|
|
if (port == RTW89_PORT_NUM) {
|
|
|
|
ret = -ENOSPC;
|
|
|
|
goto release_macid;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_init_vif(rtwdev, rtwvif, mac_id, port);
|
2024-09-16 13:31:54 +08:00
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
rtw89_core_txq_init(rtwdev, vif->txq);
|
2024-09-16 13:31:54 +08:00
|
|
|
|
2025-01-03 10:45:00 +08:00
|
|
|
if (!rtw89_rtwvif_in_list(rtwdev, rtwvif)) {
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
list_add_tail(&rtwvif->list, &rtwdev->rtwvifs_list);
|
2025-01-03 10:45:00 +08:00
|
|
|
INIT_LIST_HEAD(&rtwvif->mgnt_entry);
|
2025-04-28 19:24:56 +08:00
|
|
|
INIT_LIST_HEAD(&rtwvif->dlink_pool);
|
2025-01-03 10:45:00 +08:00
|
|
|
}
|
2024-10-22 16:31:04 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
ether_addr_copy(rtwvif->mac_addr, vif->addr);
|
|
|
|
|
|
|
|
rtwvif->offchan = false;
|
|
|
|
rtwvif->roc.state = RTW89_ROC_IDLE;
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_delayed_work_init(&rtwvif->roc.roc_work, rtw89_roc_work);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
rtw89_traffic_stats_init(rtwdev, &rtwvif->stats);
|
|
|
|
|
2024-11-20 11:40:51 +08:00
|
|
|
rtwvif_link = rtw89_vif_set_link(rtwvif, RTW89_VIF_IDLE_LINK_ID);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (!rtwvif_link) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto release_port;
|
|
|
|
}
|
2024-09-16 13:31:52 +08:00
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
ret = __rtw89_ops_add_iface_link(rtwdev, rtwvif_link);
|
|
|
|
if (ret)
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
goto unset_link;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
rtw89_recalc_lps(rtwdev);
|
|
|
|
return 0;
|
2023-05-27 16:29:38 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
unset_link:
|
2024-11-20 11:40:51 +08:00
|
|
|
rtw89_vif_unset_link(rtwvif, RTW89_VIF_IDLE_LINK_ID);
|
2024-09-16 13:31:56 +08:00
|
|
|
release_port:
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
list_del_init(&rtwvif->list);
|
2024-09-16 13:31:56 +08:00
|
|
|
rtw89_core_release_bit_map(rtwdev->hw_port, port);
|
|
|
|
release_macid:
|
|
|
|
rtw89_release_mac_id(rtwdev, mac_id);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_remove_interface(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
u8 macid = rtw89_vif_get_main_macid(rtwvif);
|
|
|
|
u8 port = rtw89_vif_get_main_port(rtwvif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2022-09-22 09:04:31 +08:00
|
|
|
rtw89_debug(rtwdev, RTW89_DBG_STATE, "remove vif %pM type %d p2p %d\n",
|
|
|
|
vif->addr, vif->type, vif->p2p);
|
|
|
|
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_delayed_work_cancel(hw->wiphy, &rtwvif->roc.roc_work);
|
2022-01-07 11:42:25 +08:00
|
|
|
|
2024-11-20 11:40:51 +08:00
|
|
|
rtwvif_link = rtwvif->links[RTW89_VIF_IDLE_LINK_ID];
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
2024-11-20 11:40:51 +08:00
|
|
|
__func__, RTW89_VIF_IDLE_LINK_ID);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
goto bottom;
|
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
__rtw89_ops_remove_iface_link(rtwdev, rtwvif_link);
|
|
|
|
|
2024-11-20 11:40:51 +08:00
|
|
|
rtw89_vif_unset_link(rtwvif, RTW89_VIF_IDLE_LINK_ID);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
bottom:
|
|
|
|
list_del_init(&rtwvif->list);
|
|
|
|
rtw89_core_release_bit_map(rtwdev->hw_port, port);
|
|
|
|
rtw89_release_mac_id(rtwdev, macid);
|
|
|
|
|
2023-05-27 16:29:38 +08:00
|
|
|
rtw89_recalc_lps(rtwdev);
|
2023-04-11 20:48:30 +08:00
|
|
|
rtw89_enter_ips_by_hwflags(rtwdev);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2022-09-22 09:04:31 +08:00
|
|
|
static int rtw89_ops_change_interface(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
enum nl80211_iftype type, bool p2p)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
2022-11-17 16:52:35 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
set_bit(RTW89_FLAG_CHANGING_INTERFACE, rtwdev->flags);
|
2022-09-22 09:04:31 +08:00
|
|
|
|
|
|
|
rtw89_debug(rtwdev, RTW89_DBG_STATE, "change vif %pM (%d)->(%d), p2p (%d)->(%d)\n",
|
|
|
|
vif->addr, vif->type, type, vif->p2p, p2p);
|
|
|
|
|
|
|
|
rtw89_ops_remove_interface(hw, vif);
|
|
|
|
|
|
|
|
vif->type = type;
|
|
|
|
vif->p2p = p2p;
|
|
|
|
|
2022-11-17 16:52:35 +08:00
|
|
|
ret = rtw89_ops_add_interface(hw, vif);
|
|
|
|
if (ret)
|
|
|
|
rtw89_warn(rtwdev, "failed to change interface %d\n", ret);
|
|
|
|
|
|
|
|
clear_bit(RTW89_FLAG_CHANGING_INTERFACE, rtwdev->flags);
|
|
|
|
|
|
|
|
return ret;
|
2022-09-22 09:04:31 +08:00
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
static void rtw89_ops_configure_filter(struct ieee80211_hw *hw,
|
|
|
|
unsigned int changed_flags,
|
|
|
|
unsigned int *new_flags,
|
|
|
|
u64 multicast)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
2023-08-22 20:58:20 +08:00
|
|
|
const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
|
2023-11-29 15:00:45 +08:00
|
|
|
u32 rx_fltr;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
*new_flags &= FIF_ALLMULTI | FIF_OTHER_BSS | FIF_FCSFAIL |
|
2022-01-07 11:42:21 +08:00
|
|
|
FIF_BCN_PRBRESP_PROMISC | FIF_PROBE_REQ;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if (changed_flags & FIF_ALLMULTI) {
|
|
|
|
if (*new_flags & FIF_ALLMULTI)
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_MC;
|
|
|
|
else
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_MC;
|
|
|
|
}
|
|
|
|
if (changed_flags & FIF_FCSFAIL) {
|
|
|
|
if (*new_flags & FIF_FCSFAIL)
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_CRC32_ERR;
|
|
|
|
else
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_CRC32_ERR;
|
|
|
|
}
|
|
|
|
if (changed_flags & FIF_OTHER_BSS) {
|
|
|
|
if (*new_flags & FIF_OTHER_BSS)
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_A1_MATCH;
|
|
|
|
else
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_A1_MATCH;
|
|
|
|
}
|
|
|
|
if (changed_flags & FIF_BCN_PRBRESP_PROMISC) {
|
|
|
|
if (*new_flags & FIF_BCN_PRBRESP_PROMISC) {
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_BCN_CHK_EN;
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_BC;
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_A1_MATCH;
|
|
|
|
} else {
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_BCN_CHK_EN;
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_BC;
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_A1_MATCH;
|
|
|
|
}
|
|
|
|
}
|
2022-01-07 11:42:21 +08:00
|
|
|
if (changed_flags & FIF_PROBE_REQ) {
|
|
|
|
if (*new_flags & FIF_PROBE_REQ) {
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_BC_CAM_MATCH;
|
|
|
|
rtwdev->hal.rx_fltr &= ~B_AX_A_UC_CAM_MATCH;
|
|
|
|
} else {
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_BC_CAM_MATCH;
|
|
|
|
rtwdev->hal.rx_fltr |= B_AX_A_UC_CAM_MATCH;
|
|
|
|
}
|
|
|
|
}
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2023-11-29 15:00:45 +08:00
|
|
|
rx_fltr = rtwdev->hal.rx_fltr;
|
|
|
|
|
|
|
|
/* mac80211 doesn't configure filter when HW scan, driver need to
|
|
|
|
* set by itself. However, during P2P scan might have configure
|
|
|
|
* filter to overwrite filter that HW scan needed, so we need to
|
|
|
|
* check scan and append related filter
|
|
|
|
*/
|
|
|
|
if (rtwdev->scanning) {
|
|
|
|
rx_fltr &= ~B_AX_A_BCN_CHK_EN;
|
|
|
|
rx_fltr &= ~B_AX_A_BC;
|
|
|
|
rx_fltr &= ~B_AX_A_A1_MATCH;
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_write32_mask(rtwdev,
|
2023-08-22 20:58:20 +08:00
|
|
|
rtw89_mac_reg_by_idx(rtwdev, mac->rx_fltr, RTW89_MAC_0),
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
B_AX_RX_FLTR_CFG_MASK,
|
2023-11-29 15:00:45 +08:00
|
|
|
rx_fltr);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
if (!rtwdev->dbcc_en)
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_write32_mask(rtwdev,
|
2023-08-22 20:58:20 +08:00
|
|
|
rtw89_mac_reg_by_idx(rtwdev, mac->rx_fltr, RTW89_MAC_1),
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
B_AX_RX_FLTR_CFG_MASK,
|
2023-11-29 15:00:45 +08:00
|
|
|
rx_fltr);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static const u8 ac_to_fw_idx[IEEE80211_NUM_ACS] = {
|
|
|
|
[IEEE80211_AC_VO] = 3,
|
|
|
|
[IEEE80211_AC_VI] = 2,
|
|
|
|
[IEEE80211_AC_BE] = 0,
|
|
|
|
[IEEE80211_AC_BK] = 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
static u8 rtw89_aifsn_to_aifs(struct rtw89_dev *rtwdev,
|
2024-09-16 13:31:52 +08:00
|
|
|
struct rtw89_vif_link *rtwvif_link, u8 aifsn)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
2023-08-16 16:21:31 +08:00
|
|
|
const struct rtw89_chan *chan = rtw89_chan_get(rtwdev,
|
2024-09-16 13:31:52 +08:00
|
|
|
rtwvif_link->chanctx_idx);
|
2024-09-16 13:31:54 +08:00
|
|
|
struct ieee80211_bss_conf *bss_conf;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
u8 slot_time;
|
|
|
|
u8 sifs;
|
|
|
|
|
2024-09-16 13:31:54 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
bss_conf = rtw89_vif_rcu_dereference_link(rtwvif_link, true);
|
|
|
|
slot_time = bss_conf->use_short_slot ? 9 : 20;
|
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2024-04-30 10:05:15 +08:00
|
|
|
sifs = chan->band_type == RTW89_BAND_2G ? 10 : 16;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
return aifsn * slot_time + sifs;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ____rtw89_conf_tx_edca(struct rtw89_dev *rtwdev,
|
2024-09-16 13:31:52 +08:00
|
|
|
struct rtw89_vif_link *rtwvif_link, u16 ac)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
2024-09-16 13:31:52 +08:00
|
|
|
struct ieee80211_tx_queue_params *params = &rtwvif_link->tx_params[ac];
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
u32 val;
|
|
|
|
u8 ecw_max, ecw_min;
|
|
|
|
u8 aifs;
|
|
|
|
|
|
|
|
/* 2^ecw - 1 = cw; ecw = log2(cw + 1) */
|
|
|
|
ecw_max = ilog2(params->cw_max + 1);
|
|
|
|
ecw_min = ilog2(params->cw_min + 1);
|
2024-09-16 13:31:52 +08:00
|
|
|
aifs = rtw89_aifsn_to_aifs(rtwdev, rtwvif_link, params->aifs);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
val = FIELD_PREP(FW_EDCA_PARAM_TXOPLMT_MSK, params->txop) |
|
|
|
|
FIELD_PREP(FW_EDCA_PARAM_CWMAX_MSK, ecw_max) |
|
|
|
|
FIELD_PREP(FW_EDCA_PARAM_CWMIN_MSK, ecw_min) |
|
|
|
|
FIELD_PREP(FW_EDCA_PARAM_AIFS_MSK, aifs);
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_fw_h2c_set_edca(rtwdev, rtwvif_link, ac_to_fw_idx[ac], val);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2023-10-12 10:14:52 +08:00
|
|
|
#define R_MUEDCA_ACS_PARAM(acs) {R_AX_MUEDCA_ ## acs ## _PARAM_0, \
|
|
|
|
R_BE_MUEDCA_ ## acs ## _PARAM_0}
|
|
|
|
|
|
|
|
static const u32 ac_to_mu_edca_param[IEEE80211_NUM_ACS][RTW89_CHIP_GEN_NUM] = {
|
|
|
|
[IEEE80211_AC_VO] = R_MUEDCA_ACS_PARAM(VO),
|
|
|
|
[IEEE80211_AC_VI] = R_MUEDCA_ACS_PARAM(VI),
|
|
|
|
[IEEE80211_AC_BE] = R_MUEDCA_ACS_PARAM(BE),
|
|
|
|
[IEEE80211_AC_BK] = R_MUEDCA_ACS_PARAM(BK),
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static void ____rtw89_conf_tx_mu_edca(struct rtw89_dev *rtwdev,
|
2024-09-16 13:31:52 +08:00
|
|
|
struct rtw89_vif_link *rtwvif_link, u16 ac)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
2024-09-16 13:31:52 +08:00
|
|
|
struct ieee80211_tx_queue_params *params = &rtwvif_link->tx_params[ac];
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
struct ieee80211_he_mu_edca_param_ac_rec *mu_edca;
|
2023-10-12 10:14:52 +08:00
|
|
|
int gen = rtwdev->chip->chip_gen;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
u8 aifs, aifsn;
|
|
|
|
u16 timer_32us;
|
|
|
|
u32 reg;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
if (!params->mu_edca)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mu_edca = ¶ms->mu_edca_param_rec;
|
|
|
|
aifsn = FIELD_GET(GENMASK(3, 0), mu_edca->aifsn);
|
2024-09-16 13:31:52 +08:00
|
|
|
aifs = aifsn ? rtw89_aifsn_to_aifs(rtwdev, rtwvif_link, aifsn) : 0;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
timer_32us = mu_edca->mu_edca_timer << 8;
|
|
|
|
|
|
|
|
val = FIELD_PREP(B_AX_MUEDCA_BE_PARAM_0_TIMER_MASK, timer_32us) |
|
|
|
|
FIELD_PREP(B_AX_MUEDCA_BE_PARAM_0_CW_MASK, mu_edca->ecw_min_max) |
|
|
|
|
FIELD_PREP(B_AX_MUEDCA_BE_PARAM_0_AIFS_MASK, aifs);
|
2024-09-16 13:31:52 +08:00
|
|
|
reg = rtw89_mac_reg_by_idx(rtwdev, ac_to_mu_edca_param[ac][gen],
|
|
|
|
rtwvif_link->mac_idx);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_write32(rtwdev, reg, val);
|
|
|
|
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_mac_set_hw_muedca_ctrl(rtwdev, rtwvif_link, true);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __rtw89_conf_tx(struct rtw89_dev *rtwdev,
|
2024-09-16 13:31:52 +08:00
|
|
|
struct rtw89_vif_link *rtwvif_link, u16 ac)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
2024-09-16 13:31:52 +08:00
|
|
|
____rtw89_conf_tx_edca(rtwdev, rtwvif_link, ac);
|
|
|
|
____rtw89_conf_tx_mu_edca(rtwdev, rtwvif_link, ac);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_conf_tx(struct rtw89_dev *rtwdev,
|
2024-09-16 13:31:52 +08:00
|
|
|
struct rtw89_vif_link *rtwvif_link)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
u16 ac;
|
|
|
|
|
|
|
|
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
|
2024-09-16 13:31:52 +08:00
|
|
|
__rtw89_conf_tx(rtwdev, rtwvif_link, ac);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:57 +08:00
|
|
|
static int __rtw89_ops_sta_add(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
2024-09-16 13:31:57 +08:00
|
|
|
bool acquire_macid = false;
|
|
|
|
u8 macid;
|
|
|
|
int ret;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (vif->type == NL80211_IFTYPE_STATION && !sta->tdls) {
|
2025-05-05 15:24:35 +08:00
|
|
|
rtwvif->mlo_mode = RTW89_MLO_MODE_MLSR;
|
|
|
|
|
2024-09-16 13:31:57 +08:00
|
|
|
/* for station mode, assign the mac_id from itself */
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
macid = rtw89_vif_get_main_macid(rtwvif);
|
2024-09-16 13:31:57 +08:00
|
|
|
} else {
|
|
|
|
macid = rtw89_acquire_mac_id(rtwdev);
|
|
|
|
if (macid == RTW89_MAX_MAC_ID_NUM)
|
|
|
|
return -ENOSPC;
|
|
|
|
|
|
|
|
acquire_macid = true;
|
|
|
|
}
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_init_sta(rtwdev, rtwvif, rtwsta, macid);
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sta->txq); i++)
|
|
|
|
rtw89_core_txq_init(rtwdev, sta->txq[i]);
|
|
|
|
|
2025-04-28 19:24:56 +08:00
|
|
|
INIT_LIST_HEAD(&rtwsta->dlink_pool);
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
skb_queue_head_init(&rtwsta->roc_queue);
|
2024-11-20 11:40:52 +08:00
|
|
|
bitmap_zero(rtwsta->pairwise_sec_cam_map, RTW89_MAX_SEC_CAM_NUM);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
rtwsta_link = rtw89_sta_set_link(rtwsta, sta->deflink.link_id);
|
|
|
|
if (!rtwsta_link) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
ret = rtw89_core_sta_link_add(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret)
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
goto unset_link;
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
if (vif->type == NL80211_IFTYPE_AP || sta->tdls)
|
|
|
|
rtw89_queue_chanctx_change(rtwdev, RTW89_CHANCTX_REMOTE_STA_CHANGE);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
unset_link:
|
|
|
|
rtw89_sta_unset_link(rtwsta, sta->deflink.link_id);
|
2024-09-16 13:31:57 +08:00
|
|
|
err:
|
|
|
|
if (acquire_macid)
|
|
|
|
rtw89_release_mac_id(rtwdev, macid);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_sta_assoc(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
bool station_mode)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
2024-09-16 13:31:57 +08:00
|
|
|
int ret;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_sta_for_each_link(rtwsta, rtwsta_link, link_id) {
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
2024-09-16 13:31:57 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (station_mode)
|
|
|
|
rtw89_vif_type_mapping(rtwvif_link, true);
|
|
|
|
|
|
|
|
ret = rtw89_core_sta_link_assoc(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
rtwdev->total_sta_assoc++;
|
|
|
|
if (sta->tdls)
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwvif->tdls_peer++;
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_sta_disassoc(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
2024-09-16 13:31:57 +08:00
|
|
|
int ret;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_sta_for_each_link(rtwsta, rtwsta_link, link_id) {
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
|
|
|
ret = rtw89_core_sta_link_disassoc(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2024-09-16 13:31:57 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwsta->disassoc = true;
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
rtwdev->total_sta_assoc--;
|
|
|
|
if (sta->tdls)
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwvif->tdls_peer--;
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_sta_disconnect(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
2024-09-16 13:31:57 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
rtw89_core_free_sta_pending_ba(rtwdev, sta);
|
|
|
|
rtw89_core_free_sta_pending_forbid_ba(rtwdev, sta);
|
|
|
|
rtw89_core_free_sta_pending_roc_tx(rtwdev, sta);
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_sta_for_each_link(rtwsta, rtwsta_link, link_id) {
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
|
|
|
ret = rtw89_core_sta_link_disconnect(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_sta_remove(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
u8 macid = rtw89_sta_get_main_macid(rtwsta);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
2024-09-16 13:31:57 +08:00
|
|
|
int ret;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_sta_for_each_link(rtwsta, rtwsta_link, link_id) {
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
|
|
|
ret = rtw89_core_sta_link_remove(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
rtw89_sta_unset_link(rtwsta, link_id);
|
|
|
|
}
|
2024-09-16 13:31:57 +08:00
|
|
|
|
|
|
|
if (vif->type == NL80211_IFTYPE_AP || sta->tdls) {
|
|
|
|
rtw89_release_mac_id(rtwdev, macid);
|
|
|
|
rtw89_queue_chanctx_change(rtwdev, RTW89_CHANCTX_REMOTE_STA_CHANGE);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
static void rtw89_station_mode_sta_assoc(struct rtw89_dev *rtwdev,
|
2024-05-09 17:06:45 +08:00
|
|
|
struct ieee80211_vif *vif)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct ieee80211_sta *sta;
|
|
|
|
|
|
|
|
if (vif->type != NL80211_IFTYPE_STATION)
|
|
|
|
return;
|
|
|
|
|
2024-05-09 17:06:45 +08:00
|
|
|
sta = ieee80211_find_sta(vif, vif->cfg.ap_addr);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
if (!sta) {
|
|
|
|
rtw89_err(rtwdev, "can't find sta to set sta_assoc state\n");
|
|
|
|
return;
|
|
|
|
}
|
2022-02-07 14:38:56 +08:00
|
|
|
|
2024-09-16 13:31:57 +08:00
|
|
|
__rtw89_ops_sta_assoc(rtwdev, vif, sta, true);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:56 +08:00
|
|
|
static void __rtw89_ops_bss_link_assoc(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_vif_link *rtwvif_link)
|
|
|
|
{
|
|
|
|
rtw89_phy_set_bss_color(rtwdev, rtwvif_link);
|
|
|
|
rtw89_chip_cfg_txpwr_ul_tb_offset(rtwdev, rtwvif_link);
|
|
|
|
rtw89_mac_port_update(rtwdev, rtwvif_link);
|
|
|
|
rtw89_mac_set_he_obss_narrow_bw_ru(rtwdev, rtwvif_link);
|
2025-03-06 10:11:44 +08:00
|
|
|
rtw89_mac_set_he_tb(rtwdev, rtwvif_link);
|
2024-09-16 13:31:56 +08:00
|
|
|
}
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
static void __rtw89_ops_bss_assoc(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif)
|
|
|
|
{
|
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
unsigned int link_id;
|
|
|
|
|
|
|
|
rtw89_vif_for_each_link(rtwvif, rtwvif_link, link_id)
|
|
|
|
__rtw89_ops_bss_link_assoc(rtwdev, rtwvif_link);
|
|
|
|
}
|
|
|
|
|
2024-05-09 17:06:45 +08:00
|
|
|
static void rtw89_ops_vif_cfg_changed(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif, u64 changed)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
if (changed & BSS_CHANGED_ASSOC) {
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
if (vif->cfg.assoc) {
|
2024-05-09 17:06:45 +08:00
|
|
|
rtw89_station_mode_sta_assoc(rtwdev, vif);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
__rtw89_ops_bss_assoc(rtwdev, vif);
|
2023-08-16 16:21:33 +08:00
|
|
|
|
|
|
|
rtw89_queue_chanctx_work(rtwdev);
|
2022-02-25 11:08:50 +08:00
|
|
|
} else {
|
|
|
|
/* Abort ongoing scan if cancel_scan isn't issued
|
|
|
|
* when disconnected by peer
|
|
|
|
*/
|
|
|
|
if (rtwdev->scanning)
|
2024-01-19 16:14:58 +08:00
|
|
|
rtw89_hw_scan_abort(rtwdev, rtwdev->scan_info.scanning_vif);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-05-09 17:06:45 +08:00
|
|
|
if (changed & BSS_CHANGED_PS)
|
|
|
|
rtw89_recalc_lps(rtwdev);
|
|
|
|
|
|
|
|
if (changed & BSS_CHANGED_ARP_FILTER)
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwvif->ip_addr = vif->cfg.arp_addr_list[0];
|
2024-05-09 17:06:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_link_info_changed(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_bss_conf *conf,
|
|
|
|
u64 changed)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2024-05-09 17:06:45 +08:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
2024-05-09 17:06:45 +08:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwvif_link = rtwvif->links[conf->link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, conf->link_id);
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
if (changed & BSS_CHANGED_BSSID) {
|
2024-09-16 13:31:52 +08:00
|
|
|
ether_addr_copy(rtwvif_link->bssid, conf->bssid);
|
|
|
|
rtw89_cam_bssid_changed(rtwdev, rtwvif_link);
|
|
|
|
rtw89_fw_h2c_cam(rtwdev, rtwvif_link, NULL, NULL);
|
|
|
|
WRITE_ONCE(rtwvif_link->sync_bcn_tsf, 0);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2022-01-07 11:42:23 +08:00
|
|
|
if (changed & BSS_CHANGED_BEACON)
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_chip_h2c_update_beacon(rtwdev, rtwvif_link);
|
2022-01-07 11:42:23 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
if (changed & BSS_CHANGED_ERP_SLOT)
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_conf_tx(rtwdev, rtwvif_link);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if (changed & BSS_CHANGED_HE_BSS_COLOR)
|
2024-09-16 13:31:56 +08:00
|
|
|
rtw89_phy_set_bss_color(rtwdev, rtwvif_link);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if (changed & BSS_CHANGED_MU_GROUPS)
|
|
|
|
rtw89_mac_bf_set_gid_table(rtwdev, vif, conf);
|
|
|
|
|
2022-09-22 09:04:35 +08:00
|
|
|
if (changed & BSS_CHANGED_P2P_PS)
|
2024-09-16 13:31:54 +08:00
|
|
|
rtw89_core_update_p2p_ps(rtwdev, rtwvif_link, conf);
|
2022-09-22 09:04:35 +08:00
|
|
|
|
2023-04-11 20:48:28 +08:00
|
|
|
if (changed & BSS_CHANGED_CQM)
|
2024-09-16 13:31:57 +08:00
|
|
|
rtw89_fw_h2c_set_bcn_fltr_cfg(rtwdev, rtwvif_link, true);
|
2023-04-11 20:48:28 +08:00
|
|
|
|
2024-06-26 10:32:37 +08:00
|
|
|
if (changed & BSS_CHANGED_TPE)
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_reg_6ghz_recalc(rtwdev, rtwvif_link, true);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
2022-06-02 15:08:16 +03:00
|
|
|
static int rtw89_ops_start_ap(struct ieee80211_hw *hw,
|
2022-06-29 12:22:24 +03:00
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_bss_conf *link_conf)
|
2022-02-07 14:38:58 +08:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2023-06-02 23:05:52 +08:00
|
|
|
const struct rtw89_chan *chan;
|
wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports
After FW v0.35.46.0, for AP mode, RTL8922A FW supports a new FW feature,
called NOTIFY_AP_INFO, to notify driver information related to AP mode.
And, one function of it is to monitor PS states of remote stations. Once
one of them changes, FW will send a C2H event to tell driver. With this
FW feature, we can declare AP_LINK_PS.
For now, driver still needs to determine if a frame is ps-poll or U-APSD
trigger. So, add the corresponding RX handling in driver, which activates
only when at least one AP is running.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241120034054.13575-2-pkshih@realtek.com
2024-11-20 11:40:49 +08:00
|
|
|
int ret = 0;
|
2022-02-07 14:38:58 +08:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2023-06-02 23:05:52 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwvif_link = rtwvif->links[link_conf->link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, link_conf->link_id);
|
2025-01-22 14:03:08 +08:00
|
|
|
return -ENOLINK;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:52 +08:00
|
|
|
chan = rtw89_chan_get(rtwdev, rtwvif_link->chanctx_idx);
|
2025-01-22 14:03:08 +08:00
|
|
|
if (chan->band_type == RTW89_BAND_6G)
|
2023-06-02 23:05:52 +08:00
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2023-11-29 15:00:46 +08:00
|
|
|
if (rtwdev->scanning)
|
|
|
|
rtw89_hw_scan_abort(rtwdev, rtwdev->scan_info.scanning_vif);
|
|
|
|
|
2024-09-16 13:31:54 +08:00
|
|
|
ether_addr_copy(rtwvif_link->bssid, link_conf->bssid);
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_cam_bssid_changed(rtwdev, rtwvif_link);
|
|
|
|
rtw89_mac_port_update(rtwdev, rtwvif_link);
|
2024-09-16 13:31:57 +08:00
|
|
|
rtw89_chip_h2c_assoc_cmac_tbl(rtwdev, rtwvif_link, NULL);
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_fw_h2c_role_maintain(rtwdev, rtwvif_link, NULL, RTW89_ROLE_TYPE_CHANGE);
|
|
|
|
rtw89_fw_h2c_join_info(rtwdev, rtwvif_link, NULL, true);
|
|
|
|
rtw89_fw_h2c_cam(rtwdev, rtwvif_link, NULL, NULL);
|
|
|
|
rtw89_chip_rfk_channel(rtwdev, rtwvif_link);
|
2023-08-16 16:21:33 +08:00
|
|
|
|
wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports
After FW v0.35.46.0, for AP mode, RTL8922A FW supports a new FW feature,
called NOTIFY_AP_INFO, to notify driver information related to AP mode.
And, one function of it is to monitor PS states of remote stations. Once
one of them changes, FW will send a C2H event to tell driver. With this
FW feature, we can declare AP_LINK_PS.
For now, driver still needs to determine if a frame is ps-poll or U-APSD
trigger. So, add the corresponding RX handling in driver, which activates
only when at least one AP is running.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241120034054.13575-2-pkshih@realtek.com
2024-11-20 11:40:49 +08:00
|
|
|
if (RTW89_CHK_FW_FEATURE(NOTIFY_AP_INFO, &rtwdev->fw)) {
|
|
|
|
ret = rtw89_fw_h2c_ap_info_refcount(rtwdev, true);
|
|
|
|
if (ret)
|
2025-01-22 14:03:08 +08:00
|
|
|
return ret;
|
wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports
After FW v0.35.46.0, for AP mode, RTL8922A FW supports a new FW feature,
called NOTIFY_AP_INFO, to notify driver information related to AP mode.
And, one function of it is to monitor PS states of remote stations. Once
one of them changes, FW will send a C2H event to tell driver. With this
FW feature, we can declare AP_LINK_PS.
For now, driver still needs to determine if a frame is ps-poll or U-APSD
trigger. So, add the corresponding RX handling in driver, which activates
only when at least one AP is running.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241120034054.13575-2-pkshih@realtek.com
2024-11-20 11:40:49 +08:00
|
|
|
}
|
|
|
|
|
2023-08-16 16:21:33 +08:00
|
|
|
rtw89_queue_chanctx_work(rtwdev);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
return 0;
|
2022-02-07 14:38:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static
|
2022-06-02 15:08:16 +03:00
|
|
|
void rtw89_ops_stop_ap(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
|
2022-06-29 12:22:24 +03:00
|
|
|
struct ieee80211_bss_conf *link_conf)
|
2022-02-07 14:38:58 +08:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2022-02-07 14:38:58 +08:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
rtwvif_link = rtwvif->links[link_conf->link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, link_conf->link_id);
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
wifi: rtw89: 8922a: configure AP_LINK_PS if FW supports
After FW v0.35.46.0, for AP mode, RTL8922A FW supports a new FW feature,
called NOTIFY_AP_INFO, to notify driver information related to AP mode.
And, one function of it is to monitor PS states of remote stations. Once
one of them changes, FW will send a C2H event to tell driver. With this
FW feature, we can declare AP_LINK_PS.
For now, driver still needs to determine if a frame is ps-poll or U-APSD
trigger. So, add the corresponding RX handling in driver, which activates
only when at least one AP is running.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241120034054.13575-2-pkshih@realtek.com
2024-11-20 11:40:49 +08:00
|
|
|
if (RTW89_CHK_FW_FEATURE(NOTIFY_AP_INFO, &rtwdev->fw))
|
|
|
|
rtw89_fw_h2c_ap_info_refcount(rtwdev, false);
|
|
|
|
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_mac_stop_ap(rtwdev, rtwvif_link);
|
2024-09-16 13:31:57 +08:00
|
|
|
rtw89_chip_h2c_assoc_cmac_tbl(rtwdev, rtwvif_link, NULL);
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_fw_h2c_join_info(rtwdev, rtwvif_link, NULL, true);
|
2022-02-07 14:38:58 +08:00
|
|
|
}
|
|
|
|
|
2022-01-07 11:42:25 +08:00
|
|
|
static int rtw89_ops_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
|
|
|
|
bool set)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif *rtwvif = rtwsta->rtwvif;
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
unsigned int link_id;
|
2022-01-07 11:42:25 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_vif_for_each_link(rtwvif, rtwvif_link, link_id)
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_work_queue(hw->wiphy, &rtwvif_link->update_beacon_work);
|
2022-01-07 11:42:25 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
static int rtw89_ops_conf_tx(struct ieee80211_hw *hw,
|
2022-06-24 15:40:11 +02:00
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
unsigned int link_id, u16 ac,
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
const struct ieee80211_tx_queue_params *params)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
rtwvif_link = rtwvif->links[link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, link_id);
|
2025-01-22 14:03:08 +08:00
|
|
|
return -ENOLINK;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:52 +08:00
|
|
|
rtwvif_link->tx_params[ac] = *params;
|
|
|
|
__rtw89_conf_tx(rtwdev, rtwvif_link, ac);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
return 0;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_sta_state(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
enum ieee80211_sta_state old_state,
|
|
|
|
enum ieee80211_sta_state new_state)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
|
|
|
if (old_state == IEEE80211_STA_NOTEXIST &&
|
|
|
|
new_state == IEEE80211_STA_NONE)
|
2024-09-16 13:31:57 +08:00
|
|
|
return __rtw89_ops_sta_add(rtwdev, vif, sta);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if (old_state == IEEE80211_STA_AUTH &&
|
|
|
|
new_state == IEEE80211_STA_ASSOC) {
|
2022-06-10 15:26:00 +08:00
|
|
|
if (vif->type == NL80211_IFTYPE_STATION && !sta->tdls)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
return 0; /* defer to bss_info_changed to have vif info */
|
2024-09-16 13:31:57 +08:00
|
|
|
return __rtw89_ops_sta_assoc(rtwdev, vif, sta, false);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (old_state == IEEE80211_STA_ASSOC &&
|
|
|
|
new_state == IEEE80211_STA_AUTH)
|
2024-09-16 13:31:57 +08:00
|
|
|
return __rtw89_ops_sta_disassoc(rtwdev, vif, sta);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if (old_state == IEEE80211_STA_AUTH &&
|
|
|
|
new_state == IEEE80211_STA_NONE)
|
2024-09-16 13:31:57 +08:00
|
|
|
return __rtw89_ops_sta_disconnect(rtwdev, vif, sta);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
if (old_state == IEEE80211_STA_NONE &&
|
|
|
|
new_state == IEEE80211_STA_NOTEXIST)
|
2024-09-16 13:31:57 +08:00
|
|
|
return __rtw89_ops_sta_remove(rtwdev, vif, sta);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_sta_state(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
enum ieee80211_sta_state old_state,
|
|
|
|
enum ieee80211_sta_state new_state)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
return __rtw89_ops_sta_state(hw, vif, sta, old_state, new_state);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
struct ieee80211_key_conf *key)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
2025-01-22 14:03:08 +08:00
|
|
|
int ret;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case SET_KEY:
|
|
|
|
rtw89_btc_ntfy_specific_packet(rtwdev, PACKET_EAPOL_END);
|
|
|
|
ret = rtw89_cam_sec_key_add(rtwdev, vif, sta, key);
|
|
|
|
if (ret && ret != -EOPNOTSUPP) {
|
|
|
|
rtw89_err(rtwdev, "failed to add key to sec cam\n");
|
2025-01-22 14:03:08 +08:00
|
|
|
return ret;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case DISABLE_KEY:
|
|
|
|
rtw89_hci_flush_queues(rtwdev, BIT(rtwdev->hw->queues) - 1,
|
|
|
|
false);
|
|
|
|
rtw89_mac_flush_txq(rtwdev, BIT(rtwdev->hw->queues) - 1, false);
|
|
|
|
ret = rtw89_cam_sec_key_del(rtwdev, vif, sta, key, true);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_err(rtwdev, "failed to remove key from sec cam\n");
|
2025-01-22 14:03:08 +08:00
|
|
|
return ret;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_ampdu_action(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_ampdu_params *params)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct ieee80211_sta *sta = params->sta;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
u16 tid = params->tid;
|
|
|
|
struct ieee80211_txq *txq = sta->txq[tid];
|
|
|
|
struct rtw89_txq *rtwtxq = (struct rtw89_txq *)txq->drv_priv;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(rtwdev->hw->wiphy);
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
switch (params->action) {
|
|
|
|
case IEEE80211_AMPDU_TX_START:
|
|
|
|
return IEEE80211_AMPDU_TX_START_IMMEDIATE;
|
|
|
|
case IEEE80211_AMPDU_TX_STOP_CONT:
|
|
|
|
case IEEE80211_AMPDU_TX_STOP_FLUSH:
|
|
|
|
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
|
|
|
|
clear_bit(RTW89_TXQ_F_AMPDU, &rtwtxq->flags);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
clear_bit(tid, rtwsta->ampdu_map);
|
|
|
|
rtw89_chip_h2c_ampdu_cmac_tbl(rtwdev, rtwvif, rtwsta);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
|
|
|
|
break;
|
|
|
|
case IEEE80211_AMPDU_TX_OPERATIONAL:
|
|
|
|
set_bit(RTW89_TXQ_F_AMPDU, &rtwtxq->flags);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwsta->ampdu_params[tid].agg_num = params->buf_size;
|
|
|
|
rtwsta->ampdu_params[tid].amsdu = params->amsdu;
|
|
|
|
set_bit(tid, rtwsta->ampdu_map);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_chip_h2c_ampdu_cmac_tbl(rtwdev, rtwvif, rtwsta);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
break;
|
|
|
|
case IEEE80211_AMPDU_RX_START:
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_chip_h2c_ba_cam(rtwdev, rtwsta, true, params);
|
2022-01-04 09:20:52 +08:00
|
|
|
break;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
case IEEE80211_AMPDU_RX_STOP:
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_chip_h2c_ba_cam(rtwdev, rtwsta, false, params);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
WARN_ON(1);
|
|
|
|
return -ENOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
static int rtw89_ops_set_rts_threshold(struct ieee80211_hw *hw, int radio_idx,
|
|
|
|
u32 value)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
if (test_bit(RTW89_FLAG_POWERON, rtwdev->flags))
|
2024-09-25 10:01:18 +08:00
|
|
|
rtw89_mac_update_rts_threshold(rtwdev);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_sta_statistics(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
struct station_info *sinfo)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
|
2025-04-28 19:24:56 +08:00
|
|
|
rtwsta_link = rtw89_get_designated_link(rtwsta);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (unlikely(!rtwsta_link))
|
|
|
|
return;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2024-09-16 13:31:53 +08:00
|
|
|
sinfo->txrate = rtwsta_link->ra_report.txrate;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_BITRATE);
|
|
|
|
}
|
|
|
|
|
2022-09-14 11:50:32 +08:00
|
|
|
static
|
|
|
|
void __rtw89_drop_packets(struct rtw89_dev *rtwdev, struct ieee80211_vif *vif)
|
|
|
|
{
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif;
|
2022-09-14 11:50:32 +08:00
|
|
|
|
|
|
|
if (vif) {
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtwvif = vif_to_rtwvif(vif);
|
|
|
|
rtw89_mac_pkt_drop_vif(rtwdev, rtwvif);
|
2022-09-14 11:50:32 +08:00
|
|
|
} else {
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_for_each_rtwvif(rtwdev, rtwvif)
|
|
|
|
rtw89_mac_pkt_drop_vif(rtwdev, rtwvif);
|
2022-09-14 11:50:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
static void rtw89_ops_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
|
|
|
|
u32 queues, bool drop)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_leave_lps(rtwdev);
|
|
|
|
rtw89_hci_flush_queues(rtwdev, queues, drop);
|
2022-09-14 11:50:32 +08:00
|
|
|
|
2023-02-20 15:02:02 +08:00
|
|
|
if (drop && !RTW89_CHK_FW_FEATURE(NO_PACKET_DROP, &rtwdev->fw))
|
2022-09-14 11:50:32 +08:00
|
|
|
__rtw89_drop_packets(rtwdev, vif);
|
|
|
|
else
|
|
|
|
rtw89_mac_flush_txq(rtwdev, queues, drop);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
struct rtw89_iter_bitrate_mask_data {
|
|
|
|
struct rtw89_dev *rtwdev;
|
|
|
|
struct ieee80211_vif *vif;
|
|
|
|
const struct cfg80211_bitrate_mask *mask;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void rtw89_ra_mask_info_update_iter(void *data, struct ieee80211_sta *sta)
|
|
|
|
{
|
|
|
|
struct rtw89_iter_bitrate_mask_data *br_data = data;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_vif *rtwvif = rtwsta->rtwvif;
|
|
|
|
struct ieee80211_vif *vif = rtwvif_to_vif(rtwvif);
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2022-09-22 09:04:32 +08:00
|
|
|
if (vif != br_data->vif || vif->p2p)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
return;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_sta_for_each_link(rtwsta, rtwsta_link, link_id) {
|
|
|
|
rtwsta_link->use_cfg_mask = true;
|
|
|
|
rtwsta_link->mask = *br_data->mask;
|
|
|
|
}
|
|
|
|
|
2024-07-24 13:26:26 +08:00
|
|
|
rtw89_phy_ra_update_sta(br_data->rtwdev, sta, IEEE80211_RC_SUPP_RATES_CHANGED);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ra_mask_info_update(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
const struct cfg80211_bitrate_mask *mask)
|
|
|
|
{
|
|
|
|
struct rtw89_iter_bitrate_mask_data br_data = { .rtwdev = rtwdev,
|
|
|
|
.vif = vif,
|
|
|
|
.mask = mask};
|
|
|
|
|
|
|
|
ieee80211_iterate_stations_atomic(rtwdev->hw, rtw89_ra_mask_info_update_iter,
|
|
|
|
&br_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_set_bitrate_mask(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
const struct cfg80211_bitrate_mask *mask)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
rtw89_phy_rate_pattern_vif(rtwdev, vif, mask);
|
|
|
|
rtw89_ra_mask_info_update(rtwdev, vif, mask);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
2025-06-15 13:53:09 +05:30
|
|
|
int rtw89_ops_set_antenna(struct ieee80211_hw *hw, int radio_idx, u32 tx_ant, u32 rx_ant)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct rtw89_hal *hal = &rtwdev->hal;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2023-04-18 09:28:15 +08:00
|
|
|
if (hal->ant_diversity) {
|
|
|
|
if (tx_ant != rx_ant || hweight32(tx_ant) != 1)
|
|
|
|
return -EINVAL;
|
|
|
|
} else if (rx_ant != hw->wiphy->available_antennas_rx && rx_ant != hal->antenna_rx) {
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
return -EINVAL;
|
2023-04-18 09:28:15 +08:00
|
|
|
}
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
hal->antenna_tx = tx_ant;
|
|
|
|
hal->antenna_rx = rx_ant;
|
2022-09-08 15:41:37 +08:00
|
|
|
hal->tx_path_diversity = false;
|
2023-04-18 09:28:15 +08:00
|
|
|
hal->ant_diversity_fixed = true;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
2025-06-15 13:53:09 +05:30
|
|
|
int rtw89_ops_get_antenna(struct ieee80211_hw *hw, int radio_idx, u32 *tx_ant,
|
|
|
|
u32 *rx_ant)
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct rtw89_hal *hal = &rtwdev->hal;
|
|
|
|
|
|
|
|
*tx_ant = hal->antenna_tx;
|
|
|
|
*rx_ant = hal->antenna_rx;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_sw_scan_start(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
const u8 *mac_addr)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
2025-04-28 19:24:56 +08:00
|
|
|
rtwvif_link = rtw89_get_designated_link(rtwvif);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (unlikely(!rtwvif_link)) {
|
2025-04-28 19:24:56 +08:00
|
|
|
rtw89_err(rtwdev, "sw scan start: find no designated link\n");
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
2025-04-22 09:46:12 +08:00
|
|
|
rtw89_leave_lps(rtwdev);
|
|
|
|
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_core_scan_start(rtwdev, rtwvif_link, mac_addr, false);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_sw_scan_complete(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
2025-04-28 19:24:56 +08:00
|
|
|
rtwvif_link = rtw89_get_designated_link(rtwvif);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (unlikely(!rtwvif_link)) {
|
2025-04-28 19:24:56 +08:00
|
|
|
rtw89_err(rtwdev, "sw scan complete: find no designated link\n");
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
rtw89_core_scan_complete(rtwdev, rtwvif_link, false);
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_reconfig_complete(struct ieee80211_hw *hw,
|
|
|
|
enum ieee80211_reconfig_type reconfig_type)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
|
|
|
if (reconfig_type == IEEE80211_RECONFIG_TYPE_RESTART)
|
|
|
|
rtw89_ser_recfg_done(rtwdev);
|
|
|
|
}
|
|
|
|
|
2022-02-25 11:08:50 +08:00
|
|
|
static int rtw89_ops_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_scan_request *req)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
int ret;
|
2022-02-25 11:08:50 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2022-03-14 15:12:49 +08:00
|
|
|
if (!RTW89_CHK_FW_FEATURE(SCAN_OFFLOAD, &rtwdev->fw))
|
2022-02-25 11:08:50 +08:00
|
|
|
return 1;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
if (rtwdev->scanning || rtwvif->offchan)
|
|
|
|
return -EBUSY;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
2025-04-28 19:24:56 +08:00
|
|
|
rtwvif_link = rtw89_get_designated_link(rtwvif);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (unlikely(!rtwvif_link)) {
|
2025-04-28 19:24:56 +08:00
|
|
|
rtw89_err(rtwdev, "hw scan: find no designated link\n");
|
2025-01-22 14:03:08 +08:00
|
|
|
return -ENOLINK;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
2025-04-22 09:46:12 +08:00
|
|
|
rtw89_leave_lps(rtwdev);
|
|
|
|
rtw89_leave_ips_by_hwflags(rtwdev);
|
|
|
|
|
|
|
|
ret = rtw89_hw_scan_start(rtwdev, rtwvif_link, req);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
ret = rtw89_hw_scan_offload(rtwdev, rtwvif_link, true);
|
2022-02-25 11:08:50 +08:00
|
|
|
if (ret) {
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_hw_scan_abort(rtwdev, rtwvif_link);
|
2022-02-25 11:08:50 +08:00
|
|
|
rtw89_err(rtwdev, "HW scan failed with status: %d\n", ret);
|
|
|
|
}
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
2022-02-25 11:08:50 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_cancel_hw_scan(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2022-02-25 11:08:50 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2022-03-14 15:12:49 +08:00
|
|
|
if (!RTW89_CHK_FW_FEATURE(SCAN_OFFLOAD, &rtwdev->fw))
|
2022-02-25 11:08:50 +08:00
|
|
|
return;
|
|
|
|
|
2025-01-07 19:42:54 +08:00
|
|
|
if (!rtwdev->scanning)
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
2025-01-07 19:42:54 +08:00
|
|
|
|
2025-04-28 19:24:56 +08:00
|
|
|
rtwvif_link = rtw89_get_designated_link(rtwvif);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (unlikely(!rtwvif_link)) {
|
2025-04-28 19:24:56 +08:00
|
|
|
rtw89_err(rtwdev, "cancel hw scan: find no designated link\n");
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
rtw89_hw_scan_abort(rtwdev, rtwvif_link);
|
2022-02-25 11:08:50 +08:00
|
|
|
}
|
|
|
|
|
2022-05-16 08:52:10 +08:00
|
|
|
static void rtw89_ops_sta_rc_update(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
2024-10-07 15:00:54 +03:00
|
|
|
struct ieee80211_link_sta *link_sta,
|
|
|
|
u32 changed)
|
2022-05-16 08:52:10 +08:00
|
|
|
{
|
2024-11-28 13:54:32 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(link_sta->sta);
|
2022-05-16 08:52:10 +08:00
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
2024-11-28 13:54:32 +08:00
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
|
|
|
|
rtwsta_link = rtwsta->links[link_sta->link_id];
|
|
|
|
if (unlikely(!rtwsta_link))
|
|
|
|
return;
|
2022-05-16 08:52:10 +08:00
|
|
|
|
2024-11-28 13:54:32 +08:00
|
|
|
rtw89_phy_ra_update_sta_link(rtwdev, rtwsta_link, changed);
|
2022-05-16 08:52:10 +08:00
|
|
|
}
|
|
|
|
|
2022-08-09 18:49:50 +08:00
|
|
|
static int rtw89_ops_add_chanctx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_chanctx_conf *ctx)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2022-08-09 18:49:50 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
return rtw89_chanctx_ops_add(rtwdev, ctx);
|
2022-08-09 18:49:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_remove_chanctx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_chanctx_conf *ctx)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
2022-08-09 18:49:50 +08:00
|
|
|
rtw89_chanctx_ops_remove(rtwdev, ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_change_chanctx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_chanctx_conf *ctx,
|
|
|
|
u32 changed)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
2022-08-09 18:49:50 +08:00
|
|
|
rtw89_chanctx_ops_change(rtwdev, ctx, changed);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_assign_vif_chanctx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_bss_conf *link_conf,
|
|
|
|
struct ieee80211_chanctx_conf *ctx)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2022-08-09 18:49:50 +08:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
rtwvif_link = rtwvif->links[link_conf->link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, link_conf->link_id);
|
2025-01-22 14:03:08 +08:00
|
|
|
return -ENOLINK;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
}
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
return rtw89_chanctx_ops_assign_vif(rtwdev, rtwvif_link, ctx);
|
2022-08-09 18:49:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_unassign_vif_chanctx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_bss_conf *link_conf,
|
|
|
|
struct ieee80211_chanctx_conf *ctx)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
2022-08-09 18:49:50 +08:00
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
|
|
|
|
rtwvif_link = rtwvif->links[link_conf->link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, link_conf->link_id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-09-16 13:31:52 +08:00
|
|
|
rtw89_chanctx_ops_unassign_vif(rtwdev, rtwvif_link, ctx);
|
2022-08-09 18:49:50 +08:00
|
|
|
}
|
|
|
|
|
2025-06-05 19:42:05 +08:00
|
|
|
static
|
|
|
|
int rtw89_ops_switch_vif_chanctx(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif_chanctx_switch *vifs,
|
|
|
|
int n_vifs,
|
|
|
|
enum ieee80211_chanctx_switch_mode mode)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
bool replace;
|
|
|
|
int ret;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
|
|
|
switch (mode) {
|
|
|
|
case CHANCTX_SWMODE_REASSIGN_VIF:
|
|
|
|
replace = false;
|
|
|
|
break;
|
|
|
|
case CHANCTX_SWMODE_SWAP_CONTEXTS:
|
|
|
|
replace = true;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < n_vifs; i++) {
|
|
|
|
struct ieee80211_vif_chanctx_switch *p = &vifs[i];
|
|
|
|
struct ieee80211_bss_conf *link_conf = p->link_conf;
|
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(p->vif);
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
|
|
|
|
rtwvif_link = rtwvif->links[link_conf->link_id];
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: rtwvif link (link_id %u) is not active\n",
|
|
|
|
__func__, link_conf->link_id);
|
|
|
|
return -ENOLINK;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = rtw89_chanctx_ops_reassign_vif(rtwdev, rtwvif_link,
|
|
|
|
p->old_ctx, p->new_ctx,
|
|
|
|
replace);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_channel_switch_beacon(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct cfg80211_chan_def *chandef)
|
|
|
|
{
|
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(RTW89_MLD_NON_STA_LINK_NUM != 1);
|
|
|
|
|
|
|
|
rtwvif_link = rtw89_vif_get_link_inst(rtwvif, 0);
|
|
|
|
if (unlikely(!rtwvif_link)) {
|
|
|
|
rtw89_err(rtwdev, "chsw bcn: find no link on HW-0\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
wiphy_delayed_work_queue(hw->wiphy, &rtwvif_link->csa_beacon_work, 0);
|
|
|
|
}
|
|
|
|
|
2023-04-11 20:48:30 +08:00
|
|
|
static int rtw89_ops_remain_on_channel(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_channel *chan,
|
|
|
|
int duration,
|
|
|
|
enum ieee80211_roc_type type)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif_safe(vif);
|
|
|
|
struct rtw89_roc *roc = &rtwvif->roc;
|
2023-04-11 20:48:30 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (!rtwvif)
|
2023-04-11 20:48:30 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (roc->state != RTW89_ROC_IDLE) {
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rtwdev->scanning)
|
2024-01-19 16:14:58 +08:00
|
|
|
rtw89_hw_scan_abort(rtwdev, rtwdev->scan_info.scanning_vif);
|
2023-04-11 20:48:30 +08:00
|
|
|
|
|
|
|
if (type == IEEE80211_ROC_TYPE_MGMT_TX)
|
|
|
|
roc->state = RTW89_ROC_MGMT;
|
|
|
|
else
|
|
|
|
roc->state = RTW89_ROC_NORMAL;
|
|
|
|
|
|
|
|
roc->duration = duration;
|
|
|
|
roc->chan = *chan;
|
|
|
|
roc->type = type;
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_roc_start(rtwdev, rtwvif);
|
2023-04-11 20:48:30 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_cancel_remain_on_channel(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif_safe(vif);
|
2023-04-11 20:48:30 +08:00
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
if (!rtwvif)
|
2023-04-11 20:48:30 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_delayed_work_cancel(hw->wiphy, &rtwvif->roc.roc_work);
|
2023-04-11 20:48:30 +08:00
|
|
|
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
rtw89_roc_end(rtwdev, rtwvif);
|
2023-04-11 20:48:30 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-09-12 15:00:14 +08:00
|
|
|
static void rtw89_set_tid_config_iter(void *data, struct ieee80211_sta *sta)
|
|
|
|
{
|
|
|
|
struct cfg80211_tid_config *tid_config = data;
|
wifi: rtw89: tweak driver architecture for impending MLO support
The drv_priv hooked to mac80211 become as below.
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_vif | <---> | rtw89_vif | -------> | rtw89_vif_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_vif_link |
+----------------+
(drv_priv) (instance-0)
+---------------+ +-----------+ +----------------+
| ieee80211_sta | <---> | rtw89_sta | -------> | rtw89_sta_link |
+---------------+ +-----------+ | +----------------+
|
| (instance-1)
| +----------------+
+---> | rtw89_sta_link |
+----------------+
The relation bewteen mac80211 link_id and our link instance is like below.
|\
(link_id) | \
0 -------- | |
1 -------- | | ------ instance-0 (link_id: X) -> work on HW band 0
2 -------- | |
... | | ------ instance-1 (link_id: Y) -> work on HW band 1
14 -------- | |
| /
|/
N.B. For cases of non-MLD connection, we set our link instance-0
active with link_id 0. So, our code flow can be compatible between
non-MLD connection and MLD connection.
Based on above, we tweak entire driver architecture first. But, we don't
dynamically enable multiple links here. That will be handled separately.
Most of the things changed here are changing flows to iterate all active
links and read bss_conf/link_sta data according to target link. And, for
cases of scan, ROC, WOW, we use instance-0 to deal with the request.
There are some things listed below, which work for now but need to extend
before multiple active links.
1. tx path
select suitable link instance among multiple active links
2. rx path
determine rx link by PPDU instead of always link instance-0
3. CAM
apply MLD pairwise key to any active links dynamically
Besides, PS code cannot easily work along with tweaking architecture. With
supporting MLO flag (currently false), we disable PS first and will fix it
by another commit in the following.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20240916053158.47350-8-pkshih@realtek.com
2024-09-16 13:31:58 +08:00
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
struct rtw89_dev *rtwdev = rtwsta->rtwdev;
|
2022-09-12 15:00:14 +08:00
|
|
|
|
|
|
|
rtw89_core_set_tid_config(rtwdev, sta, tid_config);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_set_tid_config(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
struct cfg80211_tid_config *tid_config)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
2022-09-12 15:00:14 +08:00
|
|
|
if (sta)
|
|
|
|
rtw89_core_set_tid_config(rtwdev, sta, tid_config);
|
|
|
|
else
|
|
|
|
ieee80211_iterate_stations_atomic(rtwdev->hw,
|
|
|
|
rtw89_set_tid_config_iter,
|
|
|
|
tid_config);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-11-20 11:40:50 +08:00
|
|
|
static bool rtw89_can_work_on_links(struct rtw89_dev *rtwdev,
|
|
|
|
struct ieee80211_vif *vif, u16 links)
|
|
|
|
{
|
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
u8 w = hweight16(links);
|
|
|
|
|
|
|
|
if (vif->type != NL80211_IFTYPE_STATION &&
|
|
|
|
w > RTW89_MLD_NON_STA_LINK_NUM)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return w <= rtwvif->links_inst_valid_num;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool rtw89_ops_can_activate_links(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
u16 active_links)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2024-11-20 11:40:50 +08:00
|
|
|
|
|
|
|
return rtw89_can_work_on_links(rtwdev, vif, active_links);
|
|
|
|
}
|
|
|
|
|
2024-11-20 11:40:51 +08:00
|
|
|
static void __rtw89_ops_clr_vif_links(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_vif *rtwvif,
|
|
|
|
unsigned long clr_links)
|
|
|
|
{
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
unsigned int link_id;
|
|
|
|
|
|
|
|
for_each_set_bit(link_id, &clr_links, IEEE80211_MLD_MAX_NUM_LINKS) {
|
|
|
|
rtwvif_link = rtwvif->links[link_id];
|
|
|
|
if (unlikely(!rtwvif_link))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
__rtw89_ops_remove_iface_link(rtwdev, rtwvif_link);
|
|
|
|
|
|
|
|
rtw89_vif_unset_link(rtwvif, link_id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_set_vif_links(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_vif *rtwvif,
|
|
|
|
unsigned long set_links)
|
|
|
|
{
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
unsigned int link_id;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
for_each_set_bit(link_id, &set_links, IEEE80211_MLD_MAX_NUM_LINKS) {
|
|
|
|
rtwvif_link = rtw89_vif_set_link(rtwvif, link_id);
|
|
|
|
if (!rtwvif_link)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ret = __rtw89_ops_add_iface_link(rtwdev, rtwvif_link);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_err(rtwdev, "%s: failed to add iface (link id %u)\n",
|
|
|
|
__func__, link_id);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
int rtw89_ops_change_vif_links(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
u16 old_links, u16 new_links,
|
|
|
|
struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS])
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct rtw89_vif *rtwvif = vif_to_rtwvif(vif);
|
|
|
|
unsigned long clr_links = old_links & ~new_links;
|
|
|
|
unsigned long set_links = new_links & ~old_links;
|
|
|
|
bool removing_links = !old_links || clr_links;
|
|
|
|
struct rtw89_link_conf_container *snap;
|
|
|
|
int ret = 0;
|
|
|
|
int i;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2024-11-20 11:40:51 +08:00
|
|
|
|
|
|
|
rtw89_debug(rtwdev, RTW89_DBG_STATE,
|
|
|
|
"%s: old_links (0x%08x) -> new_links (0x%08x)\n",
|
|
|
|
__func__, old_links, new_links);
|
|
|
|
|
|
|
|
if (!rtw89_can_work_on_links(rtwdev, vif, new_links))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (removing_links) {
|
|
|
|
snap = kzalloc(sizeof(*snap), GFP_KERNEL);
|
|
|
|
if (!snap)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(snap->link_conf); i++)
|
|
|
|
snap->link_conf[i] = old[i];
|
|
|
|
|
|
|
|
rcu_assign_pointer(rtwvif->snap_link_confs, snap);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* might depend on @snap; don't change order */
|
|
|
|
rtw89_leave_ips_by_hwflags(rtwdev);
|
|
|
|
|
|
|
|
if (rtwdev->scanning)
|
|
|
|
rtw89_hw_scan_abort(rtwdev, rtwdev->scan_info.scanning_vif);
|
|
|
|
|
|
|
|
if (!old_links)
|
|
|
|
__rtw89_ops_clr_vif_links(rtwdev, rtwvif,
|
|
|
|
BIT(RTW89_VIF_IDLE_LINK_ID));
|
|
|
|
else if (clr_links)
|
|
|
|
__rtw89_ops_clr_vif_links(rtwdev, rtwvif, clr_links);
|
|
|
|
|
|
|
|
if (removing_links) {
|
|
|
|
/* @snap is required if and only if during removing links.
|
|
|
|
* However, it's done here. So, cleanup @snap immediately.
|
|
|
|
*/
|
|
|
|
rcu_assign_pointer(rtwvif->snap_link_confs, NULL);
|
|
|
|
|
|
|
|
/* The pointers in @old will free after this function return,
|
|
|
|
* so synchronously wait for all readers of snap to be done.
|
|
|
|
*/
|
|
|
|
synchronize_rcu();
|
|
|
|
kfree(snap);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (set_links) {
|
|
|
|
ret = __rtw89_ops_set_vif_links(rtwdev, rtwvif, set_links);
|
|
|
|
if (ret)
|
|
|
|
__rtw89_ops_clr_vif_links(rtwdev, rtwvif, set_links);
|
|
|
|
} else if (!new_links) {
|
|
|
|
ret = __rtw89_ops_set_vif_links(rtwdev, rtwvif,
|
|
|
|
BIT(RTW89_VIF_IDLE_LINK_ID));
|
|
|
|
if (ret)
|
|
|
|
__rtw89_ops_clr_vif_links(rtwdev, rtwvif,
|
|
|
|
BIT(RTW89_VIF_IDLE_LINK_ID));
|
|
|
|
}
|
|
|
|
|
|
|
|
rtw89_enter_ips_by_hwflags(rtwdev);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __rtw89_ops_clr_sta_links(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_sta *rtwsta,
|
|
|
|
unsigned long clr_links)
|
|
|
|
{
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
|
|
|
|
|
|
|
for_each_set_bit(link_id, &clr_links, IEEE80211_MLD_MAX_NUM_LINKS) {
|
|
|
|
rtwsta_link = rtwsta->links[link_id];
|
|
|
|
if (unlikely(!rtwsta_link))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
|
|
|
|
|
|
|
rtw89_core_sta_link_disassoc(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
rtw89_core_sta_link_disconnect(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
rtw89_core_sta_link_remove(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
|
|
|
|
rtw89_sta_unset_link(rtwsta, link_id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __rtw89_ops_set_sta_links(struct rtw89_dev *rtwdev,
|
|
|
|
struct rtw89_sta *rtwsta,
|
|
|
|
unsigned long set_links)
|
|
|
|
{
|
|
|
|
struct rtw89_vif_link *rtwvif_link;
|
|
|
|
struct rtw89_sta_link *rtwsta_link;
|
|
|
|
unsigned int link_id;
|
2024-11-20 11:40:52 +08:00
|
|
|
u8 sec_cam_idx;
|
2024-11-20 11:40:51 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
for_each_set_bit(link_id, &set_links, IEEE80211_MLD_MAX_NUM_LINKS) {
|
|
|
|
rtwsta_link = rtw89_sta_set_link(rtwsta, link_id);
|
|
|
|
if (!rtwsta_link)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
rtwvif_link = rtwsta_link->rtwvif_link;
|
|
|
|
|
|
|
|
ret = rtw89_core_sta_link_add(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_err(rtwdev, "%s: failed to add sta (link id %u)\n",
|
|
|
|
__func__, link_id);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
rtw89_vif_type_mapping(rtwvif_link, true);
|
|
|
|
|
|
|
|
ret = rtw89_core_sta_link_assoc(rtwdev, rtwvif_link, rtwsta_link);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_err(rtwdev, "%s: failed to assoc sta (link id %u)\n",
|
|
|
|
__func__, link_id);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
__rtw89_ops_bss_link_assoc(rtwdev, rtwvif_link);
|
2024-11-20 11:40:52 +08:00
|
|
|
|
|
|
|
for_each_set_bit(sec_cam_idx, rtwsta->pairwise_sec_cam_map,
|
|
|
|
RTW89_MAX_SEC_CAM_NUM) {
|
|
|
|
ret = rtw89_cam_attach_link_sec_cam(rtwdev,
|
|
|
|
rtwvif_link,
|
|
|
|
rtwsta_link,
|
|
|
|
sec_cam_idx);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_err(rtwdev,
|
|
|
|
"%s: failed to apply pairwise key (link id %u)\n",
|
|
|
|
__func__, link_id);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2024-11-20 11:40:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static
|
|
|
|
int rtw89_ops_change_sta_links(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct ieee80211_sta *sta,
|
|
|
|
u16 old_links, u16 new_links)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct rtw89_sta *rtwsta = sta_to_rtwsta(sta);
|
|
|
|
unsigned long clr_links = old_links & ~new_links;
|
|
|
|
unsigned long set_links = new_links & ~old_links;
|
|
|
|
int ret = 0;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2024-11-20 11:40:51 +08:00
|
|
|
|
|
|
|
rtw89_debug(rtwdev, RTW89_DBG_STATE,
|
|
|
|
"%s: old_links (0x%08x) -> new_links (0x%08x)\n",
|
|
|
|
__func__, old_links, new_links);
|
|
|
|
|
|
|
|
if (!rtw89_can_work_on_links(rtwdev, vif, new_links))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
rtw89_leave_ps_mode(rtwdev);
|
|
|
|
|
|
|
|
if (clr_links)
|
|
|
|
__rtw89_ops_clr_sta_links(rtwdev, rtwsta, clr_links);
|
|
|
|
|
|
|
|
if (set_links) {
|
|
|
|
ret = __rtw89_ops_set_sta_links(rtwdev, rtwsta, set_links);
|
|
|
|
if (ret)
|
|
|
|
__rtw89_ops_clr_sta_links(rtwdev, rtwsta, set_links);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-10-27 13:27:06 +08:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
static int rtw89_ops_suspend(struct ieee80211_hw *hw,
|
|
|
|
struct cfg80211_wowlan *wowlan)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
int ret;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2025-06-03 18:31:23 +03:00
|
|
|
set_bit(RTW89_FLAG_FORBIDDEN_TRACK_WORK, rtwdev->flags);
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_delayed_work_cancel(hw->wiphy, &rtwdev->track_work);
|
2025-07-01 15:38:39 +08:00
|
|
|
wiphy_delayed_work_cancel(hw->wiphy, &rtwdev->track_ps_work);
|
2022-10-27 13:27:06 +08:00
|
|
|
|
|
|
|
ret = rtw89_wow_suspend(rtwdev, wowlan);
|
|
|
|
if (ret) {
|
|
|
|
rtw89_warn(rtwdev, "failed to suspend for wow %d\n", ret);
|
2025-06-03 18:31:23 +03:00
|
|
|
clear_bit(RTW89_FLAG_FORBIDDEN_TRACK_WORK, rtwdev->flags);
|
2022-10-27 13:27:06 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rtw89_ops_resume(struct ieee80211_hw *hw)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
int ret;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2025-01-22 14:03:08 +08:00
|
|
|
|
2022-10-27 13:27:06 +08:00
|
|
|
ret = rtw89_wow_resume(rtwdev);
|
|
|
|
if (ret)
|
|
|
|
rtw89_warn(rtwdev, "failed to resume for wow %d\n", ret);
|
|
|
|
|
2025-06-03 18:31:23 +03:00
|
|
|
clear_bit(RTW89_FLAG_FORBIDDEN_TRACK_WORK, rtwdev->flags);
|
2025-01-22 14:03:02 +08:00
|
|
|
wiphy_delayed_work_queue(hw->wiphy, &rtwdev->track_work,
|
|
|
|
RTW89_TRACK_WORK_PERIOD);
|
2025-07-01 15:38:39 +08:00
|
|
|
wiphy_delayed_work_queue(hw->wiphy, &rtwdev->track_ps_work,
|
|
|
|
RTW89_TRACK_PS_WORK_PERIOD);
|
2022-10-27 13:27:06 +08:00
|
|
|
|
|
|
|
return ret ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rtw89_ops_set_wakeup(struct ieee80211_hw *hw, bool enabled)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
|
|
|
device_set_wakeup_enable(rtwdev->dev, enabled);
|
|
|
|
}
|
2024-05-02 10:25:00 +08:00
|
|
|
|
|
|
|
static void rtw89_set_rekey_data(struct ieee80211_hw *hw,
|
|
|
|
struct ieee80211_vif *vif,
|
|
|
|
struct cfg80211_gtk_rekey_data *data)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
struct rtw89_wow_param *rtw_wow = &rtwdev->wow;
|
|
|
|
struct rtw89_wow_gtk_info *gtk_info = &rtw_wow->gtk_info;
|
|
|
|
|
2025-01-22 14:03:08 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
|
|
|
|
2024-05-02 10:25:00 +08:00
|
|
|
if (data->kek_len > sizeof(gtk_info->kek) ||
|
|
|
|
data->kck_len > sizeof(gtk_info->kck)) {
|
|
|
|
rtw89_warn(rtwdev, "kek or kck length over fw limit\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(gtk_info->kek, data->kek, data->kek_len);
|
|
|
|
memcpy(gtk_info->kck, data->kck, data->kck_len);
|
|
|
|
}
|
2022-10-27 13:27:06 +08:00
|
|
|
#endif
|
|
|
|
|
2024-07-24 13:26:24 +08:00
|
|
|
static void rtw89_ops_rfkill_poll(struct ieee80211_hw *hw)
|
|
|
|
{
|
|
|
|
struct rtw89_dev *rtwdev = hw->priv;
|
|
|
|
|
2025-01-22 14:03:07 +08:00
|
|
|
lockdep_assert_wiphy(hw->wiphy);
|
2024-07-24 13:26:24 +08:00
|
|
|
|
|
|
|
/* wl_disable GPIO get floating when entering LPS */
|
|
|
|
if (test_bit(RTW89_FLAG_RUNNING, rtwdev->flags))
|
2025-01-22 14:03:08 +08:00
|
|
|
return;
|
2024-07-24 13:26:24 +08:00
|
|
|
|
|
|
|
rtw89_core_rfkill_poll(rtwdev, false);
|
|
|
|
}
|
|
|
|
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
const struct ieee80211_ops rtw89_ops = {
|
|
|
|
.tx = rtw89_ops_tx,
|
|
|
|
.wake_tx_queue = rtw89_ops_wake_tx_queue,
|
|
|
|
.start = rtw89_ops_start,
|
|
|
|
.stop = rtw89_ops_stop,
|
|
|
|
.config = rtw89_ops_config,
|
|
|
|
.add_interface = rtw89_ops_add_interface,
|
2022-09-22 09:04:31 +08:00
|
|
|
.change_interface = rtw89_ops_change_interface,
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
.remove_interface = rtw89_ops_remove_interface,
|
|
|
|
.configure_filter = rtw89_ops_configure_filter,
|
2024-05-09 17:06:45 +08:00
|
|
|
.vif_cfg_changed = rtw89_ops_vif_cfg_changed,
|
|
|
|
.link_info_changed = rtw89_ops_link_info_changed,
|
2022-02-07 14:38:58 +08:00
|
|
|
.start_ap = rtw89_ops_start_ap,
|
|
|
|
.stop_ap = rtw89_ops_stop_ap,
|
2022-01-07 11:42:25 +08:00
|
|
|
.set_tim = rtw89_ops_set_tim,
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
.conf_tx = rtw89_ops_conf_tx,
|
|
|
|
.sta_state = rtw89_ops_sta_state,
|
|
|
|
.set_key = rtw89_ops_set_key,
|
|
|
|
.ampdu_action = rtw89_ops_ampdu_action,
|
|
|
|
.set_rts_threshold = rtw89_ops_set_rts_threshold,
|
|
|
|
.sta_statistics = rtw89_ops_sta_statistics,
|
|
|
|
.flush = rtw89_ops_flush,
|
|
|
|
.set_bitrate_mask = rtw89_ops_set_bitrate_mask,
|
|
|
|
.set_antenna = rtw89_ops_set_antenna,
|
|
|
|
.get_antenna = rtw89_ops_get_antenna,
|
|
|
|
.sw_scan_start = rtw89_ops_sw_scan_start,
|
|
|
|
.sw_scan_complete = rtw89_ops_sw_scan_complete,
|
|
|
|
.reconfig_complete = rtw89_ops_reconfig_complete,
|
2022-02-25 11:08:50 +08:00
|
|
|
.hw_scan = rtw89_ops_hw_scan,
|
|
|
|
.cancel_hw_scan = rtw89_ops_cancel_hw_scan,
|
2022-08-09 18:49:50 +08:00
|
|
|
.add_chanctx = rtw89_ops_add_chanctx,
|
|
|
|
.remove_chanctx = rtw89_ops_remove_chanctx,
|
|
|
|
.change_chanctx = rtw89_ops_change_chanctx,
|
|
|
|
.assign_vif_chanctx = rtw89_ops_assign_vif_chanctx,
|
|
|
|
.unassign_vif_chanctx = rtw89_ops_unassign_vif_chanctx,
|
2025-06-05 19:42:05 +08:00
|
|
|
.switch_vif_chanctx = rtw89_ops_switch_vif_chanctx,
|
|
|
|
.channel_switch_beacon = rtw89_ops_channel_switch_beacon,
|
2023-04-11 20:48:30 +08:00
|
|
|
.remain_on_channel = rtw89_ops_remain_on_channel,
|
|
|
|
.cancel_remain_on_channel = rtw89_ops_cancel_remain_on_channel,
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
.set_sar_specs = rtw89_ops_set_sar_specs,
|
2024-10-07 15:00:54 +03:00
|
|
|
.link_sta_rc_update = rtw89_ops_sta_rc_update,
|
2022-09-12 15:00:14 +08:00
|
|
|
.set_tid_config = rtw89_ops_set_tid_config,
|
2024-11-20 11:40:50 +08:00
|
|
|
.can_activate_links = rtw89_ops_can_activate_links,
|
2024-11-20 11:40:51 +08:00
|
|
|
.change_vif_links = rtw89_ops_change_vif_links,
|
|
|
|
.change_sta_links = rtw89_ops_change_sta_links,
|
2022-10-27 13:27:06 +08:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
.suspend = rtw89_ops_suspend,
|
|
|
|
.resume = rtw89_ops_resume,
|
|
|
|
.set_wakeup = rtw89_ops_set_wakeup,
|
2024-05-02 10:25:00 +08:00
|
|
|
.set_rekey_data = rtw89_set_rekey_data,
|
2022-10-27 13:27:06 +08:00
|
|
|
#endif
|
2024-07-24 13:26:24 +08:00
|
|
|
.rfkill_poll = rtw89_ops_rfkill_poll,
|
rtw89: add Realtek 802.11ax driver
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
2021-10-11 14:47:27 +03:00
|
|
|
};
|
|
|
|
EXPORT_SYMBOL(rtw89_ops);
|