summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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>
2024-12-19wifi: ath12k: Add documentation HTT_H2T_MSG_TYPE_RX_RING_SELECTION_CFGKarthikeyan Periyasamy
Add missing field documentation for HTT_H2T_MSG_TYPE_RX_RING_SELECTION_CFG command with indentation alignment. 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-2-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Decrease ath12k_mac_station_assoc() stack usageJeff Johnson
Building the ath12k driver with llvm-18.1.7-x86_64 produces the warning: drivers/net/wireless/ath/ath12k/mac.c:5606:12: warning: stack frame size (1176) exceeds limit (1024) in 'ath12k_mac_op_sta_state' [-Wframe-larger-than] ath12k_mac_op_sta_state() itself does not consume much stack, but it calls ath12k_mac_handle_link_sta_state() which in turn calls ath12k_mac_station_add(). Since those are both static functions with only one caller, it is suspected that these both get inlined, and their stack usage is reported for ath12k_mac_op_sta_state(). A major contributor to the ath12k_mac_station_assoc() stack usage is: struct ath12k_wmi_peer_assoc_arg peer_arg; Avoid the excess stack usage by dynamically allocating peer_arg instead of declaring it on the stack. 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: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241217202618.1329312-5-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Decrease ath12k_sta_rc_update_wk() stack usageJeff Johnson
Currently when building ath12k with llvm-18.1.7-x86_64 the following warning is observed: drivers/net/wireless/ath/ath12k/mac.c:4946:13: warning: stack frame size (1112) exceeds limit (1024) in 'ath12k_sta_rc_update_wk' [-Wframe-larger-than] A major contributor to the stack usage in this function is: struct ath12k_wmi_peer_assoc_arg peer_arg; Avoid the excess stack usage by dynamically allocating peer_arg instead of declaring it on the stack. 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: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241217202618.1329312-4-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Decrease ath12k_bss_assoc() stack usageJeff Johnson
Currently when building ath12k with gcc-14.2.0 the following warning is observed: drivers/net/wireless/ath/ath12k/mac.c: In function 'ath12k_bss_assoc': drivers/net/wireless/ath/ath12k/mac.c:3080:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=] A major contributor to the stack usage in this function is: struct ath12k_wmi_peer_assoc_arg peer_arg; Avoid the excess stack usage by dynamically allocating peer_arg instead of declaring it on the stack. 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: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241217202618.1329312-3-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Decrease ath12k_mac_op_remain_on_channel() stack usageJeff Johnson
Building the ath12k driver with llvm-18.1.7-x86_64 produces the warning: drivers/net/wireless/ath/ath12k/mac.c:10028:12: warning: stack frame size (1080) exceeds limit (1024) in 'ath12k_mac_op_remain_on_channel' [-Wframe-larger-than] A major contributor to the stack usage in this function is: struct ath12k_wmi_scan_req_arg arg; Avoid the excess stack usage by dynamically allocating arg instead of declaring it on the stack. As part of the effort use __free() for both this new allocation as well as the existing chan_list allocation, and since then no central cleanup is required, replace all cleanup gotos with returns. 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: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241217202618.1329312-2-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath12k: Add support for parsing 64-bit TLVsP Praneesh
There is mismatch between the format of monitor destination TLVs received and the expected format by the current implementation. The received TLVs are in 64-bit format, while the implementation is designed to handle 32-bit TLVs. This leads to incorrect parsing. Fix it by adding support for parsing 64-bit TLVs. 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: P Praneesh <quic_ppranees@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://patch.msgid.link/20241217095058.2725755-1-quic_ppranees@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath9k: simplify internal time managementDmitry Antipov
Prefer 'ktime_t' over 'struct timespec64' for 'struct ath_chanctx' and 'struct ath_softc' timestamps, choose standard kernel time API over an ad-hoc math in 'chanctx_event_delta()' and 'ath9k_hw_get_tsf_offset()', adjust related users. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20241209155027.636400-3-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath9k: cleanup a few (mostly) TX-related routinesDmitry Antipov
Remove unused 'struct ath_softc *' argument of 'ath_pkt_duration()', 'ath_tx_update_baw()', 'ath_get_skb_tid()', 'ath_tx_addto_baw()' and 'ath_tx_count_frames()', adjust related users. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20241209155027.636400-2-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19wifi: ath9k: cleanup ath_txq_skb_done()Dmitry Antipov
Since 'txq' argument of 'ath_txq_skb_done()' is actually (mis|un)used, convert the former to local variable and adjust all related users. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20241209155027.636400-1-dmantipov@yandex.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-19Merge tag 'net-6.13-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from can and netfilter. Current release - regressions: - rtnetlink: try the outer netns attribute in rtnl_get_peer_net() - rust: net::phy fix module autoloading Current release - new code bugs: - phy: avoid undefined behavior in *_led_polarity_set() - eth: octeontx2-pf: fix netdev memory leak in rvu_rep_create() Previous releases - regressions: - smc: check sndbuf_space again after NOSPACE flag is set in smc_poll - ipvs: fix clamp() of ip_vs_conn_tab on small memory systems - dsa: restore dsa_software_vlan_untag() ability to operate on VLAN-untagged traffic - eth: - tun: fix tun_napi_alloc_frags() - ionic: no double destroy workqueue - idpf: trigger SW interrupt when exiting wb_on_itr mode - rswitch: rework ts tags management - team: fix feature exposure when no ports are present Previous releases - always broken: - core: fix repeated netlink messages in queue dump - mdiobus: fix an OF node reference leak - smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg - can: fix missed interrupts with m_can_pci - eth: oa_tc6: fix infinite loop error when tx credits becomes 0" * tag 'net-6.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (45 commits) net: mctp: handle skb cleanup on sock_queue failures net: mdiobus: fix an OF node reference leak octeontx2-pf: fix error handling of devlink port in rvu_rep_create() octeontx2-pf: fix netdev memory leak in rvu_rep_create() psample: adjust size if rate_as_probability is set netdev-genl: avoid empty messages in queue dump net: dsa: restore dsa_software_vlan_untag() ability to operate on VLAN-untagged traffic selftests: openvswitch: fix tcpdump execution net: usb: qmi_wwan: add Quectel RG255C net: phy: avoid undefined behavior in *_led_polarity_set() netfilter: ipset: Fix for recursive locking warning ipvs: Fix clamp() of ip_vs_conn_tab on small memory systems can: m_can: fix missed interrupts with m_can_pci can: m_can: set init flag earlier in probe rtnetlink: Try the outer netns attribute in rtnl_get_peer_net(). net: netdevsim: fix nsim_pp_hold_write() idpf: trigger SW interrupt when exiting wb_on_itr mode idpf: add support for SW triggered interrupts qed: fix possible uninit pointer read in qed_mcp_nvm_info_populate() net: ethernet: bgmac-platform: fix an OF node reference leak ...
2024-12-19Merge tag 'mmc-v6.13-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: - mtk-sd: Cleanup the wakeup configuration in error/remove-path - sdhci-tegra: Correct quirk for ADMA2 length * tag 'mmc-v6.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: mtk-sd: disable wakeup in .remove() and in the error path of .probe() mmc: sdhci-tegra: Remove SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC quirk
2024-12-19Merge tag 'pwm/for-6.13-rc4-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm fix from Uwe Kleine-König: "Fix regression in pwm-stm32 driver when converting to new waveform support Fabrice Gasnier found and fixed a regression I introduced with v6.13-rc1 when converting the stm32 pwm driver to support the new waveform stuff. On some hardware variants this completely broke the driver" * tag 'pwm/for-6.13-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: stm32: Fix complementary output in round_waveform_tohw()
2024-12-19Merge tag 'v6.13-rc3-ksmbd-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull smb server fixes from Steve French: - Two fixes for better handling maximum outstanding requests - Fix simultaneous negotiate protocol race * tag 'v6.13-rc3-ksmbd-server-fixes' of git://git.samba.org/ksmbd: ksmbd: conn lock to serialize smb2 negotiate ksmbd: fix broken transfers when exceeding max simultaneous operations ksmbd: count all requests in req_running counter
2024-12-19PCI/bwctrl: Enable only if more than one speed is supportedLukas Wunner
If a PCIe port only supports a single speed, enabling bandwidth control is pointless: There's no need to monitor autonomous speed changes, nor can the speed be changed. Not enabling it saves a small amount of memory and compute resources, but also fixes a boot hang reported by Niklas: It occurs when enabling bandwidth control on Downstream Ports of Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers. The ports only support 2.5 GT/s in accordance with USB4 v2 sec 11.2.1, so the present commit works around the issue. PCIe r6.2 sec 8.2.1 prescribes that: "A device must support 2.5 GT/s and is not permitted to skip support for any data rates between 2.5 GT/s and the highest supported rate." Consequently, bandwidth control is currently only disabled if a port doesn't support higher speeds than 2.5 GT/s. However the Implementation Note in PCIe r6.2 sec 7.5.3.18 cautions: "It is strongly encouraged that software primarily utilize the Supported Link Speeds Vector instead of the Max Link Speed field, so that software can determine the exact set of supported speeds on current and future hardware. This can avoid software being confused if a future specification defines Links that do not require support for all slower speeds." In other words, future revisions of the PCIe Base Spec may allow gaps in the Supported Link Speeds Vector. To be future-proof, don't just check whether speeds above 2.5 GT/s are supported, but rather check whether *more than one* speed is supported. Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller") Closes: https://lore.kernel.org/r/db8e457fcd155436449b035e8791a8241b0df400.camel@kernel.org Link: https://lore.kernel.org/r/3564908a9c99fc0d2a292473af7a94ebfc8f5820.1734428762.git.lukas@wunner.de Reported-by: Niklas Schnelle <niks@kernel.org> Tested-by: Niklas Schnelle <niks@kernel.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Jonathan Cameron <Jonthan.Cameron@huawei.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-19PCI: Honor Max Link Speed when determining supported speedsLukas Wunner
The Supported Link Speeds Vector in the Link Capabilities 2 Register indicates the *supported* link speeds. The Max Link Speed field in the Link Capabilities Register indicates the *maximum* of those speeds. pcie_get_supported_speeds() neglects to honor the Max Link Speed field and will thus incorrectly deem higher speeds as supported. Fix it. One user-visible issue addressed here is an incorrect value in the sysfs attribute "max_link_speed". But the main motivation is a boot hang reported by Niklas: Intel JHL7540 "Titan Ridge 2018" Thunderbolt controllers supports 2.5-8 GT/s speeds, but indicate 2.5 GT/s as maximum. Ilpo recalls seeing this on more devices. It can be explained by the controller's Downstream Ports supporting 8 GT/s if an Endpoint is attached, but limiting to 2.5 GT/s if the port interfaces to a PCIe Adapter, in accordance with USB4 v2 sec 11.2.1: "This section defines the functionality of an Internal PCIe Port that interfaces to a PCIe Adapter. [...] The Logical sub-block shall update the PCIe configuration registers with the following characteristics: [...] Max Link Speed field in the Link Capabilities Register set to 0001b (data rate of 2.5 GT/s only). Note: These settings do not represent actual throughput. Throughput is implementation specific and based on the USB4 Fabric performance." The present commit is not sufficient on its own to fix Niklas' boot hang, but it is a prerequisite: A subsequent commit will fix the boot hang by enabling bandwidth control only if more than one speed is supported. The GENMASK() macro used herein specifies 0 as lowest bit, even though the Supported Link Speeds Vector ends at bit 1. This is done on purpose to avoid a GENMASK(0, 1) macro if Max Link Speed is zero. That macro would be invalid as the lowest bit is greater than the highest bit. Ilpo has witnessed a zero Max Link Speed on Root Complex Integrated Endpoints in particular, so it does occur in practice. (The Link Capabilities Register is optional on RCiEPs per PCIe r6.2 sec 7.5.3.) Fixes: d2bd39c0456b ("PCI: Store all PCIe Supported Link Speeds") Closes: https://lore.kernel.org/r/70829798889c6d779ca0f6cd3260a765780d1369.camel@kernel.org Link: https://lore.kernel.org/r/fe03941e3e1cc42fb9bf4395e302bff53ee2198b.1734428762.git.lukas@wunner.de Reported-by: Niklas Schnelle <niks@kernel.org> Tested-by: Niklas Schnelle <niks@kernel.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-12-19io_uring/register: limit ring resizing to DEFER_TASKRUNJens Axboe
With DEFER_TASKRUN, we know the ring can't be both waited upon and resized at the same time. This is important for CQ resizing. Allowing SQ ring resizing is more trivial, but isn't the interesting use case. Hence limit ring resizing in general to DEFER_TASKRUN only for now. This isn't a huge problem as CQ ring resizing is generally the most useful on networking type of workloads where it can be hard to size the ring appropriately upfront, and those should be using DEFER_TASKRUN for better performance. Fixes: 79cfe9e59c2a ("io_uring/register: add IORING_REGISTER_RESIZE_RINGS") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-12-19workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from ↵Tvrtko Ursulin
!WQ_MEM_RECLAIM worker After commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu] ... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched] ... [ ] Call Trace: [ ] <TASK> ... [ ] ? check_flush_dependency+0xf5/0x110 ... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720 ... [ ] </TASK> The intent of the verifcation done in check_flush_depedency is to ensure forward progress during memory reclaim, by flagging cases when either a memory reclaim process, or a memory reclaim work item is flushed from a context not marked as memory reclaim safe. This is correct when flushing, but when called from the cancel(_delayed)_work_sync() paths it is a false positive because work is either already running, or will not be running at all. Therefore cancelling it is safe and we can relax the warning criteria by letting the helper know of the calling context. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue") References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") Cc: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Tejun Heo <tj@kernel.org>
2024-12-19smb: client: fix TCP timers deadlock after rmmodEnzo Matsumiya
Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") fixed a netns UAF by manually enabled socket refcounting (sk->sk_net_refcnt=1 and sock_inuse_add(net, 1)). The reason the patch worked for that bug was because we now hold references to the netns (get_net_track() gets a ref internally) and they're properly released (internally, on __sk_destruct()), but only because sk->sk_net_refcnt was set. Problem: (this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardless if init_net or other) Setting sk->sk_net_refcnt=1 *manually* and *after* socket creation is not only out of cifs scope, but also technically wrong -- it's set conditionally based on user (=1) vs kernel (=0) sockets. And net/ implementations seem to base their user vs kernel space operations on it. e.g. upon TCP socket close, the TCP timers are not cleared because sk->sk_net_refcnt=1: (cf. commit 151c9c724d05 ("tcp: properly terminate timers for kernel sockets")) net/ipv4/tcp.c: void tcp_close(struct sock *sk, long timeout) { lock_sock(sk); __tcp_close(sk, timeout); release_sock(sk); if (!sk->sk_net_refcnt) inet_csk_clear_xmit_timers_sync(sk); sock_put(sk); } Which will throw a lockdep warning and then, as expected, deadlock on tcp_write_timer(). A way to reproduce this is by running the reproducer from ef7134c7fc48 and then 'rmmod cifs'. A few seconds later, the deadlock/lockdep warning shows up. Fix: We shouldn't mess with socket internals ourselves, so do not set sk_net_refcnt manually. Also change __sock_create() to sock_create_kern() for explicitness. As for non-init_net network namespaces, we deal with it the best way we can -- hold an extra netns reference for server->ssocket and drop it when it's released. This ensures that the netns still exists whenever we need to create/destroy server->ssocket, but is not directly tied to it. Fixes: ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") Cc: stable@vger.kernel.org Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de> Signed-off-by: Steve French <stfrench@microsoft.com>
2024-12-19smb: client: Deduplicate "select NETFS_SUPPORT" in KconfigDragan Simic
Repeating automatically selected options in Kconfig files is redundant, so let's delete repeated "select NETFS_SUPPORT" that was added accidentally. Fixes: 69c3c023af25 ("cifs: Implement netfslib hooks") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2024-12-19smb: use macros instead of constants for leasekey size and default cifsattrs ↵Bharath SM
value Replace default hardcoded value for cifsAttrs with ATTR_ARCHIVE macro Use SMB2_LEASE_KEY_SIZE macro for leasekey size in smb2_lease_break Signed-off-by: Bharath SM <bharathsm@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2024-12-19drm/sched: Fix drm_sched_fini() docu generationBagas Sanjaya
Commit baf4afc5831438 ("drm/sched: Improve teardown documentation") added a list of drm_sched_fini()'s problems. The list triggers htmldocs warning (but renders correctly in htmldocs output): Documentation/gpu/drm-mm:571: ./drivers/gpu/drm/scheduler/sched_main.c:1359: ERROR: Unexpected indentation. Separate the list from the preceding paragraph by a blank line to fix the warning. While at it, also end the aforementioned paragraph by a colon. Fixes: baf4afc58314 ("drm/sched: Improve teardown documentation") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20241108175655.6d3fcfb7@canb.auug.org.au/ Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> [phasta: Adjust commit message] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241217034915.62594-1-bagasdotme@gmail.com
2024-12-19Merge branch 'net-fib_rules-add-flow-label-selector-support'Paolo Abeni
Ido Schimmel says: ==================== net: fib_rules: Add flow label selector support In some deployments users would like to encode path information into certain bits of the IPv6 flow label, the UDP source port and the DSCP and use this information to route packets accordingly. Redirecting traffic to a routing table based on the flow label is not currently possible with Linux as FIB rules cannot match on it despite the flow label being available in the IPv6 flow key. This patchset extends FIB rules to match on the flow label with a mask. Future patches will add mask attributes to L4 ports and DSCP matches. Patches #1-#5 gradually extend FIB rules to match on the flow label. Patches #6-#7 allow user space to specify a flow label in route get requests. This is useful for both debugging and testing. Patch #8 adjusts the fib6_table_lookup tracepoint to print the flow label to the trace buffer for better observability. Patch #9 extends the FIB rule selftest with flow label test cases while utilizing the route get functionality from patch #6. ==================== Link: https://patch.msgid.link/20241216171201.274644-1-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19selftests: fib_rule_tests: Add flow label selector match testsIdo Schimmel
Add tests for the new FIB rule flow label selector. Test both good and bad flows and with both input and output routes. # ./fib_rule_tests.sh IPv6 FIB rule tests [...] TEST: rule6 check: flowlabel redirect to table [ OK ] TEST: rule6 check: flowlabel no redirect to table [ OK ] TEST: rule6 del by pref: flowlabel redirect to table [ OK ] TEST: rule6 check: iif flowlabel redirect to table [ OK ] TEST: rule6 check: iif flowlabel no redirect to table [ OK ] TEST: rule6 del by pref: iif flowlabel redirect to table [ OK ] TEST: rule6 check: flowlabel masked redirect to table [ OK ] TEST: rule6 check: flowlabel masked no redirect to table [ OK ] TEST: rule6 del by pref: flowlabel masked redirect to table [ OK ] TEST: rule6 check: iif flowlabel masked redirect to table [ OK ] TEST: rule6 check: iif flowlabel masked no redirect to table [ OK ] TEST: rule6 del by pref: iif flowlabel masked redirect to table [ OK ] [...] Tests passed: 268 Tests failed: 0 Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19tracing: ipv6: Add flow label to fib6_table_lookup tracepointIdo Schimmel
The different parameters affecting the IPv6 route lookup are printed to the trace buffer by the fib6_table_lookup tracepoint. Add the IPv6 flow label for better observability as it can affect the route lookup both in terms of multipath hash calculation and policy based routing (FIB rules). Example: # echo 1 > /sys/kernel/tracing/events/fib6/fib6_table_lookup/enable # ip -6 route get ::1 flowlabel 0x12345 ipproto udp sport 12345 dport 54321 &> /dev/null # cat /sys/kernel/tracing/trace_pipe ip-358 [010] ..... 44.897484: fib6_table_lookup: table 255 oif 0 iif 1 proto 17 ::/12345 -> ::1/54321 flowlabel 0x12345 tos 0 scope 0 flags 0 ==> dev lo gw :: err 0 Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19netlink: specs: Add route flow label attributeIdo Schimmel
Add the new flow label attribute to the spec. Example: # ip link add name dummy1 up type dummy # ip -6 route add default table 254 dev dummy1 # ip -6 route add default table 10 dev dummy1 # ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_rule.yaml \ --do newrule \ --json '{"family": 10, "priority": 1, "flowlabel": 10, "flowlabel-mask": 255, "action": 1, "table": 10}' None $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_route.yaml \ --do getroute \ --json '{"rtm-family": 10, "rta-flowlabel": 1}' --output-json \ | jq '.["rta-table"]' 254 $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_route.yaml \ --do getroute \ --json '{"rtm-family": 10, "rta-flowlabel": 10}' --output-json \ | jq '.["rta-table"]' 10 Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19ipv6: Add flow label to route get requestsIdo Schimmel
The default IPv6 multipath hash policy takes the flow label into account when calculating a multipath hash and previous patches added a flow label selector to IPv6 FIB rules. Allow user space to specify a flow label in route get requests by adding a new netlink attribute and using its value to populate the "flowlabel" field in the IPv6 flow info structure prior to a route lookup. Deny the attribute in RTM_{NEW,DEL}ROUTE requests by checking for it in rtm_to_fib6_config() and returning an error if present. A subsequent patch will use this capability to test the new flow label selector in IPv6 FIB rules. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19netlink: specs: Add FIB rule flow label attributesIdo Schimmel
Add the new flow label attributes to the spec. Example: # ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_rule.yaml \ --do newrule \ --json '{"family": 10, "flowlabel": 1, "flowlabel-mask": 1, "action": 1, "table": 1}' None $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/rt_rule.yaml \ --dump getrule --json '{"family": 10}' --output-json \ | jq '.[] | select(.flowlabel == "0x1")' { "table": 1, "suppress-prefixlen": "0xffffffff", "protocol": 0, "priority": 32765, "flowlabel": "0x1", "flowlabel-mask": "0x1", "family": 10, "dst-len": 0, "src-len": 0, "tos": 0, "action": "to-tbl", "flags": 0 } Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19net: fib_rules: Enable flow label selector usageIdo Schimmel
Now that both IPv4 and IPv6 correctly handle the new flow label attributes, enable user space to configure FIB rules that make use of the flow label by changing the policy to stop rejecting them and accepting 32 bit values in big-endian byte order. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19ipv6: fib_rules: Add flow label supportIdo Schimmel
Implement support for the new flow label selector which allows IPv6 FIB rules to match on the flow label with a mask. Ensure that both flow label attributes are specified (or none) and that the mask is valid. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19ipv4: fib_rules: Reject flow label attributesIdo Schimmel
IPv4 FIB rules cannot match on flow label so reject requests that try to add such rules. Do that in the IPv4 configure callback as the netlink policy resides in the core and used by both IPv4 and IPv6. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19net: fib_rules: Add flow label selector attributesIdo Schimmel
Add new FIB rule attributes which will allow user space to match on the IPv6 flow label with a mask. Temporarily set the type of the attributes to 'NLA_REJECT' while support is being added in the IPv6 code. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-12-19pmdomain: core: add dummy release function to genpd deviceLucas Stach
The genpd device, which is really only used as a handle to lookup OPP, but not even registered to the device core otherwise and thus lifetime linked to the genpd struct it is contained in, is missing a release function. After b8f7bbd1f4ec ("pmdomain: core: Add missing put_device()") the device will be cleaned up going through the driver core device_release() function, which will warn when no release callback is present for the device. Add a dummy release function to shut up the warning. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Fixes: b8f7bbd1f4ec ("pmdomain: core: Add missing put_device()") Cc: stable@vger.kernel.org Message-ID: <20241218184433.1930532-1-l.stach@pengutronix.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-12-19pmdomain: imx: gpcv2: fix an OF node reference leak in imx_gpcv2_probe()Joe Hattori
imx_gpcv2_probe() leaks an OF node reference obtained by of_get_child_by_name(). Fix it by declaring the device node with the __free(device_node) cleanup construct. This bug was found by an experimental static analysis tool that I am developing. Fixes: 03aa12629fc4 ("soc: imx: Add GPCv2 power gating driver") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Cc: stable@vger.kernel.org Message-ID: <20241215030159.1526624-1-joe@pf.is.s.u-tokyo.ac.jp> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-12-19fs: relax assertions on failure to encode file handlesAmir Goldstein
Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons. The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle. There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong. The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate. The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches. Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit. Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6. Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/ Reported-by: Dmitry Safonov <dima@arista.com> Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-12-19mmc: sdhci-msm: fix crypto key evictionEric Biggers
Commit c7eed31e235c ("mmc: sdhci-msm: Switch to the new ICE API") introduced an incorrect check of the algorithm ID into the key eviction path, and thus qcom_ice_evict_key() is no longer ever called. Fix it. Fixes: c7eed31e235c ("mmc: sdhci-msm: Switch to the new ICE API") Cc: stable@vger.kernel.org Cc: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Message-ID: <20241213041958.202565-6-ebiggers@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2024-12-19selftests/bpf: Fix compilation error in get_uprobe_offset()Jerome Marchand
In get_uprobe_offset(), the call to procmap_query() use the constant PROCMAP_QUERY_VMA_EXECUTABLE, even if PROCMAP_QUERY is not defined. Define PROCMAP_QUERY_VMA_EXECUTABLE when PROCMAP_QUERY isn't. Fixes: 4e9e07603ecd ("selftests/bpf: make use of PROCMAP_QUERY ioctl if available") Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20241218175724.578884-1-jmarchan@redhat.com
2024-12-19accel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal()Jacek Lawrynowicz
Move pm_runtime_set_active() to ivpu_pm_init() so when ivpu_ipc_send_receive_internal() is executed before ivpu_pm_enable() it already has correct runtime state, even if last resume was not successful. Fixes: 8ed520ff4682 ("accel/ivpu: Move set autosuspend delay to HW specific code") Cc: stable@vger.kernel.org # v6.7+ Reviewed-by: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210130939.1575610-4-jacek.lawrynowicz@linux.intel.com
2024-12-19accel/ivpu: Fix memory leak in ivpu_mmu_reserved_context_init()Jacek Lawrynowicz
Add appropriate error handling to ensure all allocated resources are released upon encountering an error. Fixes: a74f4d991352 ("accel/ivpu: Defer MMU root page table allocation") Cc: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210130939.1575610-3-jacek.lawrynowicz@linux.intel.com
2024-12-19accel/ivpu: Fix general protection fault in ivpu_bo_list()Jacek Lawrynowicz
Check if ctx is not NULL before accessing its fields. Fixes: 37dee2a2f433 ("accel/ivpu: Improve buffer object debug logs") Cc: stable@vger.kernel.org # v6.8 Reviewed-by: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210130939.1575610-2-jacek.lawrynowicz@linux.intel.com
2024-12-19selftests/bpf: Use asm constraint "m" for LoongArchTiezhu Yang
Currently, LoongArch LLVM does not support the constraint "o" and no plan to support it, it only supports the similar constraint "m", so change the constraints from "nor" in the "else" case to arch-specific "nmr" to avoid the build error such as "unexpected asm memory constraint" for LoongArch. Fixes: 630301b0d59d ("selftests/bpf: Add basic USDT selftests") Suggested-by: Weining Lu <luweining@loongson.cn> Suggested-by: Li Chen <chenli@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Cc: stable@vger.kernel.org Link: https://llvm.org/docs/LangRef.html#supported-constraint-code-list Link: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/LoongArch/LoongArchISelDAGToDAG.cpp#L172 Link: https://lore.kernel.org/bpf/20241219111506.20643-1-yangtiezhu@loongson.cn
2024-12-19RDMA/bnxt_re: Fix the locking while accessing the QP tableSelvin Xavier
QP table handling is synchronized with destroy QP and Async event from the HW. The same needs to be synchronized during create_qp also. Use the same lock in create_qp also. Fixes: 76d3ddff7153 ("RDMA/bnxt_re: synchronize the qp-handle table array") Fixes: f218d67ef004 ("RDMA/bnxt_re: Allow posting when QPs are in error") Fixes: 84cf229f4001 ("RDMA/bnxt_re: Fix the qp table indexing") Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/20241217102649.1377704-6-kalesh-anakkur.purayil@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-12-19RDMA/bnxt_re: Fix MSN table size for variable wqe modeDamodharam Ammepalli
For variable size wqe mode, the MSN table size should be half the size of the SQ depth. Fixing this to avoid wrap around problems in the retransmission path. Fixes: de1d364c3815 ("RDMA/bnxt_re: Add support for Variable WQE in Genp7 adapters") Reviewed-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/20241217102649.1377704-5-kalesh-anakkur.purayil@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
generated by cgit (git 2.34.1) at 2025-10-03 11:04:23 +0000