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, 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, 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, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47 |
|
#
39913cc8 |
| 10-Jun-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: allocate BSSID CAM per TDLS peer
In STA mode, if peer is TDLS. Allocate a BSSID CAM entry with peer's address to match address properly, and then hardware can ACK peer's packets and rec
wifi: rtw89: allocate BSSID CAM per TDLS peer
In STA mode, if peer is TDLS. Allocate a BSSID CAM entry with peer's address to match address properly, and then hardware can ACK peer's packets and receive packets to driver.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-4-pkshih@realtek.com
show more ...
|
#
445b6bc3 |
| 10-Jun-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: separate BSSID CAM operations
Normally, we allocate a BSSID CAM to a vif. By hardware design, we must allocate a BSSID CAM to each TDLS peer, so separate BSSID CAM operations that will
wifi: rtw89: separate BSSID CAM operations
Normally, we allocate a BSSID CAM to a vif. By hardware design, we must allocate a BSSID CAM to each TDLS peer, so separate BSSID CAM operations that will be used by later patches.
This patch doesn't change logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220610072610.27095-3-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39 |
|
#
f276e20b |
| 10-May-2022 |
Johannes Berg <johannes.berg@intel.com> |
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 th
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>
show more ...
|
#
85393ca6 |
| 30-May-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
wifi: rtw89: support MULTI_BSSID and correct BSSID mask of H2C
The BSSID mask of H2C is used to match BSSID of receiving packets. Normally, we set six bits BSSID mask to exactly match BSSID of packe
wifi: rtw89: support MULTI_BSSID and correct BSSID mask of H2C
The BSSID mask of H2C is used to match BSSID of receiving packets. Normally, we set six bits BSSID mask to exactly match BSSID of packets sent by target AP. After we support multiple BSSID, it could connect a nontransmitted BSSID, so we can only match first five bytes of BSSID. That means we could possibly receive other AP's packets if only the last byte of BSSID is different from target AP.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220530112743.106857-1-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34 |
|
#
0a6f299b |
| 12-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: configure security CAM for V1 chip
Add to configure security CAM while mac80211 calls set_key and del_key.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@k
rtw89: configure security CAM for V1 chip
Add to configure security CAM while mac80211 calls set_key and del_key.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413010804.8941-4-pkshih@realtek.com
show more ...
|
#
04b5983e |
| 12-Apr-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add new H2C to configure security CAM via DCTL for V1 chip
DCTL is short for D-MAC control that V1 chip uses this H2C to configure security CAM. Implement the callers in next patch.
Signed-o
rtw89: add new H2C to configure security CAM via DCTL for V1 chip
DCTL is short for D-MAC control that V1 chip uses this H2C to configure security CAM. Implement the callers in next patch.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413010804.8941-3-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30 |
|
#
79a6c9a4 |
| 17-Mar-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: support hardware generate security header
The newer chip will generate security header itself, so don't set IEEE80211_KEY_FLAG_GENERATE_IV in this kind of chip. But, it needs to fill key_inde
rtw89: support hardware generate security header
The newer chip will generate security header itself, so don't set IEEE80211_KEY_FLAG_GENERATE_IV in this kind of chip. But, it needs to fill key_index, PN and 802.11 header length to TX descriptor, and then hardware uses these to generate security header.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220318023214.32411-11-pkshih@realtek.com
show more ...
|
#
a95bd62e |
| 17-Mar-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add chip_info::h2c_desc_size/fill_txdesc_fwcmd to support new chips
8852A and 8852C use different H2C header and size, so add h2c_desc_size to allocate different header size and fill content
rtw89: add chip_info::h2c_desc_size/fill_txdesc_fwcmd to support new chips
8852A and 8852C use different H2C header and size, so add h2c_desc_size to allocate different header size and fill content by fill_txdesc_fwcmd.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220318023214.32411-8-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.29 |
|
#
b169f877 |
| 14-Mar-2022 |
Zong-Zhe Yang <kevin_yang@realtek.com> |
rtw89: ser: fix CAM leaks occurring in L2 reset
The CAM, meaning address CAM and bssid CAM here, will get leaks during SER (system error recover) L2 reset process and ieee80211_restart_hw() which is
rtw89: ser: fix CAM leaks occurring in L2 reset
The CAM, meaning address CAM and bssid CAM here, will get leaks during SER (system error recover) L2 reset process and ieee80211_restart_hw() which is called by L2 reset process eventually.
The normal flow would be like -> add interface (acquire 1) -> enter ips (release 1) -> leave ips (acquire 1) -> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>
The ieee80211_restart_hw() flow (under connection) -> ieee80211 reconfig -> add interface (acquire 1) -> leave ips (acquire 1) -> connection (occupy (A) + 2) <(B) 1 more leak>
Originally, CAM is released before HW restart only if connection is under security. Now, release CAM whatever connection it is to fix leak in (A). OTOH, check if CAM is already valid to avoid acquiring multiple times to fix (B).
Besides, if AP mode, release address CAM of all stations before HW restart.
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/20220314071250.40292-2-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22 |
|
#
2ab856cc |
| 07-Feb-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: add addr_cam field to sta to support AP mode
In AP mode, each connected station needs an entry of address CAM. The address CAM of vif is still needed to assit in AP itself.
For station mode,
rtw89: add addr_cam field to sta to support AP mode
In AP mode, each connected station needs an entry of address CAM. The address CAM of vif is still needed to assit in AP itself.
For station mode, it still uses vif's address CAM.
Add a help macro rtw89_get_addr_cam_of() to get addr_cam from vif or sta for all use cases.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220207063900.43643-3-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16 |
|
#
14f0999d |
| 06-Jan-2022 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: separate {init,deinit}_addr_cam functions
Each stations connected to AP needs to set an address CAM, so don't combine address and BSSID CAM.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
rtw89: separate {init,deinit}_addr_cam functions
Each stations connected to AP needs to set an address CAM, so don't combine address and BSSID CAM.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220107034239.22002-13-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
40822e07 |
| 01-Dec-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: fix sending wrong rtwsta->mac_id to firmware to fill address CAM
With wrong rtwsta->mac_id, it can't send out ack properly when we receive assoc response occasionally. Then, it failed to conn
rtw89: fix sending wrong rtwsta->mac_id to firmware to fill address CAM
With wrong rtwsta->mac_id, it can't send out ack properly when we receive assoc response occasionally. Then, it failed to connect an AP.
The cause is that we store 'sta' and use it somewhere. To correct this, remove the variable and use mac_id in drv_priv of 'sta' or 'vif' passed by mac80211.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211201080607.11211-1-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2 |
|
#
e45a9e62 |
| 10-Nov-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
rtw89: update scan_mac_addr during scanning period
Update scan_mac_addr to address CAM as A1, so hardware can ACK probe response properly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-of
rtw89: update scan_mac_addr during scanning period
Update scan_mac_addr to address CAM as A1, so hardware can ACK probe response properly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211111023706.14154-2-pkshih@realtek.com
show more ...
|
Revision tags: v5.15.1, v5.15, v5.14.14 |
|
#
a04310ed |
| 17-Oct-2021 |
Yang Yingliang <yangyingliang@huawei.com> |
rtw89: fix return value check in rtw89_cam_send_sec_key_cmd()
Fix the return value check which testing the wrong variable in rtw89_cam_send_sec_key_cmd().
Reported-by: Hulk Robot <hulkci@huawei.com
rtw89: fix return value check in rtw89_cam_send_sec_key_cmd()
Fix the return value check which testing the wrong variable in rtw89_cam_send_sec_key_cmd().
Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211018033102.1813058-1-yangyingliang@huawei.com
show more ...
|
Revision tags: v5.14.13, v5.14.12 |
|
#
e3ec7017 |
| 11-Oct-2021 |
Ping-Ke Shih <pkshih@realtek.com> |
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 an
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
show more ...
|