#
f931cce3 |
| 13-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: chan: support MCC on Wi-Fi 7 chips
On Wi-Fi 7 chips, concurrent stuffs are supported by FW MRC series (multi-role concurrent) functions. And, driver has implemented the corresponding SW
wifi: rtw89: chan: support MCC on Wi-Fi 7 chips
On Wi-Fi 7 chips, concurrent stuffs are supported by FW MRC series (multi-role concurrent) functions. And, driver has implemented the corresponding SW handling in patches in front of this one. Now, we extend SW MCC (multi-channel concurrent) flow to work on Wi-Fi 7 chips.
In SW point of view, things look as below.
| SW | | FW func | | | | H2C/C2H | -------------------------------------------- | | ax | | | /----| FW MCC func | | MCC | -- chip --+ | | | \----| FW MRC func | | | be |
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://msgid.link/20240213073514.23796-5-pkshih@realtek.com
show more ...
|
#
162bf67f |
| 06-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: chan: MCC take reconfig into account
During mac80211 reconfig, chanctx ops of multiple channels might not be called in order as normal cases. However, we expect the first active chanctx
wifi: rtw89: chan: MCC take reconfig into account
During mac80211 reconfig, chanctx ops of multiple channels might not be called in order as normal cases. However, we expect the first active chanctx always to be put at our sub entity index 0. So, if it does not, we do a swap there. Besides, reconfig won't allocate a new chanctx object. So, we should reset the reference count when ops add chanctx.
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://msgid.link/20240206030624.23382-7-pkshih@realtek.com
show more ...
|
#
1ae9fbaf |
| 06-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: chan: move handling from add/remove to assign/unassign for MLO
After MLO, we will need to consider not only active chanctx but also active interfaces (roles) to decide entity things. So
wifi: rtw89: chan: move handling from add/remove to assign/unassign for MLO
After MLO, we will need to consider not only active chanctx but also active interfaces (roles) to decide entity things. So in advance, we move handling from chanctx_ops::add/remove to chanctx_ops::assign_vif/unassign_vif. Then, we can recalculate and aware active interfaces' changes.
For now, behavior should not be really different, since active chanctx and active interface are one-to-one mapping before MLO.
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://msgid.link/20240206030624.23382-6-pkshih@realtek.com
show more ...
|
#
d79fa0a6 |
| 06-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: chan: tweak weight recalc ahead before MLO
Originally, we consider weight only based on how many chanctxs that mac80211 sets. However, we need to consider both active chanctxs and activ
wifi: rtw89: chan: tweak weight recalc ahead before MLO
Originally, we consider weight only based on how many chanctxs that mac80211 sets. However, we need to consider both active chanctxs and active interfaces to distinguish MCC (multiple channel concurrent) from impending MLO.
Although the logic of handling is extended, for now, behavior might not be different under current condition.
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://msgid.link/20240206030624.23382-5-pkshih@realtek.com
show more ...
|
#
ab12a3bf |
| 06-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: chan: tweak bitmap recalc ahead before MLO
Originally, we just declared two sub-entity, and according to rolling down mechanism, we ensured that index 0 contained sub-entity as long as
wifi: rtw89: chan: tweak bitmap recalc ahead before MLO
Originally, we just declared two sub-entity, and according to rolling down mechanism, we ensured that index 0 contained sub-entity as long as there are sub-entity. So, we could use for-loop after deciding the last index.
But, we are preparing to expand num of sub-entity for MLO. Then, there won't be just two sub-entity. And, there might be holes between two bits in the bitmap. So, we cannot simply do for-loop as before. Instead, we need to follow the set bits.
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://msgid.link/20240206030624.23382-4-pkshih@realtek.com
show more ...
|
#
4f0beeef |
| 06-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: chan: add sub-entity swap function to cover replacing
Originally, we replaced sub-entity of index 0 with another one in some cases. However, we will need a swap here in following implem
wifi: rtw89: chan: add sub-entity swap function to cover replacing
Originally, we replaced sub-entity of index 0 with another one in some cases. However, we will need a swap here in following implementations. So, we introduce it ahead and change code from replacing to swapping.
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://msgid.link/20240206030624.23382-3-pkshih@realtek.com
show more ...
|
#
188045a8 |
| 06-Feb-2024 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by self
Some of our calculation during concurrent mode depend on last beacon TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and
wifi: rtw89: drop TIMING_BEACON_ONLY and sync beacon TSF by self
Some of our calculation during concurrent mode depend on last beacon TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will be restricted once we declare MLO.
Since we are about to consider the MLO stuffs, so sync beacon TSF by ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY.
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://msgid.link/20240206030624.23382-2-pkshih@realtek.com
show more ...
|
#
bcd1ae78 |
| 08-Jan-2024 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operation
Since coming WiFi 7 and existing chips use different update_beacon() format, add to abstract selection of H2C command.
S
wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operation
Since coming WiFi 7 and existing chips use different update_beacon() format, add to abstract selection of H2C command.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240108091359.67636-1-pkshih@realtek.com
show more ...
|
#
5f499ce6 |
| 21-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: pause/proceed MCC for ROC and HW scan
During (TDMA-based) MCC (multi-channel concurrency), the below two cases might not have a good behavior on channel usage. * ROC (remain on channel)
wifi: rtw89: pause/proceed MCC for ROC and HW scan
During (TDMA-based) MCC (multi-channel concurrency), the below two cases might not have a good behavior on channel usage. * ROC (remain on channel) * HW scan So, we tend to separate them from MCC.
The two cases would expect to operate the channel to which they want. However, during MCC, channels are scheduled by FW MCC state mechanism. So, channels cannot be controlled explicitly. To avoid the two cases from operating wrong channels with chance, we pause MCC (essentially stop FW MCC) once the two cases are coming. And then, we proceed MCC again (essentially restart FW MCC) once the two cases finish.
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/20230921003559.11588-3-pkshih@realtek.com
show more ...
|
#
a4d7c872 |
| 21-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: fix NoA start time when GO is auxiliary
Under TDMA-based MCC (multi-channel concurrency), there are two roles, reference and auxiliary. We arrange MCC timeline based on time domain
wifi: rtw89: mcc: fix NoA start time when GO is auxiliary
Under TDMA-based MCC (multi-channel concurrency), there are two roles, reference and auxiliary. We arrange MCC timeline based on time domain of reference role. Then, we calculate NoA start time according to MCC timeline.
Besides, when MCC runs GO+STA mode, we plan an offset between GO time domain and STA time domain to make their TBTTs have a time gap.
However, if GO is auxiliary role instead of reference role, NoA start time is described by STA time domain instead of GO time domain. To fix this, we apply the offset mentioned above to NoA start time to convert time domain from STA to GO.
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/20230921003559.11588-2-pkshih@realtek.com
show more ...
|
#
9483d8b3 |
| 20-Sep-2023 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: add subband index of primary channel to struct rtw89_chan
The subband index is a hardware value of relationship between primary channel and bandwidth, and it is used by setting channel/
wifi: rtw89: add subband index of primary channel to struct rtw89_chan
The subband index is a hardware value of relationship between primary channel and bandwidth, and it is used by setting channel/bandwidth to specify the primary channel.
Because this index is only needed when bandwidth >= 20 MHz, adjust order of enumerator bandwidth to access offsets array easier. To prevent misuse RTW89_CHANNEL_WIDTH_NUM as size, change it to RTW89_CHANNEL_WIDTH_ORDINARY_NUM that will be the size of array. The enumerator values of bandwidth (before ordinary number) will be also used by upcoming TX power table built in firmware file, so add a comment to remind keeping the order.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230920074322.42898-2-pkshih@realtek.com
show more ...
|
#
97211e02 |
| 08-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: deal with beacon NoA if GO exists
In MCC STA+GO mode, we calculate NoA information and fill it into the beacon of P2P GO. Since NoA uses only 32 bits to describe time things, we ne
wifi: rtw89: mcc: deal with beacon NoA if GO exists
In MCC STA+GO mode, we calculate NoA information and fill it into the beacon of P2P GO. Since NoA uses only 32 bits to describe time things, we need to deal with renewal when TSF[63:32] is carried. We trigger FW to notify that. Then, we can update NoA information for new time period once we get notification from FW.
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/20230908031145.20931-9-pkshih@realtek.com
show more ...
|
#
9ecb40ef |
| 08-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: deal with BT slot change
When receiving request of adjusting BT slot from coex. mechanism, we need to fetch the new BT slot and use the new one to calculate MCC (multi-channel conc
wifi: rtw89: mcc: deal with BT slot change
When receiving request of adjusting BT slot from coex. mechanism, we need to fetch the new BT slot and use the new one to calculate MCC (multi-channel concurrency) pattern. Then, we update the new MCC pattern to FW.
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/20230908031145.20931-8-pkshih@realtek.com
show more ...
|
#
15fe9b73 |
| 08-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: deal with P2P PS change
MCC fills duration limit of a role according to NoA description. If P2P PS changes during MCC, we don't process P2P PS via normal flow. Instead, we re-fill
wifi: rtw89: mcc: deal with P2P PS change
MCC fills duration limit of a role according to NoA description. If P2P PS changes during MCC, we don't process P2P PS via normal flow. Instead, we re-fill duration limit of the role for new NoA description, and then we do MCC update.
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/20230908031145.20931-7-pkshih@realtek.com
show more ...
|
#
5f69aaba |
| 08-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: track beacon offset and update when needed
In MCC STA+GC mode, the offset between TBTTs of remote AP and remote GO might change. If the change is larger than tolerance, we should u
wifi: rtw89: mcc: track beacon offset and update when needed
In MCC STA+GC mode, the offset between TBTTs of remote AP and remote GO might change. If the change is larger than tolerance, we should update MCC after re-calculating parameters for new things. So, we track that in rtw89_track_work() now. And, we add MCC update flow to tell FW either to change durations of roles or to replace entire pattern according to how MCC plans BT slot.
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/20230908031145.20931-6-pkshih@realtek.com
show more ...
|
#
31e415e3 |
| 08-Sep-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: update role bitmap when changed
Each MCC (multi-channel concurrency) role maintains a bitmap of mac IDs. The bitmap is supposed to contain the two points below. * mac ID of itself
wifi: rtw89: mcc: update role bitmap when changed
Each MCC (multi-channel concurrency) role maintains a bitmap of mac IDs. The bitmap is supposed to contain the two points below. * mac ID of itself * mac ID(s) of STA(s) connecting to it Under STA+GC mode, the bitmaps of both roles should not change. However, under STA+GO mode, the bitmap of GO may change due to P2P clients which connect/disconnect to/from it.
FW controls (TDMA-based) MCC things via mac IDs in bitmap of each role. For example, mac IDs are required by FW when it wants to pause role1's TX in role0 slot.
So, to sync between driver and FW, we update the new mac ID bitmap of GO to FW once it's changed.
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/20230908031145.20931-5-pkshih@realtek.com
show more ...
|
#
6fa25e76 |
| 31-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: trigger FW to start/stop MCC
According to Wi-Fi/BT roles' settings, we fill corresponding H2Cs (host to chip packets). Then, following MCC (multi-channel concurrency) pattern, we s
wifi: rtw89: mcc: trigger FW to start/stop MCC
According to Wi-Fi/BT roles' settings, we fill corresponding H2Cs (host to chip packets). Then, following MCC (multi-channel concurrency) pattern, we send these H2Cs as planned. Eventually, the trigger H2Cs will be sent to tell FW to really start/stop MCC.
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/20230831053133.24015-7-pkshih@realtek.com
show more ...
|
#
17aa2c33 |
| 31-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: decide pattern and calculate parameters
After the previous works, we can now expand and display the MCC pattern in more detail, as shown below.
|< MCC
wifi: rtw89: mcc: decide pattern and calculate parameters
After the previous works, we can now expand and display the MCC pattern in more detail, as shown below.
|< MCC interval >| |< duration ref >| (if mid bt) |< duration aux >| (if tail bt) | |<tob ref >|< toa ref>| ... |<tob aux >|< toa aux>| ... | V V tbtt ref tbtt aux |< beacon offset >|
(where tob means `time offset behind` and toa means `time offset ahead`)
There are two key points. 1. decide position of BT slot if MCC pattern needs to handle BT duration. 2. calculate all parameters related to tob and toa in MCC pattern.
For point (1), when BT duration needs to be handled, BT position will rely on beacon offset, either middle or tail. For point (2), to ensure durations of the Wi-Fi roles cover their beacons, we have to calculate tob and toa for them according to their TBTT.
And, there are two strategies to calculate parameters, strict and loose. In strict pattern, all parameters take HW time into account as limitation. But, the strict calculation are not always successful. In loose pattern, it only tries to give positive parameters to reference role and doesn't care much about auxiliary role. If unfortunately auxiliary role gets negative parameters in loose pattern, FW will be notified and then deal with it. So, the loose calculation won't fail. In general, we always try strict pattern cases before using a loose pattern.
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/20230831053133.24015-5-pkshih@realtek.com
show more ...
|
#
7d170464 |
| 31-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: consider and determine BT duration
Before calculating MCC pattern, we have to determine whether to handle BT duration in it or not. The decision will depend on the channels that Wi
wifi: rtw89: mcc: consider and determine BT duration
Before calculating MCC pattern, we have to determine whether to handle BT duration in it or not. The decision will depend on the channels that Wi-Fi roles use. And, we have three cases shown below. 1. non-2GHz + non-2GHz 2. non-2GHz + 2GHz (different band) 3. 2GHz + 2GHz (dual 2GHz)
For case (1), we don't care BT duration in MCC pattern. For case (2), we still don't care BT duration in MCC pattern. Instead, we try to satisfy it by modifying duration of Wi-Fi role on non-2GHz channel. For case (3), we need to modify Wi-Fi durations and also need to handle BT duration in MCC pattern.
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/20230831053133.24015-4-pkshih@realtek.com
show more ...
|
#
4dc25ef1 |
| 31-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: fill fundamental configurations
We determine the fundamental settings shown below.
|< MCC interval >| |< duration ref >|< duration aux
wifi: rtw89: mcc: fill fundamental configurations
We determine the fundamental settings shown below.
|< MCC interval >| |< duration ref >|< duration aux >| | | | | |< beacon offset >| | | V V (tbtt ref) (tbtt aux)
(where `ref` (reference) and `aux` (auxiliary) mean the two MCC roles)
Based on MCC mode (GO+STA or GC+STA), we fill configurations of MCC interval and beacon offset. And, we make sure each MCC role have a basically required duration in the MCC interval.
The beacon offset mentioned above is a parameter for further MCC pattern calculation. If MCC is in GC+STA mode, we will calculate the real beacon offset through TSFs shown in beacons of both MCC roles. Otherwise, we will use a default beacon offset, and make GO sync STA's TSF timer with this offset.
MCC pattern calculation will break down each MCC role's duration in more detail. We will implement it in the following.
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/20230831053133.24015-3-pkshih@realtek.com
show more ...
|
#
b09df09b |
| 31-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: mcc: initialize start flow
We prepare to support TDMA-based MCC (multi-channel concurrency) which allows two kinds of modes below. * P2P GO + normal STA * P2P GC + normal STA
Each mode
wifi: rtw89: mcc: initialize start flow
We prepare to support TDMA-based MCC (multi-channel concurrency) which allows two kinds of modes below. * P2P GO + normal STA * P2P GC + normal STA
Each mode has two vif and two chanctx. Then, each vif binds one separate chanctx and becomes one MCC role. We name the two MCC roles as follows. * MCC role - reference (ref) We calculate the baseline of our TDMA things accodring to its info, e.g. TBTT. In normal case, it will be put at the first slot of TDMA. * MCC role - auxiliary (aux)
MCC state machine will be running in FW eventually, but before that, we have to fill and calculate things that are needed by FW. We fill the information of MCC role according to its vif and its chanctx. Then, we calculate the start time for MCC.
Note that the parameters used in the calculation now is assigned by default rules. The precise parameters for better MCC behavior will be derived in the following.
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/20230831053133.24015-2-pkshih@realtek.com
show more ...
|
#
4843aa37 |
| 16-Aug-2023 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: initialize multi-channel handling
We prepare to deal with multiple channels via new entity modes. * MCC_PREPARE: Transitional mode before MCC * MCC: Multi-Channel Concurrent mode And,
wifi: rtw89: initialize multi-channel handling
We prepare to deal with multiple channels via new entity modes. * MCC_PREPARE: Transitional mode before MCC * MCC: Multi-Channel Concurrent mode And, enum of sub-entity is extended for second channel context.
We add the entry flow of multi-channel handling and the core stuffs for extended index of sub-entity. And, we now deal with the filling of entity channels' info in entity recalc where we know the number of active chanctx. However, the other detail coding of MCC start/stop will be implemented in the following.
Besides, chanctx listener struct is pre-added in chip info. Each component can add callback type in chanctx listener and configure its callback function to react according to chanctx states. We know at least RFK (RF calibration) and BTC (BT coexistence) will require such callbacks.
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/20230816082133.57474-7-pkshih@realtek.com
show more ...
|
#
a0e97ae3 |
| 11-Apr-2023 |
Po-Hao Huang <phhuang@realtek.com> |
wifi: rtw89: add ieee80211::remain_on_channel ops
Add support of remain on channel ops. Since channel context is required to enable multi-channel concurrent(MCC) and the current ROC in mac80211 don'
wifi: rtw89: add ieee80211::remain_on_channel ops
Add support of remain on channel ops. Since channel context is required to enable multi-channel concurrent(MCC) and the current ROC in mac80211 don't support more than 1 channel context, add this to let P2P and other protocols relying on this work as expected. The off-channel duration and cancel timing is purely controlled by upper layers.
Signed-off-by: Po-Hao Huang <phhuang@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/20230411124832.14965-4-pkshih@realtek.com
show more ...
|
#
75ee07b0 |
| 29-Nov-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: link rtw89_vif and chanctx stuffs
First, introduce struct rtw89_sub_entity for chanctx related stuffs. Second, add enum rtw89_sub_entity_idx to rtw89_vif for vif operation to access its
wifi: rtw89: link rtw89_vif and chanctx stuffs
First, introduce struct rtw89_sub_entity for chanctx related stuffs. Second, add enum rtw89_sub_entity_idx to rtw89_vif for vif operation to access its/right chanctx stuffs after future multi-channel support.
Besides, RTW89_SUB_ENTITY_0 is the default chanctx entry throughout driver, i.e. it's used for things which may not have a target chanctx yet. So, we need to ensure that RTW89_SUB_ENTITY_0 is always working. If there is at least one alive chanctx, then one of them must take RTW89_SUB_ENTITY_0. If no alive chanctx, RTW89_SUB_ENTITY_0 will be filled by rtw89_config_default_chandef().
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/20221129083130.45708-7-pkshih@realtek.com
show more ...
|
#
7fc06a07 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: declare support for mac80211 chanctx ops by chip
Some HW features are required if we hook chanctx ops to mac80211. With it, mac80211 would expect the HW-supported variant ops exists on
wifi: rtw89: declare support for mac80211 chanctx ops by chip
Some HW features are required if we hook chanctx ops to mac80211. With it, mac80211 would expect the HW-supported variant ops exists on some behavior, e.g. HW scan. But, HW features may depend on chip's FW or its development. Besides, how many chanctx can be supported also depends on chip design. We can neither decide whether to generally support chanctx ops nor how many chanctx can be supported.
So, support_chanctx_num is added under chip info to deal with this by chip. For now, all chip configure support_chanctx_num as 0. We haven't really hook chanctx ops yet. So, chip can run without mac80211 chanctx as before.
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-13-pkshih@realtek.com
show more ...
|