- Sep 21, 2023
-
-
Dmitry Antipov authored
In 'ath11k_dp_rx_mon_dest_process()', 'mon_dst_srng' points to a member of 'srng_list', which is a fixed-size array inside 'struct ath11k_hal'. This way, if 'ring_id' is valid (i. e. between 0 and HAL_SRNG_RING_ID_MAX - 1 inclusive), 'mon_dst_srng' can't be NULL and so relevant check may be dropped. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Acked-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230824075121.121144-1-dmantipov@yandex.ru
-
Dmitry Antipov authored
Since 'user_stats' is a fixed-size array of 'struct htt_ppdu_user_stats' in 'struct htt_ppdu_stats', any of its member can't be NULL and so relevant check may be dropped. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
-
Baochen Qiang authored
Commit 5b32b6dd ("ath11k: Remove core PCI references from PCI common code") breaks with one MSI vector because it moves affinity setting after IRQ request, see below log: [ 1417.278835] ath11k_pci 0000:02:00.0: failed to receive control response completion, polling.. [ 1418.302829] ath11k_pci 0000:02:00.0: Service connect timeout [ 1418.302833] ath11k_pci 0000:02:00.0: failed to connect to HTT: -110 [ 1418.303669] ath11k_pci 0000:02:00.0: failed to start core: -110 The detail is, if do affinity request after IRQ activated, which is done in request_irq(), kernel caches that request and returns success directly. Later when a subsequent MHI interrupt is fired, kernel will do the real affinity setting work, as a result, changs the MSI vector. However at that time host has configured old vector to hardware, so host never receives CE or DP interrupts. Fix it by setting affinity before registering MHI controller where host is, for the first time, doing IRQ request. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-01160-QCAMSLSWPLZ-1 Fixes: 5b32b6dd ("ath11k: Remove core PCI references from PCI common code") Signed-off-by:
Baochen Qiang <quic_bqiang@quicinc.com> Acked-by:
-
Dmitry Antipov authored
According to Jeff, 'HTT_DATA_TX_STATUS_DOWNLOAD_FAIL' from 'enum htt_data_tx_status' is never actually used by the firmware code and so may be dropped, with the related adjustment to 'ath10k_htt_rx_tx_compl_ind()'. Suggested-by:
-
Kees Cook authored
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 checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct ath10k_ce_ring. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Kalle Valo <kvalo@kernel.org> Cc: Jeff Johnson <quic_jjohnson@quicinc.com> Cc: ath10k@lists.infradead.org Cc: linux-wireless@vger.kernel.org Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Kees Cook authored
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 checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct wcn36xx_hal_ind_msg. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Kalle Valo <kvalo@kernel.org> Cc: wcn36xx@lists.infradead.org Cc: linux-wireless@vger.kernel.org Signed-off-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct hal_rx_ppdu_end_user_stats *), (struct ath12k_rx_desc_info *) or (struct hal_tx_msdu_ext_desc *). Change the prototype to remove the local variable. Signed-off-by:
Wu Yunchuan <yunchuan@nfschina.com> Suggested-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct htt_rx_ring_setup_ring32 *), (struct htt_rx_ring_setup_ring64 *). Change the prototype to remove the local variable. Signed-off-by:
-
Wu Yunchuan authored
No need cast (void *) to (struct ath6kl *) or (struct ath6kl_cookie *). Signed-off-by:
-
Wu Yunchuan authored
No need cast (void *) to (struct ath5k_hw *). Signed-off-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Wu Yunchuan authored
No need cast (void *) to other types such as (struct wcn36xx *), (struct wcn36xx_hal_update_scan_params_resp *), etc. Signed-off-by:
-
Wu Yunchuan authored
No need cast (void*) to (struct ar5523_cmd_hdr *). Signed-off-by:
-
Dongliang Mu authored
In ath9k_hif_usb_resume, the error handling code calls ath9k_hif_usb_dealloc_urbs twice in different paths. To unify the error handling code, we move the else branch before the if branch and drop one level of indentation of the if branch. In addition, move the ret variable at the end of variable declarations to be reverse x-mas tree order. Note that this patch does not incur any functionability change. Signed-off-by:
Dongliang Mu <dzm91@hust.edu.cn> Reviewed-by:
Dan Carpenter <dan.carpenter@linaro.org> Acked-by:
Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by:
-
Baochen Qiang authored
In ath12k_dp_tx(), if we reach fail_dma_unmap due to some errors, current code does DMA unmap unconditionally on skb_cb->paddr_ext_desc. However, skb_cb->paddr_ext_desc may be NULL and thus we get below warning: kernel: [ 8887.076212] WARNING: CPU: 3 PID: 0 at drivers/iommu/dma-iommu.c:1077 iommu_dma_unmap_page+0x79/0x90 Fix it by checking skb_cb->paddr_ext_desc before unmap it. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Fixes: d8899132 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by:
-
Baochen Qiang authored
reg_cap.phy_id is extracted from WMI event and could be an unexpected value in case some errors happen. As a result out-of-bound write may occur to soc->hal_reg_cap. Fix it by validating reg_cap.phy_id before using it. This is found during code review. Compile tested only. Signed-off-by:
-
- Sep 20, 2023
-
-
Dmitry Antipov authored
When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/ath/ath10k/debug.c:8: In file included from ./include/linux/module.h:13: In file included from ./include/linux/stat.h:19: In file included from ./include/linux/time.h:60: In file included from ./include/linux/time32.h:13: In file included from ./include/linux/timex.h:67: In file included from ./arch/x86/include/asm/timex.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'ath10k_debug_get_et_strings()' where fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole 'ath10k_gstrings_stats' array from it's first member and so issues an overread warning. This warning may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by: -
Wen Gong authored
Sometimes board-2.bin does not have the board data which matched the parameters such as bus type, vendor, device, subsystem-vendor, subsystem-device, qmi-chip-id and qmi-board-id, then wlan will load fail. Hence add another type which only matches the bus type and qmi-chip-id, then the ratio of missing board data reduced. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Signed-off-by:
Wen Gong <quic_wgong@quicinc.com> Signed-off-by:
-
Baochen Qiang authored
len is extracted from HTT message and could be an unexpected value in case errors happen, so add validation before using to avoid possible out-of-bound read in the following message iteration and parsing. The same issue also applies to ppdu_info->ppdu_stats.common.num_users, so validate it before using too. These are found during code review. Compile test only. Signed-off-by:
-
Wen Gong authored
Sometimes device recovery fail with this operation. Run test command for many times: echo assert > /sys/kernel/debug/ath12k/wcn7850\ hw2.0_0000\:03\:00.0/simulate_fw_crash While recovery start, ath12k_core_post_reconfigure_recovery() will call ieee80211_restart_hw(), and the restart_work which queued by ieee80211_restart_hw() is running in another thread, it will call into ath12k_mac_op_start() and ath12k_mac_wait_reconfigure(), and the variables ab->recovery_start_count and ab->recovery_start is used in ath12k_mac_wait_reconfigure(), so ath12k need to initialize the variables before queue the restart_work, otherwise ath12k_mac_wait_reconfigure() maybe use the un-initialized variables. Change to initialize the 2 variables earlier and then recovery process become correct. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by:
-
Wen Gong authored
320 MHz bandwidth is reported only for single PHY mode for WCN7850, get it from WMI_HOST_HW_MODE_SINGLE ath12k_wmi_caps_ext_params and report it for 6 GHz band. After this patch, "iw list" shows 320 MHz support for WCN7850: EHT Iftypes: managed EHT PHY Capabilities: (0xe26f090010768800): 320MHz in 6GHz Supported EHT bw=320 MHz, max NSS for MCS 8-9: Rx=0, Tx=0 EHT bw=320 MHz, max NSS for MCS 10-11: Rx=0, Tx=0 EHT bw=320 MHz, max NSS for MCS 12-13: Rx=0, Tx=0 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by: -
Dmitry Antipov authored
When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/ath/ath9k/debug.c:17: In file included from ./include/linux/slab.h:16: In file included from ./include/linux/gfp.h:7: In file included from ./include/linux/mmzone.h:8: In file included from ./include/linux/spinlock.h:56: In file included from ./include/linux/preempt.h:79: In file included from ./arch/x86/include/asm/preempt.h:9: In file included from ./include/linux/thread_info.h:60: In file included from ./arch/x86/include/asm/thread_info.h:53: In file included from ./arch/x86/include/asm/cpufeature.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); In file included from drivers/net/wireless/ath/ath9k/htc_drv_debug.c:17: In file included from drivers/net/wireless/ath/ath9k/htc.h:20: In file included from ./include/linux/module.h:13: In file included from ./include/linux/stat.h:19: In file included from ./include/linux/time.h:60: In file included from ./include/linux/time32.h:13: In file included from ./include/linux/timex.h:67: In file included from ./arch/x86/include/asm/timex.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'ath9k_get_et_strings()' and 'ath9k_htc_get_et_strings()' due to the same reason: fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole array from it's first member and so issues an overread warning. These warnings may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by: -
Dmitry Antipov authored
Since both 'ar9550_hw_get_modes_txgain_index()' and 'ar9561_hw_get_modes_txgain_index()' never returns negative values, prefer 'u32' over 'int' and adjust 'ar9003_hw_process_ini()' accordingly. Suggested-by:
-
Dmitry Antipov authored
Since commit 8896934c ("ath9k_hw: remove direct accesses to channel mode flags") changes 'ar9550_hw_get_modes_txgain_index()' so it never returns -EINVAL, and 'ar9561_hw_get_modes_txgain_index()' never returns negative value too, an extra check in 'ar9003_hw_process_ini()' may be dropped. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by:
-
Manish Dharanenthiran authored
Radar detection fails in the secondary 80 MHz when the the AP's primary 80 MHz is in non-DFS region in 160 MHz. This is due to WMI channel flag WMI_CHAN_INFO_DFS_FREQ2 is not set properly in case of the primary 80 MHz is in non-DFS region. HALPHY detects the radar pulses in the secondary 80 MHz only when WMI_CHAN_INFO_DFS_FREQ2 is set. Fix this issue by setting WMI channel flag WMI_CHAN_INFO_DFS_FREQ2 based on the radar_enabled flag from the channel context. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Manish Dharanenthiran <quic_mdharane@quicinc.com> Signed-off-by:
-
Manish Dharanenthiran authored
Fix WARN_ON() from ath12k_mac_update_vif_chan() if vdev is not up. Since change_chanctx can be called even before vdev_up. Do vdev stop followed by a vdev start in case of vdev is down. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-02903-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
- Sep 05, 2023
-
-
Muna Sinada authored
Correct parsing of reading offset for rx tid 16 bit bitmap. Incorrect offset caused peer rx mu stats tid bitmap to always be zero. This correction is in the software context and does not affect the firmware interface. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00356-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Muna Sinada <quic_msinada@quicinc.com> Acked-by:
-
Muna Sinada authored
Remove references to reserved fields and add new info fields for struct hal_rx_ppdu_end_user_stats. Reserved fields should not be accessed, therefore existing references to it are to be changed to referencing specific info fields. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-00356-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Harshitha Prem authored
When max virtual ap interfaces are configured in all the bands with ACS and hostapd restart is done every 60s, a crash is observed at random times because of handling the uninitialized peer fragments with fragment id of packet as 0. "__fls" would have an undefined behavior if the argument is passed as "0". Hence, added changes to handle the same. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d8899132 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by:
Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by:
-
Harshitha Prem authored
When max virtual ap interfaces are configured in all the bands with ACS and hostapd restart is done every 60s, a crash is observed at random times. In the above scenario, a fragmented packet is received for self peer, for which rx_tid and rx_frags are not initialized in datapath. While handling this fragment, crash is observed as the rx_frag list is uninitialized and when we walk in ath12k_dp_rx_h_sort_frags, skb null leads to exception. To address this, before processing received fragments we check dp_setup_done flag is set to ensure that peer has completed its dp peer setup for fragment queue, else ignore processing the fragments. Call trace: PC points to "ath12k_dp_process_rx_err+0x4e8/0xfcc [ath12k]" LR points to "ath12k_dp_process_rx_err+0x480/0xfcc [ath12k]". The Backtrace obtained is as follows: ath12k_dp_process_rx_err+0x4e8/0xfcc [ath12k] ath12k_dp_service_srng+0x78/0x260 [ath12k] ath12k_pci_write32+0x990/0xb0c [ath12k] __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0/0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: -
Arowa Suliman authored
Currently, the ath11k driver does not print a crash signature when a MHI_CB_EE_RDDM crash happens. Checked by triggering a simulated crash using the command and checking dmesg for logs: echo assert > /sys/kernel/debug/ath11k/../simulate_fw_crash Add a warning when firmware crash MHI_CB_EE_RDDM happens. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Signed-off-by:
Arowa Suliman <arowa@chromium.org> Reviewed-by:
-
- Aug 26, 2023
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-08-24 (igc, e1000e) This series contains updates to igc and e1000e drivers. Vinicius adds support for utilizing multiple PTP registers on igc. Sasha reduces interval time for PTM on igc and adds new device support on e1000e. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: e1000e: Add support for the next LOM generation igc: Decrease PTM short interval from 10 us to 1 us igc: Add support for multiple in-flight TX timestamps ==================== Link: https://lore.kernel.org/r/20230824204418.1551093-1-anthony.l.nguyen@intel.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Donald Hunter authored
Add del operation to the spec to help with testing. Signed-off-by:
Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20230824142221.71339-1-donald.hunter@gmail.com Signed-off-by:
-
Jakub Kicinski authored
We use a tempfile for code generation, to avoid wiping the target file out if the code generator crashes. File contents are copied from tempfile to actual destination at the end of main(). uAPI generation is relatively simple so when generating the uAPI header we return from main() early, and never reach the "copy code over" stage. Since commit under Fixes uAPI headers are not updated by ynl-gen. Move the copy/commit of the code into CodeWriter, to make it easier to call at any point in time. Hook it into the destructor to make sure we don't miss calling it. Fixes: f65f305a ("tools: ynl-gen: use temporary file for rendering") Link: https://lore.kernel.org/r/20230824212431.1683612-1-kuba@kernel.org Signed-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== stmmac cleanups One of the comments I had on Feiyang Chen's series was concerning the initialisation of phylink... and so I've decided to do something about it, cleaning it up a bit. This series: 1) adds a new phylink function to limit the MAC capabilities according to a maximum speed. This allows us to greatly simplify stmmac's initialisation of phylink's mac capabilities. 2) everywhere that uses priv->plat->phylink_node first converts this to a fwnode before doing anything with it. This is silly. Let's instead store it as a fwnode to eliminate these conversions in multiple places. 3) clean up passing the fwnode to phylink - it might as well happen at the phylink_create() callsite, rather than being scattered throughout the entire function. 4) same for mdio_bus_data 5) use phylink_limit_mac_speed() to handle the priv->plat->max_speed restriction. 6) add a method to get the MAC-specific capabilities from the code dealing with the MACs, and arrange to call it at an appropriate time. 7) convert the gmac4 users to use the MAC specific method. 8) same for xgmac. 9) group all the simple phylink_config initialisations together. 10) convert half-duplex logic to being positive logic. While looking into all of this, this raised eyebrows: if (priv->plat->tx_queues_to_use > 1) priv->phylink_config.mac_capabilities &= ~(MAC_10HD | MAC_100HD | MAC_1000HD); priv->plat->tx_queues_to_use is initialised by platforms to either 1, 4 or 8, and can be controlled from userspace via the --set-channels ethtool op. The implementation of this op in this driver limits the number of channels to priv->dma_cap.number_tx_queues, which is derived from the DMA hwcap. So, the obvious questions are: 1) what guarantees that the static initialisation of tx_queues_to_use will always be less than or equal to number_tx_queues from the DMA hw cap? 2) tx_queues_to_use starts off as 1, but number_tx_queues is larger, we will leave the half-duplex capabilities in place, but userspace can increase tx_queues_to_use above 1. Does that mean half-duplex is then not supported? 3) Should we be basing the decision whether half-duplex is supported off the DMA capabilities? 4) What about priv->dma_cap.half_duplex? Doesn't that get a say in whether half-duplex is supported or not? Why isn't this used? Why is it only reported via debugfs? If it's not being used by the driver, what's the point of reporting it via debugfs? ==================== Link: https://lore.kernel.org/r/ZOddFH22PWmOmbT5@shell.armlinux.org.uk Signed-off-by: -
Russell King (Oracle) authored
Rather than detecting when half-duplex is not supported, and clearing the MAC capabilities, reverse the if() condition and use it to set the capabilities instead. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qZAXn-005pUb-SP@rmk-PC.armlinux.org.uk Signed-off-by:
-
Russell King (Oracle) authored
Move priv->phylink_config.mac_managed_pm to be along side the other phylink initialisations. Signed-off-by:
-
Russell King (Oracle) authored
Move the xgmac specific phylink capabilities to the dwxgmac2 support core. Signed-off-by:
-
Russell King (Oracle) authored
Move the setup of gmac4 speicifc phylink capabilities into gmac4 code. Signed-off-by:
-
Russell King (Oracle) authored
Allow MACs to provide their own capabilities via the MAC operations struct. Signed-off-by:
-
Russell King (Oracle) authored
Use phylink_limit_mac_speed() to limit the MAC capabilities rather than coding this for each speed. Signed-off-by:
-
