aboutsummaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2024-06-19octeontx2-pf: Add error handling to VLAN unoffload handlingSimon Horman1-1/+4
otx2_sq_append_skb makes used of __vlan_hwaccel_push_inside() to unoffload VLANs - push them from skb meta data into skb data. However, it omitts a check for __vlan_hwaccel_push_inside() returning NULL. Found by inspection based on [1] and [2]. Compile tested only. [1] Re: [PATCH net-next v1] net: stmmac: Enable TSO on VLANs https://lore.kernel.org/all/[email protected]/ [2] Re: [PATCH net-next v2] net: stmmac: Enable TSO on VLANs https://lore.kernel.org/all/CANn89i+11L5=tKsa7V7Aeyxaj6nYGRwy35PAbCRYJ73G+b25sg@mail.gmail.com/ Fixes: fd9d7859db6c ("octeontx2-pf: Implement ingress/egress VLAN offload") Signed-off-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: ti: icss-iep: Enable compare eventsDiogo Ivo1-0/+74
The IEP module supports compare events, in which a value is written to a hardware register and when the IEP counter reaches the written value an interrupt is generated. Add handling for this interrupt in order to support PPS events. Reviewed-by: Wojciech Drewek <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: ti: icss-iep: Remove spinlock-based synchronizationDiogo Ivo1-14/+0
As all sources of concurrency in hardware register access occur in non-interrupt context eliminate spinlock-based synchronization and rely on the mutex-based synchronization that is already present. Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: ti: icssg-prueth: Enable PTP timestamping support for SR1.0 devicesDiogo Ivo1-1/+50
Enable PTP support for AM65x SR1.0 devices by registering with the IEP infrastructure in order to expose a PTP clock to userspace. Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19virtio_net: fixing XDP for fully checksummed packets handlingHeng Qi1-1/+19
The XDP program can't correctly handle partially checksummed packets, but works fine with fully checksummed packets. If the device has already validated fully checksummed packets, then the driver doesn't need to re-validate them, saving CPU resources. Additionally, the driver does not drop all partially checksummed packets when VIRTIO_NET_F_GUEST_CSUM is not negotiated. This is not a bug, as the driver has always done this. Fixes: 436c9453a1ac ("virtio-net: keep vnet header zeroed after processing XDP") Signed-off-by: Heng Qi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19virtio_net: checksum offloading handling fixHeng Qi1-2/+10
In virtio spec 0.95, VIRTIO_NET_F_GUEST_CSUM was designed to handle partially checksummed packets, and the validation of fully checksummed packets by the device is independent of VIRTIO_NET_F_GUEST_CSUM negotiation. However, the specification erroneously stated: "If VIRTIO_NET_F_GUEST_CSUM is not negotiated, the device MUST set flags to zero and SHOULD supply a fully checksummed packet to the driver." This statement is inaccurate because even without VIRTIO_NET_F_GUEST_CSUM negotiation, the device can still set the VIRTIO_NET_HDR_F_DATA_VALID flag. Essentially, the device can facilitate the validation of these packets' checksums - a process known as RX checksum offloading - removing the need for the driver to do so. This scenario is currently not implemented in the driver and requires correction. The necessary specification correction[1] has been made and approved in the virtio TC vote. [1] https://lists.oasis-open.org/archives/virtio-comment/202401/msg00011.html Fixes: 4f49129be6fa ("virtio-net: Set RXCSUM feature if GUEST_CSUM is available") Signed-off-by: Heng Qi <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-19net: usb: ax88179_178a: improve reset checkJose Ignacio Tornos Martinez1-5/+13
After ecf848eb934b ("net: usb: ax88179_178a: fix link status when link is set to down/up") to not reset from usbnet_open after the reset from usbnet_probe at initialization stage to speed up this, some issues have been reported. It seems to happen that if the initialization is slower, and some time passes between the probe operation and the open operation, the second reset from open is necessary too to have the device working. The reason is that if there is no activity with the phy, this is "disconnected". In order to improve this, the solution is to detect when the phy is "disconnected", and we can use the phy status register for this. So we will only reset the device from reset operation in this situation, that is, only if necessary. The same bahavior is happening when the device is stopped (link set to down) and later is restarted (link set to up), so if the phy keeps working we only need to enable the mac again, but if enough time passes between the device stop and restart, reset is necessary, and we can detect the situation checking the phy status register too. cc: [email protected] # 6.6+ Fixes: ecf848eb934b ("net: usb: ax88179_178a: fix link status when link is set to down/up") Reported-by: Yongqin Liu <[email protected]> Reported-by: Antje Miederhöfer <[email protected]> Reported-by: Arne Fitzenreiter <[email protected]> Tested-by: Yongqin Liu <[email protected]> Tested-by: Antje Miederhöfer <[email protected]> Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-18net: mana: Add support for page sizes other than 4KB on ARM64Haiyang Zhang5-23/+24
As defined by the MANA Hardware spec, the queue size for DMA is 4KB minimal, and power of 2. And, the HWC queue size has to be exactly 4KB. To support page sizes other than 4KB on ARM64, define the minimal queue size as a macro separately from the PAGE_SIZE, which we always assumed it to be 4KB before supporting ARM64. Also, add MANA specific macros and update code related to size alignment, DMA region calculations, etc. Signed-off-by: Haiyang Zhang <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net/mlx4_en: Use ethtool_puts/sprintf to fill stats stringsKamal Heib1-35/+17
Use the ethtool_puts/ethtool_sprintf helper to print the stats strings into the ethtool strings interface. Signed-off-by: Kamal Heib <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net/mlx4_en: Use ethtool_puts to fill selftest stringsKamal Heib1-2/+2
Use the ethtool_puts helper to print the selftest strings into the ethtool strings interface. Signed-off-by: Kamal Heib <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net/mlx4_en: Use ethtool_puts to fill priv flags stringsKamal Heib1-2/+1
Use the ethtool_puts helper to print the priv flags strings into the ethtool strings interface. Signed-off-by: Kamal Heib <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net: stmmac: No need to calculate speed divider when offload is disabledXiaolei Wang1-18/+22
commit be27b8965297 ("net: stmmac: replace priv->speed with the portTransmitRate from the tc-cbs parameters") introduced a problem. When deleting, it prompts "Invalid portTransmitRate 0 (idleSlope - sendSlope)" and exits. Add judgment on cbs.enable. Only when offload is enabled, speed divider needs to be calculated. Fixes: be27b8965297 ("net: stmmac: replace priv->speed with the portTransmitRate from the tc-cbs parameters") Signed-off-by: Xiaolei Wang <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net: phy: dp83tg720: get master/slave configuration in link down stateOleksij Rempel1-3/+21
Get master/slave configuration for initial system start with the link in down state. This ensures ethtool shows current configuration. Also fixes link reconfiguration with ethtool while in down state, preventing ethtool from displaying outdated configuration. Even though dp83tg720_config_init() is executed periodically as long as the link is in admin up state but no carrier is detected, this is not sufficient for the link in admin down state where dp83tg720_read_status() is not periodically executed. To cover this case, we need an extra read role configuration in dp83tg720_config_aneg(). Fixes: cb80ee2f9bee1 ("net: phy: Add support for the DP83TG720S Ethernet PHY") Cc: [email protected] Signed-off-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net: phy: dp83tg720: wake up PHYs in managed modeOleksij Rempel1-3/+15
In case this PHY is bootstrapped for managed mode, we need to manually wake it. Otherwise no link will be detected. Cc: [email protected] Fixes: cb80ee2f9bee1 ("net: phy: Add support for the DP83TG720S Ethernet PHY") Signed-off-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-18net: microchip: Constify struct vcap_operationsChristophe JAILLET5-5/+5
"struct vcap_operations" are not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do it, "struct vcap_control" also needs to be adjusted to this new const qualifier. As an example, on a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 15176 1094 16 16286 3f9e drivers/net/ethernet/microchip/lan966x/lan966x_vcap_impl.o After: ===== text data bss dec hex filename 15268 998 16 16282 3f9a drivers/net/ethernet/microchip/lan966x/lan966x_vcap_impl.o Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Daniel Machon <[email protected]> Link: https://lore.kernel.org/r/d8e76094d2e98ebb5bfc8205799b3a9db0b46220.1718524644.git.christophe.jaillet@wanadoo.fr Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18net: phy: introduce core support for phy-mode = "10g-qxgmii"Vladimir Oltean2-1/+9
10G-QXGMII is a MAC-to-PHY interface defined by the USXGMII multiport specification. It uses the same signaling as USXGMII, but it multiplexes 4 ports over the link, resulting in a maximum speed of 2.5G per port. Some in-tree SoCs like the NXP LS1028A use "usxgmii" when they mean either the single-port USXGMII or the quad-port 10G-QXGMII variant, and they could get away just fine with that thus far. But there is a need to distinguish between the 2 as far as SerDes drivers are concerned. Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: Luo Jie <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18net: stmmac: Enable TSO on VLANsFurong Xu1-13/+19
The TSO engine works well when the frames are not VLAN Tagged. But it will produce broken segments when frames are VLAN Tagged. The first segment is all good, while the second segment to the last segment are broken, they lack of required VLAN tag. An example here: ======== // 1st segment of a VLAN Tagged TSO frame, nothing wrong. MacSrc > MacDst, ethertype 802.1Q (0x8100), length 1518: vlan 100, p 1, ethertype IPv4 (0x0800), HostA:42643 > HostB:5201: Flags [.], seq 1:1449 // 2nd to last segments of a VLAN Tagged TSO frame, VLAN tag is missing. MacSrc > MacDst, ethertype IPv4 (0x0800), length 1514: HostA:42643 > HostB:5201: Flags [.], seq 1449:2897 MacSrc > MacDst, ethertype IPv4 (0x0800), length 1514: HostA:42643 > HostB:5201: Flags [.], seq 2897:4345 MacSrc > MacDst, ethertype IPv4 (0x0800), length 1514: HostA:42643 > HostB:5201: Flags [.], seq 4345:5793 MacSrc > MacDst, ethertype IPv4 (0x0800), length 1514: HostA:42643 > HostB:5201: Flags [P.], seq 5793:7241 // normal VLAN Tagged non-TSO frame, nothing wrong. MacSrc > MacDst, ethertype 802.1Q (0x8100), length 1022: vlan 100, p 1, ethertype IPv4 (0x0800), HostA:42643 > HostB:5201: Flags [P.], seq 7241:8193 MacSrc > MacDst, ethertype 802.1Q (0x8100), length 70: vlan 100, p 1, ethertype IPv4 (0x0800), HostA:42643 > HostB:5201: Flags [F.], seq 8193 ======== When transmitting VLAN Tagged TSO frames, never insert VLAN tag by HW, always insert VLAN tag to SKB payload, then TSO works well on VLANs for all MAC cores. Tested on DWMAC CORE 5.10a, DWMAC CORE 5.20a and DWXGMAC CORE 3.20a Signed-off-by: Furong Xu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18wifi: wilc1000: disable SDIO func IRQ before suspendAlexis Lothoré1-0/+3
Issuing a system suspend command raises the following warning: WARNING: CPU: 0 PID: 15 at drivers/mmc/core/sdio.c:1042 mmc_sdio_suspend+0xd4/0x19c CPU: 0 PID: 15 Comm: kworker/u2:1 Not tainted 6.7.0-rc1-wt+ #710 Hardware name: Atmel SAMA5 Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from __warn+0x98/0x160 __warn from warn_slowpath_fmt+0xcc/0x140 warn_slowpath_fmt from mmc_sdio_suspend+0xd4/0x19c mmc_sdio_suspend from mmc_bus_suspend+0x50/0x70 mmc_bus_suspend from dpm_run_callback+0xe4/0x248 dpm_run_callback from __device_suspend+0x234/0x91c __device_suspend from async_suspend+0x24/0x9c async_suspend from async_run_entry_fn+0x6c/0x210 async_run_entry_fn from process_one_work+0x3a0/0x870 [...] This warning is due to a check in SDIO core ensuring that interrupts do not remain enabled for cards being powered down during suspend. WILC driver currently does not set the MMC_PM_KEEP_POWER flag, so disable interrupt when entering resume. Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wilc1000: remove suspend/resume from cfg80211 partAlexis Lothoré3-24/+2
WILC1000 suspend/resume implementation is currently composed of two parts: suspend/resume ops implemented in cfg80211 ops, which merely sets a flag, and suspend/resume ops in sdio/spi driver which, based on this flag, execute or not the suspend/resume mechanism. This dual set of ops is not really needed , so keep only the sdio part to implement suspend/resume. While doing so, remove the now unused suspend_event flag. Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wilc1000: move sdio suspend method next to resume and pm ops definitionAlexis Lothoré1-24/+23
Just move the suspend method next to the resume method in the sdio part Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wilc1000: do not keep sdio bus claimed during suspend/resumeAlexis Lothoré1-2/+0
There is no reason to keep the MMC host claimed during suspend. Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wilc1000: let host->chip suspend/resume notifications manage chip ↵Alexis Lothoré2-9/+4
wake/sleep host_wakeup_notify and host_sleep_notify are surrounded by chip_wakeup and chip_allow_sleep calls, which theorically need to be protected with the hif_cs lock. This lock protection is currently missing. Instead of adding the lock where those two functions are called, move those in host->chip suspend notifications to benefit from the lock already used there (in bus_acquire/bus_release) Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wilc1000: disable power sequencerAjay Singh2-16/+0
Driver systematically disables some power mechanism each time it starts the chip firmware (so mostly when interface is brought up). This has a negative impact on some specific scenarios when the chip is exposed as a hotpluggable SDIO card (eg: WILC1000 SD): - when executing suspend/resume sequence while interface has been brought up - rebooting the platform while module is plugged and interface has been brought up Those scenarios lead to mmc core trying to initialize again the chip which is now unresponsive (because of the power sequencer setting), so it fails in mmc_rescan->mmc_attach_sdio and enter a failure loop while trying to send CMD5: mmc0: error -110 whilst initialising SDIO card mmc0: error -110 whilst initialising SDIO card mmc0: error -110 whilst initialising SDIO card [...] Preventing the driver from disabling this "power sequencer" fixes those enumeration issues without affecting nominal operations. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wl18xx: allow firmwares > 8.9.0.x.58Russell King (Oracle)1-1/+1
wlcore firmware versions are structured thusly: chip.if-type.major.sub-type.minor e.g. 8 9 0 0 58 With WL18xx ignoring the major firmware version, looking for a firmware version that conforms to: chip >= 8 if-type >= 9 major (don't care) sub-type (don't care) minor >= 58 Each test is satisfied if the value read from the firmware is greater than the minimum, but if it is equal (or we don't care about the field), then the next field is checked. Thus it doesn't recognise 8.9.1.x.0 as being newer than 8.9.0.x.58 since the major and sub-type numbers are "don't care" and the minor needs to be greater or equal to 58. We need to change the major version from "ignore" to "0" for this later firmware to be correctly detected, and allow the dual-firmware version support to work. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wl18xx: add support for reading 8.9.1 fw statusRussell King (Oracle)2-2/+129
Add the necessary code to read the 8.9.1 firmware status into the driver private status structure, augmenting the 8.9.0 firmware status code. New structure layout taken from: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0023-wlcore-Fixing-PN-drift-on-encrypted-link-after-recov.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7 Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wlcore: add pn16 supportRussell King (Oracle)3-5/+97
TI Wl18xx firmware adds a "pn16" field for AES and TKIP keys as per their patch: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0023-wlcore-Fixing-PN-drift-on-encrypted-link-after-recov.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7 Add support for this, but rather than requiring the field to be present (which would break existing firmwares), make it optional. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wlcore: store AP encryption key typeRussell King (Oracle)1-0/+4
Updates for WL18xx firmware 8.9.1.x.x need to know the AP encryption key type. Store this when a new key is set. Patch extracted from: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0023-wlcore-Fixing-PN-drift-on-encrypted-link-after-recov.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7 Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wlcore: pass "status" to wlcore_hw_convert_fw_status()Russell King (Oracle)1-1/+1
wlcore_fw_status() is passed a pointer to the struct wl_fw_status to decode the status into, which is always wl->fw_status. Rather than referencing wl->fw_status within wlcore_fw_status(), use the supplied argument so that we access this member in a consistent manner. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wlcore: improve code in wlcore_fw_status()Russell King (Oracle)1-4/+4
Referring to status->counters.tx_lnk_free_pkts[i] multiple times leads to less efficient code. Cache this value in a local variable. This also makes the code clearer. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wl18xx: make wl18xx_tx_immediate_complete() more efficientRussell King (Oracle)1-3/+10
wl18xx_tx_immediate_complete() iterates through the completed transmit descriptors in a circular fashion, and in doing so uses a modulus operation that is not a power of two. This leads to inefficient code generation, which can be easily solved by providing a helper to increment to the next descriptor. Use this more efficient solution. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18wifi: wlcore: correctness fix fwlog readingRussell King (Oracle)1-1/+1
Fix the calculation of clear_offset, which may overflow the end of the buffer. However, this is harmless if it does because in that case it will be recalculated when we copy the chunk of messages at the start of the buffer. Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-18net: phy: mxl-gpy: Remove interrupt mask clearing from config_initRaju Lakkaraju1-20/+38
When the system resumes from sleep, the phy_init_hw() function invokes config_init(), which clears all interrupt masks and causes wake events to be lost in subsequent wake sequences. Remove interrupt mask clearing from config_init() and preserve relevant masks in config_intr(). Fixes: 7d901a1e878a ("net: phy: add Maxlinear GPY115/21x/24x driver") Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Raju Lakkaraju <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18net: lan743x: Support WOL at both the PHY and MAC appropriatelyRaju Lakkaraju3-8/+58
Prevent options not supported by the PHY from being requested to it by the MAC Whenever a WOL option is supported by both, the PHY is given priority since that usually leads to better power savings. Fixes: e9e13b6adc33 ("lan743x: fix for potential NULL pointer dereference with bare card") Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Raju Lakkaraju <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18net: lan743x: disable WOL upon resume to restore full data path operationRaju Lakkaraju2-4/+50
When Wake-on-LAN (WoL) is active and the system is in suspend mode, triggering a system event can wake the system from sleep, which may block the data path. To restore normal data path functionality after waking, disable all wake-up events. Furthermore, clear all Write 1 to Clear (W1C) status bits by writing 1's to them. Fixes: 4d94282afd95 ("lan743x: Add power management support") Reviewed-by: Wojciech Drewek <[email protected]> Signed-off-by: Raju Lakkaraju <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18qca_spi: Make interrupt remembering atomicStefan Wahren3-14/+11
The whole mechanism to remember occurred SPI interrupts is not atomic, which could lead to unexpected behavior. So fix this by using atomic bit operations instead. Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000") Signed-off-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2024-06-18wifi: wlcore: fix wlcore AP modeRussell King (Oracle)4-21/+16
Using wl183x devices in AP mode with various firmwares is not stable. The driver currently adds a station to firmware with basic rates when it is first known to the stack using the CMD_ADD_PEER command. Once the station has finished authorising, another CMD_ADD_PEER command is issued to update the firmware with the rates the station can use. However, after a random amount of time, the firmware ignores the power management nullfunc frames from the station, and tries to send packets while the station is asleep, resulting in lots of retries dropping down in rate due to no response. This restricts the available bandwidth. With this happening with several stations, the user visible effect is the latency of interactive connections increases significantly, packets get dropped, and in general the WiFi connections become unreliable and unstable. Eventually, the firmware transmit queue appears to get stuck - with packets and blocks allocated that never clear. TI have a couple of patches that address this, but they touch the mac80211 core to disable NL80211_FEATURE_FULL_AP_CLIENT_STATE for *all* wireless drivers, which has the effect of not adding the station to the stack until later when the rates are known. This is a sledge hammer approach to solving the problem. The solution implemented here has the same effect, but without impacting all drivers. We delay adding the station to firmware until it has been authorised in the driver, and correspondingly remove the station when unwinding from authorised state. Adding the station to firmware allocates a hlid, which will now happen later than the driver expects. Therefore, we need to track when this happens so that we transmit using the correct hlid. This patch is an equivalent fix to these two patches in TI's wilink8-wlan repository: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0004-mac80211-patch.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7 https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0005-wlcore-patch.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7 Reported-by: Russell King (Oracle) <[email protected]> Co-developed-by: Johannes Berg <[email protected]> Tested-by: Russell King (Oracle) <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17net: dwc-xlgmac: fix missing MODULE_DESCRIPTION() warningJeff Johnson2-7/+5
With ARCH=hexagon, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/net/ethernet/synopsys/dwc-xlgmac.o With most other ARCH settings the MODULE_DESCRIPTION() is provided by the macro invocation in dwc-xlgmac-pci.c. However, for hexagon, the PCI bus is not enabled, and hence CONFIG_DWC_XLGMAC_PCI is not set. As a result, dwc-xlgmac-pci.c is not compiled, and hence is not linked into dwc-xlgmac.o. To avoid this issue, relocate the MODULE_DESCRIPTION() and other related macros from dwc-xlgmac-pci.c to dwc-xlgmac-common.c, since that file already has an existing MODULE_LICENSE() and it is unconditionally linked into dwc-xlgmac.o. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/20240616-md-hexagon-drivers-net-ethernet-synopsys-v1-1-55852b60aef8@quicinc.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-17net: mana: Use mana_cleanup_port_context() for rxq cleanupShradha Gupta1-4/+2
To cleanup rxqs in port context structures, instead of duplicating the code, use existing function mana_cleanup_port_context() which does the exact cleanup that's needed. Signed-off-by: Shradha Gupta <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Wei Liu <[email protected]> Reviewed-by: Heng Qi <[email protected]> Link: https://lore.kernel.org/r/1718349548-28697-1-git-send-email-shradhagupta@linux.microsoft.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-17wifi: ath12k: Remove unused ath12k_base from ath12k_hwHarshitha Prem2-3/+0
Currently, device (ab) reference in hardware abstraction (ah) is not used anywhere. Also, with multiple device group abstraction, hardware abstraction would be coupled with device group abstraction rather than single device. Hence, remove the ab reference from hardware abstraction. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Harshitha Prem <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: ath12k: Fix WARN_ON during firmware crash in split-phyAaradhana Sahu3-39/+8
Whenever firmware is crashed in split-phy below WARN_ON() triggered: WARNING: CPU: 3 PID: 82 at net/mac80211/driver-ops.c:41 drv_stop+0xac/0xbc Modules linked in: ath12k qmi_helpers CPU: 3 PID: 82 Comm: kworker/3:2 Tainted: G D W 6.9.0-next-20240520-00113-gd981a3784e15 #39 Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C9 (DT) Workqueue: events_freezable ieee80211_restart_work pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drv_stop+0xac/0xbc lr : ieee80211_stop_device+0x54/0x64 sp : ffff8000848dbb20 x29: ffff8000848dbb20 x28: 0000000000000790 x27: ffff000014d78900 x26: ffff000014d791f8 x25: ffff000007f0d9b0 x24: 0000000000000018 x23: 0000000000000001 x22: 0000000000000000 x21: ffff000014d78e10 x20: ffff800081dc0000 x19: ffff000014d78900 x18: ffffffffffffffff x17: ffff7fffbca84000 x16: ffff800083fe0000 x15: ffff800081dc0b48 x14: 0000000000000076 x13: 0000000000000076 x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff8000848db980 x8 : ffff000000dddfc0 x7 : 0000000000000400 x6 : ffff800083b012d8 x5 : ffff800083b012d8 x4 : 0000000000000000 x3 : ffff000014d78398 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000014d78900 Call trace: drv_stop+0xac/0xbc ieee80211_stop_device+0x54/0x64 ieee80211_do_stop+0x5a0/0x790 ieee80211_stop+0x4c/0x178 __dev_close_many+0xb0/0x150 dev_close_many+0x88/0x130 dev_close.part.171+0x44/0x74 dev_close+0x1c/0x28 cfg80211_shutdown_all_interfaces+0x44/0xfc ieee80211_restart_work+0xfc/0x14c process_scheduled_works+0x18c/0x2dc worker_thread+0x13c/0x314 kthread+0x118/0x124 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- The warning in question is from drv_stop(): if (WARN_ON(!local->started)) return; The sequence of WARN_ON() is: Thread 1: -Firmware crash calls ath12k_core_reset(). -Call ieee80211_restart_hw() inside ath12k_core_post_reconfigure_recovery() which schedules worker for both hardware. -Wait for completion of ab->recovery_start. Thread 2 (worker thread): -One hardware acquires rtnl_lock() inside ieee80211_restart_hw() and calls ath12k_mac_wait_reconfigure() into ath12k_mac_op_start(). -Hardware is waiting for ab->reconfigure_complete but at this time recovery_start_count value is 1 because another worker thread (local->restart_work) is still waiting for rtnl_lock(). recovery_start_count is not equal to number of radios (2 in split-phy). So ab->recovery_start complete does not set due to this, thread 1 is still waiting and not able to perform hif power down up and firmware reload. -Wait timeout happens for ab->reconfigure_complete and comeback to caller (ath12k_mac_op_start()) and sends WMI command to crashed firmware and gets error. -This returns error to drv_start() and local->started is set to false. -Hardware calls cfg80211_shutdown_all_interfaces() after receiving error inside ieee80211_restart_work() and goes to drv_stop(), here we trigger WARN_ON as local->started is false. To fix this issue call ieee80211_restart_hw() after firmware has been reloaded. Now, each hardware can send WMI command to firmware successfully. With this fix we don't need to wait for ab->recovery_start completion so remove ath12k_mac_wait_reconfigure(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 HW2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aaradhana Sahu <[email protected]> Acked-by: Jeff Johnson <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17net/mlx5e: Add per queue netdev-genl statsJoe Damato1-0/+132
./cli.py --spec netlink/specs/netdev.yaml \ --dump qstats-get --json '{"scope": "queue"}' ...snip {'ifindex': 7, 'queue-id': 62, 'queue-type': 'rx', 'rx-alloc-fail': 0, 'rx-bytes': 105965251, 'rx-packets': 179790}, {'ifindex': 7, 'queue-id': 0, 'queue-type': 'tx', 'tx-bytes': 9402665, 'tx-packets': 17551}, ...snip Also tested with the script tools/testing/selftests/drivers/net/stats.py in several scenarios to ensure stats tallying was correct: - on boot (default queue counts) - adjusting queue count up or down (ethtool -L eth0 combined ...) The tools/testing/selftests/drivers/net/stats.py brings the device up, so to test with the device down, I did the following: $ ip link show eth4 7: eth4: <BROADCAST,MULTICAST> mtu 9000 qdisc mq state DOWN [..snip..] [..snip..] $ cat /proc/net/dev | grep eth4 eth4: 235710489 434811 [..snip rx..] 2878744 21227 [..snip tx..] $ ./cli.py --spec ../../../Documentation/netlink/specs/netdev.yaml \ --dump qstats-get --json '{"ifindex": 7}' [{'ifindex': 7, 'rx-alloc-fail': 0, 'rx-bytes': 235710489, 'rx-packets': 434811, 'tx-bytes': 2878744, 'tx-packets': 21227}] Compare the values in /proc/net/dev match the output of cli for the same device, even while the device is down. Note that while the device is down, per queue stats output nothing (because the device is down there are no queues): $ ./cli.py --spec ../../../Documentation/netlink/specs/netdev.yaml \ --dump qstats-get --json '{"scope": "queue", "ifindex": 7}' [] Signed-off-by: Joe Damato <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-17net/mlx5e: Add txq to sq stats mappingJoe Damato3-3/+23
mlx5 currently maps txqs to an sq via priv->txq2sq. It is useful to map txqs to sq_stats, as well, for direct access to stats. Add priv->txq2sq_stats and insert mappings. The mappings will be used next to tabulate stats information. Signed-off-by: Joe Damato <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-06-17Merge tag 'v6.10-rc4' into driver-core-nextGreg Kroah-Hartman65-376/+848
We need the driver core and sysfs fixes in here to build on top of. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-17wifi: rtw89: pci: fix RX tag race condition resulting in wrong RX lengthPing-Ke Shih1-5/+8
Read 32 bits RX info to a local variable to fix race condition between reading RX length and RX tag. Another solution is to get RX tag at first statement, but adopted solution can save some memory read, and also save 15 bytes binary code. RX tag, a sequence number, is used to ensure that RX data has been DMA to memory completely, so driver must check sequence number is expected before reading other data. This potential problem happens only after enabling 36-bit DMA. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: pci: support 36-bit PCI DMA addressPing-Ke Shih7-19/+95
Modern platforms can install more than 4GB memory, so DMA address can larger than 32 bits. If a platform doesn't enable IOMMU, kernel needs extra works of swiotlb to help DMA that packets reside on memory over 4GB. The DMA addressing capability of Realtek WiFi chips is 36 bits, so set LSB 4 bits of high 32-bit address to register and TX/RX descriptor, which below figure shows 3-level pointers in TX direction, and RX direction is similar but 2-level pointers only. +--------+ | | register to head of TX BD +---|----+ | +---------+ +-----> | TX BD | (in memory) +----|----+ | +---------+ +------> | TX WD | (in memory) +----|----+ | +--------+ +------> | skb | +--------+ Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: adopt firmware whose version is equal or less but closestPing-Ke Shih1-8/+26
Version C of 8922AE hardware will use the same firmware of version B, so extend rule of firmware recognition to allow less but closest firmware version. Originally only accept firmware with matched version. Tested on version A/B/C of 8922AE. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: 885xbx: apply common settings to 8851B, 8852B and 8852BTPing-Ke Shih9-46/+57
Many common settings can share to 8851B, 8852B and 8852BT, so add an inline function rtw89_is_rtl885xb() to be concise. Meanwhile review and align settings for existing chips. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: 8852bx: add extra handles for 8852BT in 8852b_commonPing-Ke Shih8-9/+315
The channel configuration of 8852BT is very similar but a little different to 8852B, so use chip ID as condition to add extra handles including external loss compensation, ADC configurations, spur settings and so on. Don't affect existing 8852BE. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: 8852bx: move common code from 8852b to 8852b_commonPing-Ke Shih7-1800/+2079
New upcoming chip is RTL8852BE-VT (or RTL8852BTE; 8852BT PCIE interface), which is a variant of 8852B, and many codes excepting to RF calibration can be shared, so move common code to an new kernel module named rtw89_8852b_common.ko. No logic change. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang1-3/+3
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.