summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-30selftests: net: Add tests for ARP probe and DAD NS handlingDanielle Ratson
Add test cases to verify that ARP probes and DAD Neighbor Solicitations are handled correctly by the bridge neighbor suppression feature. When neighbor suppression is enabled on a bridge VXLAN port, the bridge should reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist, and the answer is known. However, when either the FDB or the neighbor exists, ARP probes / DAD NS should be treated like regular ARP requests / NS and flood to VXLAN. Add two new test functions: neigh_suppress_arp_probe(): Tests ARP probe handling by triggering duplicate address detection using arping -D. Verifies that probes are flooded when the bridge doesn't know the answer, and suppressed when FDB and neighbor entries exist. neigh_suppress_dad_ns(): Tests DAD NS handling by constructing DAD NS packets using mausezahn and verifies correct flooding/suppression behavior. Before the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [FAIL] TEST: ARP probe suppression [FAIL] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [FAIL] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [FAIL] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [FAIL] TEST: DAD NS proxy NA reply [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [FAIL] Tests passed: 10 Tests failed: 10 After the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [ OK ] TEST: ARP probe suppression [ OK ] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [ OK ] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [ OK ] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [ OK ] TEST: DAD NS proxy NA reply [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [ OK ] Tests passed: 20 Tests failed: 0 Signed-off-by: Danielle Ratson <danieller@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260429062405.1386417-3-danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30bridge: Do not suppress ARP probes and DAD NS unconditionallyDanielle Ratson
When neighbor suppression is enabled on a VXLAN port, the bridge is expected to reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist. This allows the bridge to suppress flooding of these messages to the VXLAN overlay. According to RFC 9161 ("Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks"): "A PE SHOULD reply to broadcast/multicast address resolution messages, i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages. An ARP probe is an ARP Request constructed with an all-zero sender IP address that may be used by hosts for IPv4 Address Conflict Detection as specified in [RFC5227]". However, the current implementation unconditionally suppresses ARP probes and DAD Neighbor Solicitations, which breaks Duplicate Address Detection (DAD) over EVPN. For DAD to work correctly over the VXLAN fabric: - When the bridge does not know the answer: flood the probe/DAD packet to allow remote VTEPs to respond. - When the bridge knows the answer: reply to indicate the address is in use. Fix by adjusting the early suppression checks to exclude ARP probes and DAD NS from unconditional suppression. When replying to a DAD NS, br_nd_send() is adjusted to set the NA destination to the all-nodes multicast address (ff02::1) and clear the Solicited flag, in accordance with RFC 4861 section 7.2.4. Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Danielle Ratson <danieller@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260429062405.1386417-2-danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30net/smc: cap allocation order for SMC-R physically contiguous buffersD. Wythe
The alloc_pages() cannot satisfy requests exceeding MAX_PAGE_ORDER, and attempting such allocations will lead to guaranteed failures and potential kernel warnings. For SMCR_PHYS_CONT_BUFS, cap the allocation order to MAX_PAGE_ORDER. This ensures the attempts to allocate the largest possible physically contiguous chunk succeed, instead of failing with an invalid order. This also avoids redundant "try-fail-degrade" cycles in __smc_buf_create(). For SMCR_MIXED_BUFS, no cap is needed: if the order exceeds MAX_PAGE_ORDER, alloc_pages() will silently fail (__GFP_NOWARN) and automatically fall back to virtual memory. Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Link: https://patch.msgid.link/20260429021637.21815-1-alibuda@linux.alibaba.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30ipv6: Implement limits on extension header parsingDaniel Borkmann
ipv6_{skip_exthdr,find_hdr}() and ip6_{tnl_parse_tlv_enc_lim, protocol_deliver_rcu}() iterate over IPv6 extension headers until they find a non-extension-header protocol or run out of packet data. The loops have no iteration counter, relying solely on the packet length to bound them. For a crafted packet with 8-byte extension headers filling a 64KB jumbogram, this means a worst case of up to ~8k iterations with a skb_header_pointer call each. ipv6_skip_exthdr(), for example, is used where it parses the inner quoted packet inside an incoming ICMPv6 error: - icmpv6_rcv - checksum validation - case ICMPV6_DEST_UNREACH - icmpv6_notify - pskb_may_pull() <- pull inner IPv6 header - ipv6_skip_exthdr() <- iterates here - pskb_may_pull() - ipprot->err_handler() <- sk lookup The per-iteration cost of ipv6_skip_exthdr itself is generally light, but skb_header_pointer becomes more costly on reassembled packets: the first ~1232 bytes of the inner packet are in the skb's linear area, but the remaining ~63KB are in the frag_list where skb_copy_bits is needed to read data. Initially, the idea was to add a configurable limit via a new sysctl knob with default 8, in line with knobs from commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options"), but two reasons eventually argued against it: - It adds to UAPI that needs to be maintained forever, and upcoming work is restricting extension header ordering anyway, leaving little reason for another sysctl knob - exthdrs_core.c is always built-in even when CONFIG_IPV6=n, where struct net has no .ipv6 member, so the read site would need an ifdef'd fallback to a constant anyway Therefore, just use a constant (IP6_MAX_EXT_HDRS_CNT). All four extension header walking functions are now bound by this limit. Note that the check in ip6_protocol_deliver_rcu() happens right before the goto resubmit, such that we don't have to have a test for ipv6_ext_hdr() in the fast-path. There's an ongoing IETF draft-iurman-6man-eh-occurrences to enforce IPv6 extension headers ordering and occurrence. The latter also discusses security implications. As per RFC8200 section 4.1, the occurrence rules for extension headers provide a practical upper bound which is 8. In order to be conservative, let's define IP6_MAX_EXT_HDRS_CNT as 12 to leave enough room for quirky setups. In the unlikely event that this is still not enough, then we might need to reconsider a sysctl. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Justin Iurman <justin.iurman@gmail.com> Link: https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30Merge tag 'acpi-7.1-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI support fixes from Rafael Wysocki: "These fix leftover issues in the ACPI Time and Alarm Device (TAD) driver on top of the recently merged updates of it and address assorted issues in the ACPI support code: - Fix removal code ordering in the ACPI TAD driver, refine timer value computations and checks in its RTC class device interface, make it use the __ATTRIBUTE_GROUPS() macro, and fix a comment in it (Rafael Wysocki) - Fix EINJV2 memory error injection in APEI (Tony Luck) - Add missing notifier_block structure forward declaration to acpi_bus.h (Bartosz Golaszewski) - Fix related_cpus inconsistency during CPU hotplug in the ACPI CPPC library (Jinjie Ruan) - Add a quirk to force native backlight on HP OMEN 16 (8A44) in the ACPI video bus driver (Shivam Kalra)" * tag 'acpi-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: bus: add missing forward declaration to acpi_bus.h ACPI: video: force native backlight on HP OMEN 16 (8A44) ACPI: TAD: Fix up a comment in acpi_tad_probe() ACPI: TAD: RTC: Refine timer value computations and checks ACPI: TAD: Use devres for all driver cleanup ACPI: TAD: Use __ATTRIBUTE_GROUPS() macro ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug ACPI: APEI: EINJ: Fix EINJV2 memory error injection ACPICA: Provide #defines for EINJV2 error types
2026-04-30Merge tag 'wireless-next-2026-04-30' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Some new content already, notably: - mac80211: major rework of station bandwidth handling, fixing issues with lower capability than AP - general: cleanups for EMLSR spec issues (drafts differed) - ath9k: GPIO interface improvements - ath12k: replace dynamic memory allocation in WMI RX path * tag 'wireless-next-2026-04-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (39 commits) wifi: brcmsmac: phy_lcn: Remove dead code in wlc_lcnphy_radio_2064_channel_tune_4313() wifi: mac80211: always allow transmitting null-data on TXQs wifi: mac80211: use kstrtobool_from_user() in debugfs callbacks wifi: cfg80211: validate cipher suite for NAN Data keys wifi: nl80211: check link is beaconing for color change wifi: mac80211: clarify an 802.11 VHT spec reference wifi: mac80211: fix per-station PHY capability bandwidth wifi: mac80211: clarify per-STA bandwidth handling wifi: nl80211: always validate AP operation/PHY regulatory wifi: cfg80211: provide HT/VHT operation for AP beacon wifi: nl80211: reject too short HT/VHT/HE/EHT capability/operation wifi: cfg80211: move AP HT/VHT/... operation to beacon info wifi: nl80211: reject beacons with bad HE operation wifi: cfg80211: remove HE/SAE H2E required fields wifi: mac80211: remove ieee80211_sta_cur_vht_bw() wifi: mac80211: clean up ieee80211_sta_cap_rx_bw() wifi: mac80211: clean up initial STA NSS/bandwidth handling wifi: mac80211: clean up STA NSS handling wifi: mac80211: simplify ieee80211_sta_rx_bw_to_chan_width() wifi: nl80211: document channel opmode change channel width ... ==================== Link: https://patch.msgid.link/20260430120304.249081-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30Merge tag 'v7.1-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull smb client fixes from Steve French: - multichannel crediting fix - memory allocation improvement for smb2_compound_op - remove some dead code * tag 'v7.1-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: change_conf needs to be called for session setup smb: client: change allocation requirements in smb2_compound_op smb/client: remove unused smb3_parse_opt()
2026-04-30net: phy: micrel: fix LAN8814 QSGMII soft resetRobert Marko
LAN8814 QSGMII soft reset was moved into the probe function to avoid triggering it for each of 4 PHY-s in the package. However, that broke QSGMII link between the MAC and PHY on most LAN8814 PHY-s, specificaly for us on the Microchip LAN969x switch. Reading the QSGMII status registers it was visible that lanes were only partially synced. It looks like the reset timing is crucial, so lets move the reset back into the .config_init function but guard it with phy_package_init_once() to avoid it being triggered on each of 4 PHY-s in the package. Change the probe function to use phy_package_probe_once() for coma and PtP setup. Fixes: 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://patch.msgid.link/20260428134138.1741253-1-robert.marko@sartura.hr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01netfilter: flowtable: fix inline pppoe encapsulation in xmit pathPablo Neira Ayuso
Address two issues in the inline pppoe encapsulation: - Add needs_gso_segment flag to segment PPPoE packets in software given that there is no GSO support for this. - Use FLOW_OFFLOAD_XMIT_DIRECT since neighbour cache is not available in point-to-point device, use the hardware address that is obtained via flowtable path discovery (ie. fill_forward_path). Fixes: 18d27bed0880 ("netfilter: flowtable: inline pppoe encapsulation in xmit path") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-05-01netfilter: flowtable: fix inline vlan encapsulation in xmit pathPablo Neira Ayuso
Several issues in the inline vlan support: - The layer 2 encapsulation representation in the tuple takes encap[0] as the outer header and encap[1] as the inner header as seen from the ingress path. Reverse the encap loop to push first the inner then the outer vlan header. - Postpone pushing the layer 2 header once destination device is known. This allows to calculate the needed hearoom via LL_RESERVED_SPACE to accommodate the layer 2 headers. - Add and use nf_flow_vlan_push() as suggested by Eric Woudstra, this is a simplified version of skb_vlan_push() for egress path only. Fixes: c653d5a78f34 ("netfilter: flowtable: inline vlan encapsulation in xmit path") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-05-01Revert "drm/nouveau/gsp: add support for GA100"Timur Tabi
This reverts commit 20e0c197802c545db220157fafd567a10f2b7672. Despite claiming to add GA100 support, that commit actually has quite a few problems. It falsely claims that there is no VBIOS. GA100 does have a VBIOS, but it has no display engine, so it cannot use the PRAMIN method the read VBIOS and must fall back to using PROM. For whatever reason, the VBIOS on GA100 has an "Init-from-ROM" (IFR) header where the PCI Expansion ROM would normally be found. So to find that ROM, Nouveau needs to parse the IFR header. The commit also falsely claimed that there is no graphics (GR) engine. So rather than try to fix that commit, just revert it and start over from scratch. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20260430223838.2530778-2-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-04-30hwmon: (lm63) Add locking to avoid TOCTOUGui-Dong Han
The functions show_fan(), show_pwm1(), show_temp11(), temp2_crit_hyst_show(), and show_lut_temp_hyst() access shared cached data without holding the update lock. This can cause TOCTOU races if the cached values change between the checks and the later calculations. Those cached values are updated in lm63_update_device(). In the general case, the affected functions combine multiple cached values without locking and can therefore observe a mixed old/new snapshot. In addition, show_fan() reads data->fan[nr] locklessly while lm63_update_device() updates data->fan[0] in two steps, which can expose an intermediate torn value and potentially trigger a divide-by-zero error. This means that converting the macro to a function is not sufficient to fix show_fan(). Hold the update lock across the whole read and calculation sequence so that the values remain stable. Check the other functions in the driver as well. Keep them unchanged because they either do not access shared cached values multiple times or already do so under lock. Link: https://lore.kernel.org/linux-hwmon/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: e872c91e726e ("hwmon: (lm63) Add support for unsigned upper temperature limits") Fixes: d216f6809eb6 ("hwmon: (lm63) Expose automatic fan speed control lookup table") Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20260416135703.53262-1-hanguidong02@gmail.com [groeck: Use lm63_update_device() to get driver data in temp2_crit_hyst_store] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-05-01Merge tag 'drm-misc-fixes-2026-04-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: DRM core and helpers: - calculate framebuffer geometry with format helpers - fix docs appletbdrm: - allocate protocol buffers with kvzalloc() dma-buf: - fix docs imagination: - avoid segfault in debugfs ofdrm: - put PCI device reference on errors udl: - increase USB timeout Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260430064521.GA14957@linux.fritz.box
2026-04-30wifi: ath12k: add thermal cooling device supportMaharaja Kennadyrajan
Add thermal cooling device support to control the temperature by throttling data transmission. Throttling is performed by suspending data TX queues according to a configured duty-cycle off percentage. The thermal cooling device allows users to configure the duty-cycle off percentage and operate the device with the selected value. User configuration updates a single duty-cycle off percentage, which is applied uniformly by the host and treated as only one temperature level. This value remains in effect until updated again by the user. All other thermal throttling parameters continue to use their default firmware provided values. Reject invalid duty-cycle off percentage values that fall outside the supported range. Register a cooling device to allow the thermal framework to query and set the current throttle state, report the maximum supported state, and keep the host state in sync with successful firmware updates. A throttle state of zero restores the default firmware thermal configuration. Command to set the duty-cycle off percent: echo 40 > /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device0/cur_state Command to read duty-cycle off percent: cat /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device0/cur_state Command to read the maximum duty-cycle off percent: cat /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device0/max_state Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260413153840.1969931-6-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: reorder group start/stop for safe thermal sysfs cleanupMaharaja Kennadyrajan
A later change adds thermal cooling device sysfs under the wiphy device kobject. With the current teardown order, MAC/wiphy are unregistered before per-device cleanup, so any subsequent thermal sysfs removal would run after the wiphy kobject is gone. That ordering is asymmetric with setup and would risk kernfs issues during removal. This change also adjusts the position of ath12k_mac_mlo_teardown(). Previously it ran before per-device cleanup/MAC unregister. MLO teardown issues WMI to teardown multi-link state and is part of the MAC teardown sequence. Placing it alongside MAC unregister (after per-device cleanup) preserves setup/teardown symmetry and avoids racing with remaining netdev/wiphy state. Reorder hw_group_stop() so per-device cleanup (including thermal/hwmon sysfs removal) runs while the wiphy still exists. After per-device cleanup completes, unregister the MAC (dropping wiphys), run ath12k_mac_mlo_teardown(), and finally destroy the MAC. This mirrors the setup sequence and keeps sysfs cleanup safe when introduced in a later patch. To keep start/stop symmetry, add ath12k_core_device_setup() to encapsulate the per-device bring-up steps (pdev create, IRQ enable, rfkill config) that were previously open-coded in hw_group_start(). Use this helper in hw_group_start() to match the existing per-device cleanup helper used by hw_group_stop(). Note that set_bit(ATH12K_FLAG_REGISTERED, &ab->dev_flags) is now executed outside the ab->core_lock critical section. The core_lock has not provided protection for the REGISTERED flag, readers do not rely on core_lock for this bit, and the flag is only toggled in the serialized group start/stop path using atomic bitops. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260413153840.1969931-5-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: refactor per-radio thermal hwmon setup and cleanupMaharaja Kennadyrajan
Both the error path in thermal registration and the normal thermal unregister path performed the same hwmon device unregistration and pointer cleanup. Consolidate this logic into a single helper to reduce code duplication and ensure consistent cleanup across all paths. Add a helper to set up the hwmon registration during thermal registration to keep symmetry with thermal cleanup. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260413153840.1969931-4-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: configure firmware thermal throttling via WMIMaharaja Kennadyrajan
Ath12k firmware supports thermal-throttling but requires the host to explicitly program throttle levels and mitigation actions via WMI. Without this configuration, firmware-driven thermal mitigation remains inactive or relies on platform-specific defaults. Add host-side support to build and send thermal-throttle configuration using WMI_THERM_THROT_SET_CONF_CMDID during MAC radio start, ensuring thermal parameters are programmed before data traffic begins. Maintain per-radio storage for thermal throttle levels and provide conservative default level tables for Internal Power Amplifier Device (IPA) and External Power Amplifier Device or External Front End Module (XFEM) targets. The appropriate default table is selected based on firmware-advertised service bits, allowing the host to align with target thermal mitigation capabilities. If the WMI TLV service WMI_TLV_SERVICE_IS_TARGET_IPA bit is set, then host selects the thermal throttle values from IPA index from the table and selects values from XFEM index from the table if this WMI TLV service bit is not set. Build and send the thermal throttle configuration request with either 4 or 5 levels depending on firmware capability, and populate optional fields (pout reduction and tx chain mask) only when the corresponding service bits are advertised. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260413153840.1969931-3-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: handle thermal throttle stats WMI eventMaharaja Kennadyrajan
Add handling for WMI_THERM_THROT_STATS_EVENTID by defining the wmi_therm_throt_stats_event TLV and parsing pdev_id, temperature and throttle level. The firmware can emit this event periodically, including when the throttle level is 0. Log the received thermal throttle stats to get the current temperature level, temperature and thermal throttling levels. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260413153840.1969931-2-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: unify error handling in some ath12k_wmi_xxx() functionsNicolas Escande
This is purely cosmetic changes that simplifies & standardizes error handling for functions that ends with a ath12k_wmi_cmd_send() followed by trivial error handling. Saves a few lines of code too. Compile tested only. Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20260422163208.3013496-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath11k: cancel SSR work items during PCI shutdownWei Zhang
A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources. Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence. Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once. Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: 13da397f884d ("ath11k: add support for device recovery for QCA6390/WCN6855") Fixes: 5edbb148bc57 ("wifi: ath11k: Add firmware coredump collection support") Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260404043050.3433754-1-wei.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: use kzalloc_flexRosen Penev
Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation. Add __counted_by to get extra runtime analysis. Move counting variable assignment immediately after allocation before any potential accesses. kzalloc_flex does this anyway for GCC >= 15. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260421213544.6238-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath12k: Handle DP_RX_DECAP_TYPE_8023 type in Rx pathTamizh Chelvam Raja
The driver does not currently set any rx_flag for frames received with decap type DP_RX_DECAP_TYPE_8023. When the hardware reports LLC-encapsulated packets whose length field is below 0x0600, the MSDU_END descriptor may indicate decap type DP_RX_DECAP_TYPE_8023. These frames are effectively equivalent to Ethernet-II (DIX) packets, similar to those decoded as DP_RX_DECAP_TYPE_ETHERNET2_DIX. If the driver does not set RX_FLAG_8023 for these frames, mac80211 will misinterpret them as 802.11 frames. This causes valid frames such as Bridge Protocol Data Units (BPDUs) to be dropped. BPDUs are exchanged between switches to maintain and manage network topology, and must be treated as Ethernet frames. Set RX_FLAG_8023 for decap type DP_RX_DECAP_TYPE_8023 in ath12k_dp_rx_h_undecap() to ensure mac80211 handles these frames correctly. Also add multicast packet handling support for the DP_RX_DECAP_TYPE_8023 decap type. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260418163620.3633959-1-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath: Unify user-visible "Qualcomm" nameKrzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified "Qualcomm" so it will be easier for users to identify the options when for example running menuconfig. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260427070040.17928-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath: Use the unified QMI service ID instead of defining it locallyDaniel Lezcano
Instead of defining a local macro with a custom name for the QMI service identifier, use the one provided in qmi.h and remove the locally defined macro. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://patch.msgid.link/20260316171419.2619620-3-daniel.lezcano@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath9k: fix OOB access from firmware tx status queue IDTristan Madani
ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index. Fixes: fce041beb03f ("ath9k: unify edma and non-edma tx code, improve tx fifo handling") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260415222343.1540564-1-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath9k: use kmemdup and kcallocRosen Penev
Simplifies the code slightly by removing temporary variables. multiplication overflow is also gained for free. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260223224445.27352-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath9k: owl: move name into owl_nvmem_probeRosen Penev
There is no need for dynamic allocation for a simple string. request_firmware_nowait copies the string internally anyway. The error message on failure is also wrong. It's an allocation failure, not a find failure. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260223224254.27081-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath9k: use non devm for nvmem_cell_getRosen Penev
There's absolutely no need to extend the lifetime of cell to post removal of the driver. It's only used in this function. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260223025021.19008-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30wifi: ath9k: Remove redundant rcu_read_lock/unlock() in spin_lockpengdonglin
Since commit a8bb74acd8efe ("rcu: Consolidate RCU-sched update-side function definitions") there is no difference between rcu_read_lock(), rcu_read_lock_bh() and rcu_read_lock_sched() in terms of RCU read section and the relevant grace period. That means that spin_lock(), which implies rcu_read_lock_sched(), also implies rcu_read_lock(). There is no need no explicitly start a RCU read section if one has already been started implicitly by spin_lock(). Simplify the code and remove the inner rcu_read_lock() invocation. Cc: Toke <toke@toke.dk> Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by: pengdonglin <pengdonglin@xiaomi.com> Signed-off-by: pengdonglin <dolinux.peng@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250916044735.2316171-15-dolinux.peng@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-30rust: allow `clippy::collapsible_if` globallyMiguel Ojeda
Similar to `clippy::collapsible_match` (globally allowed in the previous commit), the `clippy::collapsible_if` lint [1] can make code harder to read in certain cases. Thus just let developers decide on their own. In addition, remove the existing `expect` we had. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/DGROP5CHU1QZ.1OKJRAUZXE9WC@garyguo.net/ Link: https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_if [1] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260426144201.227108-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-30rust: allow `clippy::collapsible_match` globallyMiguel Ojeda
The `clippy::collapsible_match` lint [1] can make code harder to read in certain cases [2], e.g. CLIPPY P rust/libmacros.so - due to command line change warning: this `if` can be collapsed into the outer `match` --> rust/pin-init/internal/src/helpers.rs:91:17 | 91 | / if nesting == 1 { 92 | | impl_generics.push(tt.clone()); 93 | | impl_generics.push(tt); 94 | | skip_until_comma = false; 95 | | } | |_________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_match = note: `-W clippy::collapsible-match` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::collapsible_match)]` help: collapse nested if block | 90 ~ TokenTree::Punct(p) if skip_until_comma && p.as_char() == ',' 91 ~ && nesting == 1 => { 92 | impl_generics.push(tt.clone()); 93 | impl_generics.push(tt); 94 | skip_until_comma = false; 95 ~ } | The lint does not have much upside -- when the suggestion may be a good one, it would still read fine when nested anyway. And it is the kind of lint that may easily bias people to just apply the suggestion instead of allowing it. [ In addition, as Gary points out [3], the suggestion is also wrong [4] and in the process of being fixed [5], possibly for Rust 1.97.0: Link: https://lore.kernel.org/rust-for-linux/DI3YV94TH9I3.1SOHW51552497@garyguo.net/ [3] Link: https://github.com/rust-lang/rust-clippy/issues/16875 [4] Link: https://github.com/rust-lang/rust-clippy/pull/16878 [5] - Miguel ] Thus just let developers decide on their own. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_match [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72nWYJna_hdFxjQCQZK6yJBrr1Mb86iKavivV0U0BgufeA@mail.gmail.com/ [2] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260426144201.227108-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-30remoteproc: xlnx: Check remote core stateTanmay Shah
The remote state is set to RPROC_DETACHED if the resource table is found in the memory. However, this can be wrong if the remote is not started, but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call to the firmware to request the state of the RPU node. If the RPU is actually out of reset and running, only then move the remote state to RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support") Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Acked-by: Michal Simek <michal.simek@amd.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-04-30rust: pin-init: fix incorrect accessor reference lifetimeGary Guo
When a field has been initialized, `init!`/`pin_init!` create a reference or pinned reference to the field so it can be accessed later during the initialization of other fields. However, the reference it created is incorrectly `&'static` rather than just the scope of the initializer. This means that you can do init!(Foo { a: 1, _: { let b: &'static u32 = a; } }) which is unsound. This is caused by `&mut (*#slot).#ident`, which actually allows arbitrary lifetime, so this is effectively `'static`. Somewhat ironically, the safety justification of creating the accessor is.. "SAFETY: TODO". Fix it by adding `let_binding` method on `DropGuard` to shorten lifetime. This results in exactly what we want for these accessors. The safety and invariant comments of `DropGuard` have been reworked; instead of reasoning about what caller can do with the guard, express it in a way that the ownership is transferred to the guard and `forget` takes it back, so the unsafe operations within the `DropGuard` can be more easily justified. Fixes: 42415d163e5d ("rust: pin-init: add references to previously initialized fields") Cc: stable@vger.kernel.org Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260427-pin-init-fix-v3-2-496a699674dd@garyguo.net [ Reworded for missing word. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-30rust: pin-init: internal: move alignment check to `make_field_check`Gary Guo
Instead of having the reference creation serving dual-purpose as both for let bindings and alignment check, detangle them so that the alignment check is done explicitly in `make_field_check`. This is more robust against refactors that may change the way let bindings are created. Cc: stable@vger.kernel.org Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260427-pin-init-fix-v3-1-496a699674dd@garyguo.net [ Reworded for typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-30rust: arch: um: Fix building 32-bit UML with GCCDavid Gow
32-bit UML builds can be configured either by setting CONFIG_64BIT=n or with SUBARCH=i386. Both work with Rust-for-Linux when clang is the compiler, but when SUBARCH=i386, we don't set a bindgen target correctly if gcc is the compiler. Add the appropriate bindgen target configuration for i386, as is done in Makefile.clang. [ For reference, the errors look like: BINDGEN rust/bindings/bindings_generated.rs error: unsupported option '-mno-sse' for target '' ... error: unknown target triple 'unknown' panicked at .../bindgen-0.72.1/ir/context.rs:562:15: libclang error; possible causes include: ... - Miguel ] Fixes: ab0f4cedc355 ("arch: um: rust: Add i386 support for Rust") Signed-off-by: David Gow <david@davidgow.net> Link: https://patch.msgid.link/20260425034125.53866-1-david@davidgow.net [ Added space in title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-30net: mctp: test: remove skb dumps from test outputJeremy Kerr
We're currently dumping skb info in our fragment input test, which makes interpreting the TAP test output a bit awkward. Remove the skb dumps. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260429-dev-mctp-test-skb-dump-v1-1-13fd5789ef71@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30Merge branch 'net-mctp-test-minor-kunit-test-fixes'Jakub Kicinski
Jeremy Kerr says: ==================== net: mctp: test: minor kunit test fixes This series provides two fixes in the MCTP kunit tests - one exposed by ktr, and one found while debugging the former on different VM configs. ==================== Link: https://patch.msgid.link/20260429-dev-mctp-test-fixes-v1-0-1127b7425809@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30net: mctp: test: Use dev_direct_xmit for TX to our test deviceJeremy Kerr
In our test cases, we typically feed a packet sequence into the routing code, then inspect the device's TXed skbs to assert specific behaviours. Using dev_queue_xmit() for our TX path introduces a fair bit of complexity between the test packet sequence and the test device's ndo_start_xmit callback; which may mean that the skbs have not hit the device at the point we're inspecting the TXed skb list. Use dev_direct_xmit instead, as we want a direct a path as possible here, and the test dev does not need any queueing, scheduling or flow control. Fixes: 6ab578739a4c ("net: mctp: test: move TX packetqueue from dst to dev") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202604281320.525eee17-lkp@intel.com Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260429-dev-mctp-test-fixes-v1-2-1127b7425809@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30net: mctp: test: use a zeroed struct sockaddr_mctpJeremy Kerr
Invalid sockaddr padding will cause bind() to fail; ensure we have a zeroed address in the testcase. Fixes: 0d8647bc74cb ("net: mctp: don't require a route for null-EID ingress") Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260429-dev-mctp-test-fixes-v1-1-1127b7425809@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.1-rc2). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30riscv: cpufeature: Drop this_hwcap clear in T-Head vector workaroundHui Wang
The variable this_hwcap is initialized to 0 for each loop, it is not necessary to do the bit clearance since this_hwcap is still 0 at this point, clearing the source_isa is enough here. Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://patch.msgid.link/20260430045350.22213-1-hui.wang@canonical.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-04-30Merge branches 'acpi-apei', 'acpi-bus', 'acpi-cppc' and 'acpi-video'Rafael J. Wysocki
Merge assorted ACPI support fixes for 7.1-rc2: - Fix EINJV2 memory error injection in APEI (Tony Luck) - Add missing notifier_block structure forward declaration to acpi_bus.h (Bartosz Golaszewski) - Fix related_cpus inconsistency during CPU hotplug in the ACPI CPPC library (Jinjie Ruan) - Add a quirk to force native backlight on HP OMEN 16 (8A44) in the ACPI video bus driver (Shivam Kalra) * acpi-apei: ACPI: APEI: EINJ: Fix EINJV2 memory error injection ACPICA: Provide #defines for EINJV2 error types * acpi-bus: ACPI: bus: add missing forward declaration to acpi_bus.h * acpi-cppc: ACPI: CPPC: Fix related_cpus inconsistency during CPU hotplug * acpi-video: ACPI: video: force native backlight on HP OMEN 16 (8A44)
2026-04-30PM: tools: pm-graph: fix ValueError when parsing incomplete device propertiesGongwei Li
When parsing device properties from ftrace data, the devprops() function assumes that each line has at least three fields and that the third field (f[2]) always contains a valid integer. However, due to incomplete or corrupted ftrace logs, f[2] may be missing, empty, or non-existent. This can lead to the following error: Traceback (most recent call last): File "../sleepgraph.py", line 7142, in <module> stamp = rerunTest(sysvals.outdir) File "../sleepgraph.py", line 6255, in rerunTest testruns, stamp = processData() File "../sleepgraph.py", line 6181, in processData testruns, error = parseTraceLog(live) File "../sleepgraph.py", line 3470, in parseTraceLog tp, tf = loadTraceLog() File "../sleepgraph.py", line 3398, in loadTraceLog if tp.stampInfo(line, sysvals): File "../sleepgraph.py", line 3073, in stampInfo self.parsePlatformInfo(line, sv) File "../sleepgraph.py", line 3177, in parsePlatformInfo sv.devprops = self.devprops(sv.b64unzip(info)) File "../sleepgraph.py", line 3158, in devprops if int(f[2]): ValueError: invalid literal for int() with base 10: '' To prevent this crash, add proper validation before accessing. Signed-off-by: Gongwei Li <ligongwei@kylinos.cn> Acked-by: Todd Brandt <todd.e.brandt@intel.com> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260424071208.3610628-1-13875017792@163.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-30hwmon: (corsair-psu) Close HID device on probe errorsMyeonghun Pak
corsairpsu_probe() opens the HID device before sending the device init and firmware-info commands. If either command fails, the error path jumps directly to fail_and_stop and skips hid_hw_close(). Use the existing fail_and_close label for those post-open failures so the open count and low-level close callback are balanced before hid_hw_stop(). Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver") Cc: stable@vger.kernel.org Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Wilken Gottwalt <wilken.gottwalt@posteo.net> Link: https://lore.kernel.org/r/20260424135107.13720-1-mhun512@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-30hwmon: Remove stale CONFIG_SENSORS_SBRMI Makefile referenceSasha Levin
kconfiglint reports: X001: CONFIG_SENSORS_SBRMI referenced in Makefile but not defined in any Kconfig The SB-RMI hardware monitoring driver was originally introduced in commit 5a0f50d110b3 ("hwmon: Add support for SB-RMI power module") with both a Kconfig entry (CONFIG_SENSORS_SBRMI) and a Makefile line (obj-$(CONFIG_SENSORS_SBRMI) += sbrmi.o) in drivers/hwmon/. Commit e156586764050 ("hwmon/misc: amd-sbi: Move core sbrmi from hwmon to misc") moved the driver to drivers/misc/amd-sbi/ to support additional functionality beyond hardware monitoring. That commit correctly removed the Kconfig entry from drivers/hwmon/Kconfig, moved the source file drivers/hwmon/sbrmi.c to drivers/misc/amd-sbi/sbrmi.c, and created new Kconfig/Makefile entries in drivers/misc/amd-sbi/ with a renamed symbol (CONFIG_AMD_SBRMI_I2C). However, the Makefile line in drivers/hwmon/Makefile was not removed in that commit. The orphaned line references a CONFIG symbol that no longer exists and a source file that is no longer present, so it has no effect on the build — but it is dead code that should be cleaned up. Remove the stale Makefile reference. Assisted-by: Claude:claude-opus-4-6 kconfiglint Signed-off-by: Sasha Levin <sashal@kernel.org> Link: https://lore.kernel.org/r/20260426000319.55908-1-sashal@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-30Documentation: hwmon: fix link to ideapad-laptop.c fileNinad Naik
The ideapad-laptop.c file now exists inside drivers/platform/x86/lenovo/ directory. Updating the GitHub link to the correct path. Signed-off-by: Ninad Naik <ninadnaik07@gmail.com> Link: https://lore.kernel.org/r/20260417191411.713958-1-ninadnaik07@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-30hwmon: (ltc2992) Fix u32 overflow in power read pathSanman Pradhan
ltc2992_get_power() computes the divisor for mul_u64_u32_div() as r_sense_uohm * 1000. This multiplication overflows u32 when r_sense_uohm exceeds about 4.29 ohms (4294967 micro-ohms), producing a truncated divisor and an incorrect power reading. Cancel the factor of 1000 from both the numerator (VADC_UV_LSB * IADC_NANOV_LSB = 312500000) and the divisor (r_sense_uohm * 1000), giving (VADC_UV_LSB / 1000) * IADC_NANOV_LSB = 312500 as the numerator and plain r_sense_uohm as the divisor. The cancellation is exact because LTC2992_VADC_UV_LSB (25000) is divisible by 1000. This is the read-path counterpart of the write-path fix applied in the preceding patch. Fixes: b0bd407e94b03 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260416215904.101969-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-30hwmon: (ltc2992) Clamp threshold writes to hardware rangeSanman Pradhan
ltc2992_set_voltage(), ltc2992_set_current(), and ltc2992_set_power() do not validate the user-supplied value before converting it to a register value. This can result in: 1. Negative input values wrapping to large positive register values. For power, the negative long is implicitly cast to u64 in mul_u64_u32_div(), producing an incorrect value. For voltage and current, the negative converted value wraps when passed to ltc2992_write_reg() as a u32. 2. Intermediate arithmetic exceeding the range representable in u64 on 64-bit platforms. In ltc2992_set_voltage(), (u64)val * 1000 can exceed U64_MAX when val is a large positive long. In ltc2992_set_current(), (u64)val * r_sense_uohm can overflow similarly. In ltc2992_set_power(), the computed value may not fit in u64. 3. Register values exceeding the hardware field width. Voltage and current threshold registers are 12-bit (stored left-justified in 16 bits), and power threshold registers are 24-bit. Without clamping, bits above the field width are truncated in ltc2992_write_reg(). Fix by clamping negative values to zero, clamping positive values to the rounded hardware-representable maximum (the value returned by the read path for a full-scale register) to prevent intermediate overflow, and clamping the converted register value to the hardware field width before writing. The existing conversion formula and rounding behavior are preserved. In the power write path, cancel the factor of 1000 from both the numerator (r_sense_uohm * 1000) and the denominator (VADC_UV_LSB * IADC_NANOV_LSB) to also eliminate a u32 overflow of r_sense_uohm * 1000 when r_sense_uohm exceeds about 4.29 ohms. Fixes: b0bd407e94b03 ("hwmon: (ltc2992) Add support") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260416215904.101969-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-30s390/pai: Disable duplicate read of kernel PAI counter valueThomas Richter
The PAI crypto counter design allows for user space and kernel space PAI counter increment recording. This is achieved by splitting the recording page in half. The upper part of the 4KB page records user space increments of PAI crypto counter and the lower half records kernel space increments. The page itself looks like: lowcore ptr ---> ++++++++++++++++++++++++ |user space area | +----------------------+ |kernel space area | ++++++++++++++++++++++++ User space and kernel space entries are handled via a kernel_offset value when wrting. For PAI crypto counters this offset is 2048 or half of a page size. For PAI NNPA counter design this distinction was not needed. There is no user and kernel space part for the page pointed to by lowcore. The set up is: lowcore ptr ---> ++++++++++++++++++++++++ |user + kernel space | |area | | | ++++++++++++++++++++++++ There is always only one counter value recorded and saved. Depending on number of CPUs and machine load, the number of PAI NNPA counter increment differs between counting (perf stat) and recording (perf record). The number reported by sampling was double the number shown by counting. This was caused by a double read of the PAI NNPA values in function pai_copy(). The first part of that function reads the kernel space part. The offset into the kernel page part must be larger than zero. The second part of that function reads the user space part, which begins of offset zero. This works fine for PAI crypto counters. It fails for PAI NNPA counters because the PMU device driver does not support that feature and has a kernel_offset value of 0x0. Executing both user and kernel space read out might end up reading user space value twice. For the PAI NNPA PMU prohibit the kernel space part read out. Cc: stable@vger.kernel.org Fixes: f12473541356 ("s390/pai_crypto: Rename paicrypt_copy() to pai_copy()") Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-04-30PCI: endpoint: pci-ep-msi: Refactor doorbell allocation for new backendsKoichiro Den
Prepare pci-ep-msi for non-MSI doorbell backends. Factor MSI doorbell allocation into a helper and extend struct pci_epf_doorbell_msg with: - irq_flags: required IRQ request flags (e.g. IRQF_SHARED for some backends) - type: doorbell backend type - bar/offset: pre-exposed doorbell target location, if any Initialize these fields for the existing MSI-backed doorbell implementation. Also add PCI_EPF_DOORBELL_EMBEDDED type, which is to be implemented in a follow-up patch. No functional changes. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260414141514.1341429-5-den@valinux.co.jp
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 03:10:32 +0000