Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46 |
|
#
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 ...
|
Revision tags: v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24 |
|
#
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 ...
|
Revision tags: v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60 |
|
#
84b50f41 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: add skeleton of mac80211 chanctx ops support
Support mac80211 chanctx series ops. Still, currently support single channel. Based on this premise, things should be similar to before. So,
wifi: rtw89: add skeleton of mac80211 chanctx ops support
Support mac80211 chanctx series ops. Still, currently support single channel. Based on this premise, things should be similar to before. So, we haven't dealt with relationship between vif and chanctx in depth. Instead, we leave both ::assign_vif() and ::unassign_vif() as noops for now.
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-12-pkshih@realtek.com
show more ...
|
#
7cf674ff |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: introduce entity mode and its recalculated prototype
After supporting more than one channel, we need entity mode to decide how to set current channel(s) on the sub-entities. This decisi
wifi: rtw89: introduce entity mode and its recalculated prototype
After supporting more than one channel, we need entity mode to decide how to set current channel(s) on the sub-entities. This decision may happen on set_channel() and rtw89_core_set_chip_txpwr().
For now, we support single one channel and use only first HW entry, i.e. RTW89_SUB_ENTITY_0, RTW89_MAC_0, RTW89_PHY_0. Without something unexpected, the entity mode should always be RTW89_ENT_MODE_SCC after recalcated, where SCC means single channel concurrency. So, an assert is added in set_channel() and rtw89_core_set_chip_txpwr().
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-11-pkshih@realtek.com
show more ...
|
#
a88b6cc4 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: initialize entity and configure default chandef
While idle, we need a default chandef to set channel for things, such as scan. Before support of mac80211 chanctx, mac80211 would configu
wifi: rtw89: initialize entity and configure default chandef
While idle, we need a default chandef to set channel for things, such as scan. Before support of mac80211 chanctx, mac80211 would configure a default one on ieee80211_hw::conf::chandef. And we just queried it whenever we did set channel. However, after support of mac80211 chanctx, the flow won't work like before.
Besides, we don't now query chandef from ieee80211_hw::conf::chandef either. So, similar to mac80211 without using chanctx, we configure the default chandef with ieee80211_channel of index 0 in 2GHz.
Although we have not added the support of mac80211 chanctx here, this configuration should be compatible before that. So, we commit this ahead.
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-10-pkshih@realtek.com
show more ...
|
#
494399b2 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
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
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
show more ...
|
#
bb8152b3 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: create rtw89_chan centrally to avoid breakage
Sometimes we need to write current rtw89_chan outside set_channel(), e.g. during HW scan, we adjust it to align FW process through C2H. How
wifi: rtw89: create rtw89_chan centrally to avoid breakage
Sometimes we need to write current rtw89_chan outside set_channel(), e.g. during HW scan, we adjust it to align FW process through C2H. However, we don't have full parameters to fill entire rtw89_chan. And it will breakage if we update only part of current rtw89_chan. That is what we don't want to see because most flows throughout driver treat rtw89_chan as a whole.
So, we divide struct rtw89_chan to basic part and derived part. The basic part contains the parameters which we are always able to know. And the derived part will be calculated by the basic part. Then, a central function, rtw89_chan_create(), is added to deal with this.
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-5-pkshih@realtek.com
show more ...
|
#
cbb145b9 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: re-arrange channel related stuffs under HAL
We are planning to support mac80211 chanctx. To reduce future works, the driver architecture is adjusted first to isolate related things.
Ac
wifi: rtw89: re-arrange channel related stuffs under HAL
We are planning to support mac80211 chanctx. To reduce future works, the driver architecture is adjusted first to isolate related things.
According to chip, our HW may have multiple sub-entities to support multiple mac80211 chanctx. Struct rtw89_chan has been introduced for things about channel/band/subband/... Now introduce struct rtw89_chan_rcd to record difference after assigning new one of struct rtw89_chan.
We will implement and support chanctx with single channel first, i.e. only use entry in RTW89_SUB_ENTITY_0, before handling dual channels.
Our hierarchy in planning will become as the following. DEV -> HAL ---> entity (manage status across sub-entities) -----> sub-entity[*] (support mac80211 chanctx) where each sub-entity contains one struct rtw89_chan.
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-4-pkshih@realtek.com
show more ...
|
#
967439c7 |
| 09-Aug-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
wifi: rtw89: rewrite decision on channel by entity state
We need to invoke the callback of the changed band at the first set_channel() after every power-off. Originally, we forced the channel to be
wifi: rtw89: rewrite decision on channel by entity state
We need to invoke the callback of the changed band at the first set_channel() after every power-off. Originally, we forced the channel to be 0 when doing power-off, and then determined things by comparing channel with 0.
However, deciding on such things by channel might be confusing. It's also confusing to use this kind of decision when we consider multiple channels in the follow-up patches. So, another flag, entity_active, is added ahead to HAL to deal with this.
Besides, we also need to check if entity is active when we set TX power.
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-2-pkshih@realtek.com
show more ...
|