- 10 Apr, 2024 5 commits
-
-
Sriram R authored
When multiple radios are advertised as a single wiphy which supports various bands, a default scan request to mac80211 from cfg80211 will split the driver request based on band, so each request will have channels belonging to the same band. With this supported by default, the ath12k driver on receiving this request checks for one of the channels in the request and selects the corresponding radio(ar) on which the scan is going to be performed and creates a vdev on that radio. Note that on scan completion this vdev is not deleted. If a new scan request is seen on that same vif for a different band the vdev will be deleted and created on the new radio supporting the request. The vdev delete logic is refactored to have this done dynamically. The reason for not deleting the vdev on scan stop is to avoid repeated delete-create sequence if the scan is on the same band. Also, during channel assign, new vdev creation can be optimized as well. Also if the scan is requested when the vdev is in started state, no switching to new radio is allowed and scan on channels only within same radio is allowed. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
Sriram R <quic_srirrama@quicinc.com> Co-developed-by:
Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://msgid.link/20240405194519.1337906-6-quic_ramess@quicinc.com
-
Sriram R authored
With single wiphy, multiple radios are combined into a single wiphy. Since any channel can be assigned to a vif being brought up, the vdev cannot be created during add_interface(). Hence defer the vdev creation till channel assignment. If only one radio is part of the wiphy, then the existing logic is maintained, i.e vdevs are created during add interface and started during channel assignment. This ensures no functional changes to single pdev devices which has only one radio in the SoC. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
-
Sriram R authored
When mac80211 does drv start/stop, apply the state change for all the radios within the wiphy in ath12k. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
Sriram R authored
Modify add and remove chanctx mac80211 ops to fetch the correct radio(ar) based on channel context. This change also introduces new helper function to fetch the radio/ar based on channel context and ieee80211_chan which internally uses the radio's low/high freq range. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
Karthikeyan Periyasamy authored
Currently MAC HW un/register helper function support the single radio. To enable single/multi link operation in the future, the following helper functions need to be refactored to accommodate multiple radios under a single MAC HW un/register: * ath12k_ah_to_ar() * ath12k_mac_hw_allocate() * ath12k_mac_hw_register() * ath12k_mac_hw_unregister() This refactoring will make it easier to scale these functionalities and support Multi link operation. Current Multi wiphy Model +---------------+ +---------------+ +---------------+ | Mac80211 hw | | Mac80211 hw | | Mac80211 hw | | private data | | private data | | private data | | | | | | | |ath12k_hw (ah) | |ath12k_hw (ah) | |ath12k_hw (ah) | | | | | | | | +-----------+ | | +-----------+ | | +-----------+ | | | ar (2GHz) | | | | ar (5GHz) | | | | ar (6GHz) | | | +-----------+ | | +-----------+ | | +-----------+ | | | | | | | +---------------+ +---------------+ +---------------+ Single wiphy Model +--------------+ | Mac80211 hw | | private data | | | |ath12k hw (ah)| | +----------+ | | |ar (2GHz) | | | +----------+ | | |ar (5GHz) | | | +----------+ | | |ar (6GHz) | | | +----------+ | +--------------+ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Signed-off-by:
-
- 09 Apr, 2024 3 commits
-
-
Karthikeyan Periyasamy authored
Rename the "ATH12k" word to "ATH12K" for consistent capitalization in the word. Signed-off-by:
-
Baochen Qiang authored
Now that all infrastructure is in place and ath11k is fixed to handle all the corner cases, power down the ath11k firmware during suspend and power it back up during resume. This fixes the problem when using hibernation with ath11k PCI devices. For suspend, two conditions needs to be satisfied: 1. since MHI channel unprepare would be done in late suspend stage, ath11k needs to get all QMI-dependent things done before that stage. 2. and because unprepare MHI channels requires a working MHI stack, ath11k is not allowed to call mhi_power_down() until that finishes. So the original suspend callback is separated into two parts: the first part handles all QMI-dependent things in suspend callback; while the second part powers down MHI in suspend_late callback. This is valid because kernel calls ath11k's suspend callback before all suspend_late callbacks, making the first condition happy. And because MHI devices are children of ath11k device (ab->dev), kernel guarantees that ath11k's suspend_late callback is called after QRTR's suspend_late callback, this satisfies the second condition. Above analysis also applies to resume process. so the original resume callback is separated into two parts: the first part powers up MHI stack in resume_early callback, this guarantees MHI stack is working when QRTR tries to prepare MHI channels (kernel calls QRTR's resume_early callback after ath11k's resume_early callback, due to the child-father relationship); the second part waits for the completion of restart, which won't fail now since MHI channels are ready for use by QMI. Another notable change is in power down path, we tell mhi_power_down() to not to destroy MHI devices, making it possible for QRTR to help unprepare/prepare MHI channels, and finally get us rid of the probe-defer issue when resume. Also change related code due to interface changes. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by:Takashi Iwai <tiwai@suse.de> Signed-off-by:
Baochen Qiang <quic_bqiang@quicinc.com> Acked-by:
-
Baochen Qiang authored
MHI devices may not be destroyed during suspend/hibernation, so need to unprepare/prepare MHI channels throughout the transition, this is done by adding suspend/resume callbacks. The suspend callback is called in the late suspend stage, this means MHI channels are still alive at suspend stage, and that makes it possible for an MHI controller driver to communicate with others over those channels at suspend stage. While the resume callback is called in the early resume stage, for a similar reason. Also note that we won't do unprepare/prepare when MHI device is in suspend state because it's pointless if MHI is only meant to go through a suspend/resume transition, instead of a complete power cycle. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by:
-
- 08 Apr, 2024 2 commits
-
-
Karthikeyan Periyasamy authored
By default driver supports intra-device SLO/MLO, the link capability flags reflect this. When the QMI PHY capability learning fails driver not enable the MLO parameter in the host capability QMI request message. In this case, reset the device link capability flags to zero (SLO/MLO not support) to accurately represent the capabilities. Found in code review. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Karthikeyan Periyasamy authored
Link capability categorized as Single Link Operation (SLO) and Multi Link Operation (MLO). - Intra-device SLO/MLO refers to links present within a device - Inter-device SLO/MLO refers to links present across multiple devices Currently, driver uses a boolean variable to represent intra-device SLO/MLO capability. To accommodate inter-device SLO/MLO capabilities within the same variable, modify the existing variable name and type. Define a new enumeration for the link capabilities to accommodate both intra-device and inter-device scenarios. Populate the enum based on the supported capabilities. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
- 05 Apr, 2024 3 commits
-
-
Kalle Valo authored
Merge branch 'mhi-immutable' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into ath-next This is needed for patch 'wifi: ath11k: support hibernation'.
-
Dmitry Baryshkov authored
Different Qualcomm platforms using WCN3990 WiFI chip use SoC-specific firmware versions with different features. For example firmware for SDM845 doesn't use single-chan-info-per-channel feature, while firmware for QRB2210 / QRB4210 requires that feature. Allow board DT files to override the subdir of the fw dir used to lookup the firmware-N.bin file decribing corresponding WiFi firmware. For example: - ath10k/WCN3990/hw1.0/wlanmdsp.mbn, ath10k/WCN3990/hw1.0/firmware-5.bin: main firmware files, used by default - ath10k/WCN3990/hw1.0/qcm2290/wlanmdsp.mbn, ath10k/WCN3990/hw1.0/qcm2290/firmware-5.bin: SoC specific firmware with different signature and feature bits Note, while board files lookup uses the same function and thus it is possible to provide board-specific board-2.bin files, this is not required in 99% of cases as board-2.bin already contains a way to provide board-specific data with finer granularity than DT overrides. Signed-off-by:Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
For WCN3990 platforms we need to look for the platform / board specific firmware-N.mbn file which corresponds to the wlanmdsp.mbn loaded to the modem DSP via the TQFTPserv. Add firmware-name property describing this classifier. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
- 04 Apr, 2024 27 commits
-
-
Krzysztof Kozlowski authored
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:
-
Gustavo A. R. Silva authored
wifi: wil6210: wmi: Use __counted_by() in struct wmi_set_link_monitor_cmd and avoid -Wfamnae warning Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). Also, -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally. So, use the `DEFINE_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warning: drivers/net/wireless/ath/wil6210/wmi.c:4018:49: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Link: https://github.com/KSPP/linux/issues/202Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
-
Gustavo A. R. Silva authored
wifi: wil6210: cfg80211: Use __counted_by() in struct wmi_start_scan_cmd and avoid some -Wfamnae warnings Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). Also, -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally. So, use the `DEFINE_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warning: drivers/net/wireless/ath/wil6210/cfg80211.c:896:43: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Link: https://github.com/KSPP/linux/issues/202Signed-off-by:
-
Jeff Johnson authored
kernel-doc flagged the following issue, so fix it: drivers/net/wireless/ath/ath12k/hal.h:771: warning: missing initial short description on line: * enum hal_rx_buf_return_buf_manager Signed-off-by:
-
Jeff Johnson authored
kernel-doc flagged the following issue, so fix it: drivers/net/wireless/ath/ath11k/hal.h:668: warning: missing initial short description on line: * enum hal_rx_buf_return_buf_manager Signed-off-by:
-
Arnd Bergmann authored
gcc-9 and some other older versions produce a false-positive warning for zeroing two fields In file included from include/linux/string.h:369, from drivers/net/wireless/ath/ath9k/main.c:18: In function 'fortify_memset_chk', inlined from 'ath9k_ps_wakeup' at drivers/net/wireless/ath/ath9k/main.c:140:3: include/linux/fortify-string.h:462:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 462 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Using a struct_group seems to reliably avoid the warning and not make the code much uglier. The combined memset() should even save a couple of cpu cycles. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Acked-by:
Toke Høiland-Jørgensen <toke@toke.dk> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Arnd Bergmann authored
The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds: In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler. Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though. Fixes: fb5f6a0e ("mac80211: Use memset_after() to clear tx status") Link: https://lore.kernel.org/lkml/20230623152443.2296825-1-arnd@kernel.org/Signed-off-by:Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Miaoqing Pan authored
The WMI commands are in little endian byte order, fix missing endianness conversion in wmi_vdev_create_cmd. Tested-on: WCN7850 hw2.0 WLAN.IOE_HMT.1.0.2-00240-QCAHMTSWPL_V1.0_V2.0_SILICON-1 Signed-off-by:
Miaoqing Pan <quic_miaoqing@quicinc.com> Signed-off-by:
-
Ramya Gnanasekar authored
Create dfs_simulate_radar debugfs in ath12k debugfs directory. Usage: echo 1 > /sys/kernel/debug/ath12k/pci-0000:06:00.0/mac0/dfs_simulate_radar This debugfs helps user to simulate RADAR interference in run time. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Ramya Gnanasekar <quic_rgnanase@quicinc.com> Acked-by:
-
Ramasamy Kaliappan authored
The initial debugfs infra bringup in ath12k driver and create the ath12k debugfs and soc-specific directories in /sys/kernel/debug/ For each ath12k device, directory will be created in <bus>-<devname> schema under ath12k root directory. Example with one ath12k device: /sys/kernel/debug/ath12k/pci-0000:06:00.0 ath12k `-- pci-0000:06:00.0 |-- mac0 To enable ath12k debugfs support (CONFIG_ATH12K_DEBUGFS=y) Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:Ramasamy Kaliappan <quic_rkaliapp@quicinc.com> Signed-off-by:
-
Jakub Kicinski authored
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.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Amit Cohen authored
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.comSigned-off-by:
-
Amit Cohen authored
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 authored
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 authored
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 authored
This function will be broken into several functions later. As preparation, reorder variables to reverse xmas tree. Signed-off-by:
-
Amit Cohen authored
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 authored
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 authored
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 authored
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 authored
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 authored
The structure 'mlxsw_pci_queue' stores several counters which were consumed via debugfs. Since commit 9a32562b ("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 authored
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 authored
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 authored
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 authored
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: -
Jakub Kicinski authored
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.comSigned-off-by:
-
