summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-12-20ixgbe: Add support for NVM handling in E610 devicePiotr Kwapulinski
Add low level support for accessing NVM in E610 device. NVM operations are handled via the Admin Command Interface. Add the following NVM specific operations: - acquire, release, read - validate checksum - read shadow ram Co-developed-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Signed-off-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Co-developed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Bharath R <bharath.r@intel.com> Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-12-20ixgbe: Add link management support for E610 devicePiotr Kwapulinski
Add low level link management support for E610 device. Link management operations are handled via the Admin Command Interface. Add the following link management operations: - get link capabilities - set up link - get media type - get link status, link status events - link power management Co-developed-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Signed-off-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Co-developed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Jan Glaza <jan.glaza@intel.com> Tested-by: Bharath R <bharath.r@intel.com> Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-12-20ixgbe: Add support for E610 device capabilities detectionPiotr Kwapulinski
Add low level support for E610 device capabilities detection. The capabilities are discovered via the Admin Command Interface. Discover the following capabilities: - function caps: vmdq, dcb, rss, rx/tx qs, msix, nvm, orom, reset - device caps: vsi, fdir, 1588 - phy caps Co-developed-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Signed-off-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Co-developed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Jan Sokolowski <jan.sokolowski@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Bharath R <bharath.r@intel.com> Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-12-20ixgbe: Add support for E610 FW Admin Command InterfacePiotr Kwapulinski
Add low level support for Admin Command Interface (ACI). ACI is the Firmware interface used by a driver to communicate with E610 adapter. Add the following ACI features: - data structures, macros, register definitions - commands handling - events handling Co-developed-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Signed-off-by: Stefan Wegrzyn <stefan.wegrzyn@intel.com> Co-developed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Bharath R <bharath.r@intel.com> Signed-off-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2024-12-20Merge tag 'riscv-soc-fixes-for-v6.13-rc4' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V soc driver fixes for v6.13-rc4 A single fix for the Auto Update driver, where a mistake in array indexing (accessing as a u32 rather than a u8) caused the driver to read the wrong feature disable bits. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-soc-fixes-for-v6.13-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: firmware: microchip: fix UL_IAP lock check in mpfs_auto_update_state() Link: https://lore.kernel.org/r/20241218-suffrage-unfazed-fa0113072a42@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-12-20staging: gpib: fix address space mixupArnd Bergmann
Throughout the gpib drivers, a 'void *' struct member is used in place of either port numbers or __iomem pointers, which leads to lots of extra type casts, sparse warnings and less portable code. Split the struct member in two separate ones with the correct types, so each driver can pick which one to use. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/all/f10e976e-7a04-4454-b38d-39cd18f142da@roeck-us.net/ Link: https://lore.kernel.org/r/20241213064959.1045243-3-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: use ioport_mapArnd Bergmann
The tnt4882 backend has a rather elabolate way of abstracting the PIO and MMIO based hardware variants, duplicating the functionality of ioport_map() in a less portable way. Change it to use ioport_map() with ioread8()/iowrite8() to do this more easily. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20241213064959.1045243-2-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: fix pcmcia dependenciesArnd Bergmann
With CONFIG_PCMCIA=m, the gpib drivers that optionally support PCMCIA cannot be built-in. Add a Kconfig dependency to force these to be loadable modules as well, and change the GPIB_PCMCIA symbol to have the correct state for that. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20241213064959.1045243-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: add module author and description fieldsArnd Bergmann
The FMH driver is still missing both, so take them from the comment at the start of the file. Fixes: 8e4841a0888c ("staging: gpib: Add Frank Mori Hess FPGA PCI GPIB driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com> Link: https://lore.kernel.org/r/20241213083119.2607901-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: fix MakefilesArnd Bergmann
Having gpib drivers built-in rather than as loadable modules causes link failure because the drivers are never actually built: arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_t1_delay': fmh_gpib.c:(.text+0x3b0): undefined reference to `nec7210_t1_delay' arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_serial_poll_status': fmh_gpib.c:(.text+0x418): undefined reference to `nec7210_serial_poll_status' arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_secondary_address': fmh_gpib.c:(.text+0x57c): undefined reference to `nec7210_secondary_address' arm-linux-gnueabi-ld: drivers/staging/gpib/fmh_gpib/fmh_gpib.o: in function `fmh_gpib_primary_address': fmh_gpib.c:(.text+0x5ac): undefined reference to `nec7210_primary_address' Change this to use the correct Makefile syntax, setting either obj-m or obj-y. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20241212154245.1411411-2-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: make global 'usec_diff' functions staticArnd Bergmann
Trying to build both gpib_bitbang and lpvo_usb_gpib into the kernel reveals a function that should have been static and is also duplicated: x86_64-linux-ld: drivers/staging/gpib/lpvo_usb_gpib/lpvo_usb_gpib.o: in function `usec_diff': lpvo_usb_gpib.c:(.text+0x23c0): multiple definition of `usec_diff'; drivers/staging/gpib/gpio/gpib_bitbang.o:gpib_bitbang.c:(.text+0x2470): first defined here Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20241212154245.1411411-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: Modify mismatched function nameJiapeng Chong
No functional modification involved. drivers/staging/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c:676: warning: expecting prototype for interface_clear(). Prototype was for usb_gpib_interface_clear() instead. drivers/staging/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c:654: warning: expecting prototype for go_to_standby(). Prototype was for usb_gpib_go_to_standby() instead. drivers/staging/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c:636: warning: expecting prototype for enable_eos(). Prototype was for usb_gpib_enable_eos() instead. drivers/staging/gpib/lpvo_usb_gpib/lpvo_usb_gpib.c:618: warning: expecting prototype for disable_eos(). Prototype was for usb_gpib_disable_eos() instead. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=12253 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20241206022504.69670-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: Add lower bound check for secondary addressDave Penkler
Commit 9dde4559e939 ("staging: gpib: Add GPIB common core driver") from Sep 18, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/staging/gpib/common/gpib_os.c:541 dvrsp() warn: no lower bound on 'sad' rl='s32min-30' The value -1 was introduced in user land to signify No secondary address to the driver so that a lower bound check could be added. This patch adds that check. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-staging/4efd91f3-4259-4e95-a4e0-925853b98858@stanley.mountain/ Signed-off-by: Dave Penkler <dpenkler@gmail.com> Link: https://lore.kernel.org/r/20241207123410.28759-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20staging: gpib: Fix erroneous removal of blank before newlineDave Penkler
The USB_GPIB_SET_LINES command string used to be: "\nIBDC \n" but when we were merging this code into the upstream kernel we deleted the space character before the newline to make checkpatch happy. That turned out to be a mistake. The "\nIBDC" part of the string is a command that we pass to the firmware and the next character is a variable u8 value. It gets set in set_control_line(). msg[leng - 2] = value ? (retval & ~line) : retval | line; where leng is the length of the command string. Imagine the parameter was supposed to be "8". With the pre-merge code the command string would be "\nIBDC8\n" With the post-merge code the command string became "\nIBD8\n" The firmware doesn't recognize "IBD8" as a valid command and rejects it. Putting a "." where the parameter is supposed to go fixes the driver and makes checkpatch happy. Same thing with the other define and the in-line assignment. Reported-by: Marcello Carla' <marcello.carla@gmx.com> Fixes: fce79512a96a ("staging: gpib: Add LPVO DIY USB GPIB driver") Co-developed-by: Marcello Carla' <marcello.carla@gmx.com> Signed-off-by: Marcello Carla' <marcello.carla@gmx.com> Signed-off-by: Dave Penkler <dpenkler@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20241205093442.5796-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-20gve: fix XDP allocation path in edge casesJoshua Washington
This patch fixes a number of consistency issues in the queue allocation path related to XDP. As it stands, the number of allocated XDP queues changes in three different scenarios. 1) Adding an XDP program while the interface is up via gve_add_xdp_queues 2) Removing an XDP program while the interface is up via gve_remove_xdp_queues 3) After queues have been allocated and the old queue memory has been removed in gve_queues_start. However, the requirement for the interface to be up for gve_(add|remove)_xdp_queues to be called, in conjunction with the fact that the number of queues stored in priv isn't updated until _after_ XDP queues have been allocated in the normal queue allocation path means that if an XDP program is added while the interface is down, XDP queues won't be added until the _second_ if_up, not the first. Given the expectation that the number of XDP queues is equal to the number of RX queues, scenario (3) has another problematic implication. When changing the number of queues while an XDP program is loaded, the number of XDP queues must be updated as well, as there is logic in the driver (gve_xdp_tx_queue_id()) which relies on every RX queue having a corresponding XDP TX queue. However, the number of XDP queues stored in priv would not be updated until _after_ a close/open leading to a mismatch in the number of XDP queues reported vs the number of XDP queues which actually exist after the queue count update completes. This patch remedies these issues by doing the following: 1) The allocation config getter function is set up to retrieve the _expected_ number of XDP queues to allocate instead of relying on the value stored in `priv` which is only updated once the queues have been allocated. 2) When adjusting queues, XDP queues are adjusted to match the number of RX queues when XDP is enabled. This only works in the case when queues are live, so part (1) of the fix must still be available in the case that queues are adjusted when there is an XDP program and the interface is down. Fixes: 5f08cd3d6423 ("gve: Alloc before freeing when adjusting queues") Cc: stable@vger.kernel.org Signed-off-by: Joshua Washington <joshwash@google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Shailend Chand <shailend@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-20gve: process XSK TX descriptors as part of RX NAPIJoshua Washington
When busy polling is enabled, xsk_sendmsg for AF_XDP zero copy marks the NAPI ID corresponding to the memory pool allocated for the socket. In GVE, this NAPI ID will never correspond to a NAPI ID of one of the dedicated XDP TX queues registered with the umem because XDP TX is not set up to share a NAPI with a corresponding RX queue. This patch moves XSK TX descriptor processing from the TX NAPI to the RX NAPI, and the gve_xsk_wakeup callback is updated to use the RX NAPI instead of the TX NAPI, accordingly. The branch on if the wakeup is for TX is removed, as the NAPI poll should be invoked whether the wakeup is for TX or for RX. Fixes: fd8e40321a12 ("gve: Add AF_XDP zero-copy support for GQI-QPL format") Cc: stable@vger.kernel.org Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-20gve: guard XSK operations on the existence of queuesJoshua Washington
This patch predicates the enabling and disabling of XSK pools on the existence of queues. As it stands, if the interface is down, disabling or enabling XSK pools would result in a crash, as the RX queue pointer would be NULL. XSK pool registration will occur as part of the next interface up. Similarly, xsk_wakeup needs be guarded against queues disappearing while the function is executing, so a check against the GVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the disabling of the bit and the synchronize_net() in gve_turndown. Fixes: fd8e40321a12 ("gve: Add AF_XDP zero-copy support for GQI-QPL format") Cc: stable@vger.kernel.org Signed-off-by: Joshua Washington <joshwash@google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Shailend Chand <shailend@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-20gve: guard XDP xmit NDO on existence of xdp queuesJoshua Washington
In GVE, dedicated XDP queues only exist when an XDP program is installed and the interface is up. As such, the NDO XDP XMIT callback should return early if either of these conditions are false. In the case of no loaded XDP program, priv->num_xdp_queues=0 which can cause a divide-by-zero error, and in the case of interface down, num_xdp_queues remains untouched to persist XDP queue count for the next interface up, but the TX pointer itself would be NULL. The XDP xmit callback also needs to synchronize with a device transitioning from open to close. This synchronization will happen via the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call, which waits for any RCU critical sections at call-time to complete. Fixes: 39a7f4aa3e4a ("gve: Add XDP REDIRECT support for GQI-QPL format") Cc: stable@vger.kernel.org Signed-off-by: Joshua Washington <joshwash@google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Shailend Chand <shailend@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-20gve: clean XDP queues in gve_tx_stop_ring_gqiJoshua Washington
When stopping XDP TX rings, the XDP clean function needs to be called to clean out the entire queue, similar to what happens in the normal TX queue case. Otherwise, the FIFO won't be cleared correctly, and xsk_tx_completed won't be reported. Fixes: 75eaae158b1b ("gve: Add XDP DROP and TX support for GQI-QPL format") Cc: stable@vger.kernel.org Signed-off-by: Joshua Washington <joshwash@google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-12-20Merge tag 'amd-drm-fixes-6.13-2024-12-18' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.13-2024-12-18: amdgpu: - Disable BOCO when CONFIG_HOTPLUG_PCI_PCIE is not enabled - scheduler job fixes - IP version check fixes - devcoredump fix - GPUVM update fix - NBIO 2.5 fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241218204637.2966198-1-alexander.deucher@amd.com
2024-12-19xsk: make xsk_buff_add_frag() really add the frag via __xdp_buff_add_frag()Alexander Lobakin
Currently, xsk_buff_add_frag() only adds the frag to pool's linked list, not doing anything with the &xdp_buff. The drivers do that manually and the logic is the same. Make it really add an skb frag, just like xdp_buff_add_frag() does that, and freeing frags on error if needed. This allows to remove repeating code from i40e and ice and not add the same code again and again. Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20241218174435.1445282-5-aleksander.lobakin@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19sfc: remove efx_writed_page_lockedAndy Moreton
From: Andy Moreton <andy.moreton@amd.com> efx_writed_page_locked is a workaround for Siena hardware that is not needed on later adapters, and has no callers. Remove it. Signed-off-by: Andy Moreton <andy.moreton@amd.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20241218135930.2350358-1-edward.cree@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: stmmac: Drop useless code related to ethtool rx-copybreakFurong Xu
After commit 2af6106ae949 ("net: stmmac: Introducing support for Page Pool"), the driver always copies frames to get a better performance, zero-copy for RX frames is no more, then these code turned to be useless and users of ethtool may get confused about the unhandled rx-copybreak parameter. This patch mostly reverts commit 22ad38381547 ("stmmac: do not perform zero-copy for rx frames") Signed-off-by: Furong Xu <0x1207@gmail.com> Link: https://patch.msgid.link/20241218083407.390509-1-0x1207@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: airoha: Fix error path in airoha_probe()Lorenzo Bianconi
Do not run napi_disable() if airoha_hw_init() fails since Tx/Rx napi has not been started yet. In order to fix the issue, introduce airoha_qdma_stop_napi routine and remove napi_disable in airoha_hw_cleanup(). Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20241216-airoha_probe-error-path-fix-v2-1-6b10e04e9a5c@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: ethernet: ti: cpsw: disable PHY EEE advertisementHeiner Kallweit
It seems the cpsw MAC doesn't support EEE. See e.g. the commit message of ce2899428ec0 ("ARM: dts: am335x-baltos: disable EEE for Atheros 8035 PHY"). There are cases where this causes issues if the PHY's on both sides have negotiated EEE. As a workaround EEE modes of the PHY are marked broken in DT, effectively disabling EEE advertisement. Improve this by using new function phy_disable_eee() in the MAC driver. This properly disables EEE advertisement, and allows to remove the eee-broken-xxx properties from DT. As EEE is disabled anyway, we can remove also the set_eee ethtool op. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/d08a798e-8565-422c-b2ed-121794db077f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: phy: add phy_disable_eeeHeiner Kallweit
If a MAC driver doesn't support EEE, then the PHY shouldn't advertise it. Add phy_disable_eee() for this purpose. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/fd51738c-dcd6-4d61-b8c5-faa6ac0f1026@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19Merge tag 'wireless-next-2024-12-19' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.14 Multi-Link Operation implementation continues, both in stack and in drivers. Otherwise it has been relatively quiet. Major changes: cfg80211/mac80211 - define wiphy guard - get TX power per link - EHT 320 MHz channel support for mesh ath11k - QCA6698AQ support ath9k - RX inactivity detection rtl8xxxu - add more USB device IDs rtw88 - add more USB device IDs - enable USB RX aggregation and USB 3 to improve performance rtw89 - PowerSave flow for Multi-Link Operation * tag 'wireless-next-2024-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (121 commits) wifi: wlcore: sysfs: constify 'struct bin_attribute' wifi: brcmfmac: clarify unmodifiable headroom log message wifi: brcmfmac: add missing header include for brcmf_dbg wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() wifi: qtnfmac: fix spelling error in core.h wifi: rtw89: phy: add dummy C2H event handler for report of TAS power wifi: rtw89: 8851b: rfk: remove unnecessary assignment of return value of _dpk_dgain_read() wifi: rtw89: 8852c: rfk: refine target channel calculation in _rx_dck_channel_calc() wifi: rtlwifi: pci: wait for firmware loading before releasing memory wifi: rtlwifi: fix memory leaks and invalid access at probe error path wifi: rtlwifi: destroy workqueue at rtl_deinit_core wifi: rtlwifi: remove unused check_buddy_priv wifi: rtw89: 8922a: update format of RFK pre-notify H2C command v2 wifi: rtw89: regd: update regulatory map to R68-R51 wifi: rtw89: 8852c: disable ER SU when 4x HE-LTF and 0.8 GI capability differ wifi: rtw89: disable firmware training HE GI and LTF wifi: rtw89: ps: update data for firmware and settings for hardware before/after PS wifi: rtw89: ps: refactor channel info to firmware before entering PS wifi: rtw89: ps: refactor PS flow to support MLO wifi: mwifiex: decrease timeout waiting for host sleep from 10s to 5s ... ==================== Link: https://patch.msgid.link/20241219185709.774EDC4CECE@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19Merge tag 'wireless-2024-12-19' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.13-rc5 Few minor fixes this time, nothing special. * tag 'wireless-2024-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: cw1200: Fix potential NULL dereference wifi: iwlwifi: mvm: Fix __counted_by usage in cfg80211_wowlan_nd_* MAINTAINERS: wifi: ath: add Jeff Johnson as maintainer wifi: iwlwifi: fix CRF name for Bz ==================== Link: https://patch.msgid.link/20241219185042.662B6C4CECE@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: dsa: microchip: Add suspend/resume support to KSZ DSA driverTristram Ha
The KSZ DSA driver starts a timer to read MIB counters periodically to avoid count overrun. During system suspend this will give an error for not able to write to register as the SPI system returns an error when it is in suspend state. This implementation stops the timer when the system goes into suspend and restarts it when resumed. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241218020311.70628-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: dsa: microchip: Fix LAN937X set_ageing_time functionTristram Ha
The aging count is not a simple 20-bit value but comprises a 3-bit multiplier and a 20-bit second time. The code tries to use the original multiplier which is 4 as the second count is still 300 seconds by default. As the 20-bit number is now too large for practical use there is an option to interpret it as microseconds instead of seconds. Fixes: 2c119d9982b1 ("net: dsa: microchip: add the support for set_ageing_time") Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241218020224.70590-3-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: dsa: microchip: Fix KSZ9477 set_ageing_time functionTristram Ha
The aging count is not a simple 11-bit value but comprises a 3-bit multiplier and an 8-bit second count. The code tries to use the original multiplier which is 4 as the second count is still 300 seconds by default. Fixes: 2c119d9982b1 ("net: dsa: microchip: add the support for set_ageing_time") Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241218020224.70590-2-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-20drm: adv7511: Drop dsi single lane supportBiju Das
As per [1] and [2], ADV7535/7533 supports only 2-, 3-, or 4-lane. Drop unsupported 1-lane. [1] https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf [2] https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7533.pdf Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device") Reported-by: Hien Huynh <hien.huynh.px@renesas.com> Cc: stable@vger.kernel.org Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Adam Ford <aford173@gmail.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241119192040.152657-4-biju.das.jz@bp.renesas.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-20drm: adv7511: Fix use-after-free in adv7533_attach_dsi()Biju Das
The host_node pointer was assigned and freed in adv7533_parse_dt(), and later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put() in error path of probe() and also in the remove(). Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device") Cc: stable@vger.kernel.org Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241119192040.152657-2-biju.das.jz@bp.renesas.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-20drm/bridge: adv7511_audio: Update Audio InfoFrame properlyStefan Ekenberg
AUDIO_UPDATE bit (Bit 5 of MAIN register 0x4A) needs to be set to 1 while updating Audio InfoFrame information and then set to 0 when done. Otherwise partially updated Audio InfoFrames could be sent out. Two cases where this rule were not followed are fixed: - In adv7511_hdmi_hw_params() make sure AUDIO_UPDATE bit is updated before/after setting ADV7511_REG_AUDIO_INFOFRAME. - In audio_startup() use the correct register for clearing AUDIO_UPDATE bit. The problem with corrupted audio infoframes were discovered by letting a HDMI logic analyser check the output of ADV7535. Note that this patchs replaces writing REG_GC(1) with REG_INFOFRAME_UPDATE. Bit 5 of REG_GC(1) is positioned within field GC_PP[3:0] and that field doesn't control audio infoframe and is read- only. My conclusion therefore was that the author if this code meant to clear bit 5 of REG_INFOFRAME_UPDATE from the very beginning. Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Fixes: 53c515befe28 ("drm/bridge: adv7511: Add Audio support") Signed-off-by: Stefan Ekenberg <stefan.ekenberg@axis.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241119-adv7511-audio-info-frame-v4-1-4ae68e76c89c@axis.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-19bnxt_en: Skip reading PXP registers during ethtool -d if unsupportedMichael Chan
Newer firmware does not allow reading the PXP registers during ethtool -d, so skip the firmware call in that case. Userspace (bnxt.c) always expects the register block to be populated so zeroes will be returned instead. Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20241217182620.2454075-6-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19bnxt_en: Skip MAC loopback selftest if it is unsupported by FWMichael Chan
Call the new HWRM_PORT_MAC_QCAPS to check if mac loopback is supported. Skip the MAC loopback ethtool self test if it is not supported. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20241217182620.2454075-5-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19bnxt_en: Skip PHY loopback ethtool selftest if unsupported by FWMichael Chan
Skip PHY loopback selftest if firmware advertises that it is unsupported in the HWRM_PORT_PHY_QCAPS call. Only show PHY loopback test result to be 0 if the test has run and passes. Do the same for external loopback to be consistent. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20241217182620.2454075-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19bnxt_en: Do not allow ethtool -m on an untrusted VFMichael Chan
Block all ethtool module operations on an untrusted VF. The firmware won't allow it and will return error. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20241217182620.2454075-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19bnxt_en: Use FW defined resource limits for RoCEHongguang Gao
If FW supports setting resource limits for RoCE, then just use the FW limits instead of using some fixed values in the driver. These limits will be used to allocate context memory for QP, SRQ, AH, and MR resources for RoCE. Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Hongguang Gao <hongguang.gao@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20241217182620.2454075-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19net: phy: micrel: Dynamically control external clock of KSZ PHYWei Fang
On the i.MX6ULL-14x14-EVK board, enet1_ref and enet2_ref are used as the clock sources for two external KSZ PHYs. However, after closing the two FEC ports, the clk_enable_count of the enet1_ref and enet2_ref clocks is not 0. The root cause is that since the commit 985329462723 ("net: phy: micrel: use devm_clk_get_optional_enabled for the rmii-ref clock"), the external clock of KSZ PHY has been enabled when the PHY driver probes, and it can only be disabled when the PHY driver is removed. This causes the clock to continue working when the system is suspended or the network port is down. Although Heiko explained in the commit message that the patch was because some clock suppliers need to enable the clock to get the valid clock rate , it seems that the simple fix is to disable the clock after getting the clock rate to solve the current problem. This is indeed true, but we need to admit that Heiko's patch has been applied for more than a year, and we cannot guarantee whether there are platforms that only enable rmii-ref in the KSZ PHY driver during this period. If this is the case, disabling rmii-ref will cause RMII on these platforms to not work. Secondly, commit 99ac4cbcc2a5 ("net: phy: micrel: allow usage of generic ethernet-phy clock") just simply enables the generic clock permanently, which seems like the generic clock may only be enabled in the PHY driver. If we simply disable the generic clock, RMII may not work. If we keep it as it is, the platform using the generic clock will have the same problem as the i.MX6ULL platform. To solve this problem, the clock is enabled when phy_driver::resume() is called, and the clock is disabled when phy_driver::suspend() is called. Since phy_driver::resume() and phy_driver::suspend() are not called in pairs, an additional clk_enable flag is added. When phy_driver::suspend() is called, the clock is disabled only if clk_enable is true. Conversely, when phy_driver::resume() is called, the clock is enabled if clk_enable is false. The changes that introduced the problem were only a few lines, while the current fix is about a hundred lines, which seems out of proportion, but it is necessary because kszphy_probe() is used by multiple KSZ PHYs and we need to fix all of them. Fixes: 985329462723 ("net: phy: micrel: use devm_clk_get_optional_enabled for the rmii-ref clock") Fixes: 99ac4cbcc2a5 ("net: phy: micrel: allow usage of generic ethernet-phy clock") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20241217063500.1424011-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-20Merge tag 'drm-misc-fixes-2024-12-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.13-rc4: - udma-buf fixes related to sealing. - dma-buf build warning fix when debugfs is not enabled. - Assorted drm/panel fixes. - Correct error return in drm_dp_tunnel_mgr_create. - Fix even more divide by zero in drm_mode_vrefresh. - Fix FBDEV dependencies in Kconfig. - Documentation fix for drm_sched_fini. - IVPU NULL pointer, memory leak and WARN fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d0763051-87b7-483e-89e0-a9f993383450@linux.intel.com
2024-12-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.13-rc4). No conflicts. Adjacent changes: drivers/net/ethernet/renesas/rswitch.h 32fd46f5b69e ("net: renesas: rswitch: remove speed from gwca structure") 922b4b955a03 ("net: renesas: rswitch: rework ts tags management") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-19wifi: ath12k: Fix spelling mistake "requestted" -> "requested"Colin Ian King
There is a spelling mistake in an ath12k_err error message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217105505.306047-1-colin.i.king@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Avoid explicit type cast in monitor status parse handlerKarthikeyan Periyasamy
Currently, monitor status parse procedure handles all the supported TLV tags. Each TLV tag has its own data structure for parsing. Now, this handler is passed the tlv_data as a u8 pointer, so explicit type cast conversion happens for every TLV tag parsing. Therefore, avoid the explicit type conversion by changing the tlv_data type from a u8 pointer to a const void pointer. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-9-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Change the Tx monitor SRNG ring IDKarthikeyan Periyasamy
The Tx monitor SRNG ring ID does not align with the ath12k 802.11be hardware architecture. Currently, there is no issue since the Tx monitor is not enabled. However, in the future, the Tx monitor will be enabled. Therefore, change the HAL_SRNG_RING_ID_WMAC1_SW2TXMON_BUF0 SRNG ID and assign the correct start ring ID for the ring type HAL_TX_MONITOR_BUF. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-8-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Remove unused HAL Rx mask in DP monitor pathKarthikeyan Periyasamy
Currently, CODING and TXBF are unused masks defined in the HAL Rx monitor status TLV parsing code path. Therefore, remove the unused masks to prevent incorrect assumptions for code readers. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-7-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: fix incorrect TID updation in DP monitor status pathKarthikeyan Periyasamy
Currently, an incorrect TID value gets populated in the monitor status Rx path due to an incorrect bitmap value given to the ffs() built-in helper function. Therefore, avoid the decrement and directly provide the TID bitmap to the ffs() built-in helper function for the correct TID update in the monitor status Rx path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-6-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Fix the misspelled of hal TLV tag HAL_PHYRX_GENERICHT_SIGKarthikeyan Periyasamy
There is "HAL_PHYRX_GENERICHT_SIG" misspelled as "HAL_PHYRX_GENERIC_EHT_SIG" in the comments. Fix the spelling. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-5-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: cleanup Rx peer statistics structureKarthikeyan Periyasamy
Currently, unused fields are present in the Rx peer statistics structure. These fields are already present in the same structure under the ath12k_rx_peer_rate_stats container structure. Therefore, remove the unused fields from the Rx peer statistics structure. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-4-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Refactor monitor status TLV structureKarthikeyan Periyasamy
The following TLV structures and bitmask definitions were inherited from the ath11k but were not updated for the ath12k 802.11be hardware. These data structure and bitmask will be used to parse the monitor status TLV data in the Rx path. 1. hal_rx_ppdu_end_user_stats_ext structure 2. hal_rx_ppdu_end_duration structure 3. HAL_RX_HE_SIG_B2_OFDMA_INFO_INFO0_STA_TXBF bitmask 4. HAL_RX_MPDU_START_INFO1_PEERID bitmask 5. HAL_INVALID_PEERID 6. hal_rx_ppdu_end_user_stats bitmask Currently, there is no issue since the monitor status Rx path is not enabled. However, in the future, the monitor status Rx path will be enabled. Therefore, update the above TLV structures and bitmask to align with the ath12k 802.11be hardware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241217084511.2981515-3-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
generated by cgit (git 2.34.1) at 2025-09-14 21:12:48 +0000