summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-09-02wifi: rtw89: pci: correct suspend/resume setting for variant chipsChin-Yen Lee
We find that suspend/resume tests cause 8852CE lost, because some pci registers are changed for 8852CE. So, correct them accordingly. Signed-off-by: Chin-Yen Lee <timlee@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/20220819064811.37700-6-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: enable CLK_REQ, ASPM, L1 and L1ss for 8852cChin-Yen Lee
8852CE controls CLKREQ, ASPM L1, L1ss via wifi registers instead, so change them accordingly. Signed-off-by: Chin-Yen Lee <timlee@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/20220819064811.37700-5-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: fix PCI PHY auto adaption by using software restoreChia-Yuan Li
There is chance that PCI PHY auto adaption fail. When first time boot up, software restore the right adaption value and close PHY auto adaption mechanism. Signed-off-by: Chia-Yuan Li <leo.li@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/20220819064811.37700-4-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: set TBTT shift configurationChia-Yuan Li
It is found that 8852ce loses some beacon after enabling deep ps mode. We set TBTT shift to wake up firmware early to open RF/BB for receiving beacon in time. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> 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/20220819064811.37700-3-pkshih@realtek.com
2022-09-02wifi: rtw89: add retry to change power_mode stateChin-Yen Lee
When starting to send heavy traffic in low power mode, driver will call multiple tx wake notify to wake firmware within a short time. In this situation, firmware may miss power mode change request from driver and leads to status error. So we change driver to call power_mode_change at most three times to make sure firmware could get the request. Signed-off-by: Chin-Yen Lee <timlee@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/20220819064811.37700-2-pkshih@realtek.com
2022-09-02wifi: rtw89: correct BA CAM allocationPing-Ke Shih
BA CAM entries are global resource of hardware, so move the bitmap and instances to rtw89_cam_info, and then use link list from rtw89_sta to these instances. To check the allocation, add ba_cam to debugfs: map: mac_id: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 addr_cam: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bssid_cam: 01 00 00 00 00 00 00 00 sec_cam: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ba_cam: 03 00 00 00 00 00 00 00 VIF [0] 94:08:53:8e:ef:21 bssid_cam_idx=0 addr_cam_idx=0 -> bssid_cam_idx=0 sec_cam_bitmap=00 00 00 00 00 00 00 00 STA [0] 38:78:62:8b:cb:c6 addr_cam_idx=0 -> bssid_cam_idx=0 sec_cam_bitmap=00 00 00 00 00 00 00 00 ba_cam tid[6]=0, tid[1]=1 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-4-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: initialize and correct BA CAM contentPing-Ke Shih
The bacam_v1 must do additional initialization, and H2C content of BA CAM is also different. So, correct them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-3-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: declare correct BA CAM numberPing-Ke Shih
8852A has 2 BA CAM entries, but 8852C has 8 entries. Add a field to discriminate their differences. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-2-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: update TX power tables to R49Zong-Zhe Yang
TX power byrate: doesn't change TX power limit: configure values for KCC and UK refine a bit configuration vales TX power limit_ru: configure values for KCC and UK refine a bit configuration values change 6GHz to follow indoor setting configure 6GHz values for ETSI TX power shape: change with TX power limit/limit_ru 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/20220812093116.56791-4-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: update RF radio A/B parameters to R49Ping-Ke Shih
Update 8852c radio A/B parameters from internal HALRF_027_00_071 R49. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220812093116.56791-3-pkshih@realtek.com
2022-09-02wifi: rtw89: TX power limit/limit_ru consider negativeZong-Zhe Yang
Some chips' RF TX power limit/limit_ru tables start to configure some negative values. Fix the setting logic to prevent negative values from polluting fields of others. 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/20220812093116.56791-2-pkshih@realtek.com
2022-09-02rtw89: coex: Update Wi-Fi driver/firmware TDMA cycle report for RTL8852cChing-Te Ku
Because RTL8852c firmware handshake use different structure definition with RTL8852a, so it's necessary to update a version for RTL8852c. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-10-pkshih@realtek.com
2022-09-02rtw89: coex: Add v1 Wi-Fi SCC coexistence policyChing-Te Ku
Because the later firmware had patched some new feature, it can control the Wi-Fi/BT slots more efficiently. This patch enhance it for better Wi-Fi SCC mode performance. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-9-pkshih@realtek.com
2022-09-02rtw89: coex: Move _set_policy to chip_opsChing-Te Ku
Due to the difference of Wi-Fi firmware supported feature, RTL8852C need to defined more policy to enable the features. (Ex: DBCC, Wi-Fi multi-role, TDMA instant and so on) Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-8-pkshih@realtek.com
2022-09-02rtw89: coex: update WL role info v1 for RTL8852C branch usingChing-Te Ku
The H2C format and support feature are different. The newer Wi-Fi firmware and driver branch need to handshake more information like DBCC or P2P connection info. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-7-pkshih@realtek.com
2022-09-02rtw89: coex: Add v1 version TDMA format and parametersChing-Te Ku
RTL8852C use a later version Wi-Fi firmware, there are some parameters need to be defined. These new parameter can avoid some unexpected TDMA mode while Wi-Fi enter/leave lps. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-6-pkshih@realtek.com
2022-09-02rtw89: coex: Define BT B1 slot lengthChing-Te Ku
It is for setting up BT slot max length at BT auto slot mechanism. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-5-pkshih@realtek.com
2022-09-02rtw89: coex: Add logic to parsing rtl8852c firmware type ctrl reportChing-Te Ku
Add a part of logic to parse type of ctrl report from firmware, and remove Bluetooth packet counter count from driver, the feature was moved to firmware at rtl8852c. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-4-pkshih@realtek.com
2022-09-02rtw89: coex: Move Wi-Fi firmware coexistence matching version to chipChing-Te Ku
To configure the different chips with different coexistence version, separated the firmware feature version matching number is necessary. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-3-pkshih@realtek.com
2022-09-02rtw89: coex: update radio state for RTL8852A/RTL8852CChing-Te Ku
Update scoreboard setting to let Bluetooth know Wi-Fi power save state. Signed-off-by: Ching-Te Ku <ku920601@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/20220725023509.43114-2-pkshih@realtek.com
2022-09-02rtw89: 8852c: adjust mactxen delay of mac/phy interfaceChia-Yuan Li
mac_txen time is to inform TMAC tx after rx air end. Modify 8852c value to meet TB SIFS time. Signed-off-by: Chia-Yuan Li <leo.li@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/20220704023453.19935-7-pkshih@realtek.com
2022-09-02rtw89: 8852c: modify PCIE prebkf timeChia-Yuan Li
Prebkf time is to inform generating tx command if remaining backoff time less than this setting value. It might cause SER if generating tx command early in security mode. Signed-off-by: Chia-Yuan Li <leo.li@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/20220704023453.19935-6-pkshih@realtek.com
2022-09-02rtw89: ser: leave lps with mutexZong-Zhe Yang
Calling rtw89_leave_lps() should hold rtwdev::mutex. So, fix it. 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/20220704023453.19935-5-pkshih@realtek.com
2022-09-02rtw89: declare support HE HTC alwaysPing-Ke Shih
Correct ability of HE HTC that both STA and AP mode can support. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-4-pkshih@realtek.com
2022-09-02rtw89: 8852a: update HW setting on BBZong-Zhe Yang
Sometimes, BB might encounter RX problem on OFDM 6M. It's not quite easy to happen, but if it happens, we will keep getting stuck on RX. And, since we cannot properly receive layer 2 ACK, it also casues TX problem, e.g. constantly retrying TX. Eventually, after some time, we would get disconnected due to abnormal behavior. Update break setting and phy status parsing time to make BB get out of stuck state faster. 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/20220704023453.19935-3-pkshih@realtek.com
2022-09-02rtw89: 8852c: disable dma during mac initPo-Hao Huang
Without this patch, our hardware attempts to perform dma while device cpu restarts, and leads to iommu page faults caused by invalid requests. Some platforms show warning messages as below: rtw89_8852ce 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x10000000004 flags=0x0030] 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/20220704023453.19935-2-pkshih@realtek.com
2022-09-02wifi: rtw89: early recognize FW feature to decide if chanctxZong-Zhe Yang
In current flow, FW is asynchronously loaded after alloc_hw(). It defers the decision on FW feature map. It makes things difficult for us to decide whether to hook chanctx ops, which should be decided while alloc_hw() is calling. Still, asynchronous gets its advantages. So, we want to resolve this without dropping them. Based on multi-FW flag, RTW89_MFW_SIG, we can determine runtime FW is multi-FW (MFW) or single FW (SFW). Both of them have a quite small chunk for header at the head. The difference is that MFW doesn't describe version code in its header while SFW does. So, we plan to extend MFW header for version code. After that, in both cases, we can determine FW feature map by just FW header. And, according to the map, we can decide chanctx. So, we call request_partial_firmware_into_buf() to request a quite small chunk before alloc_hw() to get a early FW feature map without affecting things much and only use early map to decide whether to hook chanctx ops. It means that if non-extended MFW is used at runtime, driver just acts without chanctx as before. If extended MFW or SFW, which supports required FW features, is used at runtime, driver can hook chanctx ops to mac80211 if chip has configured support_chanctx_num > 0. Besides, key point for now to support single one chanctx is whether HW scan is supported at runtime. So, we configure all chip's support_chanctx_num to 1, and check if HW scan is supported at runtime via early FW feature map. 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-14-pkshih@realtek.com
2022-09-02wifi: rtw89: declare support for mac80211 chanctx ops by chipZong-Zhe Yang
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
2022-09-02wifi: rtw89: add skeleton of mac80211 chanctx ops supportZong-Zhe Yang
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
2022-09-02wifi: rtw89: introduce entity mode and its recalculated prototypeZong-Zhe Yang
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
2022-09-02wifi: rtw89: initialize entity and configure default chandefZong-Zhe Yang
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
2022-09-02wifi: rtw89: concentrate chandef setting to stack callbackZong-Zhe Yang
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-09-02wifi: rtw89: concentrate parameter control for setting channel callbackZong-Zhe Yang
For future support on multiple channels by multiple sub-entities, we need to manage parameters of each channel instance like rtw89_chan, rtw89_mac_idx, rtw89_phy_idx. So, we adjust related channel callback functions and centrally conrtol these parameters in set_channel(). 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-8-pkshih@realtek.com
2022-09-02wifi: rtw89: rfk: concentrate parameter control while set_channel()Zong-Zhe Yang
For future support on multiple channels, there will be settings of multiple sub-entities that we need to control. We don't want such settings to be scattered all over the place. So, we centrally manage controls of rtw89_phy_idx for RFK in set_channel(). 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-7-pkshih@realtek.com
2022-09-02wifi: rtw89: txpwr: concentrate channel related control to topZong-Zhe Yang
For future support on multiple channels, it would be disturbing if we still allow scattered leaf functions of TX power to query and manage channel related control by themselves. So, query rtw89_chan only on top functions. Then, pass it via functions to make sure that the values coming from the same struct rtw89_chan. Besides, fix rtw8852a_set_txpwr_offset() from rtw8852a_set_txpwr_ctrl() to rtw8852a_set_txpwr(). TX power offset should consider current band, so move it to chip_ops::set_txpwr() which will be called every time that channel is set. 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-6-pkshih@realtek.com
2022-09-02wifi: rtw89: create rtw89_chan centrally to avoid breakageZong-Zhe Yang
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
2022-09-02wifi: rtw89: re-arrange channel related stuffs under HALZong-Zhe Yang
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
2022-09-02wifi: rtw89: introduce rtw89_chan for channel stuffsZong-Zhe Yang
Introduce struct rtw89_chan ahead to encapsulate stuffs from struct rtw89_channel_params. These stuffs have a clone in HAL and are used throughout driver. After multiple channels support, it's expected that each channel instance has a configuration of them. So, we refine them with struct rtw89_chan by precise type first, and will re-arrange HAL by struct rtw89_chan in the following as well. (No logic has 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/20220809104952.61355-3-pkshih@realtek.com
2022-09-02wifi: rtw89: rewrite decision on channel by entity stateZong-Zhe Yang
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
2022-09-02Revert "usb: gadget: udc-xilinx: replace memcpy with memcpy_toio"Greg Kroah-Hartman
This reverts commit 8cb339f1c1f04baede9d54c1e40ac96247a6393b as it throws up a bunch of sparse warnings as reported by the kernel test robot. Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/202209020044.CX2PfZzM-lkp@intel.com Fixes: 8cb339f1c1f0 ("usb: gadget: udc-xilinx: replace memcpy with memcpy_toio") Cc: stable@vger.kernel.org Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Piyush Mehta <piyush.mehta@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-02Merge tag 'soundwire-6.0-fixes' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire into char-misc-linus Vinod writes: "soundwire fixes for v6.0 This contains two fixes to qcom sdw driver which resolve duplicate reset control get and second one fixes device array indices." * tag 'soundwire-6.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: qcom: fix device status array range soundwire: qcom: remove duplicate reset control get
2022-09-01ipv6: tcp: send consistent autoflowlabel in SYN_RECV stateEric Dumazet
This is a followup of commit c67b85558ff2 ("ipv6: tcp: send consistent autoflowlabel in TIME_WAIT state"), but for SYN_RECV state. In some cases, TCP sends a challenge ACK on behalf of a SYN_RECV request. WHen this happens, we want to use the flow label that was used when the prior SYNACK packet was sent, instead of another one. After his patch, following packetdrill passes: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +.2 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7> +0 > (flowlabel 0x11) S. 0:0(0) ack 1 <...> // Test if a challenge ack is properly sent (same flowlabel than prior SYNACK) +.01 < . 4000000000:4000000000(0) ack 1 win 320 +0 > (flowlabel 0x11) . 1:1(0) ack 1 Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20220831203729.458000-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-01Revert "net: phy: meson-gxl: improve link-up behavior"Heiner Kallweit
This reverts commit 2c87c6f9fbddc5b84d67b2fa3f432fcac6d99d93. Meanwhile it turned out that the following commit is the proper workaround for the issue that 2c87c6f9fbdd tries to address. a3a57bf07de2 ("net: stmmac: work around sporadic tx issue on link-up") It's nor clear why the to be reverted commit helped for one user, for others it didn't make a difference. Fixes: 2c87c6f9fbdd ("net: phy: meson-gxl: improve link-up behavior") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8deeeddc-6b71-129b-1918-495a12dc11e3@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-01selftests: net: dsa: symlink the tc_actions.sh testVladimir Oltean
This has been validated on the Ocelot/Felix switch family (NXP LS1028A) and should be relevant to any switch driver that offloads the tc-flower and/or tc-matchall actions trap, drop, accept, mirred, for which DSA has operations. TEST: gact drop and ok (skip_hw) [ OK ] TEST: mirred egress flower redirect (skip_hw) [ OK ] TEST: mirred egress flower mirror (skip_hw) [ OK ] TEST: mirred egress matchall mirror (skip_hw) [ OK ] TEST: mirred_egress_to_ingress (skip_hw) [ OK ] TEST: gact drop and ok (skip_sw) [ OK ] TEST: mirred egress flower redirect (skip_sw) [ OK ] TEST: mirred egress flower mirror (skip_sw) [ OK ] TEST: mirred egress matchall mirror (skip_sw) [ OK ] TEST: trap (skip_sw) [ OK ] TEST: mirred_egress_to_ingress (skip_sw) [ OK ] Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220831170839.931184-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-01netdevsim: remove redundant variable retJinpeng Cui
Return value directly from nsim_dev_reload_create() instead of getting value from redundant variable ret. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Jinpeng Cui <cui.jinpeng2@zte.com.cn> Link: https://lore.kernel.org/r/20220831154329.305372-1-cui.jinpeng2@zte.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-01net: rtnetlink: use netif_oper_up instead of open codeJuhee Kang
The open code is defined as a new helper function(netif_oper_up) on netdev.h, the code is dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN. Thus, replace the open code to netif_oper_up. This patch doesn't change logic. Signed-off-by: Juhee Kang <claudiajkang@gmail.com> Link: https://lore.kernel.org/r/20220831125845.1333-1-claudiajkang@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-01net: sched: etf: remove true check in etf_enable_offload()Zhengchao Shao
etf_enable_offload() is only called when q->offload is false in etf_init(). So remove true check in etf_enable_offload(). Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Link: https://lore.kernel.org/r/20220831092919.146149-1-shaozhengchao@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-02Merge tag 'drm-intel-fixes-2022-09-01' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix for a null pointer dereference (Lukasz) - HDMI related quirk for ECS Liva Q2 with GLK graphics (Diego) - Skip wm/ddb readout for disabled pipes (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YxC3GmSOpDiZTdIJ@intel.com
2022-09-01Merge tag 'kvm-s390-master-6.0-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD PCI interpretation compile fixes
2022-09-01bpf: Only add BTF IDs for socket security hooks when CONFIG_SECURITY_NETWORK ↵Hou Tao
is on When CONFIG_SECURITY_NETWORK is disabled, there will be build warnings from resolve_btfids: WARN: resolve_btfids: unresolved symbol bpf_lsm_socket_socketpair ...... WARN: resolve_btfids: unresolved symbol bpf_lsm_inet_conn_established Fixing it by wrapping these BTF ID definitions by CONFIG_SECURITY_NETWORK. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Fixes: 9113d7e48e91 ("bpf: expose bpf_{g,s}etsockopt to lsm cgroup") Signed-off-by: Hou Tao <houtao1@huawei.com> Link: https://lore.kernel.org/r/20220901065126.3856297-1-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-22 13:08:10 +0000