summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2023-04-14net/mlx5: DR, Enable patterns and arguments for supporting devicesYevgeny Kliteynik
Check if patterns and arguments for modify header action are supported and enable them accordingly. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add support for the pattern/arg parameters in debug dumpYevgeny Kliteynik
Support the pattern/args-based MODIFY_HDR and TNL_L3_TO_L2 actions in dbg dump Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Modify header action of size 1 optimizationYevgeny Kliteynik
Set modify header action of size 1 directly on the STE for supporting devices, thus reducing number of hops and cache misses. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Support decap L3 action using pattern / arg mechanismYevgeny Kliteynik
Use the new accelerated action for decap L3 on RX side: use the mechanism of pattern and argument same as in modify-header action. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Apply new accelerated modify action and decapl3Yevgeny Kliteynik
If there is support for pattern/args, use the new accelerated modify header action for modify header and decap L3 actions. Otherwise fall back to the old modify-header implementation. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add modify header argument pointer to actions attributesYevgeny Kliteynik
While building the actions, add the pointer of the arguments for accelerated modify list action into the action's attributes. This will be used later on while building the specific STE for this action. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add modify header arg pool mechanismYevgeny Kliteynik
Added new mechanism for handling arguments for modify-header action. The new action "accelerated modify-header" asks for the arguments from separated area from the pattern, this area accessed via general objects. Handling of these object is done via the pool-manager struct. When the new header patterns are supported, while loading the domain, a few pools for argument creations will be created. The requests for allocating/deallocating arg objects are done via the pool manager API. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Fix QP continuous allocationYevgeny Kliteynik
When allocating a QP we allocate an RQ and an SQ, the RQ is stored first in memory and followed by the SQ. This allocation is not physically continiuos - it may span across different physical pages. SW Steering code always writes in pairs: 1BB write + 1BB read, or 2 continuous BBs of GTA WQE. This lead to an issue where RQ allocation was 4x16 which is equal to 1 WQE BB, causing 1 BB offset in the page and splitting the GTA WQE between different physical pages. The solution was to create the RQ with a even number of BBs and to have the RQ aligned to a page. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Read ICM memory into dedicated bufferYevgeny Kliteynik
Instead of using the write buffer for reading we will use a dedicated buffer only for reading ICM memory. Due to the new support for args, we can have a case with pending_wc being odd number, and with reading into the same write buffer, it is possible to overwrite next write on the same slot. For example: pending_wc is 17 so the buffer for write is: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | and we have requests as follows: r wr wr wr wr wr wr wr wr Now, the first read will be written into the last write because we use the same buffer for read and write, before it was written to the HW and we will have a wrong data in the ICM area. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add support for writing modify header argumentYevgeny Kliteynik
The accelerated modify header arguments are written in the HW area with special WQE and specific data format. New function was added to support writing of new argument type. Note that GTA WQE is larger than READ and WRITE, so the queue management logic was updated to support this. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add create/destroy for modify-header-argument general objectYevgeny Kliteynik
Add functions for creation/destruction of the new type of general object. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Check for modify_header_argument device capabilitiesYevgeny Kliteynik
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Split chunk allocation to HW-dependent waysYevgeny Kliteynik
This way we are able to allocate chunk for modify_headers from 2 types: STEv0 that is allocated from the action area, and STEv1 that is allocating the chunks from the special area for patterns. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add cache for modify header patternYevgeny Kliteynik
Starting with ConnectX-6 Dx, we use new design of modify_header FW object. The current modify_header object allows for having only limited number of FW objects, so the new design of pattern and argument allows pattern reuse, saving memory, and having a large number of modify_header objects. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Move ACTION_CACHE_LINE_SIZE macro to headerYevgeny Kliteynik
Move ACTION_CACHE_LINE_SIZE macro to header to be used by the pattern functions as well. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14Merge back Intel thermal control material for 6.4-rc1.Rafael J. Wysocki
2023-04-14Merge tag 'qcom-drivers-for-6.4' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers Qualcomm driver updates for v6.4 The Qualcomm SCM driver will now always clear the download bit, avoiding entering download mode on a clean reboot because the bootloader left it set. The vmid bitmap passed to qcom_scm_assign_mem() is transitioned to a well defined size. SM6375 support is added, and SC8180X, QDU1000/QRU1000, IPQ5332 and IPQ9574 compatibles are documented. GENI gains support for newer hardware with deeper FIFOs. The BWMON driver is updated to better handle the two register blocks, which are not consistent between MSM8998 and newer platforms. The LLCC driver no longer assumes a fixes stride across the various banks, and instead acquire the bank placement from DeviceTree. EDAC support for polling is introduced. EDAC support on SDM845 is disabled, as its been observed that accessing relevant registers is not permitted on most devices. PMIC GLINK is reworked to support defining which auxiliary children to spawn per platform, support for spawning a UCSI child is added and SM8450 and SM8550 is introduced. The RPM power-domain driver is cleaned up by moving and generalizing structures that are common between platforms, rather than duplicating everything. Macros are replaced with just direct definition of the relevant structures. Support for defining parent relationships between the power-domains is introduced, like it has been in rpmhpd for a long time. Number of processors has gone up, so max processor count in SMEM is bumped again. Error handling in SMSM is cleaned up using dev_err_probe(). Socinfo is taught about IPQ9574, QCM2290, QRB2210, QRB4210, SM7150, SA8775P and a number of PMICs. * tag 'qcom-drivers-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (51 commits) dt-bindings: firmware: document Qualcomm SC8180X SCM dt-bindings: sram: qcom,imem: document SM6375 IMEM soc: qcom: icc-bwmon: Handle global registers correctly soc: qcom: icc-bwmon: Remove unused struct member soc: qcom: smsm: Use dev_err_probe() firmware: qcom_scm: Add SM6375 compatible soc: qcom: llcc: Add configuration data for SM7150 dt-bindings: arm: msm: Add LLCC for SM7150 dt-bindings: soc: qcom: smd-rpm: re-add missing qcom,rpm-msm8994 soc: qcom: pmic_glink: register ucsi aux device dt-bindings: soc: qcom: qcom,pmic-glink: document SM8550 compatible dt-bindings: soc: qcom: qcom,pmic-glink: document SM8450 compatible firmware: qcom_scm: Clear download bit during reboot dt-bindings: soc: qcom: aoss: Document QDU1000/QRU1000 compatible dt-bindings: firmware: qcom,scm: Update QDU1000/QRU1000 compatible dt-bindings: soc: qcom: smd-rpm: Add IPQ9574 compatible firmware: qcom_scm: Use fixed width src vm bitmap dt-bindings: firmware: qcom,scm: document IPQ5332 SCM dt-bindings: scm: Add compatible for IPQ9574 soc: qcom: rpmpd: Remove useless comments ... Link: https://lore.kernel.org/r/20230410152421.4477-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-04-14wifi: rtl8xxxu: Support devices with 5-6 out endpointsBitterblue Smith
Handle them the same way as the devices with 3-4 USB out endpoints. This is needed for the RTL8192FU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/ef4bc66d-84f5-4021-efd7-1787d097519c@gmail.com
2023-04-14wifi: rtl8xxxu: Clean up some messy ifsBitterblue Smith
Add some new members to rtl8xxxu_fileops and use them instead of checking priv->rtl_chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/e24a5534-6e33-cfb9-0634-0caf4646513f@gmail.com
2023-04-14wifi: brcmfmac: add Cypress 43439 SDIO idsMarek Vasut
Add SDIO ids for use with the muRata 1YN (Cypress CYW43439). The odd thing about this is that the previous 1YN populated on M.2 card for evaluation purposes had BRCM SDIO vendor ID, while the chip populated on real hardware has a Cypress one. The device ID also differs between the two devices. But they are both 43439 otherwise, so add the IDs for both. On-device 1YN (43439), the new one, chip label reads "1YN": ``` /sys/.../mmc_host/mmc2/mmc2:0001 # cat vendor device 0x04b4 0xbd3d ``` EA M.2 evaluation board 1YN (43439), the old one, chip label reads "1YN ES1.4": ``` /sys/.../mmc_host/mmc0/mmc0:0001/# cat vendor device 0x02d0 0xa9a6 ``` Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230407203752.128539-1-marex@denx.de
2023-04-14wifi: rtw89: fix crash due to null pointer of sta in AP modePing-Ke Shih
In AP mode, 'sta' could be NULL if sending broadcast/multicast packets, so we should check before accessing, or it causes crash: BUG: kernel NULL pointer dereference, address: 0000000000000004 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 92 Comm: kworker/u33:0 Tainted: G OE Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core] RIP: 0010:rtw89_core_tx_update_desc_info+0x2cc/0x7d0 [rtw89_core] Code: e2 01 41 be 04 00 00 00 41 8b 84 c4 0c 01 00 00 75 0d 45 31 f6 ... RSP: 0018:ffffb4cf807afce0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffffb4cf807afd48 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 RBP: ffffb4cf807afd30 R08: ffff9b28c1e59808 R09: ffff9b28c0297100 R10: 00000000052cf7c4 R11: 00000000052cf7c4 R12: ffff9b28c1602040 R13: ffff9b28c07b3000 R14: 0000000000000004 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9b2a73280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000004 CR3: 00000001ca410003 CR4: 00000000000606e0 Call Trace: <TASK> rtw89_core_tx_write+0x7c/0x100 [rtw89_core] rtw89_core_txq_work+0x1b4/0x530 [rtw89_core] process_one_work+0x222/0x3f0 worker_thread+0x50/0x3f0 kthread+0x16b/0x190 ? rescuer_thread+0x3a0/0x3a0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> Fixes: e5307c9cd7ee ("wifi: rtw89: set data lowest rate according to AP supported rate") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230406093009.5869-1-pkshih@realtek.com
2023-04-14wifi: rtw89: correct 5 MHz mask settingEric Huang
Use primary channel index to determine which 5 MHz mask should be enable. This mask is used to prevent noise from channel edge to effect CCA threshold in wide bandwidth (>= 40 MHZ). Fixes: 1b00e9236a71 ("rtw89: 8852c: add set channel of BB part") Fixes: 6b0698984eb0 ("wifi: rtw89: 8852b: add chip_ops::set_channel") Cc: stable@vger.kernel.org Signed-off-by: Eric Huang <echuang@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/20230406072841.8308-1-pkshih@realtek.com
2023-04-14wifi: rtw89: 8851b: add tables for RFKPing-Ke Shih
These tables are used by RF calibrations to assist to configure PHY and RF registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230401142548.55466-4-pkshih@realtek.com
2023-04-14wifi: rtw89: 8851b: add BB and RF tables (2 of 2)Ping-Ke Shih
These tables contain BB and RF parameters that driver will load them into registers. It also contains TX power according to country, band, rate and so on. Increasing thermal can cause TX power degraded, so power tracking tables are defined to compensate TX power. Internal version of these tables: - HALBB_029_106_15 (V17) - HALRF_029_00_089 * Radio A 0x22 * NCTL 0x5 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230401142548.55466-3-pkshih@realtek.com
2023-04-14wifi: rtw89: 8851b: add BB and RF tables (1 of 2)Ping-Ke Shih
These tables contain BB and RF parameters that driver will load them into registers. It also contains TX power according to country, band, rate and so on. Increasing thermal can cause TX power degraded, so power tracking tables are defined to compensate TX power. Internal version of these tables: - HALBB_029_106_15 (V17) - HALRF_029_00_089 * Radio A 0x22 * NCTL 0x5 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230401142548.55466-2-pkshih@realtek.com
2023-04-14wifi: rtw89: pci: update PCI related settings to support 8851BPing-Ke Shih
Many settings of 8851B are like 8852A or 8852B. Change them to proper settings as hardware design. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230330133324.19538-5-pkshih@realtek.com
2023-04-14wifi: rtw89: mac: update MAC settings to support 8851bPing-Ke Shih
Many settings of 8851B are the same as 8852B or 8852A, like DLE (Data link engine), security engine and so on. Update them according to hardware design. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230330133324.19538-4-pkshih@realtek.com
2023-04-14wifi: rtw89: 8851b: fix TX path to path A for one RF path chipPing-Ke Shih
For two RF paths chips, we normally set path B as main path by default. 8851B has single one RF path, so set TX path to A and set mapping of path B to 0. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230330133324.19538-3-pkshih@realtek.com
2023-04-14wifi: rtw89: read version of analog hardwarePing-Ke Shih
The chip contains digital and analog parts, and each of them has its own version number. This is used by BT coexistence mechanism to make strategy decision for different analog version. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230330133324.19538-2-pkshih@realtek.com
2023-04-14wifi: rtw89: use hardware CFO to improve performanceEric Huang
Turn on hardware CFO (central frequency offset) compensation based on IC capability, and improve digital CFO compensation accuracy by using more fixed points number. Signed-off-by: Eric Huang <echuang@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/20230330132352.13647-1-pkshih@realtek.com
2023-04-14wifi: rtw89: support parameter tables by RFE typeZong-Zhe Yang
One chip can have different RFE (RF front end) types which we will judge at runtime. And, different RFE types may use different RF parameter tables. Though we didn't really meet this case previously, we are going to meet it on upcoming chip RTL8851B. So, this commit handles parameter tables for runtime RFE type. We now encapsulate rtw89_txpwr_rule_<2/5/6>ghz tables into rtw89_rfe_parms. Then, each chip defines its default parameter tables, and if needed, it can configure extra parameter tables by RFE type. Finally we determine runtime parameter tables by RFE type if one is configured. Otherwise, we use the default parameter tables. For now, we just move all settings under default parameter tables. We will configure parameter tables by RFE types in separate commits afterwards. 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/20230330080331.37155-1-pkshih@realtek.com
2023-04-14wifi: rtw89: add firmware format version to backward compatible with older ↵Ping-Ke Shih
drivers In the discuss threads [1] [2], new firmware format break user space because older drivers can't recognize new firmware format. To avoid this, the new format will be named rtw89/rtw8852b_fw-1.bin and only new driver try to load it. Old drivers only load original and understandable firmware rtw89/rtw8852b_fw.bin. More, new driver will be still backward compatible with old firmware, so original firmware can be used by new driver. If there is newer firmware format is introduced, rtw89/rtw8852b_fw-2.bin will be given. The same rules will be applied like above. So, we will have firmware like below in linux-firmware in the future. rtw89/rtw8852b_fw-2.bin rtw89/rtw8852b_fw-1.bin rtw89/rtw8852b_fw.bin After this patch, MODULE_FIRMWARE() of 8852A/B/C become rtw89/rtw8852a_fw.bin rtw89/rtw8852b_fw-1.bin rtw89/rtw8852c_fw.bin [1] https://lore.kernel.org/linux-wireless/df1ce994-3368-a57e-7078-8bdcccf4a1fd@gmail.com/T/#m24cb43be31a762d0ea70bf07f27ae96c59f6931b [2] https://bugzilla.kernel.org/show_bug.cgi?id=217207 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230320130606.20777-4-pkshih@realtek.com
2023-04-14wifi: rtw89: use schedule_work to request firmwarePing-Ke Shih
Since we are going to load more than one firmware and some are not presented or optional, using asynchronous API request_firmware_nowait() will become complicated. Also, we want to use firmware_request_nowarn() to avoid warning messages when loading optional files. So, use schedule_work to be simpler. To abstract loading a firmware or file, define a struct rtw89_fw_req_info containing a struct firmware and a completion to ensure this firmware is loaded completely. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230320130606.20777-3-pkshih@realtek.com
2023-04-14wifi: rtw89: fw: use generic flow to set/check featuresZong-Zhe Yang
In early feature bitmap obtained from rtw89_early_fw_feature_recognize(), the bits needed to check get increased. It's more friendly to work with RTW89_CHK_FW_FEATURE(). So, we concentrate the flow of iterating FW feature configures and calling RTW89_SET_FW_FEATURE() for various uses. And then, we adjust rtw89_early_fw_feature_recognize() for RTW89_CHK_FW_FEATURE(). 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/20230320130606.20777-2-pkshih@realtek.com
2023-04-14wifi: rtw89: fix authentication fail during scanPo-Hao Huang
We used to store operating channel info after associated. However, scan might happen before that. Without switching back to operating channel, authentication or association might fail. Therefore, we switch back to operating channel when the scanning vif's BSSID is non-zero, which implies connected or during attempt to connect. 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-6-pkshih@realtek.com
2023-04-14wifi: rtw89: add flag check for power statePo-Hao Huang
Use POWER_ON flag to make sure power on/off is symmetric. Since both remain_on_channel and hw_scan both alter the power state, this makes sure that we don't enter/leave IPS mode twice. Also, replace IPS related functions with inline function that does similar logic so we can track it more easily. 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-5-pkshih@realtek.com
2023-04-14wifi: rtw89: add ieee80211::remain_on_channel opsPo-Hao Huang
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
2023-04-14wifi: rtw89: add function to wait for completion of TX skbsPo-Hao Huang
Allocate a per-skb completion to track those skbs we are interested in and wait for them to complete transmission with TX status. Normally, the completion object is freed by wait side, but it could be timeout result that complete side should free the object instead. Add a owner field with RCU to determine which side should free the object. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> 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/20230411124832.14965-3-pkshih@realtek.com
2023-04-14wifi: rtw89: 8852c: add beacon filter and CQM supportPo-Hao Huang
Adding this supports beacon filter and connection quality monitor. To make host CPU wake up less, let firmware perform signal monitoring and beacon processing, then notify driver upon signal changes or beacon loss. This feature needs firmware 0.27.56 or newer to support it. 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-2-pkshih@realtek.com
2023-04-14wifi: iwlwifi: mvm: tx: remove misleading if statementJohannes Berg
The if statement here is misleading, we return zero anyway since we just checked the 'ret' variable, simplify the code to remove the condition entirely. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.57c1eb58e655.I1b47a7771cd66306931089c150c6b5b240bdcba5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: Fix setting the rate for non station casesIlan Peer
The setting of the rate used for non station cases did not take into consideration the interface type etc., thus when probe responses are transmitted on P2P Device interface etc. CCK rates were used which is not allowed. Modify the code so the non station case would consider the interface type etc. For HWs/FWs that do not support rate control, preserve the previous behavior, i.e., take the rate from the skb metadata and adjust as needed. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.fa0e4d42205d.Iab4784560c77b965fec070d4d0a1ec84171d94ff@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: validate station properly in flushJohannes Berg
If we have MLO, then the deflink.ap_sta_id cannot be used. However, we can use the new mvmvif->ap_sta pointer for the validation instead. Also don't do it multiple times for different FW instances of the same AP STA (TDLS STAs are only on a single link). Note that this isn't really working right yet since the underlying flush code hasn't been updated yet to know of multiple link STAs. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.7d747df44d65.Ie5392859fab4cfb73c20b49bfee2caadef5fd8ec@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: set STA mask for keys in MLOJohannes Berg
Implement the full STA mask and selecting the correct link for key installation. While at it, catch errors if this function returns a bad zero station mask, rather than waiting for the firmware to crash on it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.cedae2f21829.Iae07b736c3109d085ad5b74ec8282ce45020da39@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: fix ptk_pn memory leakJohannes Berg
If adding a key to firmware fails we leak the allocated ptk_pn. This shouldn't happen in practice, but we should still fix it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.99446ffd02bc.I82a2ad6ec1395f188e0a1677cc619e3fcb1feac9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: make iwl_mvm_mac_ctxt_send_beacon() staticJohannes Berg
We never needed this to be non-static, that was just an artifact of the development process. Make it static. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.3c018c15f948.I87fd1aee288f33312a7206492608002d4e8e213e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: track AP STA pointer and use it for MFPJohannes Berg
Instead of relying on the AP STA ID and dereferencing our firmware -> mac80211 STA array when we really only need the STA, not the per-link information (and might not have it, e.g. for a pairwise key installation where this is relevant), keep track of the AP STA as a pointer to the mac80211 STA, protected by the mutex. Then use it here in the key code instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.7db01b1508de.I88e6d252cdb0a6e4581d7c5fd7cbc037b4fd40ae@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_bufHyunwoo Kim
An integer overflow occurs in the iwl_write_to_user_buf() function, which is called by the iwl_dbgfs_monitor_data_read() function. static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count, void *buf, ssize_t *size, ssize_t *bytes_copied) { int buf_size_left = count - *bytes_copied; buf_size_left = buf_size_left - (buf_size_left % sizeof(u32)); if (*size > buf_size_left) *size = buf_size_left; If the user passes a SIZE_MAX value to the "ssize_t count" parameter, the ssize_t count parameter is assigned to "int buf_size_left". Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a negative number, so "*size" is assigned "buf_size_left" and goes into the third argument of the copy_to_user function, causing a heap overflow. This is not a security vulnerability because iwl_dbgfs_monitor_data_read() is a debugfs operation with 0400 privileges. Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.2d80ace81532.Iecfba549e0e0be21bbb0324675392e42e75bd5ad@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: fw: move memset before early returnTom Rix
Clang static analysis reports this representative issue dbg.c:1455:6: warning: Branch condition evaluates to a garbage value if (!rxf_data.size) ^~~~~~~~~~~~~~ This check depends on iwl_ini_get_rxf_data() to clear rxf_data but the function can return early without doing the clear. So move the memset before the early return. Fixes: cc9b6012d34b ("iwlwifi: yoyo: use hweight_long instead of bit manipulating") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.872a7175f1ff.I33802a77a91998276992b088fbe25f61c87c33ac@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: initialize seq variableTom Rix
Clang static analysis reports this issue d3.c:567:22: warning: The left operand of '>' is a garbage value if (seq.tkip.iv32 > cur_rx_iv32) ~~~~~~~~~~~~~ ^ seq is never initialized. Call ieee80211_get_key_rx_seq() to initialize seq. Fixes: 0419e5e672d6 ("iwlwifi: mvm: d3: separate TKIP data from key iteration") Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.6dd372f84f93.If1f708c90e6424a935b4eba3917dfb7582e0dd0a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-14wifi: iwlwifi: mvm: Fix spelling mistake "Gerenal" -> "General"Colin Ian King
There is a spelling mistake in a IWL_DEBUG_SCAN debug message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230414130637.eac55cbef8f1.I15cc5d3f1489759bf915bfb3cbbb72b67b18f8b6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.34.1) at 2025-07-19 05:56:42 +0000