summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-18dt-bindings: arm: qcom,ids: Add SoC ID for Nord SA8797PDeepti Jaggi
Nord is a SoC family from Qualcomm designed as the next generation of Lemans series. SA8797P is the automotive variant of Nord, where platform resources such as clocks, regulators, interconnects, etc. are managed by firmware through SCMI. Add SoC ID for Nord SA8797P. Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427003531.229671-2-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-18soc: qcom: socinfo: Add SoC ID for SM7750Alexander Koskovich
Recognize the SM7750 SoC which is an Eliza SoC variant. Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260412-sm7550-id-v1-2-958a673ff791@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-18dt-bindings: arm: qcom,ids: Add SoC ID for SM7750Alexander Koskovich
Document the ID for SM7750, an Eliza SoC variant that can be found on the Nothing Phone (4a) Pro. Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260412-sm7550-id-v1-1-958a673ff791@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-18soc: qcom: socinfo: Add PMIC PMAU0102Shawn Guo
Add PMAU0102 found on Nord boards to pmic_models array. Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260419131523.1232835-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-18soc: qcom: socinfo: Add PMIV0102 & PMIV0104 PMICsAlexander Koskovich
Add the PMIV0102 and PMIV0104 to the pmic_models array. Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20260413-add-pmic-ids-v1-1-1f40b8773ef8@pm.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-19wifi: rtw89: phy: set BB wrap of QAM optionsPing-Ke Shih
Apply these options to selected QAM to TX signal under requirements. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260511070148.25257-7-pkshih@realtek.com
2026-05-19wifi: rtw89: phy: set BB wrap of QAM thresholdPing-Ke Shih
Make hardware to consider which QAM (data rate) to apply BB wrapper parameters, which are set by other registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260511070148.25257-6-pkshih@realtek.com
2026-05-19wifi: rtw89: phy: set BB wrap of control optionsPing-Ke Shih
Set main options to control BB wrap functions. For example, enable options by data bandwidth or channel bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260511070148.25257-5-pkshih@realtek.com
2026-05-19wifi: rtw89: phy: set BB wrap of DPD by bandwidthPing-Ke Shih
Apply different settings to out-of-band DPD (digital pre-distortion) by bandwidth, as hardware defines separate registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260511070148.25257-4-pkshih@realtek.com
2026-05-19wifi: rtw89: phy: set BB wrap of out-of-band DPDPing-Ke Shih
Control the out-of-band DPD (digital pre-distortion) to ensure out-of-band signal under requirement. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260511070148.25257-3-pkshih@realtek.com
2026-05-19wifi: rtw89: phy: define BB wrap data for RTL8922D variantsPing-Ke Shih
The BB wrap is a hardware block to control TX power. Since RTL8922D has many variants with different CID and RFE types, prepare flow and dummy struct adopt to configuration functions for coming patches. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260511070148.25257-2-pkshih@realtek.com
2026-05-18selftests/bpf: Fix test for refinement of single-value tnumPaul Chaignon
This patch fixes the "bounds refinement with single-value tnum on umin" verifier selftest. This selftest was introduced in commit e6ad477d1bf8 ("selftests/bpf: Test refinement of single-value tnum") to cover the logic from __update_reg64_bounds(), introduced in commit efc11a667878 ("bpf: Improve bounds when tnum has a single possible value"). However, the test still passes if that last commit is reverted. The test is supposed to cover the case when the tnum and u64 range (or cnum64 now) overlap in a single value. __update_reg64_bounds() detects that case and refines the bounds to a known constant. However, the constants for the test were poorly chosen and the bounds get refined to a known constant even without __update_reg64_bounds(). The code is as follows: 0: call bpf_get_prandom_u32#7 ; R0=scalar() 1: r0 |= 224 ; R0=scalar(umin=umin32=224,var_off=(0xe0; 0xffffffffffffff1f)) 2: r0 &= 240 ; R0=scalar(smin=umin=smin32=umin32=224,smax=umax=smax32=umax32=240,var_off=(0xe0; 0x10)) 3: if r0 == 0xf0 goto pc+2 ; R0=224 After instruction 3, we have u64=[0xe0; 0xef] and tnum=(0xe0; 0x10). __reg_bound_offset() is able to deduce a new tnum from the u64, tnum=(0xe0; 0x0f), which combined with the existing tnum gives us a constant: 0xe0 or 224. We can easily fix this by choosing different starting bounds. If we make it u64=[0xe1; 0xf0], then __reg_bound_offset() doesn't have any impact. Fixes: e6ad477d1bf8 ("selftests/bpf: Test refinement of single-value tnum") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/be2dc2c3d85120286e60b3029b3338fff339f942.1779121582.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18selftests/bpf: Reject unsupported -k option in vmtest.shRoman Kvasnytskyi
vmtest.sh does not document a -k option and does not handle it in the getopts case statement. However, the getopts optstring includes k, which causes the script to accept -k silently instead of reporting it as an invalid option. Remove k from the optstring so unsupported options are rejected through the existing invalid-option path. Fixes: c9709f52386d ("bpf: Helper script for running BPF presubmit tests") Signed-off-by: Roman Kvasnytskyi <roman@kvasnytskyi.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/20260516120625.80839-1-roman@kvasnytskyi.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18selftests/bpf: Override EXTRA_LDFLAGS for static buildsPaul Chaignon
When running vmtest.sh with static linking, the bpftool_map_access selftests fail. These selftests are calling the bpftool binary in tools/sbin/ directly, which results in the following error: error while loading shared libraries: libLLVM.so.21.1: cannot open shared object file: No such file or directory To fix this, we need to also build bpftool statically. That can be done by setting EXTRA_LDFLAGS=-static. Fixes: 2d96bbdfd3b5 ("selftests/bpf: convert test_bpftool_map_access.sh into test_progs framework") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/r/714556da329c812988010ffe53173d9152570a78.1778669303.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18Merge branch 'intel-wired-lan-driver-updates-2026-05-15-ice-ixgbevf-igc-e1000e'Jakub Kicinski
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-05-15 (ice, ixgbevf, igc, e1000e) For ice: Jake fixes a mismatch in locking around wait queue usage. Jose Ignacio Tornos Martinez adjusts allowed lower bound for VF data buffer size to accommodate low MTU sizes. Marcin adjusts for -EEXIST to not trigger error path when the promisc filter already exists as part of adding VLAN Ids. Grzegorz fixes a few issues related to PTP. He adds locking to ice_start_phy_timer_eth56g() to protect proper register programming. Fixes the PTP lock used in 2xNAC configuration to always be the primary and restores PTP configuration on ethtool channel changes. For ixgbevf: Michael Bommarito sets freed skb pointer to NULL to prevent use-after-free. For igc: Kohei Enju resolves a couple of issues reported by Sashiko; setting buffer type for an SMD skb and freeing skb on error of igc_fpe_init_tx_descriptor(). ==================== Link: https://patch.msgid.link/20260515182419.1597859-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18igc: fix potential skb leak in igc_fpe_xmit_smd_frame()Kohei Enju
When igc_fpe_init_tx_descriptor() fails, no one takes care of an allocated skb, leaking it. [1] Use dev_kfree_skb_any() on failure. Tested on an I226 adapter with the following command, while injecting faults in igc_fpe_init_tx_descriptor() to trigger the error path. # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on [1] unreferenced object 0xffff888113c6cdc0 (size 224): ... backtrace (crc be3d3fda): kmem_cache_alloc_node_noprof+0x3b1/0x410 __alloc_skb+0xde/0x830 igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0 igc_fpe_send_mpacket+0x37/0x90 ethtool_mmsv_verify_timer+0x15e/0x300 Cc: stable@vger.kernel.org Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Tested-by: Avigail Dahan <avigailx.dahan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-10-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18igc: set tx buffer type for SMD framesKohei Enju
Sashiko pointed out that igc_fpe_init_smd_frame() initializes igc_tx_buffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp Since igc_tx_buffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path. Set the buffer type to IGC_TX_BUFFER_TYPE_SKB. Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Avigail Dahan <avigailx.dahan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-9-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ixgbevf: fix use-after-free in VEPA multicast source pruningMichael Bommarito
ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor: dev_kfree_skb_irq(skb); continue; The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context. The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here. I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags): BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90) QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible. Fixes: bad17234ba70 ("ixgbevf: Change receive model to use double buffered page based receives") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-8-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ice: restore PTP Rx timestamp config after ethtool set-channelsGrzegorz Nitka
When ethtool -L changes queue counts, ice_vsi_recfg_qs() closes and rebuilds the VSI, reallocating Rx rings. The newly allocated rings have ptp_rx cleared, so RX hardware timestamps are no longer attached to skb until hwtstamp configuration is applied again. Restore timestamp mode after ice_vsi_open() in the queue reconfiguration path, matching reset/rebuild behavior and ensuring newly rebuilt Rx rings have PTP RX timestamping re-enabled. Testing hints: - run ptp4l application in client synchronization mode: ptp4l -i ethX -m -s - run PTP traffic - change queue number on ethX netdev interface: ethtool -L ethX combined new_queue_size - observe ptp4l output - expected result: no "received DELAY_REQ without timestamp" messages Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-7-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ice: ptp: use primary NAC semaphore on E825Grzegorz Nitka
For E825 2xNAC configurations, PTP semaphore operations must hit the primary NAC register block so both sides coordinate on the same lock. Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") updated other primary-only PTP register accesses to use the primary NAC on non-primary functions, but left ice_ptp_lock() and ice_ptp_unlock() operating on the local NAC. As a result, secondary NAC PTP paths can take a different semaphore than the primary side. Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock() when the current function is not primary, keeping semaphore operations symmetric and consistent with the rest of the 2xNAC PTP register access path. Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices") Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-6-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ice: ptp: serialize E825 PHY timer start with PTP lockGrzegorz Nitka
ice_start_phy_timer_eth56g() programs TIMETUS registers and issues INIT_INCVAL without holding the global PTP semaphore. This allows concurrent PTP command paths to interleave with PHY timer start, which can make the sequence fail and leave timer initialization inconsistent. Take the PTP lock around TIMETUS registers programming and INIT_INCVAL command execution, and make sure the lock is released on all error paths. Keep the subsequent sync step outside of this critical section, since ice_sync_phy_timer_eth56g() takes the same semaphore internally. Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-5-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ice: fix setting promisc mode while adding VID filterMarcin Szycik
There are at least two paths through which VSI promiscuous mode can be independently configured via ice_fltr_set_vsi_promisc(): - ice_vlan_rx_add_vid() (netdev op) - ice_service_task() -> ... -> ice_set_promisc() Both paths may try to program promiscuous mode concurrently. One such scenario is: 1. Add ice netdev to bond 2. Add the bond netdev to bridge 3. ice netdev enters allmulticast mode (IFF_ALLMULTI) 4. Service task programs promisc mode filter 5. Bridge -> bond calls ice_vlan_rx_add_vid() Crucially, ice_vlan_rx_add_vid() fails if ice_fltr_set_vsi_promisc() returns any error, including -EEXIST. This causes VLAN filtering setup to fail on the bond interface. ice_set_promisc() already handles -EEXIST correctly. Fix by adding the same -EEXIST check to ice_vlan_rx_add_vid(): if the promisc filter is already programmed, continue without returning error. Fixes: 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling") Cc: stable@vger.kernel.org Signed-off-by: Marcin Szycik <marcin.szycik@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ice: fix VF queue configuration with low MTU valuesJose Ignacio Tornos Martinez
The ice driver's VF queue configuration validation rejects databuffer_size values below 1024 bytes, which prevents VFs from using MTU values below 871 bytes. The iavf driver calculates databuffer_size based on the MTU using: databuffer_size = ALIGN(MTU + LIBETH_RX_LL_LEN, 128) where LIBETH_RX_LL_LEN = 26 (ETH_HLEN + 2*VLAN_HLEN + ETH_FCS_LEN). For MTU values below 871: MTU 870: 870 + 26 = 896, aligned to 128 = 896 (< 1024, rejected) MTU 871: 871 + 26 = 897, aligned to 128 = 1024 (>= 1024, accepted) The 1024-byte minimum seems unnecessarily restrictive, because the hardware supports databuffer_size as low as 128 bytes (the alignment boundary), which should allow MTU values down to the standard minimum of 68 bytes. I haven't found the reason why the limit was configured in the commit 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message"), so with no more information and since it is working, change the minimum databuffer_size validation from 1024 to 128 bytes to allow standard low MTU values while still preventing invalid configurations. Fixes: 9c7dd7566d18 ("ice: add validation in OP_CONFIG_VSI_QUEUES VF message") cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18ice: fix locking around wait_event_interruptible_locked_irqJacob Keller
Commit 50327223a8bb ("ice: add lock to protect low latency interface") introduced a wait queue used to protect the low latency timer interface. The queue is used with the wait_event_interruptible_locked_irq macro, which unlocks the wait queue lock while sleeping. The irq variant uses spin_lock_irq and spin_unlock_irq to manage this. The wait queue lock was previously locked using spin_lock_irqsave. This difference in lock variants could lead to issues, since wait_event would unlock the wait queue and restore interrupts while sleeping. The ice_read_phy_tstamp_ll_e810() function is ultimately called through ice_read_phy_tstamp, which is called from ice_ptp_process_tx_tstamp or ice_ptp_clear_unexpected_tx_ready. The former is called through the miscellaneous IRQ thread function, while the latter is called from the service task work queue thread. Neither of these functions has interrupts disabled, so use spin_lock_irq instead of spin_lock_irqsave. Fixes: 50327223a8bb ("ice: add lock to protect low latency interface") Cc: stable@vger.kernel.org Reported-by: Jakub Kicinski <kuba@kernel.org> Closes: https://lore.kernel.org/netdev/20250109181823.77f44c69@kernel.org/ Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260515182419.1597859-2-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-19ARM: dts: aspeed: anacapa: Correct SGPIO names for monitoringRex Fu
Update several Anacapa SGPIO line names to match the existing platform hardware design and the signal names consumed by userspace monitoring. The previous names did not match the actual Anacapa SGPIO usage. Some lines were named as CPU or CPU power-good signals, but they are wired and used on Anacapa for EDSFF presence, EDSFF power-good, boot EDSFF presence, and thermal-trip assertion monitoring. Correct the mappings as follows: PWRGD_PVDDCR_SOC_P0 -> L_PRSNT_EDSFF0_N PWRGD_PVDDIO_P0 -> L_PRSNT_EDSFF1_N PWRGD_PVDDIO_MEM_S3_P0 -> R_PRSNT_EDSFF2_N PWRGD_CHMP_CPU0_FPGA -> R_PRSNT_EDSFF3_N PWRGD_CHIL_CPU0_FPGA -> HPM_EDSFF_PG EAM2_CPU_MOD_PWR_GD_R -> PRSNT_EDSFF_BOOT_N CPU0_SP7R1 -> L_EDSFF0_PG CPU0_SP7R2 -> L_EDSFF1_PG CPU0_SP7R3 -> R_EDSFF2_PG CPU0_SP7R4 -> R_EDSFF3_PG HPM_AMC_THERMTRIP_R_L -> AMC_THERMTRIP_ASSERT FM_CPU0_THERMTRIP_N -> CPU_THERMTRIP_ASSERT The left-side EDSFF slots are numbered as EDSFF0 and EDSFF1 to match the platform slot numbering used by userspace. The thermtrip names are also updated to describe the asserted condition monitored by userspace instead of the raw active-low signal names. This is a naming correction for the existing Anacapa hardware design. There is no new board revision or underlying hardware change involved. [arj: Tweak capitalisation in commit subject, rewrap paragraph] Signed-off-by: Rex Fu <Rex.Fu@amd.com> Link: https://patch.msgid.link/20260518-anacapa-sgpio-edsff-thermtrip-v2-1-e43b1847b2dc@amd.com Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2026-05-18Merge branch 'bpf-follow-up-fixes-for-bpf-syscall-common-attributes'Alexei Starovoitov
Leon Hwang says: ==================== bpf: Follow-up fixes for BPF syscall common attributes Address sashiko reviews for BPF syscall common attributes series. 1. The tailing padding bytes in struct bpf_common_attr should be checked. [1] 2. There was a concurrent regression in syscall.c::map_create(). [2] 3. OPTS_VALID() was missing to validate the nested struct bpf_log_opts in libbpf. [3] 4. The token_fd should be -1 to avoid a valid token fd in test. [4] A test is added to verify the fix #1. The fix #2 is hard to be verified by test. So, I decide not to add a test for it to avoid over-engineering. Decide not to add a test for fix #3 to avoid over-engineering, as the fix looks really simple. Links: [1] https://lore.kernel.org/bpf/20260513224823.6494FC19425@smtp.kernel.org/ [2] https://lore.kernel.org/bpf/20260512233658.CEED7C2BCB0@smtp.kernel.org/ [3] https://lore.kernel.org/bpf/20260512235629.C5CABC2BCB0@smtp.kernel.org/ [4] https://lore.kernel.org/bpf/20260513003358.55836C2BCB0@smtp.kernel.org/ ==================== Link: https://patch.msgid.link/20260518145446.6794-1-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18selftests/bpf: Add test to verify checking padding bytes for BPF syscall ↵Leon Hwang
common attributes Add a test to verify that the tailing padding 4 bytes are checked in syscall.c::__sys_bpf() using bpf_check_uarg_tail_zero(). Without the fix, the test fails with: test_common_attr_padding:FAIL:syscall unexpected syscall: actual 4 >= expected 0 #213/12 map_create_failure/common_attr_padding:FAIL Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260518145446.6794-6-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18selftests/bpf: Use -1 as token_fd in map create failure testLeon Hwang
Because 0xFF can be an open BPF token fd in the test runner that will fail test_invalid_token_fd(), change token_fd from 0xFF to -1 to avoid such test failure. Fixes: f675483cac1d ("selftests/bpf: Add tests to verify map create failure log") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260518145446.6794-5-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18libbpf: Add OPTS_VALID() for log_opts in bpf_map_createLeon Hwang
There should be an OPTS_VALID() check for log_opts before extracting its fields. If no such OPTS_VALID() check and an application compiled against a future libbpf header passes a log_opts with new, non-zero fields to libbpf.so, those fields will be ignored silently. Fixes: 702259006f93 ("libbpf: Add syscall common attributes support for map_create") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260518145446.6794-4-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18bpf: Check tail zero of bpf_common_attr using offsetofendLeon Hwang
Because of the 8-byte alignment, the compiler will pad struct bpf_common_attr to 24 bytes. That said, sizeof(attr_common) is 24 instead of 20. When check tail zero using sizeof(attr_common) in bpf_check_uarg_tail_zero(), there will be 4 bytes that won't be checked. To also check the padding 4 bytes, replace sizeof(attr_common) with offsetofend(struct bpf_common_attr, log_true_size). Fixes: f28771c0691b ("bpf: Extend BPF syscall with common attributes support") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260518145446.6794-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-18Merge branch 'net-devmem-support-devmem-with-netkit-devices'Jakub Kicinski
Bobby Eshleman says: ==================== net: devmem: support devmem with netkit devices This series enables TCP devmem TX through netkit devices. Netkit now supports queue leasing. A physical NIC's RX queue can be leased to a netkit guest interface inside a container namespace. This gives the container a devmem-capable data path on the RX side (bind-rx, etc...). On the TX side, the container process binds to its netkit guest interface and sends traffic that netkit redirects (via BPF or ip forwarding) to the physical NIC for DMA. Two things in the existing devmem TX path prevent this from working: 1. validate_xmit_unreadable_skb() requires dev->netmem_tx before it will forward a dmabuf-backed (unreadable) skb. This protects skbs from landing on devices that don't have the IOMMU mappings for the backing dmabuf or that don't speak netmem. Netkit, however, does not support DMA, doesn't attempt to read unreadable skb pages and so doesn't break netmem (it is pure skb routing and redirection). It is functionally capable of routing unreadable skbs, but there is no way for the TX validation pathway to distinguish between a device that will actually attempt DMA-ing the skb and another device (like netkit) that does not DMA but also does not break netmem. 2. bind_tx_doit uses the bound device as the DMA device. When the user binds devmem TX to the netkit guest, the bind handler attempts to create DMA mappings against netkit, which has no DMA capability and no IOMMU mappings. This series solves these problems as follows: 1. Extend netmem_tx to two bits, assigned to one of three values: NETMEM_TX_NONE - netmem not supported NETMEM_TX_DMA - netmem supported and performs DMA NETMEM_TX_NO_DMA - netmem supported, but does not DMA With these bits, phys devices can set NETMEM_TX_DMA and devices like netkit set NETMEM_TX_NO_DMA. The validation TX path ensures that any DMA-capable netdev exactly matches the bound device, guaranteeing the correct mapping of the bound dmabuf. The validation TX path also allows devices with NETMEM_TX_NO_DMA to pass, knowing these devices will not misuse netmem or run into IOMMU faults. After redirection or routing and the skb finally makes its way through the stack to a physical device's TX path, the above NETMEM_TX_DMA check is performed again to guarantee the device has the appropriate binding/mappings. 2. On TX bind, the bind handler recognizes NETMEM_TX_NO_DMA devices and finds the phys TX device and binds to that instead. For the netkit case, if it has been leased a queue from a DMA-capable device already, then the bind action is performed on the DMA-capable device instead and the dmabuf is mapped correctly. ==================== Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-0-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18selftests: drv-net: add netkit devmem testsBobby Eshleman
Add nk_devmem.py with four tests for TCP devmem through a netkit device. These tests are just duplicates of the original devmem tests, with some adjusted parameters such as telling ncdevmem to avoid device setup (since it only has access to netkit, not a phys device). Each test uses NetDrvContEnv with primary_rx_redirect=True to set up the BPF redirect program on the primary netkit interface, then calls a shared run_*() helper which probes for devmem support and configures the NIC (HDS, RSS, queue lease) before driving the test. NIC state is restored per-test via defer() callbacks registered inside the helper. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-8-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18selftests: drv-net: add primary_rx_redirect support to NetDrvContEnvBobby Eshleman
When sending from a namespace that has access to a netkit device with a leased queue, the nk primary in the host namespace needs to redirect its RX to the physical device. This patch adds that redirection bpf program and teaches the harness to install it. Add primary_rx_redirect=False parameter to NetDrvContEnv.__init__(). When enabled, _attach_primary_rx_redirect_bpf() attaches a new BPF TC program (nk_primary_rx_redirect.bpf.c) to the primary (host-side) netkit interface. The program redirects non-ICMPv6 IPv6 packets to the physical NIC via bpf_redirect_neigh(), with the physical ifindex configured via the .bss map. ICMPv6 is left on the host's netkit primary so IPv6 neighbor discovery still work locally. Extract _find_bss_map_id() from _attach_bpf() into a reusable helper so other BPF attachment methods can use it. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-7-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18selftests: drv-net: refactor devmem command builders into lib moduleBobby Eshleman
Adding netkit-based devmem tests is a straight-forward copy of devmem test commands plus some args for the nk cases, so this patch breaks out these command builders into helpers used by both. Though we tried to avoid libraries to avoid increasing the barrier of entry/complexity (see selftests/drivers/net/README.md, section "Avoid libraries and frameworks"), factoring out these functions seemed like the lesser of two evils in this case of using the same commands, just with slightly different args per environment. I experimented with just having all of the tests in the same file to avoid having helpers in a library file, but because ksft_run() is limited to a single call per file, and the new tests will require different environments (NetDrvContEnv/NetDrvEpEnv), it would have been necessary to have each test set up its own environment instead of sharing one for the entire ksft_run() run. This came at the cost of ballooning the test time (from under 5s to 30s on my test system), so to strike a balance these tests were placed in separate files so they could keep a shared environment across a single ksft_run() run shared across all tests using the same env type (introduced in subsequent patches). The helpers work transparently with both plain and netkit environments by inspecting cfg for netkit-specific attributes (netns, nk_queue, etc...). Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-6-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18selftests: drv-net: make attr _nk_guest_ifname publicBobby Eshleman
Subsequent patches will use the _nk_guest_ifname as a public attr for setting up devmem. Rename to nk_guest_ifname to avoid angering the linter about the '_' prefix being used for a non-private attr. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-5-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18selftests: drv-net: ncdevmem: add -n flag to skip NIC configurationBobby Eshleman
Add a -n (skip_config) flag that causes ncdevmem to skip NIC configuration when operating as an RX server. When -n is passed, ncdevmem skips configuring header split, RSS, and flow steering, as well as their teardown on exit. This allows ksft tests to pre-configure the NIC in the host namespace before launching ncdevmem in the guest namespace. This is needed for netkit devmem tests where the test harness namespace has direct access to the NIC and the ncdevmem namespace does not. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-4-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net: devmem: support TX over NETMEM_TX_NO_DMA devicesBobby Eshleman
When a netkit virtual device leases queues from a physical NIC, devmem TX bindings created on the netkit device must still result in the dmabuf being mapped for dma by the physical device. This patch accomplishes this by teaching the bind handler to search for the underlying DMA-capable device by looking it up via leased rx queues. The function netdev_find_netmem_tx_dev(), used for finding the underlying DMA-capable device, can be extended to support other non-netkit NETMEM_TX_NO_DMA devices in the future if needed. Additionally, this patch extends validate_xmit_unreadable_skb() to support the netkit case, where the skb is validated twice: once on the netkit guest device and again on the physical NIC after BPF redirect or ip forwarding. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-3-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net: netkit: declare NETMEM_TX_NO_DMA modeBobby Eshleman
Some virtual devices like netkit (or ifb) never DMA and never touch frag contents, they just forward the skb to another device. They are unable to forward unreadable skbs, however, because they fail to pass TX validation checks on dev->netmem_tx. The existing two-state NETMEM_TX_NONE / NETMEM_TX_DMA doesn't give the TX validator enough information to differentiate devices that will attempt DMA on the unreadable skb from those that will simply route it untouched. Add a third mode to the enum so drivers can indicate 1) if they have netmem TX support, and 2) if they do, whether they are DMA-capable: NETMEM_TX_NO_DMA - pass-through, device never DMAs Widen dev->netmem_tx from a 1-bit field to 2 bits to fit the new value, and declare netkit as NETMEM_TX_NO_DMA. Devmem TX support over these devices comes in a follow-up patch. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-2-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net: convert netmem_tx flag to enumBobby Eshleman
Devices that support netmem TX previously set dev->netmem_tx = true. This was checked in validate_xmit_unreadable_skb() to drop unreadable skbs (skbs with dmabuf-backed frags) before they reach drivers that would mishandle them or devices that would not have the iommu mappings for them. A subsequent patch will introduce a third state for virtual devices that forward unreadable skbs without ever performing DMA on them. To prepare for that, convert the boolean dev->netmem_tx into an enum: NETMEM_TX_NONE - no netmem TX support (drop unreadable skbs) NETMEM_TX_DMA - full support, device does DMA Update the existing NIC drivers (bnxt, gve, mlx5, fbnic) and the validators in net/core to use the new enum. No functional change. Acked-by: Harshitha Ramamurthy <hramamurthy@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-1-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18Merge branch 'net-mlx5e-simplify-and-optimize-napi-poll-flow'Jakub Kicinski
Tariq Toukan says: ==================== net/mlx5e: simplify and optimize napi poll flow This series simplifies the mlx5e napi poll flow and reduces branching in hot paths by leveraging existing dependencies between channel features. Patch 1 avoids passing the full channel object to kTLS RX code paths when only the async ICOSQ is needed, and slightly optimizes the common flow in the pending resync handling logic. Patch 2 further reduces branches in napi poll by relying on established feature dependencies between XDP, async ICOSQ, XSK, and kTLS RX state. ==================== Link: https://patch.msgid.link/20260514111038.338251-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net/mlx5e: Let kTLS RX get async ICOSQ param in napi pollTariq Toukan
Do not pass channel just to extract the async ICOSQ. It's already extracted, pass it. Re-order the checks in mlx5e_ktls_rx_pending_resync_list to optimize the common flow. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Link: https://patch.msgid.link/20260514111038.338251-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18net/mlx5e: Reduce branches in napi pollTariq Toukan
Reduce the number of branches in napi poll, based on the following list of dependencies: 1. xsk_open=t only if c->xdp and c->async_icosq. 2. c->xdpsq only if c->xdp. 3. c->xdp implies c->async_icosq. 4. ktls_rx_was_enabled implies c->async_icosq. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Link: https://patch.msgid.link/20260514111038.338251-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18Merge tag 'perf-tools-fixes-for-v7.1-2026-05-18' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf-tools fixes "An usual sync-up for the header files and related code: - copy headers that are used for perf trace syscall beautifier - update the beautifier scripts according to the changes - don't show differences in the headers by default" * tag 'perf-tools-fixes-for-v7.1-2026-05-18' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf trace: Update beautifier script for clone flags perf trace: Add beautifier script for fsmount flags perf build: Add make check-headers target perf trace: Sync uapi/linux/sched.h with the kernel source perf trace: Sync uapi/linux/mount.h with the kernel source perf trace: Sync uapi/linux/fs.h with the kernel source perf trace: Sync linux/socket.h with the kernel source
2026-05-18cifs: Fix undefined variablesDavid Howells
Fix a couple of undefined variables introduced by the patch to fix tearing on ->remote_i_size and ->zero_point. For some reason, make W=1 with gcc doesn't give undefined variable warnings (but clang does). Fixes: 2c8f4742bb76 ("netfs: Fix potential for tearing in ->remote_i_size and ->zero_point") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605031459.eX5UbO3K-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202605021450.ca5QGqLH-lkp@intel.com/ cc: Steve French <sfrench@samba.org> cc: Paulo Alcantara <pc@manguebit.org> cc: Matthew Wilcox <willy@infradead.org> cc: Christian Brauner <brauner@kernel.org> cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-05-18include: Remove unused ks8851_mll.hCosta Shulyupin
The last user was removed in commit 72628da6d634 ("net: ks8851: Remove ks8851_mll.c") which consolidated the driver into a common implementation. No file includes this header. Signed-off-by: Costa Shulyupin <costa.shul@redhat.com> Link: https://patch.msgid.link/20260515184531.1515418-1-costa.shul@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18Merge tag 'nf-26-05-16' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net: 1) Fix small race windows in nf_ct_helper_log() when accessing helper, from Florian Westphal. 2) Fix potential infinite loop and race conditions in IPVS caused by frequent user-triggered service table changes, from Julia Anastasov. 3) Fix a race condition when dumping ipsets for restore, from Jozsef Kadlecsik. 4) Fix inner transport offset in IPv6 in nft_inner when extension headers come before the layer 4 transport header, from Yizhou Zhao. 5) Fix incorrect iteration over IPv4 ranges in several hash set types, from Nan Li. 6) Fix incorrect order when restoring BH in nft_inner_restore_tun_ctx(), from Florian Westphal. 7) Validate option array from ip6t_hbh checkpath() to fix an off-by-one access, from Zhengchuan Liang. 8) Fix race condition between ipset list -terse and concurrent updates, from Jozsef Kadlecisk. 9) Fix race condition when inserting elements into a hash bucket, also from Jozsef. 10) Annotate access to first free slot in hashtable, from Jozsef Kadlecsik. 11) Ensure sufficient headroom in br_netfilter neigh transmission, from Lorenzo Bianconi. 12) Hold reference on skb->dev in nfqueue exit path, bridge local input is speciall since skb->dev != state->indev, allowing for net_device to go away while packet is sitting in nfqueue. From Haoze Xie. * tag 'nf-26-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_queue: hold bridge skb->dev while queued netfilter: br_netfilter: Reallocate headroom if necessary in neigh_hh_bridge() netfilter: ipset: annotate "pos" for concurrent readers/writers netfilter: ipset: Fix data race between add and dump in all hash types netfilter: ipset: Fix data race between add and list header in all hash types netfilter: ip6t_hbh: reject oversized option lists netfilter: nft_inner: release local_lock before re-enabling softirqs netfilter: ipset: stop hash:* range iteration at end netfilter: nft_inner: Fix IPv6 inner_thoff desync netfilter: ipset: fix a potential dump-destroy race ipvs: avoid possible loop in ip_vs_dst_event on resizing netfilter: nf_conntrack_helper: fix possible null deref during error log ==================== Link: https://patch.msgid.link/20260516115627.967773-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18dibs: Improve DIBS prompts and help textsGeert Uytterhoeven
The Kconfig prompts for the DIBS options read: DIBS support (DIBS) [N/m/y/?] intra-OS shortcut with dibs loopback (DIBS_LO) [N/y/?] Clarify the DIBS prompt by expanding the acronym. Capitalize the first character of the DIBS_LO prompt. While at it, join the first two lines of the DIBS help text into a real sentence. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Link: https://patch.msgid.link/9093259c43e5d1996965d1522562444419196a19.1778838921.git.geert+renesas@glider.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18x86: Remove unnecessary architecture-specific <asm/device.h>Ethan Nelson-Moore
arch/x86/include/asm/device.h is identical to include/asm-generic/device.h, and therefore the x86-specific version is unnecessary. Remove it. [ dhansen: Minor note: It looks like if asm/foo.h does not exist that the build system generates one that does a #include <asm-generic/foo.h>. Thus, all that needs to be done is remove the arch-specific one. ] Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260517025713.97791-1-enelsonmoore@gmail.com
2026-05-18Merge tag 'batadv-net-pullrequest-20260515' of https://git.open-mesh.org/batadvJakub Kicinski
Simon Wunderlich says: ==================== Here are various batman-adv bugfixes: - fix tp_meter counter underflow during shutdown, by Luxiao Xu - fix tp_meter tp_vars reference leak in receiver shutdown, by Sven Eckelmann - fix various translation table integer handling issues, by Sven Eckelmann (3 patches) - fix various translation table counter issues, by Sven Eckelmann (3 patches) - fix fragment reassembly length accounting, by Ruide Cao - clear current gateway during teardown, by Ruijie Li - handle forward allocation error in DAT, by Sven Eckelmann - tp_meter: avoid use of uninitialized sender variables in tp_meter, by Sven Eckelmann - disallow unicast fragment in fragment, by Sven Eckelmann - directly shut down tp_meter timer on cleanup, by Sven Eckelmann * tag 'batadv-net-pullrequest-20260515' of https://git.open-mesh.org/batadv: batman-adv: tp_meter: directly shut down timer on cleanup batman-adv: frag: disallow unicast fragment in fragment batman-adv: tp_meter: avoid use of uninit sender vars batman-adv: dat: handle forward allocation error batman-adv: clear current gateway during teardown batman-adv: fix fragment reassembly length accounting batman-adv: tt: prevent TVLV entry number overflow batman-adv: tt: avoid empty VLAN responses batman-adv: tt: fix TOCTOU race for reported vlans batman-adv: tt: fix negative last_changeset_len batman-adv: tt: fix negative tt_buff_len batman-adv: tt: reject oversized local TVLV buffers batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown batman-adv: fix tp_meter counter underflow during shutdown ==================== Link: https://patch.msgid.link/20260515095540.325586-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-18Merge tag 'for-net-2026-05-14' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - af_bluetooth: serialize accept_q access - L2CAP: ecred_reconfigure: send packed pdu, not stack pointer - btmtk: accept too short WMT FUNC_CTRL events - hci_qca: Convert timeout from jiffies to ms * tag 'for-net-2026-05-14' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: hci_qca: Convert timeout from jiffies to ms Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer Bluetooth: btmtk: accept too short WMT FUNC_CTRL events Bluetooth: serialize accept_q access ==================== Link: https://patch.msgid.link/20260514172340.1515042-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>