summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2024-02-05nfp: enable NETDEV_XDP_ACT_REDIRECT feature flagJames Hershaw
Enable previously excluded xdp feature flag for NFD3 devices. This feature flag is required in order to bind nfp interfaces to an xdp socket and the nfp driver does in fact support the feature. Fixes: 66c0e13ad236 ("drivers: net: turn on XDP features") Cc: stable@vger.kernel.org # 6.3+ Signed-off-by: James Hershaw <james.hershaw@corigine.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-05nfp: flower: prevent re-adding mac index for bonded portDaniel de Villiers
When physical ports are reset (either through link failure or manually toggled down and up again) that are slaved to a Linux bond with a tunnel endpoint IP address on the bond device, not all tunnel packets arriving on the bond port are decapped as expected. The bond dev assigns the same MAC address to itself and each of its slaves. When toggling a slave device, the same MAC address is therefore offloaded to the NFP multiple times with different indexes. The issue only occurs when re-adding the shared mac. The nfp_tunnel_add_shared_mac() function has a conditional check early on that checks if a mac entry already exists and if that mac entry is global: (entry && nfp_tunnel_is_mac_idx_global(entry->index)). In the case of a bonded device (For example br-ex), the mac index is obtained, and no new index is assigned. We therefore modify the conditional in nfp_tunnel_add_shared_mac() to check if the port belongs to the LAG along with the existing checks to prevent a new global mac index from being re-assigned to the slave port. Fixes: 20cce8865098 ("nfp: flower: enable MAC address sharing for offloadable devs") CC: stable@vger.kernel.org # 5.1+ Signed-off-by: Daniel de Villiers <daniel.devilliers@corigine.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-05nfp: use correct macro for LengthSelect in BAR configDaniel Basilio
The 1st and 2nd expansion BAR configuration registers are configured, when the driver starts up, in variables 'barcfg_msix_general' and 'barcfg_msix_xpb', respectively. The 'LengthSelect' field is ORed in from bit 0, which is incorrect. The 'LengthSelect' field should start from bit 27. This has largely gone un-noticed because NFP_PCIE_BAR_PCIE2CPP_LengthSelect_32BIT happens to be 0. Fixes: 4cb584e0ee7d ("nfp: add CPP access core") Cc: stable@vger.kernel.org # 4.11+ Signed-off-by: Daniel Basilio <daniel.basilio@corigine.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-04tun: Implement ethtool's get_channels() callbackYunjian Wang
Implement the tun .get_channels functionality. This feature is necessary for some tools, such as libxdp, which need to retrieve the queue count. Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-04hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missedShradha Gupta
If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe. Cc: stable@vger.kernel.org Fixes: 85520856466e ("hv_netvsc: Fix race of register_netdevice_notifier and VF register") Suggested-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-04r8169: add support for RTL8126AHeiner Kallweit
This adds support for the RTL8126A found on Asus z790 Maximus Formula. It was successfully tested w/o the firmware at 1000Mbps. Firmware file has been provided by Realtek and submitted to linux-firmware. 2.5G and 5G modes are untested. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-04net: micrel: Fix the frequency adjustmentsHoratiu Vultur
By default lan8841's 1588 clock frequency is 125MHz. But when adjusting the frequency, it is using the 1PPM format of the lan8814. Which is the wrong format as lan8814 has a 1588 clock frequency of 250MHz. So then for each 1PPM adjustment would adjust less than expected. Therefore fix this by using the correct 1PPM format for lan8841. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-04wifi: iwlwifi: mvm: fix warnings from dmi_get_system_info()Johannes Berg
dmi_get_system_info() will statically return NULL when the kernel is compiled without CONFIG_DMI, leading to compiler warnings. Fix that by printing "<unknown>" in that case. Fixes: c3f40c3e0273 ("iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed") Fixes: 9457077df49e ("wifi: iwlwifi: mvm: Add debugfs to get TAS status") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-04wifi: iwlwifi: fw: fix compiler warning for NULL string printJohannes Berg
When the system is compiled without CONFIG_DMI, the function here statically returns NULL, leading to a compiler warning. Catch that and print "<unknown>" in that case. While at it, fix some indentation in the function. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402030641.zUTuACYV-lkp@intel.com/ Fixes: 09059c6764a8 ("wifi: iwlwifi: prepare for reading PPAG table from UEFI") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-04wifi: iwlwifi: fw: fix compile w/o CONFIG_ACPIJohannes Berg
The user of this function passes a pointer to a value that doesn't exist when compiled w/o CONFIG_ACPI. Since we don't need the value then, make the non-ACPI version a macro to allow it to still build. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402031454.syX4cSGN-lkp@intel.com/ Fixes: c4c954547755 ("wifi: iwlwifi: implement WPFC ACPI table loading") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-03net: phy: qcom: qca808x: default to LED active High if not setChristian Marangi
qca808x PHY provide support for the led_polarity_set OP to configure and apply the active-low property but on PHY reset, the Active High bit is not set resulting in the LED driven as active-low. To fix this, check if active-low is not set in DT and enable Active High polarity by default to restore correct funcionality of the LED. Fixes: 7196062b64ee ("net: phy: at803x: add LED support for qca808x") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-03net: phy: qcom: qca808x: fix logic error in LED brightness setChristian Marangi
In switching to using phy_modify_mmd and a more short version of the LED ON/OFF condition in later revision, it was made a logic error where value ? QCA808X_LED_FORCE_ON : QCA808X_LED_FORCE_OFF is always true as value is always OR with QCA808X_LED_FORCE_EN due to missing () resulting in the testing condition being QCA808X_LED_FORCE_EN | value. Add the () to apply the correct condition and restore correct functionality of the brightness ON/OFF. Fixes: 7196062b64ee ("net: phy: at803x: add LED support for qca808x") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-03octeontx2-pf: Fix a memleak otx2_sq_initZhipeng Lu
When qmem_alloc and pfvf->hw_ops->sq_aq_init fails, sq->sg should be freed to prevent memleak. Fixes: c9c12d339d93 ("octeontx2-pf: Add support for PTP clock") Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn> Acked-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-03tsnep: Fix mapping for zero copy XDP_TX actionGerhard Engleder
For XDP_TX action xdp_buff is converted to xdp_frame. The conversion is done by xdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame depends on the memory type of the xdp_buff. For page pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy XSK pool based xdp_buff it produces xdp_frame with memory type MEM_TYPE_PAGE_ORDER0. tsnep_xdp_xmit_back() is not prepared for that and uses always the page pool buffer type TSNEP_TX_TYPE_XDP_TX. This leads to invalid mappings and the transmission of undefined data. Improve tsnep_xdp_xmit_back() to use the generic buffer type TSNEP_TX_TYPE_XDP_NDO for zero copy XDP_TX. Fixes: 3fc2333933fd ("tsnep: Add XDP socket zero-copy RX support") Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-02r8169: simplify EEE handlingHeiner Kallweit
We don't have to store the EEE modes to be advertised in the driver, phylib does this for us and stores it in phydev->advertising_eee. phylib also takes care of properly handling the EEE advertisement. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/27c336a8-ea47-483d-815b-02c45ae41da2@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-02net: atlantic: Fix DMA mapping for PTP hwts ringIvan Vecera
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic] Fixes: 94ad94558b0f ("net: aquantia: add PTP rings infrastructure") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240201094752.883026-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-02net: phy: realtek: add support for RTL8126A-integrated 5Gbps PHYHeiner Kallweit
A user reported that first consumer mainboards show up with a RTL8126A 5Gbps MAC/PHY. This adds support for the integrated PHY, which is also available stand-alone. From a PHY driver perspective it's treated the same as the 2.5Gbps PHY's, we just have to support the new PHY ID. Reported-by: Joe Salmeri <jmscdba@gmail.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Joe Salmeri <jmscdba@gmail.com> Link: https://lore.kernel.org/r/0c8e67ea-6505-43d1-bd51-94e7ecd6e222@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-02netdevsim: avoid potential loop in nsim_dev_trap_report_work()Eric Dumazet
Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> Fixes: 012ec02ae441 ("netdevsim: convert driver to use unlocked devlink API during init/fini") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240201175324.3752746-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-02ice: remove incorrect commentPaul M Stillwell Jr
Copy paste issue left a comment for this structure that has nothing to do with FW alignment; remove the comment. Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-02-02ice: Add a new counter for Rx EIPE errorsAniruddha Paul
HW incorrectly reports EIPE errors on encapsulated packets with L2 padding inside inner packet. HW shows outer UDP/IPV4 packet checksum errors as part of the EIPE flags of the Rx descriptor. These are reported only if checksum offload is enabled and L3/L4 parsed flag is valid in Rx descriptor. When that error is reported by HW, we don't act on it instead of incrementing main Rx errors statistic as it would normally happen. Add a new statistic to count these errors since we still want to print them. Signed-off-by: Aniruddha Paul <aniruddha.paul@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Jan Glaza <jan.glaza@intel.com> Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-02-02ice: make ice_vsi_cfg_txq() staticMaciej Fijalkowski
Currently, XSK control path in ice driver calls directly ice_vsi_cfg_txq() whereas we have ice_vsi_cfg_single_txq() for that purpose. Use the latter from XSK side and make ice_vsi_cfg_txq() static. ice_vsi_cfg_txq() resides in ice_base.c and is rather big, so to reduce the code churn let us move the callers of it from ice_lib.c to ice_base.c. This change puts ice_qp_ena() on nice diet due to the checks and operations that ice_vsi_cfg_single_{r,t}xq() do internally. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-182 (-182) Function old new delta ice_xsk_pool_setup 2165 1983 -182 Total: Before=472597, After=472415, chg -0.04% Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Acked-by: Magnus Karlsson <magnus.karlsson@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-02-02ice: make ice_vsi_cfg_rxq() staticMaciej Fijalkowski
Currently, XSK control path in ice driver calls directly ice_vsi_cfg_rxq() whereas we have ice_vsi_cfg_single_rxq() for that purpose. Use the latter from XSK side and make ice_vsi_cfg_rxq() static. ice_vsi_cfg_rxq() resides in ice_base.c and is rather big, so to reduce the code churn let us move two callers of it from ice_lib.c to ice_base.c. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Acked-by: Magnus Karlsson <magnus.karlsson@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-02-02wifi: brcmfmac: Adjust n_channels usage for __counted_byKees Cook
After commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by"), the compiler may enforce dynamic array indexing of req->channels to stay below n_channels. As a result, n_channels needs to be increased _before_ accessing the newly added array index. Increment it first, then use "i" for the prior index. Solves this warning in the coming GCC that has __counted_by support: ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 'brcmf_internal_escan_add_info': ../drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:3783:46: warning: operation on 'req-> n_channels' may be undefined [-Wsequence-point] 3783 | req->channels[req->n_channels++] = chan; | ~~~~~~~~~~~~~~~^~ Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Cc: Arend van Spriel <aspriel@gmail.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Chi-hsien Lin <chi-hsien.lin@infineon.com> Cc: Ian Lin <ian.lin@infineon.com> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Wright Feng <wright.feng@cypress.com> Cc: Hector Martin <marcan@marcan.st> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240126223150.work.548-kees@kernel.org
2024-02-02wifi: iwlwifi: mvm: make functions publicShaul Triebitz
In the following patch, iwl_mvm_roc_duration_and_delay and iwl_mvm_roc_add_cmd will be called also from time-event.c. Move then there (where they more belong) and make then public. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240201155157.3edafc4d59aa.Ic68e90758bcad9ae00e0aa602101842dac60e1a1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: bump FW API to 88 for AX/BZ/SC devicesMiri Korenblit
Start supporting API version 88 for new devices. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.e35556d3f956.I6543857041a33e2b35e67eecf648c9cc6972e60a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: mvm: don't send BT_COEX_CI command on new devicesEmmanuel Grumbach
AX210 and above have this logic offloaded in the firmware and it just ignores the command coming from the driver. Stop sending it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240201155157.4e3e0b52f98b.I7e9481050921d95c38f5a21ccc47112b3698e859@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: read DSM functions from UEFIMiri Korenblit
For each DSM function, try to first read it from the UEFI. If the UEFI WIFI GUID is unclocked, or the DSM function in UEFI is invalid/unavailable - read it from ACPI. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.27dd626ce2bd.Ib90bab74a9d56deb2362edb712294360e4ddae5b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: prepare for reading DSM from UEFIMiri Korenblit
Move all the common items (functions, enumerations and mcaros) to regulatory.h/c files, and rename it to a common name. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.eae9bcbc0023.If1175f3143d6369076669ddd5d6ad4df0ee00659@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: simplify getting DSM from ACPIMiri Korenblit
As DSMs are going to be read from UEFI too, we need a unified API to get DSMs for both ACPI and UEFI. The difference in getting DSM in each one of these methods (ACPI, UEFI) is in the GUID, revision (0 for ACPI, 4 for UEFI), and size of the DSM values (8 or 32 for ACPI, 32 for UEFI). Therefore, change the iwl_acpi_get_dsm_x() to iwl_acpi_get_dsm() which determines the GUID, revision (these two are the same for all WiFi DSMs), and size (based on a func-to-size mapping) internally. While at it, fix DSM_FUNC_RFI_CONFIG to expect a 32-bit value (as defined in Intel BIOS spec) and not a 8-bit one. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.1bcd7072a7a5.I344ee0a11abbc27da0c693187d1b8bee653aaeef@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: take send-DSM-to-FW flows out of ACPI ifdefMiri Korenblit
These functions shouldn't be ACPI_CONFIG dependent, as they don't access the ACPI. The functions that really access ACPI - already handle the case that CONFIG_ACPI is not set. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.1412e6d561f8.I84f67478d01b576457e1bf489fbcb044adfda6fe@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: rfi: use a single DSM function for all RFI configurationsMiri Korenblit
RFI configuration moved from internal guid to the wifi guid, DSM function 11. Update reading RFI configuration from BIOS. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.f4e62435310d.I4f9b6860dd8e3c7ae1f816be5ff8b5967eee266f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: read ECKV table from UEFIMiri Korenblit
Try to read the ECKV table from UEFI first, and if the WIFI UEFI tables are unlocked or the table doesn't exist - try to read it from ACPI. Change iwl_acpi_get_eckv() to receive fwrt as argument so it will be the same as all iwl_acpi_get_x() functions, so it could be generated by the macro. While at it - move the reading of ECKV to INIT stage. There is no reason to read it each time we load the FW. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.d4937cc00727.I36e5fc7f7850229b9b377c80b5203aa47137c97c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: read WRDD table from UEFIMiri Korenblit
Try to read the WRDD table from UEFI first, and if the WIFI UEFI tables are unlocked or the table doesn't exist - try to read it from ACPI. Change iwl_acpi_get_mcc() to receive fwrt as argument so it will be the same as all iwl_acpi_get_x() functions, so it could be generated by the macro. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.5d52eeb109f7.I4d81700a7ae7fe2dfee14e363de358be59de7823@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: support link command version 2Shaul Triebitz
In version 2, listen_lmac becomes reserved. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240201155157.df1890aba2fd.Icad9ba10f8bab770adc6a559b2c7bff5cccbffe9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: mvm: use fast balance scan in case of an active P2P GOAyala Beker
Set fast balance scan in case of active P2P GO, regardless of the BSS DTIM interval. This will increase the chances of scheduler to successfully schedule out-of-channel events. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240201155157.310a00388e11.Ib136140dffa8704e68ff14e8fb69d35b97057171@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: mvm: don't send NDPs for new tx devicesEmmanuel Grumbach
New tx devices may have issues sending NDPs from the host. Send a CQM event instead. If the AP is really gone, we will get a beacon loss and disconnect. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Reviewed-by: Berg, Johannes <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240201155157.e95d53448e94.I0ec92f1ca56a62cd8c13390b9fe60e9a7e9411c7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: read SPLC from UEFIMiri Korenblit
Try to read the SPLC table from UEFI first, and if the WIFI UEFI tables are unlocked or the table doesn't exist - try to read it from ACPI Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.3d9d835b6edb.I7ea262df9431ced787b77c87149c6d7bddb7e7d6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: prepare for reading SPLC from UEFIMiri Korenblit
As the iwl_bios_get_x() functions are now generated using a macro, and this macro requires the all iwl_acpi_get_x() to have the same prototype, change iwl_acpi_get_pwr_limit() to return a int and the actuall power limit will be filled in a pointer function parameter. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.4cce81198afe.Ice8b1b97a68da9ec7b5a4799ddb668642198e1af@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: do not announce EPCS supportBenjamin Berg
mac80211 does not have proper support for EPCS currently as that would require changing the ECDA parameters if EPCS (Emergency Preparedness Communications Service) is in use. As such, do not announce support for it in the capabilities. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240201155157.59d71656addc.Idde91b3018239c49fc6ed231b411d05354fb9fb1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: exit eSR only after the FW doesMiri Korenblit
Currently the driver exits eSR by calling iwl_mvm_esr_mode_inactive() before updating the FW (by deactivating one of the links), and therefore before sending the EML frame notifying that we are no longer in eSR. This is wrong for several reasons: 1. The driver sends SMPS activation frames when we are still in eSR and SMPS should be disabled when in eSR 2. The driver restores RLC configuration as it was before eSR entering, and RLC command shouldn't be sent in eSR Fix this by calling iwl_mvm_esr_mode_inactive() after FW update Fixes: 12bacfc2c065 ("wifi: iwlwifi: handle eSR transitions") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240201155157.d8d9dc277d4e.Ib5aee0fd05e35b1da7f18753eb3c8fa0a3f872f3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: api: clean up some kernel-doc/typosJohannes Berg
Add some kernel-doc for a union, and fix a couple of typos I noticed looking through this. Link: https://msgid.link/20240131220227.7fd507f09bb1.I278edc9a3d5de7fddcd84009a93c494c42686b68@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: remove unused function prototypeJohannes Berg
Saw this while going through the code, this function hasn't existed for a while now; remove it. Link: https://msgid.link/20240131220039.6fdb8cbf4814.I6c46065b836cafd93df676dd88c99a626a25bf46@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02iwlwifi: fw: fix more kernel-doc warningsEmmanuel Grumbach
Fix some more kernel-doc warnings in FW API definitions. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://msgid.link/20240131213817.9f30c6529216.I69e98612c6c81cf1b7bd480d8041b5d3e25610d3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: mac80211_hwsim: enable all links only in MLOMiri Korenblit
The existing code is enabling all usable links when moving to authorized state, but this should happen only for MLO connections. Fix this. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240129200054.f5459f6c29c8.I397814449e17950fcf882ef44a1e790a71aa1dce@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: mac80211_hwsim: add control to skip beaconsJohannes Berg
To test certain beacon loss scenarios it can be useful to simply not send a couple of beacons. Add a simple debugfs file (per vif) to skip sending the beacons. They're still fully prepared etc. so their DTIM count etc. will appear as if they were simply corrupt over the air or otherwise not received. Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://msgid.link/20240129200001.a267383709e6.I36f427d17c3478a7df46e205716f5ebc9b35a918@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: read WTAS table from UEFIMiri Korenblit
Try to read the WTAS table from UEFI first, and if the WIFI UEFI tables are unlocked or the table doesn't exist - try to read it from ACPI. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240131091413.45e6ff7b5063.Id3aec70887e14533b10d564f32c0cf5f2a14b792@changeid [move uefi_tables_lock_status outside ifdef to fix build errors] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: separate TAS 'read-from-BIOS' and 'send-to-FW' flowsMiri Korenblit
Currently the TAS 'read-from-BIOS' flow receives the command struct and the version of it as read from FW TLVs, and fills the command accordingly. This seems wrong, we should have the 'read-from-BIOS' flow (iwl_acpi_get_tas in iwlwifi) reading/parsing/validating the table from BIOS, and the 'send-to-FW' flow (iwl_mvm_tas_init) doing all the FW versioning checks and cmd filling. Move the cmd filling to the 'send-to-fw' flow. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240131091413.24df27772a71.I57b702af4feb3f38dc21d52593c25de4b1999e4b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: prepare for reading TAS table from UEFIMiri Korenblit
We are going to support reading BIOS tables from UEFI too, Refactor the TAS table flow: 1. Rename and move the common code to the regulatory.h/c files. 2. Remove the IWL_TAS_BLOCK_LIST_MAX, as we can use IWL_WTAS_BLACK_LIST_MAX instead. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240131091413.0c2197cf1feb.Ib0e83d5bd3f4d5cfa9c3d2925317ba49377d257f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: don't check TAS block list size twiceMiri Korenblit
Currenltly we check the validity of this variable twice. Remove the second check. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240131091413.2234490624c4.I6399b652a3c83afff1b0b5f114604d15892ee01e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-02-02wifi: iwlwifi: read PPAG table from UEFIMiri Korenblit
Try to read the PPAG table from UEFI first, and if the WIFI UEFI tables are unlocked or the table doesn't exist - try to read it from ACPI Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://msgid.link/20240131091413.6516da09aec1.I0dcaf0b6d8857417ba1318467a28da5d0d7d7f27@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit (git 2.34.1) at 2025-09-13 13:01:33 +0000