summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-22wifi: rtl8xxxu: enable MFP support with security flag of RX descriptorMartin Kaistra
In order to connect to networks which require 802.11w, add the MFP_CAPABLE flag and let mac80211 do the actual crypto in software. When a robust management frame is received, rx_dec->swdec is not set, even though the HW did not decrypt it. Extend the check and don't set RX_FLAG_DECRYPTED for these frames in order to use SW decryption. Use the security flag in the RX descriptor for this purpose, like it is done in the rtw88 driver. Cc: stable@vger.kernel.org Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240418071813.1883174-3-martin.kaistra@linutronix.de
2024-04-22Revert "wifi: rtl8xxxu: enable MFP support"Martin Kaistra
This reverts commit 77f5924fc41c243e907c80ce2576902d3a9cb336. There is a more elegant solution to check for not decrypted frames, which is to check the security flag in the RX descriptor. Revert commit 77f5924fc41c ("wifi: rtl8xxxu: enable MFP support") in favor of this to be able to send it to stable. Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240418071813.1883174-2-martin.kaistra@linutronix.de
2024-04-22wifi: rtw88: suppress messages of failed to flush queuePing-Ke Shih
Driver throws messages when scanning with a lot of traffic, because packets in TX buffer can not be transmitted in time. Since this is a common occurrence, change them to debug message with special debug mask that developers can turn on this mask by default for further analysis. Cc: Lewis Robbins <lewis.robbins2@gmail.com> Tested-by: Lewis Robbins <lewis.robbins2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240418002916.5965-1-pkshih@realtek.com
2024-04-22wifi: rtw89: 8922a: fix argument to hal_reset in bb_cfg_txrx_pathZong-Zhe Yang
When hal_reset on MAC_1/PHY_1, we should pass tx_en1 instead of tx_en0. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240417090058.42663-1-pkshih@realtek.com
2024-04-22wifi: rtw89: set WIPHY_FLAG_DISABLE_WEXT before MLOZong-Zhe Yang
We will support MLO on 802.11be chip, e.g. RTL8922A, in the future. At that time being, we will set WIPHY_FLAG_SUPPORTS_MLO according to chip info and FW features at runtime. But, with WIPHY_FLAG_SUPPORTS_MLO flag, cfg80211 will disable WEXT. In case inconsistent user experience, if 802.11be chip, we disable WEXT uniformly from now on. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240417090050.42607-1-pkshih@realtek.com
2024-04-19wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AUBitterblue Smith
Don't subtract 1 from the power index. This was added in commit 2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts") for unknown reasons. The vendor drivers don't do this. Also correct the calculations of values written to REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver, these are used for TX power training. With these changes rtl8xxxu sets the TX power of RTL8192CU the same as the vendor driver. None of this appears to have any effect on my RTL8192CU device. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/6ae5945b-644e-45e4-a78f-4c7d9c987910@gmail.com
2024-04-18wifi: rtw89: regd: handle policy of 6 GHz SP according to BIOSZong-Zhe Yang
According to BIOS configuration of Realtek ACPI DSM function 7, RTW89_ACPI_DSM_FUNC_6GHZ_SP_SUP, we handle the regd policy of 6 GHz SP. If BIOS indicates to override driver settings, we only allow the countries, which are enabled by BIOS, to use 6 GHz SP power. Other countries will be applied to select default power when recalculating 6 GHz regulatory power selection. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-9-pkshih@realtek.com
2024-04-18wifi: rtw89: acpi: process 6 GHz SP policy from ACPI DSMZong-Zhe Yang
Realtek ACPI DSM func 7, RTW89_ACPI_DSM_FUNC_6GHZ_SP_SUP, accepts a format via ACPI buffer as below. | index | description | -------------------------------------------- | [0-3] | signature | | [4] | revision | | [5] | override driver settings, or not | | [6] | configuration if override | | [7] | reserved | where field of [6] is a bitmap by country, and for now, only define BIT(0) is for US. Through this function with overriding, BIOS can indicate to allow/block 6 GHz SP power by country. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-8-pkshih@realtek.com
2024-04-18wifi: rtw89: regd: extend policy of UNII-4 for IC regulatoryZong-Zhe Yang
Originally, we have an ACPI function to determine whether to enable UNII-4. Since IC (Industry Canada) has allowed UNII-4, the ACPI result is extended to be two bits as below. * BIT(0): determine if rtw89_regd::FCC enable UNII-4 * BIT(1): determine if rtw89_regd::IC enable UNII-4 Besides, to take old platforms into account, we enable UNII-4 on IC if and only if BIOS configuration enable it. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-7-pkshih@realtek.com
2024-04-18wifi: rtw89: regd: block 6 GHz by policy if not specific countryZong-Zhe Yang
We allow 6 GHz on target regd if and only if 1. it is a specific country, i.e. not any world-wide cases 2. its 6 GHz is not blocked So, for world-wide cases, their 6 GHz will be blocked now. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-6-pkshih@realtek.com
2024-04-18wifi: rtw89: 8852c: update TX power tables to R69.1 (2 of 2)Zong-Zhe Yang
Deconfigure fields for 6GHz SP. Don't use these set of values until getting certification of 6GHz SP regulation. Without configuring these fields, driver takes world-wide values when 6GHz SP cases. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-5-pkshih@realtek.com
2024-04-18wifi: rtw89: 8852c: update TX power tables to R69.1 (1 of 2)Zong-Zhe Yang
Deconfigure fields for 6GHz SP. Don't use these set of values until getting certification of 6GHz SP regulation. Without configuring these fields, driver takes world-wide values when 6GHz SP cases. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-4-pkshih@realtek.com
2024-04-18wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sbandZong-Zhe Yang
We have some policy via BIOS to block uses of 6 GHz. In this case, 6 GHz sband will be NULL even if it is WiFi 7 chip. So, add NULL handling here to avoid crash. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-3-pkshih@realtek.com
2024-04-18wifi: rtw89: sar: correct TX power boundary for MAC domainZong-Zhe Yang
TX power in MAC domain is signed 7 bits. (unit: based on txpwr_factor_mac) The valid range should be [-64, 63]. While the original wrong bounds might not really be encountered, still make them correct. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240412115729.8316-2-pkshih@realtek.com
2024-04-18wifi: rtw89: pci: correct TX resource checking for PCI DMA channel of ↵Ping-Ke Shih
firmware command The DMA channel of firmware command doesn't use TX WD (WiFi descriptor), so don't need to consider number of TX WD as factor of TX resource. Otherwise, during pause state (a transient state to switch to/from low power mode) firmware commands could be dropped and driver throws warnings suddenly: rtw89_8852ce 0000:04:00.0: no tx fwcmd resource rtw89_8852ce 0000:04:00.0: failed to send h2c The case we met is that driver sends RSSI strength of firmware command at RX path that could be running concurrently with switching low power mode. The missing of this firmware command doesn't affect user experiences, because the RSSI strength will be updated again after a while. The DMA descriptors of normal packets has three layers like: +-------+ | TX BD | (*n elements) +-------+ | | +-------+ +-> | TX WD | (*m elements) +-------+ | | +--------+ +-> | SKB | +--------+ And, firmware command queue (TXCH 12) is a special queue that has only two layers: +-------+ | TX BD | (*n elements) +-------+ | | +------------------+ +-> | firmware command | +------------------+ Fixes: 4a29213cd775 ("wifi: rtw89: pci: correct TX resource checking in low power mode") Cc: stable@vger.kernel.org Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240410011316.9906-1-pkshih@realtek.com
2024-04-08wifi: mac80211: extend IEEE80211_KEY_FLAG_GENERATE_MMIE to other ciphersMichael-CY Lee
Extend the flag IEEE80211_KEY_FLAG_GENERATE_MMIE to BIP-CMAC-256, BIP-GMAC-128 and BIP-GMAC-256 for the same reason and in the same way that the flag was added originally in commit a0b4496a4368 ("mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flags"). Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com> Link: https://msgid.link/20240326003036.15215-1-michael-cy.lee@mediatek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: Add missing return value documentationJeff Johnson
kernel-doc is reporting some warnings, so fix them: % scripts/kernel-doc -Wall -Werror -none include/net/mac80211.h include/net/mac80211.h:2056: warning: No description found for return value of 'wdev_to_ieee80211_vif' include/net/mac80211.h:2066: warning: No description found for return value of 'ieee80211_vif_to_wdev' include/net/mac80211.h:5603: warning: No description found for return value of 'ieee80211_beacon_cntdwn_is_complete' include/net/mac80211.h:5968: warning: No description found for return value of 'ieee80211_gtk_rekey_add' include/net/mac80211.h:6350: warning: No description found for return value of 'ieee80211_find_sta_by_link_addrs' include/net/mac80211.h:6478: warning: No description found for return value of 'ieee80211_txq_airtime_check' include/net/mac80211.h:6981: warning: No description found for return value of 'rate_control_set_rates' include/net/mac80211.h:7142: warning: No description found for return value of 'ieee80211_tx_prepare_skb' include/net/mac80211.h:7156: warning: No description found for return value of 'ieee80211_parse_tx_radiotap' include/net/mac80211.h:7277: warning: No description found for return value of 'ieee80211_tx_dequeue' include/net/mac80211.h:7292: warning: No description found for return value of 'ieee80211_tx_dequeue_ni' include/net/mac80211.h:7324: warning: No description found for return value of 'ieee80211_next_txq' include/net/mac80211.h:7405: warning: No description found for return value of 'ieee80211_txq_may_transmit' include/net/mac80211.h:7466: warning: No description found for return value of 'ieee80211_calc_rx_airtime' include/net/mac80211.h:7480: warning: No description found for return value of 'ieee80211_calc_tx_airtime' include/net/mac80211.h:7528: warning: No description found for return value of 'ieee80211_is_tx_data' include/net/mac80211.h:7562: warning: No description found for return value of 'ieee80211_set_active_links' 17 warnings as Errors Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://msgid.link/20240329-mac80211-kdoc-retval-v1-2-5e4d1ad6c250@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: remove ieee80211_set_hw_80211_encap()Jeff Johnson
While fixing kernel-doc issues it was discovered that the ieee80211_set_hw_80211_encap() prototype doesn't actually have an implementation, so remove it. Note the implementation was removed in commit 6aea26ce5a4c ("mac80211: rework tx encapsulation offload API"). Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://msgid.link/20240329-mac80211-kdoc-retval-v1-1-5e4d1ad6c250@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-08wifi: mac80211: correctly document struct mesh_tableJeff Johnson
Currently kernel-doc -Wall reports: net/mac80211/ieee80211_i.h:687: warning: missing initial short description on line: * struct mesh_table So add a short description. Reported-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/linux-wireless/a009a21a-56d7-4a1a-aaf9-feefa5acc561@infradead.org/ Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://msgid.link/20240328-mesh_table-kerneldoc-v1-1-174c4df341b1@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-04-05Merge tag 'rtw-next-2024-04-04' of https://github.com/pkshih/rtwKalle Valo
rtw-next patches for v6.10 Some fixes and changes of capabilities detailed in following: rtl8xxxu: * enable MFP support rtlwifi: * some cleanups rtw88: * disable unsupported interface type of mesh point for all chips, and only support station mode for SDIO chips. rtw89: * fixes of 8852b, 8852c and 8922a
2024-04-05wifi: mwifiex: replace open-coded module_sdio_driver()Krzysztof Kozlowski
Use module_sdio_driver() instead of open-coding it. No functional difference. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240329171019.63836-6-krzysztof.kozlowski@linaro.org
2024-04-05wifi: wilc1000: replace open-coded module_sdio_driver()Krzysztof Kozlowski
Use module_sdio_driver() instead of open-coding it. No functional difference. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240329171019.63836-5-krzysztof.kozlowski@linaro.org
2024-04-05wifi: wl1251: simplify module initializationKrzysztof Kozlowski
This driver's initialization functions do not perform any custom code, except printing messages. Printing messages on modules loading/unloading is discouraged because it pollutes the dmesg regardless whether user actually has this device. Core kernel code already gives tools to investigate whether module was loaded or not. Drop the printing messages which allows to replace open-coded module_sdio_driver(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240329171019.63836-4-krzysztof.kozlowski@linaro.org
2024-04-05wifi: rsi: sdio: simplify module initializationKrzysztof Kozlowski
This driver's initialization functions do not perform any custom code, except printing messages. Printing messages on modules loading/unloading is discouraged because it pollutes the dmesg regardless whether user actually has this device. Core kernel code already gives tools to investigate whether module was loaded or not. Drop the printing messages which allows to replace open-coded module_sdio_driver(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240329171019.63836-3-krzysztof.kozlowski@linaro.org
2024-04-04wifi: rtw89: 8922a: configure UL MU/OFDMA power settingKuan-Chung Chen
8922A needs to set UL MU/OFDMA power and fine tune power error tolerance for proper response to AP's trigger frame. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240401063818.12880-1-pkshih@realtek.com
2024-04-04wifi: rtw88: Set default CQM config if not presentPo-Hao Huang
When wpa_supplicant is initiated by users and not by NetworkManager, the CQM configuration might not be set. Without this setting, ICs with connection quality monitor handled by firmware won't detect connection loss. To fix this we prepare a default setting upon associated at first, then update again if any is given later. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240401033019.9664-1-pkshih@realtek.com
2024-04-03Merge branch 'mlxsw-preparations-for-improving-performance'Jakub Kicinski
Petr Machata says: ==================== mlxsw: Preparations for improving performance Amit Cohen writes: mlxsw driver will use NAPI for event processing in a next patch set. Some additional improvements will be added later. This patch set prepares the code for NAPI usage and refactor some relevant areas. See more details in commit messages. Patch Set overview: Patches #1-#2 are preparations for patch #3 Patch #3 setups tasklets as part of queue initializtion Patch #4 removes handling of unlikely scenario Patch #5 removes unused counters Patch #6 makes style change in mlxsw_pci_eq_tasklet() Patch #7-#10 poll command interface instead of EQ0 usage Patches #11-#12 make style change and break the function mlxsw_pci_cq_tasklet() Patches #13-#14 remove functions which can be replaced by a stored value Patch #15 improves accessing to descriptor queue instance ==================== Link: https://lore.kernel.org/r/cover.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Store DQ pointer as part of CQ structureAmit Cohen
Currently, for each completion, we check the number of descriptor queue and take it via mlxsw_pci_{sdq,rdq}_get(). This is inefficient, the DQ should be the same for all the completions in CQ, as each CQ handles only one DQ - SDQ or RDQ. This mapping is handled as part of DQ initialization via mlxsw_cmd_mbox_sw2hw_dq_cq_set(). Instead, as part of DQ initialization, set DQ pointer in the appropriate CQ structure. When we handle completions, warn in case that the DQ number that we expect is different from the number we get in the CQE. Call WARN_ON_ONCE() only after checking the value, to avoid calling this method for each completion. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/a5b2559cd6d532c120f3194f89a1e257110318f1.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Remove mlxsw_pci_cq_count()Amit Cohen
Currently, for each interrupt we call mlxsw_pci_cq_count() to determine the number of CQs. This call makes additional two function's calls. This can be removed by storing this value as part of structure 'mlxsw_pci', as we already do for number of SDQs. Remove the function and __mlxsw_pci_queue_count() which is now not used and store the value instead. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/f08ad113e8160678f3c8d401382a696c6c7f44c7.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Remove mlxsw_pci_sdq_count()Amit Cohen
The number of SDQs is stored as part of 'mlxsw_pci' structure. In some cases, the driver uses this value and in some cases it calls mlxsw_pci_sdq_count() to get the value. Align the code to use the stored value. This simplifies the code and makes it clearer that the value is always the same. Rename 'mlxsw_pci->num_sdq_cqs' to 'mlxsw_pci->num_sdqs' as now it is used not only in CQ context. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/0c8788506d9af35d589dbf64be35a508fd63d681.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Break mlxsw_pci_cq_tasklet() into tasklets per queue typeAmit Cohen
Completion queues are used for completions of RDQ or SDQ. Each completion queue is used for one DQ. The first CQs are used for SDQs and the rest are used for RDQs. Currently, for each CQE (completion queue element), we check 'sr' value (send/receive) to know if it is completion of RDQ or SDQ. Actually, we do not really have to check it, as according to the queue number we know if it handles completions of Rx or Tx. Break the tasklet into two - one for Rx (RDQ) and one for Tx (SDQ). Then, setup the appropriate tasklet for each queue as part of queue initialization. Use 'sr' value for unlikely case that we get completion with type that we do not expect. Call WARN_ON_ONCE() only after checking the value, to avoid calling this method for each completion. A next patch set will use NAPI to handle events, then we will have a separate poll method for Rx and Tx. This change is a preparation for NAPI usage. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/50fbc366f8de54cb5dc72a7c4f394333ef71f1d0.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Make style change in mlxsw_pci_cq_tasklet()Amit Cohen
This function will be broken into several functions later. As preparation, reorder variables to reverse xmas tree. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/7170a8f4429ecb5a539b0374c621697778ff8363.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Remove unused wait queueAmit Cohen
The previous patch changed the code to do not handle command interface from event queue. With this change the wait queue is not used anymore. Remove it and 'wait_done' variable. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/f3af6a5a9dabd97d2920cefe475c6aa57767f504.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Use only one event queueAmit Cohen
The device supports two event queues. EQ0 is used for command interface completion events. EQ1 is used for completion events of RDQ or SDQ. Currently, for each EQE (event queue element), we check the queue number and handle accordingly. More than that, for each interrupt we schedule tasklets for both EQs. This is really ineffective, especially because of the fact that EQ0 is used only as part of driver init/fini, when EMADs are not available. There is no point to schedule the tasklet for it and check each EQE. A previous patch changed the code to poll command interface for each use of it. It means that now there is no real reason to use EQ0, as we poll the command interface. Initialize only one event queue and use it as EQ1 (this is determined by queue number). Then, for each interrupt we can schedule the tasklet only for one queue and we do not have to check the queue number. This simplifies the code and should improve performance. Note that polling command interface is ok as we use it only as part of driver init/fini. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/23d764f5c032e4c363b98590b746a4b32d2bf900.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Rename MLXSW_PCI_EQS_COUNTAmit Cohen
Currently we use MLXSW_PCI_EQS_COUNT event queues. A next patch will change the driver to initialize only EQ1, as EQ0 is not required anymore when we poll command interface. Rename the macro to MLXSW_PCI_EQS_MAX as later we will not initialize the maximum supported EQs, this value represents the maximum and a new macro will be added to represent the actual used queues. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/b08df430b62f23ca1aa3aaa257896d2d95aa7691.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Poll command interface for each cmd_exec()Amit Cohen
Command interface is used for configuring and querying FW when EMADs are not available. During the time that the driver sets up the asynchronous queues, it polls the command interface for getting completions. Then, there is a short period when asynchronous queues work, but EMADs are not available (marked in the code as nopoll = true). During this time, we send commands via command interface, but we do not poll it, as we can get an interrupt for the completion. Completions of command interface are received from HW in EQ0 (event queue 0). The usage of EQ0 instead of polling is done only 4 times during initialization and one time during tear down, but it makes an overhead during lifetime of the driver. For each interrupt, we have to check if we get events in EQ0 or EQ1 and handle them. This is really ineffective, especially because of the fact that EQ0 is used only as part of driver init/fini. Instead, we can poll command interface for each call of cmd_exec(). It means that when we send a command via command interface (as EMADs are not available), we will poll it, regardless of availability of the asynchronous queues. This will allow us to configure later only EQ1 and simplify the flow. Remove 'nopoll' indication and change mlxsw_pci_cmd_exec() to poll till answer/timeout regardless of queues' state. For now, completions are handled also by EQ0, but it will be removed in next patch. Additional cleanups will be added in next patches. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/e674c70380ceda953e0e45a77334c5d22e69938f.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Make style changes in mlxsw_pci_eq_tasklet()Amit Cohen
This function will be used later only for EQ1. As preparation, reorder variables to reverse xmas tree and return earlier when it is possible, to simplify the code. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/2412d6c135b2a6aedb4484f5d8baab3aecd7b9ae.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Remove unused countersAmit Cohen
The structure 'mlxsw_pci_queue' stores several counters which were consumed via debugfs. Since commit 9a32562becd9 ("mlxsw: Remove debugfs interface"), these counters are not used. Remove them. This makes the 'union u' and 'struct eq' redundant. Maintain 'struct cq' as it will be extended later. Replace increasing 'q->u.eq.ev_other_count' with WARN_ON_ONCE(), as it is used in an unreasonable case of receiving event in EQ which is not EQ0 or EQ1. When the queues are initialized, we check number of event queues and fail with the print "Unsupported number of queues" in case that the driver tries to initialize more than two queues. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/ee9e658800aa0390e08342100bc27daff4c176c0.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Arm CQ doorbell regardless of number of completionsAmit Cohen
Currently, as part of mlxsw_pci_cq_tasklet(), we check if any item was handled, and only in such case we arm doorbell. This is unlikely case, as we schedule tasklet only for CQs that we get an event for them, which means that they contain completions to handle. Remove this check, which is supposed to be true always, and even if it is false, it is not a mistake to ring the doorbell. We can warn on such case, but it is not really worth to add a check which will be run for each CQ handling when we do not expect to reach it and it does not point to logic error that should be handled. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/f8efa481bfe7bebb9f93bb803f44ab7da77f53e6.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Do not setup tasklet from operationAmit Cohen
Currently, the structure 'mlxsw_pci_queue_ops' holds a pointer to the callback function of tasklet. This is used only for EQ and CQ. mlxsw driver will use NAPI in a following patch set, so CQ will not use tasklet anymore. As preparation, remove this pointer from the shared operation structure and setup the tasklet as part of queue initialization. For now, setup tasklet for EQ and CQ. Later, CQ code will be changed. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/a326cae5fc1ad085a1a063c004983de6fe389414.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Move mlxsw_pci_cq_{init, fini}()Amit Cohen
Move mlxsw_pci_cq_{init, fini}() after mlxsw_pci_cq_tasklet() as a next patch will setup the tasklet as part of initialization. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/25196cb5baf5acf6ec1e956203790e018ba8e306.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03mlxsw: pci: Move mlxsw_pci_eq_{init, fini}()Amit Cohen
Move mlxsw_pci_eq_{init, fini}() after mlxsw_pci_eq_tasklet() as a next patch will setup the tasklet as part of initialization. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/7ae120a02e1c490084daae7e684a0d40b7cce4e7.1712062203.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03Merge branch 'mlx5-misc-patches'Jakub Kicinski
Tariq Toukan says: ==================== mlx5 misc patches This patchset includes small features and misc code enhancements for the mlx5 core and EN drivers. Patches 1-4 by Gal improves the mlx5e ethtool stats implementation, for example by using standard helpers ethtool_sprintf/puts. Patch 5 by me adds a reset option for the FW command interface debugfs stats entries. This allows explicit FW command interface stats reset between different runs of a test case. Patches 6 and 7 are simple cleanups. Patch 8 by Gal adds driver support for 800Gbps link modes. Patch 9 by Jianbo enhances the L4 steering abilities. Patches 10-11 by Jianbo save redundant operations. ==================== Link: https://lore.kernel.org/r/20240402133043.56322-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5: Don't call give_pages() if request 0 pageJianbo Liu
Firmware will return 0 on query BOOT/INIT PAGES for non-page supplier functions (external host PF/VF/SF), so no page is needed to be allocated for them. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240402133043.56322-12-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5: Skip pages EQ creation for non-page supplier functionJianbo Liu
Page events are not issued by device on the function if page_request_disable is set, so no need to create pages EQ. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240402133043.56322-11-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5: Support matching on l4_type for ttc_tableJianbo Liu
Replace matching on TCP and UDP protocols with new l4_type field which is parsed by steering for ttc_table. It is enabled by the outer_l4_type or inner_l4_type bits in nic_rx or port_sel flow table capabilities and used only if pcc_ifa2 bit in HCA capabilities is set. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240402133043.56322-10-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5e: Add support for 800Gbps link modesGal Pressman
Add support for 800Gbps speed, link modes of 100Gbps per lane. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240402133043.56322-9-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5: Convert uintX_t to uXGal Pressman
In the kernel, the preferred types are uX. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240402133043.56322-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5e: XDP, Fix an inconsistent commentCarolina Jubran
Starting from commit eb9b9fdcafe2 ("net/mlx5e: Introduce extended version for mlx5e_xmit_data") sinfo is no longer passed as an argument to mlx5e_xmit_xdp_frame(), the comment is inconsistent. check_result must be zero when the packet is fragmented. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240402133043.56322-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-03net/mlx5e: debugfs, Add reset option for command interface statsTariq Toukan
Resetting stats just before some test/debug case allows us to eliminate out the impact of previous commands. Useful in particular for the average latency calculation. The average_write() callback was unreachable, as "average" is a read-only file. Extend, rename, and use it for a newly exposed write-only "reset" file. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240402133043.56322-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 07:34:54 +0000