- 26 Aug, 2021 25 commits
-
-
Mukesh Sisodiya authored
With recent changes in the firmware SRAM debug during D3 is enabled by default and need not be enabled by driver. cleaning the code to align the same. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210802215208.8535203d0ef7.Ib1695ce5de921b0472d0b1052e729e071573b863@changeidSigned-off-by:
-
Johannes Berg authored
There's no need for all the complicated conditions here, any bufferable MMPDUs or MMPDUs for client interfaces are already coming through the TXQ interface, not iwl_mvm_mac_tx(). Simplify the logic. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Since switching to mac80211 TXQs, we no longer need to advertise more hardware queues than ACs, since we don't even set QUEUE_CONTROL anyway, so the vif->hw_queue[] mapping array won't be used. All we need (at least for now) is for hw->queues to indicate that we have enough queues to handle QoS. Signed-off-by:
-
Johannes Berg authored
When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then queue numbers are just sequentially assigned 0, 1, 2, ... Prior to TVQM, in DQA, there were some statically allocated queue numbers: * IWL_MVM_DQA_AUX_QUEUE == 1, * both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and * IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9. Now, these values are assigned to the members mvm->aux_queue, mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by default. Normally, this doesn't really matter, and if TVQM is in fact available we override them to the real values after allocating a queue for use there. However, this allocation doesn't always happen. For example, for mvm->p2p_dev_queue (== 2) it only happens when the P2P Device interface is started, if any. If it's not started, the value in mvm->p2p_dev_queue remains 2. This wouldn't really matter all that much if it weren't for iwl_mvm_is_static_queue() which checks a queue number against one of those four static numbers. Now, if no P2P Device or monitor interface is added then queue 2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously returns true for it. If it then gets full, all interface queues are stopped, instead of just backpressuring against the one TXQ that's really the only affected one. This clearly can lead to issues, as everything is stopped even if just a single TXQ filled its corresponding HW queue, if it happens to have an appropriate number (2 or 9, AUX is always reassigned.) Due to a mac80211 bug, this also led to a situation in which the queues remained stopped across a deauthentication and then attempts to connect to a new AP started failing, but that's fixed separately. Fix all of this by simply initializing the queue numbers to the invalid value until they're used, if TVQM is enabled, and also setting them back to that value when the queues are later freed again. Signed-off-by:
-
Zheng Yongjun authored
mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init(). Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by:
-
Tom Rix authored
The macro use will already have a semicolon. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Zhang Qilong authored
If beacon_inject_active is true, we will return without freeing beacon. Fid that by freeing it before returning. Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> [reworded the commit message] Signed-off-by:
-
Wei Yongjun authored
GCC reports warning as follows: drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:14:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration] 14 | const static struct iwl_rfi_lut_entry iwl_rfi_table[IWL_RFI_LUT_SIZE] = { | ^~~~~ Move static to the beginning of declaration. Fixes: 21254908 ("iwlwifi: mvm: add RFI-M support") Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Luca Coelho authored
This check is useless, because we would return NULL in that case and none of the callers actually check that the return value was not NULL before accessing it. Signed-off-by:
-
Luca Coelho authored
If we use spaces in the queue names, we get files with spaces in their name in procfs, which is ugly. Remove the spaces. Reported-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Johannes Berg authored
The firmware SMPS request should only be honoured if the connection is currently with HE and on 160 MHz, so check that and then potentially reapply any request if the BW changes. Signed-off-by:
-
Johannes Berg authored
When installing a (new) key, set the replay counter so that after FW restart the firmware has the correct value of the replay counters. This doesn't have a large effect - for frames that reach the driver, it will do a replay check, and when installing a new key, the counter is normally zero to start with (not for GTK though, if joining the BSS for the first time). Since this only affects frames handled entirely by the FW, and that's restricted to a few unicast management frames, the only affect here is for those after a firmware restart. Signed-off-by:
-
Mordechay Goodstein authored
EAPOL failure results in deauthentication with various reasons, not related to AUTH failure specifically, so we just merge AUTH failure with failed to assoc to AP. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by:
-
Mordechay Goodstein authored
This helps understand why and what debug capabilities are running. Signed-off-by:
-
Ilan Peer authored
Add support for discovery of hidden networks on the 6GHz band, by including the scan request direct SSIDs in the FW scan request command: - In case a short SSID matches one of the direct SSIDs in the scan request command, add the matching SSID in the same offset in the 'direct_ssids' array. - Otherwise, add the SSID in one of the available slots. Additionally, as a preparation to handle hidden APs, refactor iwl_mvm_umac_scan_cfg_channels_v6_6g() the function. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Ilan Peer authored
The scan request processing populated the direct SSIDs in the FW scan request command also for 6GHz scan, which is not needed and might result in unexpected behavior. Fix the code to add the direct SSIDs only in case the scan is not a 6GHz scan. Signed-off-by:
-
Luca Coelho authored
This value is not a simple incrementing integer, it contains some flags as well, so reading it in hexadecimal is easier. Change the print to do it in hex instead of decimal. Signed-off-by:
-
Johannes Berg authored
If the firmware crashes while we're waiting for the reset handshake then it cannot possibly make progress anymore, and we will just time out the wait. That's pointless, so just stop waiting at that point. Additionally, if it never acknowledges the reset handshake, something went wrong. Dump an error in both of these cases, but we need to do it synchronously here since the device will be turned off. Signed-off-by:
-
Johannes Berg authored
In some cases it may be necessary to synchronously create a firmware error report, add the necessary infrastructure for this. Signed-off-by:
-
Johannes Berg authored
When switching op-modes, or more generally when reconfiguring, we might switch the RB size. In _iwl_pcie_rx_init() we have a comment saying we must free all RBs since we might switch the size, but this is actually too late: the switch has been done and we'll free the buffers with the wrong size. Fix this by always freeing the buffers, if any, at the start of configure, instead of only after the size may have changed. Signed-off-by:
-
Johannes Berg authored
On 64-bit machines, struct iwl_rx_mem_buffer has a lot of padding due to the use of pointers after the small items. Move the list entry before them, and while at it also add documentation for it. Signed-off-by:
-
Johannes Berg authored
If the firmware crashes while we're already shutting down the system, there isn't much we can do since the shutdown process is continuing and we wanted to do that. Don't do a FW restart, with the implied debug collection, in this case. Signed-off-by:
-
Johannes Berg authored
The device is capable of receiving MU-MIMO frames with 8 symbols, enable the bit here that says so. Signed-off-by:
-
Shaul Triebitz authored
If broadcast TWT is supported in the BSS, tell the firmware about it by setting the BROADCAST_TWT_SUPPORTED in the MAC context command. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
-
Mordechay Goodstein authored
Our HW supersets STBC for HE but never set it in assoc IE, fix it by setting it and enable using it. Signed-off-by:
-
- 25 Aug, 2021 15 commits
-
-
David S. Miller authored
Juhee Kang says: ==================== samples: pktgen: enhance the ability to print the execution results of samples This patch series improves the ability to print the execution result of pktgen samples by adding a line which calls the function before termination and adding trap SIGINT. Also, this series documents the latest pktgen usage options. Currently, pktgen samples print the execution result when terminated usually. However, sample03 is not working properly. This is results of sample04 and sample03: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 1 Running... ctrl^C to stop Device: eth0@0 Result: OK: 19(c5+d13) usec, 1 (60byte,0frags) 51762pps 24Mb/sec (24845760bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample03_burst_single_flow.sh -n 1 Running... ctrl^C to stop Because sample03 doesn't call the function which prints the execution result when terminated normally, unlike other samples. So the first commit solves this issue by adding a line which calls the function before termination. Also, all pktgen samples are able to send infinite messages per thread by setting the count option to 0, and pktgen is stopped by Ctrl-C. However, the sample besides sample{3...5} don't work appropriately because Ctrl-C stops the script, not just pktgen. This is results of samples: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 0 Running... ctrl^C to stop ^CDevice: eth0@0 Result: OK: 569657(c569538+d118) usec, 84650 (60byte,0frags) 148597pps 71Mb/sec (71326560bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample01_simple.sh -n 0 Running... ctrl^C to stop ^C # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample02_multiqueue.sh -n 0 Running... ctrl^C to stop ^C # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample06_numa_awared_queue_irq_affinity.sh -n 0 Running... ctrl^C to stop ^C # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_bench_xmit_mode_netif_receive.sh -n 0 Running... ctrl^C to stop ^C # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_bench_xmit_mode_queue_xmit.sh -n 0 Running... ctrl^C to stop ^C So the second commit solves this issue by adding trap SIGINT. Also, changes control_c function to print_results to maintain consistency with other samples on the first commit and second commit. And current pktgen.rst documentation doesn't add the latest pktgen sample usage options such as count and IPv6, and so on. Also, the old pktgen sample scripts are still included in the document. The old scripts were removed by the commit a4b6ade8 ("samples/pktgen: remove remaining old pktgen sample scripts"). Thus, the last commit documents the latest pktgen sample usage and removes old sample scripts. And fixes a minor typo. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Juhee Kang authored
Currently, the pktgen.rst documentation doesn't cover the latest pktgen sample usage options such as count and IPv6, and so on. Also, this documentation includes the old sample scripts which are no longer use because it was removed by the commit a4b6ade8 ("samples/pktgen : remove remaining old pktgen sample scripts") Thus, this commit documents pktgen sample usage using the latest options and removes old sample scripts, and fixes a minor typo. Signed-off-by:
Juhee Kang <claudiajkang@gmail.com> Signed-off-by:
-
Juhee Kang authored
All pktgen samples can send indefinitely num messages per thread by setting the count option to 0(-n 0). If running sample with setting count 0 and press Ctrl-C to stop this program, the program prints the result of the execution so far. Currently, the samples besides sample{3...5} don't work properly. Because Ctrl-C stops the script, not just pktgen. This is results of samples: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 0 Running... ctrl^C to stop ^CDevice: eth0@0 Result: OK: 569657(c569538+d118) usec, 84650 (60byte,0frags) 148597pps 71Mb/sec (71326560bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample01_simple.sh -n 0 Running... ctrl^C to stop ^C In order to solve this, this commit adds trap SIGINT. Also, this commit changes control_c function to print_result to maintain consistency with other samples. Signed-off-by: -
Juhee Kang authored
Currently, most pktgen samples print the execution result when the program is terminated normally. However, sample03 doesn't work appropriately. This is results of samples: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 1 Running... ctrl^C to stop Device: eth0@0 Result: OK: 19(c5+d13) usec, 1 (60byte,0frags) 51762pps 24Mb/sec (24845760bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample03_burst_single_flow.sh -n 1 Running... ctrl^C to stop The reason why it doesn't print the execution result when the program is terminated usually is that sample03 doesn't call the function which prints the result, unlike other samples. So, this commit solves this issue by calling the function before termination. Also, this commit changes control_c function to print_result to maintain consistency with other samples. Signed-off-by: -
David S. Miller authored
Sunil Goutham says: ==================== Octeontx2: Traffic shaping and SDP link config support This patch series adds support for traffic shaping configuration on all silicons available after 96xx C0. And also adds SDP link related configuration needed when Octeon is connected as an end-point and traffic needs to flow from end-point to host and vice versa. Series also has other changes like - New mbox messages in admin function driver for PF/VF drivers to retrieve available HW resource count. HW resources like block LFs, bandwidth profiles etc are covered. - Added PTP device ID for new CN10K and 95O silicons. - etc ==================== Signed-off-by: -
Sunil Goutham authored
Added mbox for PF/VF drivers to retrieve current ingress bandwidth profile free count. Also added current policer timeunit configuration info based on which ratelimiting decisions can be taken by PF/VF drivers. Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
-
Sunil Goutham authored
New usecases are popping up where in user wants to install common MCAM filters for all interfaces. Having channel verification will result in duplicating such MCAM filters for each of the ingress interface. Hence removed channel verification. Signed-off-by:
-
Subbaraya Sundeep authored
CN10K slicon has different device id for PTP device. Hence this patch updates the driver with new id. Though ptp driver being a separate driver AF manages configuring PTP block by all PFs. To manage ptp, AF driver checks in its probe whether 1. ptp hardware device found on silicon 2. A driver is bound to ptp device 3. The ptp driver probe is successful In failure of cases 1 and 3, AF proceeds with out ptp and for case 2 defers the probe. This patch refactors code also to check for all the PTP device ids given in ptp device ids table for case 1. Also added PTP device ID for 95O silicon Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
George Cherian authored
Upon receiving the MBOX_MSG_FREE_RSRC_CNT, the AF will find out the current number of free resources and reply it back to the requester. No guarantee is given on the future state of the free resources yet. If another requester sends MBOX_MSG_ATTACH_RESOURCES after this call, the number of available resources might change. Signed-off-by:
George Cherian <george.cherian@marvell.com> Signed-off-by:
Stanislaw Kardach <skardach@marvell.com> Signed-off-by:
-
Radha Mohan Chintakuntla authored
Added support for packet IO via SDK links which is used when Octeon is connected as a end-point. Traffic host to end-point and vice versa flow through SDP links. This patch also support dual SDP blocks supported in 98xx silicon. Signed-off-by:
Radha Mohan Chintakuntla <radhac@marvell.com> Signed-off-by:
Nalla Pradeep <pnalla@marvell.com> Signed-off-by:
Subrahmanyam Nilla <snilla@marvell.com> Signed-off-by:
-
Harman Kalra authored
In 98xx, there are 2 NIX blocks and 4 LBK blocks present. The way these NIX-LBK should be configured depends on the use case. By default loopback functionality is supported in AF VF pairs which are attached to NIX0 and NIX1 LFs alternatively to ensure load balancing. NIX0 transmits a packet to LBK1 which will be received by NIX1 and packet transmitted by NIX1 will get received by NIX0 via LBK2. There are some requirements where only one AF VF is used and respective NIX is expected to operate in a mode where it can receive it own packet back. This can be achieved if NIX0 sends packet to LBK0 and not LBK1. Adding a flag in LF alloc request mailbox which can setup NIX0 to use LBK0 and NIX1 can use LBK3. Signed-off-by:
Harman Kalra <hkalra@marvell.com> Signed-off-by:
-
Subbaraya Sundeep authored
Unlike OcteonTx2, the channel numbers used by CGX/RPM and LBK on CN10K silicons aren't fixed in HW. They are SW programmable, hence we cannot derive transmit link from static channel numbers anymore. Get the same from admin function via mailbox. Signed-off-by:
-
Jerin Jacob authored
Before C0 HW revision, The RSS adder was computed based the following static formula. rss_adder<7:0> = flow_tag<7:0> ^ flow_tag<15:8> ^ flow_tag<23:16> ^ flow_tag<31:24> The above scheme has the following drawbacks: 1) It is not in line with other standard NIC behavior. 2) There can be an SW use case where SW can compute the hash upfront using Toeplitz function and predict the queue selection to optimize some packet lookup function. The nonstandard way of doing XOR makes the consumer to not predict the queue selection. C0 HW revision onwards, The HW can configure the rss_adder<7:0> as flow_tag<7:0> to align with standard NICs. This patch adds an option to select legacy RSS adder mode vs standard NIC behavior by setting NIX_LF_RSS_TAG_LSB_AS_ADDER flag. Since this bit field is used as reserved in old HW revisions, No need to have an additional HW version check. Signed-off-by:
Jerin Jacob <jerinj@marvell.com> Signed-off-by:
-
Nithin Dabilpuram authored
Starting from 96xx C0 onwards all silicons support traffic shaping. This patch enables that feature along with other changes - When PIR/CIR shaping config is modified, toggle SW_XOFF for config to take effect - Before SMQ flush, clear SW_XOFF at all parent schedulers - Support to read current transmit scheduler configuration via mbox Signed-off-by:
Nithin Dabilpuram <ndabilpuram@marvell.com> Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
-
Cai Huoqing authored
it's helpful for complie test in other platform(e.g.X86) Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
