summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-05-06wifi: iwlwifi: mld: tests: extend link pair testsJohannes Berg
Generalize and extend the link pair tests to not just do channel load checks, but generally check link pairs. To enable more accurate checking, return the reasons bitmap from iwl_mld_valid_emlsr_pair() and therefore rename it to iwl_mld_emlsr_pair_state. It's also necessary now to add more chandefs, and while doing so fix the existing ones to be valid and add a test to check they really are valid. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250430151952.1f7c4ac75c6d.I69d68359e02d99632e95daba3d126115dce167b3@changeid
2025-05-06wifi: iwlwifi: mld: refactor tests to use chandefsJohannes Berg
Instead of building invalid chandefs on the fly, use only chandefs throughout and ensure those are valid. Also add more chandefs that will be needed for new tests. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250430151952.6643fa8773f1.I644e9053d222a772e1d109799c4bfa0677add4d7@changeid
2025-05-06wifi: iwlwifi: mld: send the WPFC table to the FWMiri Korenblit
Read the table on op mode start, and send it to the FW when it is loaded. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250430151952.e349a33cd871.Ied196cf0fbe18b82b87ce713c4e3347f9aca1c25@changeid
2025-05-06wifi: iwlwifi: read WPFC also from UEFIMiri Korenblit
We are currently reading it only from ACPI, but we need to read it from UEFI too (if exists, and if the UEFI variables are locked) Add the reading from the UEFI and use IWL_BIOS_TABLE_LOADER to generate the code that determines the source from which the table should be read (ACPI/UEFI). Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250430151952.839a5e7dd89b.I491acbf68047874df97b3971f1ba692ebc998a52@changeid
2025-05-06wifi: iwlwifi: prepare for reading WPFC from UEFIMiri Korenblit
IWL_BIOS_TABLE_LOADER generates the code that determines from what source to read a BIOS table (ACPI or UEFI). As we want to read WPFC from UEFI to, iwl_acpi_get_phy_filters needs to have the prototype that is required by this macro: receive fwrt and return a int on success/failure. Do that. This allowes us to make to version of iwl_acpi_get_phy_filters for non ACPI builds back to an iniline function. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Link: https://patch.msgid.link/20250430151952.8046a2db775b.Ifbcf4168183d3cd635e3e800ec7ecd903e57d361@changeid
2025-05-06wifi: iwlwifi: Add short description to enum iwl_power_schemeJeff Johnson
The kernel-doc script flagged the following: drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:130: warning: missing initial short description on line: * enum iwl_power_scheme 1 warnings as Errors Add a short description to address this warning. Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250319-iwl_power_scheme-kdoc-v1-1-2033ae38b178@oss.qualcomm.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-05-06can: mcan: m_can_class_unregister(): fix order of unregistration callsMarc Kleine-Budde
If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-3-59a9b131589d@pengutronix.de Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-05-06can: rockchip_canfd: rkcanfd_remove(): fix order of unregistration callsMarc Kleine-Budde
If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-2-59a9b131589d@pengutronix.de Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-05-06can: mcp251xfd: mcp251xfd_remove(): fix order of unregistration callsMarc Kleine-Budde
If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. With the mcp251xfd driver the removal of the module causes the following warning: | WARNING: CPU: 0 PID: 352 at net/core/dev.c:7342 __netif_napi_del_locked+0xc8/0xd8 as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-1-59a9b131589d@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-05-06can: mcp251xfd: fix TDC setting for low data bit ratesKelsey Maes
The TDC is currently hardcoded enabled. This means that even for lower CAN-FD data bitrates (with a DBRP (data bitrate prescaler) > 2) a TDC is configured. This leads to a bus-off condition. ISO 11898-1 section 11.3.3 says "Transmitter delay compensation" (TDC) is only applicable if DBRP is 1 or 2. To fix the problem, switch the driver to use the TDC calculation provided by the CAN driver framework (which respects ISO 11898-1 section 11.3.3). This has the positive side effect that userspace can control TDC as needed. Demonstration of the feature in action: | $ ip link set can0 up type can bitrate 125000 dbitrate 500000 fd on | $ ip -details link show can0 | 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 | link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 | can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 | bitrate 125000 sample-point 0.875 | tq 50 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 10 brp 2 | mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1 | dbitrate 500000 dsample-point 0.875 | dtq 125 dprop-seg 6 dphase-seg1 7 dphase-seg2 2 dsjw 1 dbrp 5 | mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1 | tdcv 0..63 tdco 0..63 | clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0 | $ ip link set can0 up type can bitrate 1000000 dbitrate 4000000 fd on | $ ip -details link show can0 | 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 | link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 | can <FD,TDC-AUTO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 | bitrate 1000000 sample-point 0.750 | tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 5 brp 1 | mcp251xfd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp_inc 1 | dbitrate 4000000 dsample-point 0.700 | dtq 25 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1 dbrp 1 | tdco 7 | mcp251xfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp_inc 1 | tdcv 0..63 tdco 0..63 | clock 40000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0 There has been some confusion about the MCP2518FD using a relative or absolute TDCO due to the datasheet specifying a range of [-64,63]. I have a custom board with a 40 MHz clock and an estimated loop delay of 100 to 216 ns. During testing at a data bit rate of 4 Mbit/s I found that using can_get_relative_tdco() resulted in bus-off errors. The final TDCO value was 1 which corresponds to a 10% SSP in an absolute configuration. This behavior is expected if the TDCO value is really absolute and not relative. Using priv->can.tdc.tdco instead results in a final TDCO of 8, setting the SSP at exactly 80%. This configuration works. The automatic, manual, and off TDC modes were tested at speeds up to, and including, 8 Mbit/s on real hardware and behave as expected. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reported-by: Kelsey Maes <kelsey@vpprocess.com> Closes: https://lore.kernel.org/all/C2121586-C87F-4B23-A933-845362C29CA1@vpprocess.com Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Kelsey Maes <kelsey@vpprocess.com> Link: https://patch.msgid.link/20250430161501.79370-1-kelsey@vpprocess.com [mkl: add comment] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-05-06can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probeAntonios Salios
The spin lock tx_handling_spinlock in struct m_can_classdev is not being initialized. This leads the following spinlock bad magic complaint from the kernel, eg. when trying to send CAN frames with cansend from can-utils: | BUG: spinlock bad magic on CPU#0, cansend/95 | lock: 0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Hardware name: MachineWare SIM-V (DT) | Call Trace: | [<ffffffff800133e0>] dump_backtrace+0x1c/0x24 | [<ffffffff800022f2>] show_stack+0x28/0x34 | [<ffffffff8000de3e>] dump_stack_lvl+0x4a/0x68 | [<ffffffff8000de70>] dump_stack+0x14/0x1c | [<ffffffff80003134>] spin_dump+0x62/0x6e | [<ffffffff800883ba>] do_raw_spin_lock+0xd0/0x142 | [<ffffffff807a6fcc>] _raw_spin_lock_irqsave+0x20/0x2c | [<ffffffff80536dba>] m_can_start_xmit+0x90/0x34a | [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee | [<ffffffff8065b730>] sch_direct_xmit+0x114/0x292 | [<ffffffff80614e2a>] __dev_queue_xmit+0x3b0/0xaa8 | [<ffffffff8073b8fa>] can_send+0xc6/0x242 | [<ffffffff8073d1c0>] raw_sendmsg+0x1a8/0x36c | [<ffffffff805ebf06>] sock_write_iter+0x9a/0xee | [<ffffffff801d06ea>] vfs_write+0x184/0x3a6 | [<ffffffff801d0a88>] ksys_write+0xa0/0xc0 | [<ffffffff801d0abc>] __riscv_sys_write+0x14/0x1c | [<ffffffff8079ebf8>] do_trap_ecall_u+0x168/0x212 | [<ffffffff807a830a>] handle_exception+0x146/0x152 Initializing the spin lock in m_can_class_allocate_dev solves that problem. Fixes: 1fa80e23c150 ("can: m_can: Introduce a tx_fifo_in_flight counter") Signed-off-by: Antonios Salios <antonios@mwa.re> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250425111744.37604-2-antonios@mwa.re Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-05-06net: ethernet: mtk_eth_soc: do not reset PSE when setting FEFrank Wunderlich
Remove redundant PSE reset. When setting FE register there is no need to reset PSE, doing so may cause FE to work abnormal. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/3a5223473e086a4b54a2b9a44df7d9ddcc2bc75a Fixes: dee4dd10c79aa ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Link: https://patch.msgid.link/18f0ac7d83f82defa3342c11ef0d1362f6b81e88.1746406763.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ethernet: mtk_eth_soc: reset all TX queues on DMA freeDaniel Golle
The purpose of resetting the TX queue is to reset the byte and packet count as well as to clear the software flow control XOFF bit. MediaTek developers pointed out that netdev_reset_queue would only resets queue 0 of the network device. Queues that are not reset may cause unexpected issues. Packets may stop being sent after reset and "transmit timeout" log may be displayed. Import fix from MediaTek's SDK to resolve this issue. Link: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/319c0d9905579a46dc448579f892f364f1f84818 Fixes: f63959c7eec31 ("net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/c9ff9adceac4f152239a0f65c397f13547639175.1746406763.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: phy: realtek: Add support for PHY LEDs on RTL8211EMichael Klein
Like the RTL8211F, the RTL8211E PHY supports up to three LEDs. Add netdev trigger support for them, too. Signed-off-by: Michael Klein <michael@fossekall.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250504172916.243185-7-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: phy: realtek: use __set_bit() in rtl8211f_led_hw_control_get()Michael Klein
rtl8211f_led_hw_control_get() does not need atomic bit operations, replace set_bit() by __set_bit(). Signed-off-by: Michael Klein <michael@fossekall.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250504172916.243185-6-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: phy: realtek: Group RTL82* macro definitionsMichael Klein
Group macro definitions by PHY in lexicographic order. Within each PHY block, definitions are order by page number and then register number. Signed-off-by: Michael Klein <michael@fossekall.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250504172916.243185-5-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: phy: realtek: add RTL8211F register definesMichael Klein
Add some more defines for RTL8211F page and register numbers. Signed-off-by: Michael Klein <michael@fossekall.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250504172916.243185-4-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: phy: realtek: Clean up RTL821x ExtPage accessMichael Klein
Factor out RTL8211E extension page access code to rtl821x_modify_ext_page() and clean up rtl8211e_config_init() Signed-off-by: Michael Klein <michael@fossekall.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250504172916.243185-3-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: phy: realtek: remove unsed RTL821x_PHYSR* macrosMichael Klein
These macros have there since the first revision but were never used, so let's just remove them. Signed-off-by: Michael Klein <michael@fossekall.de> Link: https://patch.msgid.link/20250504172916.243185-2-michael@fossekall.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06eth: fbnic: fix `tx_dropped` countingMohsin Bashir
Fix the tracking of rtnl_link_stats.tx_dropped. The counter `tmi.drop.frames` is being double counted whereas, the counter `tti.cm_drop.frames` is being skipped. Fixes: f2957147ae7a ("eth: fbnic: add support for TTI HW stats") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20250503020145.1868252-1-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ibmveth: added KUnit tests for some buffer pool functionsDave Marquardt
Added KUnit tests for ibmveth_remove_buffer_from_pool and ibmveth_rxq_get_buffer under new IBMVETH_KUNIT_TEST config option. Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250501194944.283729-4-davemarq@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ibmveth: Reset the adapter when unexpected states are detectedDave Marquardt
Reset the adapter through new function ibmveth_reset, called in WARN_ON situations. Removed conflicting and unneeded forward declaration. Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Link: https://patch.msgid.link/20250501194944.283729-3-davemarq@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-06net: ibmveth: Indented struct ibmveth_adapter correctlyDave Marquardt
Made struct ibmveth_adapter follow indentation rules Signed-off-by: Dave Marquardt <davemarq@linux.ibm.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250501194944.283729-2-davemarq@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-05-05net: phy: Refactor fwnode_get_phy_node()Andy Shevchenko
Refactor to check if the fwnode we got is correct and return if so, otherwise do additional checks. Using same pattern in all conditionals makes it slightly easier to read and understand. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250430143802.3714405-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()Jakub Kicinski
The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Acked-by: Jason Wang <jasowang@redhat.com> Fixes: e9f3962441c0 ("virtio_net: xsk: rx: support fill with xsk buffer") Link: https://patch.msgid.link/20250430163836.3029761-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05virtio-net: don't re-enable refill work too early when NAPI is disabledJakub Kicinski
Commit 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") fixed a deadlock between reconfig paths and refill work trying to disable the same NAPI instance. The refill work can't run in parallel with reconfig because trying to double-disable a NAPI instance causes a stall under the instance lock, which the reconfig path needs to re-enable the NAPI and therefore unblock the stalled thread. There are two cases where we re-enable refill too early. One is in the virtnet_set_queues() handler. We call it when installing XDP: virtnet_rx_pause_all(vi); ... virtnet_napi_tx_disable(..); ... virtnet_set_queues(..); ... virtnet_rx_resume_all(..); We want the work to be disabled until we call virtnet_rx_resume_all(), but virtnet_set_queues() kicks it before NAPIs were re-enabled. The other case is a more trivial case of mis-ordering in __virtnet_rx_resume() found by code inspection. Taking the spin lock in virtnet_set_queues() (requested during review) may be unnecessary as we are under rtnl_lock and so are all paths writing to ->refill_enabled. Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Bui Quang Minh <minhquangbui99@gmail.com> Fixes: 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") Fixes: 413f0271f396 ("net: protect NAPI enablement with netdev_lock()") Link: https://patch.msgid.link/20250430163758.3029367-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-05wifi: rtw89: constrain TX power according to dynamic antenna power tableKuan-Chung Chen
Dynamic Antenna Gain (DAG) adjusts TX power based on antenna gain. To prevent signal distortion from excessive power increases, a dynamic antenna power table limits the maximum adjustable TX power. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250430055157.13623-3-pkshih@realtek.com
2025-05-05wifi: rtw89: phy: add C2H event handler for report of FW scanKuan-Chung Chen
Newer firmware will notify driver of the Packet Detection (PD) value on the channel after switch channels during FW scan. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250430055157.13623-2-pkshih@realtek.com
2025-05-05wifi: rtw89: Fix inadverent sharing of struct ieee80211_supported_band dataOndrej Jirman
Internally wiphy writes to individual channels in this structure, so we must not share one static definition of channel list between multiple device instances, because that causes hard to debug breakage. For example, with two rtw89 driven devices in the system, channel information may get incoherent, preventing channel use. Signed-off-by: Ondrej Jirman <megi@xff.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250429122916.1734879-3-megi@xff.cz
2025-05-05wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*Ondrej Jirman
The code can be simplified by using device managed memory allocations. Simplify it. Signed-off-by: Ondrej Jirman <megi@xff.cz> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250429122916.1734879-2-megi@xff.cz
2025-05-05wifi: rtw89: introduce helper to get designated link for MLOZong-Zhe Yang
A link bound to HW band 0 was previously always assumed to exist, because it's true on non-MLD connection, and MLO connection is not supported yet. Now, start to consider MLO cases and prepare to enable MLO support in the following. Add skeleton of designated link. For single-link cases, helper returns the one. For multi-link cases, priorities can be scheduled. Then, drop assumption of link bound to HW band 0. One exception is that MCC doesn't work with MLD yet, so it still expects link on HW band 0 somewhere. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-11-pkshih@realtek.com
2025-05-05wifi: rtw89: roc: dynamically handle link id and link instance indexZong-Zhe Yang
Originally, a macro, RTW89_ROC_BY_LINK_INDEX, is used to decide the link which deals with the ROC process. Before enabling MLO support, it's fine to hard-code RTW89_ROC_BY_LINK_INDEX as 0 since the link instance-0 (on HW-0) is always active. But, for the impending enablement of MLO support, tweak the leaf functions to dynamically handle ROC link instance index. Besides, in the follow-up, ROC caller will get a designated link and will then drop RTW89_ROC_BY_LINK_INDEX. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-10-pkshih@realtek.com
2025-05-05wifi: rtw89: Fill in correct Rx link ID for MLOPo-Hao Huang
For MLO connections, RX link ID is required to do address conversion. Fill it in by the hardware info. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-9-pkshih@realtek.com
2025-05-05wifi: rtw89: add MLD capabilities declarationPo-Hao Huang
Add MLD capabilities so association requests can carry multi-link element with correct content. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-8-pkshih@realtek.com
2025-05-05wifi: rtw89: extend join_info H2C command for MLO fieldsPo-Hao Huang
The join_info H2C command is used to indicate a station is connected and tell FW to create/maintain an instance for it. Extend to fill MLO fields. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-7-pkshih@realtek.com
2025-05-05wifi: rtw89: Configure scan band when mlo_dbcc_mode changesPo-Hao Huang
Previously only the first band is used for scanning. With MLO, update scan parameters accordingly by so we can choose to scan from either band. C2H event return value reflects current scanning band, mask it out so we don't treat correct return value as fail. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-6-pkshih@realtek.com
2025-05-05wifi: rtw89: extend mapping from Qsel to DMA ch for MLOZong-Zhe Yang
After impending MLO support, TX Qsel would come from other HW band rather than HW-0. For example, when working on HW-1, TX release report may fill QSEL_XX_1 and cause warning "Cannot map qsel to dma: ...". So, extend the mapping to recognize multiple HW bands. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-5-pkshih@realtek.com
2025-05-05wifi: rtw89: Adjust management queue mapping for [MLO, HW-1]Po-Hao Huang
Adjust mapping of management packets accordingly to send it on the second hardware band. Previously only single band is used and we plan to enable MLO, so the second band will be needed. Data packets will be steered by hardware so no related changes are required. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-4-pkshih@realtek.com
2025-05-05wifi: rtw89: 8922a: use SW CRYPTO when broadcast in MLO modePo-Hao Huang
8922A doesn't support broadcast/multicast traffic under MLO mode. So let mac80211 do the encryption/decryption for us when the connection is in MLO mode. Future BE ICs fixes this issue. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-3-pkshih@realtek.com
2025-05-05wifi: rtw89: 8922a: rfk: adjust timeout time of RX DCKPing-Ke Shih
The RX DCK in firmware could retry 3 times if calibration value is not stable. Roughly each calibration can be done within 16 ms, so expect 16 * 4 (with additional 16 ms) will be enough. More, in coming MLO, it will do calibration on two path, so multiply 2. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250428112456.13165-2-pkshih@realtek.com
2025-05-05wifi: rtw89: fw: Remove "const" on allocation typeKees Cook
In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct rtw89_reg2_def *" but the returned type, while technically matching, will be const qualified. As there isn't a general way to discard "const" qualifiers, adjust the returned type to match the assigned type. No change in allocation size results. Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250426060935.work.049-kees@kernel.org
2025-05-05wifi: rtlwifi: Remove unused rtl_bb_delay()Dr. David Alan Gilbert
The last use of rtl_bb_delay() was removed in 2014's commit 5c99f04fec93 ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-4-linux@treblig.org
2025-05-05wifi: rtlwifi: Remove uncalled stub rtl*_phy_ap_calibrateDr. David Alan Gilbert
rtl92d_phy_ap_calibrate(), rtl92du_phy_ap_calibrate(), rtl92ee_phy_ap_calibrate(), and rtl8821ae_phy_ap_calibrate() are all empty function stubs that are never called anywhere. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-3-linux@treblig.org
2025-05-05wifi: rtlwifi: Remove unused rtl_usb_{resume|suspend}Dr. David Alan Gilbert
rtl_usb_resume() and rtl_usb_suspend() are trivial stubs that were added in 2011's commit 2ca20f79e0d8 ("rtlwifi: Add usb driver") but aren't wired up anywhere (though commit 442888c706e9 ("rtlwifi: rtl8192cu: Add routines dm, fw, led and sw") added commented out assignments). Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250425235340.288340-2-linux@treblig.org
2025-05-02net: stmmac: remove speed_mode_2500() methodRussell King (Oracle)
Remove the speed_mode_2500() platform method which is no longer used or necessary, being superseded by the more flexible get_interfaces() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASM3-0021R3-2B@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: stmmac: intel: convert speed_mode_2500() to get_interfaces()Russell King (Oracle)
TGL platforms support either SGMII or 2500BASE-X, which is determined by reading a SERDES register. Thus, plat->phy_interface (and phylink's supported_interfaces) depend on this. Use the new .get_interfaces() method to set both plat->phy_interface and the supported_interfaces bitmap. This removes the only user of the .speed_mode_2500() method. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLx-0021Qs-Uz@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: stmmac: intel: move phy_interface init to tgl_common_data()Russell King (Oracle)
Move the initialisation of plat->phy_interface to tgl_common_data() as all callers set this same interface mode. This moves it to a single location to make the change to get_interfaces() more obvious. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLs-0021Qk-Qt@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: stmmac: add get_interfaces() platform methodRussell King (Oracle)
Add a get_interfaces() platform method to allow platforms to indicate to phylink which interface modes they support - which then allows phylink to validate on initialisation that the configured PHY interface mode is actually supported. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uASLn-0021Qd-Mi@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: stmmac: use priv->plat->phy_interface directlyRussell King (Oracle)
Avoid using a local variable for priv->plat->phy_interface as this may be modified in the .get_interfaces() method added in a future commit. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLi-0021QX-HG@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-02net: stmmac: use a local variable for priv->phylink_configRussell King (Oracle)
Use a local variable for priv->phylink_config in stmmac_phy_setup() which makes the code a bit easier to read, allowing some lines to be merged. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1uASLd-0021QR-Cu@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-07-16 00:29:49 +0000