summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-04-23wifi: mwifiex: make region_code_mapping_t constSascha Hauer
region_code_mapping_t is not modified and shouldn't be. Mark it const. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-4-a6bbd4ac4d37@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: drop unnecessary initializationSascha Hauer
Several functions initialize the priv * without actually using the initialized value. Drop the initialization. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-3-a6bbd4ac4d37@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: use adapter as context pointer for mwifiex_hs_activated_event()Sascha Hauer
mwifiex_hs_activated_event() takes a struct mwifiex_private * as context pointer which this function doesn't need directly and the callers don't have. Use struct mwifiex_adapter * instead to simplify both the function and the callers. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-2-a6bbd4ac4d37@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: deduplicate code in mwifiex_cmd_tx_rate_cfg()Sascha Hauer
The code block inside the if/else is the same with just using pbitmap_rates if non NULL or priv->bitmap_rates otherwise. Deduplicate the code by picking the correct pointer first and then using it unconditionally. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-1-a6bbd4ac4d37@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mac80211: Replace __get_unaligned_cpu32 in mesh_pathtbl.cJulian Vetter
The __get_unaligned_cpu32 function is deprecated. So, replace it with the more generic get_unaligned and just cast the input parameter. Signed-off-by: Julian Vetter <julian@outer-limits.org> Link: https://patch.msgid.link/20250408092220.2267754-1-julian@outer-limits.org [fix subject] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23bcma: use new GPIO line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20250407-gpiochip-set-rv-bcma-v1-1-fa403ad76966@linaro.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23Revert "mac80211: Dynamically set CoDel parameters per station"Toke Høiland-Jørgensen
This reverts commit 484a54c2e597dbc4ace79c1687022282905afba0. The CoDel parameter change essentially disables CoDel on slow stations, with some questionable assumptions, as Dave pointed out in [0]. Quoting from there: But here are my pithy comments as to why this part of mac80211 is so wrong... static void sta_update_codel_params(struct sta_info *sta, u32 thr) { - if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { 1) sta->local->num_sta is the number of associated, rather than active, stations. "Active" stations in the last 50ms or so, might have been a better thing to use, but as most people have far more than that associated, we end up with really lousy codel parameters, all the time. Mistake numero uno! 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016. - sta->cparams.target = MS2TIME(50); This, by itself, was probably not too bad. 30ms might have been better, at the time, when we were battling powersave etc, but 20ms was enough, really, to cover most scenarios, even where we had low rate 2Ghz multicast to cope with. Even then, codel has a hard time finding any sane drop rate at all, with a target this high. - sta->cparams.interval = MS2TIME(300); But this was horrible, a total mistake, that is leading to codel being completely ineffective in almost any scenario on clients or APS. 100ms, even 80ms, here, would be vastly better than this insanity. I'm seeing 5+seconds of delay accumulated in a bunch of otherwise happily fq-ing APs.... 100ms of observed jitter during a flow is enough. Certainly (in 2016) there were interactions with powersave that I did not understand, and still don't, but if you are transmitting in the first place, powersave shouldn't be a problemmmm..... - sta->cparams.ecn = false; At the time we were pretty nervous about ecn, I'm kind of sanguine about it now, and reliably indicating ecn seems better than turning it off for any reason. [...] In production, on p2p wireless, I've had 8ms and 80ms for target and interval for years now, and it works great. I think Dave's arguments above are basically sound on the face of it, and various experimentation with tighter CoDel parameters in the OpenWrt community have show promising results[1]. So I don't think there's any reason to keep this parameter fiddling; hence this revert. [0] https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/ [1] https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/130 Suggested-By: Dave Taht <dave.taht@gmail.com> In-memory-of: Dave Taht <dave.taht@gmail.com> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: cfg80211/mac80211: remove more 5/10 MHz codeJohannes Berg
We still have ieee80211_chandef_rate_flags() and all that, but all the users seem pretty much broken (deflink, etc.) Remove all the code. It's been two years since last anyone even vaguely entertained the notion of looking at this and fixing it. Link: https://patch.msgid.link/20250329221419.c31da7ae8c84.I1a3a4b6008134d66ca75a5bdfc004f4594da8145@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mvm: Avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warning: drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:6430:41: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/Z-SV8gb6MuZJmmhe@kspp Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mac80211: Avoid -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Use the `DEFINE_RAW_FLEX()` helper for on-stack definitions of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warnings: net/mac80211/spectmgmt.c:151:47: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] net/mac80211/spectmgmt.c:155:48: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/Z-SQdHZljwAgIlp9@kspp Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23dt-bindings: wireless: qcom,wcnss: Use wireless-controller.yamlDavid Heidelberg
Reference wireless-controller.yaml schema, so we can use properties as local-mac-address or mac-address. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-5-f5c3fe00e8f0@ixit.cz Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23dt-bindings: wireless: silabs,wfx: Use wireless-controller.yamlJanne Grunau
Instead listing local-mac-address and mac-address properties, reference wireless-controller.yaml schema. The schema brings in constraints for the property checked during `make dtbs_check`. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-4-f5c3fe00e8f0@ixit.cz Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23dt-bindings: wireless: bcm4329-fmac: Use wireless-controller.yaml schemaJanne Grunau
The wireless-controller schema specifies local-mac-address as used in the bcm4329-fmac device nodes of Apple silicon devices (arch/arm64/boot/dts/apple). Fixes `make dtbs_check` for those devices. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-3-f5c3fe00e8f0@ixit.cz Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23dt-bindings: net: Add generic wireless controllerDavid Heidelberg
Wireless controllers share the common properties. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-2-f5c3fe00e8f0@ixit.cz Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23dt-bindings: net: Add network-class schema for mac-address propertiesJanne Grunau
The ethernet-controller schema specifies "mac-address" and "local-mac-address" but other network devices such as wireless network adapters use mac addresses as well. The Devicetree Specification, Release v0.3 specifies in section 4.3.1 a generic "Network Class Binding" with "address-bits", "mac-address", "local-mac-address" and "max-frame-size". This schema specifies the "address-bits" property and moves the remaining properties over from the ethernet-controller.yaml schema. The "max-frame-size" property is used to describe the maximal payload size despite its name. Keep the description from ethernet-controller specifying this property as MTU. The contradictory description in the Devicetree Specification is ignored. Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250324-dt-bindings-network-class-v5-1-f5c3fe00e8f0@ixit.cz Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: fw: api: Absolute rudimentary typo fixes in the file power.hBhaskar Chowdhury
s/folowing/following/ s/Celsuis/Celsius/ s/temerature/temperature/ ...twice Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20210317042540.4097078-1-unixbhaskar@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: Add missing MODULE_FIRMWARE for Qu-c0-jf-b0Víctor Gonzalo
The module metadata for the firmware file iwlwifi-Qu-c0-jf-b0-* is missing. Signed-off-by: Víctor Gonzalo <victor.gonzalo@anddroptable.net> Link: https://patch.msgid.link/20240313180227.2224780-1-victor.gonzalo@anddroptable.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mvm: Remove duplicated include in iwl-utils.cYang Li
The header files net/gso.h is included twice in iwl-utils.c, so one inclusion of each can be removed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=13555 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250115005431.89510-1-yang.lee@linux.alibaba.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: free SKBTX_WIFI_STATUS skb tx_flags flagJohannes Berg
Jason mentioned at netdevconf that we've run out of tx_flags in the skb_shinfo(). Gain one bit back by removing the wifi bit. We can do that because the only userspace application for it (hostapd) doesn't change the setting on the socket, it just uses different sockets, and normally doesn't even use this any more, sending the frames over nl80211 instead. Reviewed-by: Jason Xing <kerneljasonxing@gmail.com> Link: https://patch.msgid.link/20250313134942.52ff54a140ec.If390bbdc46904cf451256ba989d7a056c457af6e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23irqdomain: ssb: Switch to irq_domain_create_linear()Jiri Slaby (SUSE)
irq_domain_add_linear() is going away as being obsolete now. Switch to the preferred irq_domain_create_linear(). That differs in the first parameter: It takes more generic struct fwnode_handle instead of struct device_node. Therefore, of_fwnode_handle() is added around the parameter. Note some of the users can likely use dev->fwnode directly instead of indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not guaranteed to be set for all, so this has to be investigated on case to case basis (by people who can actually test with the HW). Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Michael Buesch <m@bues.ch> Cc: linux-wireless@vger.kernel.org Link: https://patch.msgid.link/20250319092951.37667-38-jirislaby@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: rt2x00: remove weird self-assignment in rt2800_loft_search()Dmitry Antipov
Remove weird self-assignment in 'rt2800_loft_search()' assuming that it was just a typo. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20250321134256.821596-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-17wifi: wcn36xx: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Acked-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-4-4e9a04dbe362@linutronix.de Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-3-4e9a04dbe362@linutronix.de Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath11k: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-2-4e9a04dbe362@linutronix.de Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath10k: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250417-restricted-pointers-ath-v1-1-4e9a04dbe362@linutronix.de Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: fix node corruption in ar->arvifs listMaharaja Kennadyrajan
In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250416021724.2162519-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Prevent sending WMI commands to firmware during firmware crashMaharaja Kennadyrajan
Currently, we encounter the following kernel call trace when a firmware crash occurs. This happens because the host sends WMI commands to the firmware while it is in recovery, causing the commands to fail and resulting in the kernel call trace. Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the host driver receives the firmware crash notification from MHI. This prevents sending WMI commands to the firmware during recovery. Call Trace: <TASK> dump_stack_lvl+0x75/0xc0 register_lock_class+0x6be/0x7a0 ? __lock_acquire+0x644/0x19a0 __lock_acquire+0x95/0x19a0 lock_acquire+0x265/0x310 ? ath12k_ce_send+0xa2/0x210 [ath12k] ? find_held_lock+0x34/0xa0 ? ath12k_ce_send+0x56/0x210 [ath12k] _raw_spin_lock_bh+0x33/0x70 ? ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_ce_send+0xa2/0x210 [ath12k] ath12k_htc_send+0x178/0x390 [ath12k] ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k] ath12k_wmi_cmd_send+0x62/0x190 [ath12k] ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k] ieee80211_dump_survey+0x99/0x240 [mac80211] nl80211_dump_survey+0xe7/0x470 [cfg80211] ? kmalloc_reserve+0x59/0xf0 genl_dumpit+0x24/0x70 netlink_dump+0x177/0x360 __netlink_dump_start+0x206/0x280 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0 ? genl_op_lock.part.12+0x10/0x10 ? genl_dumpit+0x70/0x70 genl_rcv_msg+0x1d0/0x290 ? nl80211_del_station+0x330/0x330 [cfg80211] ? genl_get_cmd_both+0x50/0x50 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x1f/0x30 netlink_unicast+0x1b6/0x260 netlink_sendmsg+0x31a/0x450 __sock_sendmsg+0xa8/0xb0 ____sys_sendmsg+0x1e4/0x260 ___sys_sendmsg+0x89/0xe0 ? local_clock_noinstr+0xb/0xc0 ? rcu_is_watching+0xd/0x40 ? kfree+0x1de/0x370 ? __sys_sendmsg+0x7a/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Fixes: a9b46dd2e483 ("wifi: ath12k: Add firmware coredump collection support") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250416020414.2161545-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: avoid multiple skb_cb fetch in ath12k_mac_mgmt_tx_wmi()Rameshkumar Sundaram
ath12k_mac_mgmt_tx_wmi() fetches ath12k's skb_cb space multiple times from TX skb which is redundant operation. Save the skb_cb in a local pointer and use the same instead. 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: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250415195812.2633923-3-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: fix wrong handling of CCMP256 and GCMP ciphersRameshkumar Sundaram
Currently for CCMP256, GCMP128 and GCMP256 ciphers, in ath12k_install_key() IEEE80211_KEY_FLAG_GENERATE_IV_MGMT is not set and in ath12k_mac_mgmt_tx_wmi() a length of IEEE80211_CCMP_MIC_LEN is reserved for all ciphers. This results in unexpected drop of protected management frames in case either of above 3 ciphers is used. The reason is, without IEEE80211_KEY_FLAG_GENERATE_IV_MGMT set, mac80211 will not generate CCMP/GCMP headers in TX frame for ath12k. Also MIC length reserved is wrong and such frames are dropped by hardware. Fix this by setting IEEE80211_KEY_FLAG_GENERATE_IV_MGMT flag for above ciphers and by reserving proper MIC length for those ciphers. 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 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250415195812.2633923-2-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Fix the QoS control field offset to build QoS headerRamasamy Kaliappan
Currently, in the mac80211 layer, received EAPOL packets are dropped when the HT control field is present in the QoS header. This issue arises due to an incorrect QoS control field offset used to build the QoS header in the MSDU data, leading to a corrupted header in the mac80211 layer. This issue also applies to other frames that contain the QoS control field, such as QoS data or Null frames. To resolve this, use ieee80211_get_qos_ctl() to obtain the correct QoS control offset from the MSDU data. Additionally, ensure the QoS control header is copied in little-endian format within the MSDU data. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Ramasamy Kaliappan <quic_rkaliapp@quicinc.com> Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250415184102.2707300-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Avoid allocating rx_stats when ext_rx_stats is disabledP Praneesh
Currently, driver allocates the struct ath12k_rx_peer_stats for each station regardless of whether ext_rx_stats is enabled. This structure is populated by the monitor destination ring for both single-user and multi-user scenarios when ext_rx_stats is enabled. However, when ext_rx_stats is disabled, this allocation is unnecessary and results in additional memory consumption. To address this issue, allocate the struct ath12k_rx_peer_stats only when ext_rx_stats is enabled through debugfs. This change prevents unnecessary memory allocation. Additionally, ensure that the station dump RSSI is updated irrespective of the ext_rx_stats enablement. 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 <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250409052647.81955-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: avoid deadlock during regulatory update in ath12k_regd_update()Wen Gong
Running this test in a loop it is easy to reproduce an rtnl deadlock: iw reg set FI ifconfig wlan0 down What happens is that thread A (workqueue) tries to update the regulatory: try to acquire the rtnl_lock of ar->regd_update_work rtnl_lock ath12k_regd_update [ath12k] ath12k_regd_update_work [ath12k] process_one_work worker_thread kthread ret_from_fork And thread B (ifconfig) tries to stop the interface: try to cancel_work_sync(&ar->regd_update_work) in ath12k_mac_op_stop(). ifconfig 3109 [003] 2414.232506: probe: ath12k_mac_op_stop [ath12k] drv_stop [mac80211] ieee80211_do_stop [mac80211] ieee80211_stop [mac80211] The sequence of deadlock is: 1. Thread B calls rtnl_lock(). 2. Thread A starts to run and calls rtnl_lock() from within ath12k_regd_update_work(), then enters wait state because the lock is owned by thread B. 3. Thread B tries to call cancel_work_sync(&ar->regd_update_work), but thread A is in ath12k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync() forever waits for ath12k_regd_update_work() to finish and we have a deadlock. Change to use regulatory_set_wiphy_regd(), which is the asynchronous version of regulatory_set_wiphy_regd_sync(). This way rtnl & wiphy locks are not required so can be removed, and in the end the deadlock issue can be avoided. But a side effect introduced by the asynchronous regd update is that, some essential information used in ath12k_reg_update_chan_list(), which would be called later in ath12k_regd_update(), might has not been updated by cfg80211, as a result wrong channel parameters sent to firmware. To handle this side effect, move ath12k_reg_update_chan_list() to ath12k_reg_notifier(), and advertise WIPHY_FLAG_NOTIFY_REGDOM_BY_DRIVER to cfg80211. This works because, in the process of the asynchronous regd update, after the new regd is processed, cfg80211 will notify ath12k by calling ath12k_reg_notifier(). Since all essential information is updated at that time, we are good to do channel list update. Please note ath12k_reg_notifier() could also be called due to other reasons, like core/beacon/user hints etc. For them we are not allowed to call ath12k_reg_update_chan_list() because regd has not been updated. This is done by verifying the initiator. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Co-developed-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-rtnl-deadlock-v3-1-fdc12bc511ea@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Add MSDU length validation for TKIP MIC errorP Praneesh
In the WBM error path, while processing TKIP MIC errors, MSDU length is fetched from the hal_rx_desc's msdu_end. This MSDU length is directly passed to skb_put() without validation. In stress test scenarios, the WBM error ring may receive invalid descriptors, which could lead to an invalid MSDU length. To fix this, add a check to drop the skb when the calculated MSDU length is greater than the skb size. 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 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250416021903.3178962-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: fix invalid access to memorySarika Sharma
In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408045327.1632222-1-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: correctly handle mcast packets for clientsSarika Sharma
Currently, RX is_mcbc bit is set for packets sent from client as destination address (DA) is multicast/broadcast address, but packets are actually unicast as receiver address (RA) is not multicast address. Hence, packets are not handled properly due to this is_mcbc bit. Therefore, reset the is_mcbc bit if interface type is AP. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411061523.859387-3-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: using msdu end descriptor to check for rx multicast packetsSarika Sharma
Currently, the RX multicast broadcast packet check is performed using bit 15 from the info6 field of the MPDU start descriptor. This check can also be done using bit 9 from the info5 field of the MSDU end descriptor. However, in some scenarios multicast bit is not set when fetched from MPDU start descriptor. Therefore, checking the RX multicast broadcast packet from the MSDU end descriptor is more reliable as it is per MSDU. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411061523.859387-2-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Update frequency range if reg rules changesAditya Kumar Singh
During the hardware register, driver updates the frequency range during boot-up. However, if new regulatory rules are applied after boot-up, the frequency range remains based on the older rules. Since different countries have varying regulatory rules, the frequency range can differ. Retaining the frequency range based on outdated rules can be misleading. Update the frequency range according to the new regulatory rules in the function ath12k_regd_update(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-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: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Co-developed-by: Rajat Soni <quic_rajson@quicinc.com> Signed-off-by: Rajat Soni <quic_rajson@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408042128.720263-4-quic_rajson@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Fix frequency range in driverAditya Kumar Singh
During the initial WMI exchange, the firmware updates the hardware-supported start and end frequencies in the ath12k_wmi_hal_reg_capabilities_ext_arg structure. These frequencies, being hardware-supported, may not always align with the current regulatory operating frequencies. When operating as multiple grouped hardwares under a single wiphy, the driver advertises these values directly to the upper layer in the per-radio frequency range, which can be misleading. Sample output snippet from iw phyX info command - [..] Supported wiphy radios: * Idx 0: Frequency Range: 2312 MHz - 2732 MHz [..] * Idx 1: Frequency Range: 5150 MHz - 5330 MHz [..] [..] The frequency range displayed above is incorrect because the driver directly advertises the hardware-supported values to the upper layer. The driver is aware of the current operating regulatory rules, and hence it can use this information to determine the final operating start and end frequencies. To resolve this issue, add support to store the start and end frequencies received during the regulatory update event. Then, intersect these with the hardware-supported start and end frequencies, and finally, advertise the intersected values to the upper layer. Sample output snippet from iw phyX info command after the fix - [..] Supported wiphy radios: * Idx 0: Frequency Range: 2402 MHz - 2472 MHz [..] * Idx 1: Frequency Range: 5170 MHz - 5330 MHz [..] [..] Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-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: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Co-developed-by: Rajat Soni <quic_rajson@quicinc.com> Signed-off-by: Rajat Soni <quic_rajson@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408042128.720263-3-quic_rajson@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Add helper function ath12k_mac_update_freq_range()Rajat Soni
In a subsequent change, the frequency range needs to be updated with each regulatory update. Since the current function also modifies the DISABLED flag in the actual channel list, which should always align with hardware-supported start and end frequencies rather than the current operating ones, the existing function cannot be called again. Therefore, the logic for setting the frequency range needs to be refactored. To address this, refactor the frequency setting part into a new helper function, ath12k_mac_update_freq_range(). Since this needs to be done independently of updating the DISABLED flag, call the new helper function ath12k_mac_update_freq_range() after updating the channel list for each band. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-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: Rajat Soni <quic_rajson@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408042128.720263-2-quic_rajson@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Use skb->len for dma_unmap_single() length parameterP Praneesh
During dma_unmap_single() for extended skb, the driver currently uses sizeof() of the corresponding structure. When the allocation size changes, one of the parameters of dma_unmap_single() needs to be updated everywhere. Improve code readability by using skb->len instead of sizeof() the structure. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-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 <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-5-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Fix memory leak during extended skb allocationP Praneesh
In ath12k_dp_tx(), memory allocated for extended skb is not freed properly, causing a memory leak even when the host receives tx completion for those skbs. Fix this issue by storing skb_ext_desc in the host tx descriptor and using this skb_ext_desc field during completion or during ath12k_dp_cc_cleanup(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-4-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Refactor tx descriptor handling in tx completion handlerP Praneesh
Current code uses mac_id and msdu parameters in ath12k_dp_tx_free_txbuf() and ath12k_dp_tx_process_htt_tx_complete(). Since these parameters are already encapsulated by struct ath12k_dp_tx_desc, passing them individually results in redundant arguments. Introduce struct ath12k_tx_desc_params to capture the skb, mac_id, and pass it to the corresponding functions. Refactor these functions to use struct ath12k_tx_desc_params instead, reducing the number of arguments and improving function argument handling efficiency. Additionally, use struct ath12k_tx_desc_params in ath12k_dp_tx_htt_tx_complete_buf() and ath12k_dp_tx_complete_msdu(), which will be utilized for fetching extended skb in a future patch. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-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 <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-3-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Handle error cases during extended skb allocationP Praneesh
Currently, in the case of extended skb allocation, the buffer is freed before the DMA unmap operation. This premature deletion can result in skb->data corruption, as the memory region could be re-allocated for other purposes. Fix this issue by reordering the failure cases by calling dma_unmap_single() first, then followed by the corresponding kfree_skb(). This helps avoid data corruption in case of failures in dp_tx(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-2-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17Merge tag 'net-6.15-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from Bluetooth, CAN and Netfilter. Current release - regressions: - two fixes for the netdev per-instance locking - batman-adv: fix double-hold of meshif when getting enabled Current release - new code bugs: - Bluetooth: increment TX timestamping tskey always for stream sockets - wifi: static analysis and build fixes for the new Intel sub-driver Previous releases - regressions: - net: fib_rules: fix iif / oif matching on L3 master (VRF) device - ipv6: add exception routes to GC list in rt6_insert_exception() - netfilter: conntrack: fix erroneous removal of offload bit - Bluetooth: - fix sending MGMT_EV_DEVICE_FOUND for invalid address - l2cap: process valid commands in too long frame - btnxpuart: Revert baudrate change in nxp_shutdown Previous releases - always broken: - ethtool: fix memory corruption during SFP FW flashing - eth: - hibmcge: fixes for link and MTU handling, pause frames etc - igc: fixes for PTM (PCIe timestamping) - dsa: b53: enable BPDU reception for management port Misc: - fixes for Netlink protocol schemas" * tag 'net-6.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (81 commits) net: ethernet: mtk_eth_soc: revise QDMA packet scheduler settings net: ethernet: mtk_eth_soc: correct the max weight of the queue limit for 100Mbps net: ethernet: mtk_eth_soc: reapply mdc divider on reset net: ti: icss-iep: Fix possible NULL pointer dereference for perout request net: ti: icssg-prueth: Fix possible NULL pointer dereference inside emac_xmit_xdp_frame() net: ti: icssg-prueth: Fix kernel warning while bringing down network interface netfilter: conntrack: fix erronous removal of offload bit net: don't try to ops lock uninitialized devs ptp: ocp: fix start time alignment in ptp_ocp_signal_set net: dsa: avoid refcount warnings when ds->ops->tag_8021q_vlan_del() fails net: dsa: free routing table on probe failure net: dsa: clean up FDB, MDB, VLAN entries on unbind net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered net: txgbe: fix memory leak in txgbe_probe() error path net: bridge: switchdev: do not notify new brentries as changed net: b53: enable BPDU reception for management port netlink: specs: rt-neigh: prefix struct nfmsg members with ndm netlink: specs: rt-link: adjust mctp attribute naming netlink: specs: rtnetlink: attribute naming corrections ...
2025-04-17Merge tag 'for-linus-6.15a-rc3-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fix from Juergen Gross: "Just a single fix for the Xen multicall driver avoiding a percpu variable referencing initdata by its initializer" * tag 'for-linus-6.15a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: fix multicall debug feature
2025-04-17Merge tag 'for-linus-fwctl' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma Pull fwctl fixes from Jason Gunthorpe: "Three small changes from further build testing: - Don't rely on the userspace uuid.h for the uapi header - Fix sparse warnings in pds - Typo in log message" * tag 'for-linus-fwctl' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: fwctl: Fix repeated device word in log message pds_fwctl: Fix type and endian complaints fwctl/cxl: Fix uuid_t usage in uapi
2025-04-17Merge tag 'sound-6.15-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes. All are device-specific like quirks, new IDs, and other safe (or rather boring) changes" * tag 'sound-6.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: firmware: cs_dsp: test_bin_error: Fix uninitialized data used as fw version ASoC: codecs: Add of_match_table for aw888081 driver ASoC: fsl: fsl_qmc_audio: Reset audio data pointers on TRIGGER_START event mailmap: Add entry for Srinivas Kandagatla MAINTAINERS: use kernel.org alias ASoC: cs42l43: Reset clamp override on jack removal ALSA: hda/realtek - Fixed ASUS platform headset Mic issue ALSA: hda/cirrus_scodec_test: Don't select dependencies ALSA: azt2320: Replace deprecated strcpy() with strscpy() ASoC: hdmi-codec: use RTD ID instead of DAI ID for ELD entry ASoC: Intel: avs: Constrain path based on BE capabilities ALSA: hda/tas2781: Remove unnecessary NULL check before release_firmware() ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe() ASoC: fsl_asrc_dma: get codec or cpu dai from backend ASoC: qcom: Fix sc7280 lpass potential buffer overflow ASoC: dwc: always enable/disable i2s irqs ASoC: Intel: sof_sdw: Add quirk for Asus Zenbook S16 ASoC: codecs:lpass-wsa-macro: Fix logic of enabling vi channels ASoC: codecs:lpass-wsa-macro: Fix vi feedback rate
2025-04-17Merge tag 'platform-drivers-x86-v6.15-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform drivers fixes from Ilpo Järvinen: "Fixes: - amd/pmf: Fix STT limits - asus-laptop: Fix an uninitialized variable - intel_pmc_ipc: Allow building without ACPI - mlxbf-bootctl: Use sysfs_emit_at() in secure_boot_fuse_state_show() - msi-wmi-platform: Add locking to workaround ACPI firmware bug New HW support: - alienware-wmi-wmax: - Extended thermal control support to: - Alienware Area-51m R2 - Alienware m16 R1 - Alienware m16 R2 - Dell G16 7630 - Dell G5 5505 SE - G-Mode support to Alienware m16 R1 - x86-android-tablets: Add Vexia Edu Atla 10 tablet 5V data" * tag 'platform-drivers-x86-v6.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: msi-wmi-platform: Workaround a ACPI firmware bug platform/x86: msi-wmi-platform: Rename "data" variable platform/x86: alienware-wmi-wmax: Extend support to more laptops platform/x86: alienware-wmi-wmax: Add G-Mode support to Alienware m16 R1 platform/x86: amd: pmf: Fix STT limits mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show() platform/x86: x86-android-tablets: Add Vexia Edu Atla 10 tablet 5V data platform/x86: x86-android-tablets: Add "9v" to Vexia EDU ATLA 10 tablet symbols asus-laptop: Fix an uninitialized variable platform/x86: intel_pmc_ipc: add option to build without ACPI
2025-04-17Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Small drivers fixes, except for ufs which has two large updates, one for exposing the device level feature, which is a new addition to the device spec and the other reworking the exynos driver to fix coherence issues on some android phones" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: megaraid_sas: Driver version update to 07.734.00.00-rc1 scsi: megaraid_sas: Block zero-length ATA VPD inquiry scsi: scsi_transport_srp: Replace min/max nesting with clamp() scsi: ufs: core: Add device level exception support scsi: ufs: core: Rename ufshcd_wb_presrv_usrspc_keep_vcc_on() scsi: smartpqi: Use is_kdump_kernel() to check for kdump scsi: pm80xx: Set phy_attached to zero when device is gone scsi: ufs: exynos: gs101: Put UFS device in reset on .suspend() scsi: ufs: exynos: Move phy calls to .exit() callback scsi: ufs: exynos: Enable PRDT pre-fetching with UFSHCD_CAP_CRYPTO scsi: ufs: exynos: Ensure consistent phy reference counts scsi: ufs: exynos: Disable iocc if dma-coherent property isn't set scsi: ufs: exynos: Move UFS shareability value to drvdata scsi: ufs: exynos: Ensure pre_link() executes before exynos_ufs_phy_init() scsi: iscsi: Fix missing scsi_host_put() in error path scsi: ufs: core: Fix a race condition related to device commands scsi: hisi_sas: Fix I/O errors caused by hardware port ID changes scsi: hisi_sas: Enable force phy when SATA disk directly connected
2025-04-17Merge tag 'ata-6.15-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fix from Damien Le Moal: - Fix how sense data from the sense data for successfull NCQ commands log page is used to fully initialize the result_tf of a completed command, so that the sense data returned to the scsi layer is fully initialized with all the device provided information (from Niklas) * tag 'ata-6.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-sata: Save all fields from sense data descriptor
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 05:47:32 +0000