Dave Airlie [Fri, 27 Mar 2026 02:45:28 +0000 (12:45 +1000)]
Merge tag 'drm-misc-next-2026-03-26' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v7.1:
UAPI Changes:
amdxdna:
- support per-BO memory-usage queries
docs:
- Improve UAPI documentation
panthor:
- extend timestamp query with flags
Core Changes:
edid:
- provide enum drm_output_color_format; mass-convert drivers
gem-dma:
- use drm_dev_dma_dev() for DMA mappings
- set VM_DONTDUMP on mmap
mipi-dbi:
- drop simple-display; mass-convert drivers
prime:
- use drm_dev_dma_dev() for DMA mappings
ttm:
- improve handling of gfp_retry_mayfail
Driver Changes:
amdgpu:
- use atomic_create_state for private_obj
amdxdna:
- refactor GEM implementation
- fixes
bridge:
- provide clear-and-put helper for reliable cleanup
- analogix_dp: Use DP helpers for link training
- lontium-lt8713sx: Fix 64-bit division and Kconfig
- samsung-dsim: Use clear-and-put
imagination:
- improve power-off sequence
- support context-reset notification from firmware
komeda:
- support Arm China Linlon D6 plus DT bindings
mediatek:
- use drm_dev_dma_dev() for DMA mappings
panel:
- support Himax HX83121A plus DT bindings
- support JuTouch JT070TM041 plus DT bindings
- support Samsung S6E8FC0 plus DT bindings
- himax-hx83102c: support Samsung S6E8FC0 plus DT bindings; support backlight
- ili9806e: support Rocktech RK050HR345-CT106A plus DT bindings
- simple: support Tianma TM050RDH03 plus DT bindings
panthor:
- support various sources for timestamp queries
- fixes
omapdrm:
- use atomic_create_state for private_obj
rcar-du:
- fix suspend/resume wrt VSP interface
- fix leak of device_link
- clean up
sun4i:
- use drm_dev_dma_dev() for DMA mappings
tegra:
- use atomic_create_state for private_obj
xe:
- send 'none' recovery method for XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET
Nicholas Carlini [Fri, 27 Mar 2026 02:18:23 +0000 (02:18 +0000)]
io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
__io_uring_show_fdinfo() iterates over pending SQEs and, for 128-byte
SQEs on an IORING_SETUP_SQE_MIXED ring, needs to detect when the second
half of the SQE would be past the end of the sq_sqes array. The current
check tests (++sq_head & sq_mask) == 0, but sq_head is only incremented
when a 128-byte SQE is encountered, not on every iteration. The actual
array index is sq_idx = (i + sq_head) & sq_mask, which can be sq_mask
(the last slot) while the wrap check passes.
Fix by checking sq_idx directly. Keep the sq_head increment so the loop
still skips the second half of the 128-byte SQE on the next iteration.
Aurelien Jarno [Thu, 26 Mar 2026 18:35:33 +0000 (19:35 +0100)]
riscv: dts: spacemit: enable USB 3 ports on Milk-V Jupiter
Enable the DWC3 USB 3.0 controller (USB#2 port in the K1 datasheet) and
its associated combo_phy (USB 3 PHY) and usbphy2 (USB 2 PHY) on the
Milk-V Jupiter board.
The board uses a VLI VL817 hub, providing four ports. Two are routed to
the 3.0 type-A connectors, and two to the F_USB3 front USB header. The
hub requires two separate 5V power supplies: one for the hub itself and
one for the USB connectors. Add an always-on regulator sourcing 5V from
the DC-IN input, along with two GPIO-controlled fixed regulators to
manage the hub and connectors power supplies.
Note that the board also provides four USB 2.0 ports (two via type-A
connectors and two via the F_USB2 front USB header), but these are
handled by a different controller (USB#1 port in the K1 datasheet).
Aurelien Jarno [Thu, 26 Mar 2026 18:35:32 +0000 (19:35 +0100)]
riscv: dts: spacemit: enable QSPI and add SPI NOR on Milk-V Jupiter
Add the QSPI controller node for the Milk-V Jupiter board and describe
the attached SPI NOR flash (GD25Q64E).
The flash supports a frequency up to 133MHz (80 MHz for reads), and the
SoC supports a frequency up to 104 MHz. However tests have shown that
the flash is not reliably detected above 26.5 MHz, consistent with
frequency used in the vendor kernel. Therefore, use this frequency.
The m25p,fast-read properties is taken from the vendor kernel, and the
GD25Q64E datasheet confirms tha the fast read opcodes are supported.
Add a corresponding flash partition layout, matching the layout and the
names used in the vendor U-Boot.
Aurelien Jarno [Thu, 26 Mar 2026 18:35:30 +0000 (19:35 +0100)]
riscv: dts: spacemit: add 24c04 eeprom on Milk-V Jupiter
The Milk-V Jupiter board includes a 24c04 eeprom on the i2c2 bus. The
eeprom contains an ONIE TLV table, which on the board I tested only
provides a product-name entry. Expose it via an onie,tlv-layout nvmem
layout.
The eeprom is marked as read-only since its contents are not supposed to
be modified.
Aurelien Jarno [Thu, 26 Mar 2026 18:35:29 +0000 (19:35 +0100)]
riscv: dts: spacemit: add LEDs for Milk-V Jupiter board
The Milk-V Jupiter board provides support for two LEDs through the front
panel header. The "Power LED" indicates the system is running, and the
"HDD LED" shows disk activity. Configure the corresponding LED triggers
accordingly.
Caveats:
- The LEDs are driven through a 4.7k series resistor, making them
quite faint.
- The disk activity trigger requires a storage controller on the M.2 or
PCIe interface. That said, it matches the purpose and the vendor
kernel.
Andrew Davis [Tue, 3 Mar 2026 20:52:24 +0000 (14:52 -0600)]
arm64: dts: ti: k3-j721s2: Make MAIN domain system control bus a simple-bus
This node describes a memory address range containing several sub-regions
with control registers for various IP in the MAIN domain of this SoC. It
was described as a "ti,j721e-system-controller" but this is a J721S2 SoC
with is not compatible with the system controller region found in J721e.
No project consuming this DT has been found that makes use of the syscon
compatible for this region, to prevent any from using this node like a
generic syscon region in the future, make this a normal simple-bus as
it should have been from the start.
Andrew Davis [Tue, 3 Mar 2026 20:52:23 +0000 (14:52 -0600)]
arm64: dts: ti: k3-j7200: Make MAIN domain system control bus a simple-bus
This node describes a memory address range containing several sub-regions
with control registers for various IP in the MAIN domain of this SoC. It
was described as a "ti,j721e-system-controller" but this is a J7200 SoC
with is not compatible with the system controller region found in J721e.
No project consuming this DT has been found that makes use of the syscon
compatible for this region, to prevent any from using this node like a
generic syscon region in the future, make this a normal simple-bus as
it should have been from the start.
Judith Mendez [Mon, 23 Feb 2026 23:37:31 +0000 (17:37 -0600)]
arm64: dts: ti: k3-am62-lp-sk: Enable internal pulls for MMC0 data pins
AM62 LP SK board does not have external pullups on MMC0 DAT1-DAT7
pins [0]. Enable internal pullups on DAT1-DAT7 considering:
- without a host-side pullup, these lines rely solely on the eMMC
device's internal pullup (R_int, 10-150K per JEDEC), which may
exceed the recommended 50K max for 1.8V VCCQ
- JEDEC JESD84-B51 Table 200 requires host-side pullups (R_DAT,
10K-100K) on all data lines to prevent bus floating
[0] https://www.ti.com/lit/zip/SPRR471
Fixes: a0b8da04153e ("arm64: dts: ti: k3-am62*: Move eMMC pinmux to top level board file") Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://patch.msgid.link/20260223233731.2690472-4-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Judith Mendez [Mon, 23 Feb 2026 23:37:30 +0000 (17:37 -0600)]
arm64: dts: ti: k3-am62l3-evm: Disable MMC1 internal pulls on data pins
AM62L EVM has external 47K pullups on MMC1 DAT1-DAT3 pins [0].
Disable internal pullups on DAT1-DAT3 so that each line has a
single pullup source:
- with both pullups enabled, the effective parallel resistance on
DAT1-3 (~24.2K) creates a ~2x mismatch vs DAT0 (47K external
only). Removing internal pullups results in DAT1-3 matching DAT0 at 47K
- 47K external alone is within the recommended range for 1.8V
signaling (10K min, 50K recommended max)
- both internal and external pullups enabled equals unnecessary power
consumption
Judith Mendez [Mon, 23 Feb 2026 23:37:29 +0000 (17:37 -0600)]
arm64: dts: ti: k3-am62p5-sk: Disable MMC1 internal pulls on data pins
AM62P SK has external 10K pullups on MMC1 DAT1-DAT3 pins [0].
Disable internal pullups on DAT1-DAT3 so that each line has a
single pullup source:
- with both pullups enabled, the effective parallel resistance on
DAT1-3 (~8.33K) drops below the 10K minimum pullup requirement
for data lines (per SD Physical Layer Specification)
- removing internal pullups makes DAT1-3 match DAT0 10K
external pullup so its consistent and within spec
- both internal and external pullups enabled equals unnecessary power
consumption
[0] https://www.ti.com/lit/zip/SPRR487
Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://patch.msgid.link/20260223233731.2690472-2-jm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Kendall Willis [Thu, 12 Feb 2026 17:27:24 +0000 (11:27 -0600)]
arm64: dts: ti: k3-am62d2-evm: Enable Main UART wakeup
The Main UART can resume from suspend to RAM states when PIN_WKUP_EN
is enabled. Add the necessary pins needed to wakeup the system. Add the
system idle states that the Main UART can wakeup the system from.
The UART driver uses the "default" pinctrl state when the system is
active. In the suspend hook, if the UART is wakeup enabled, the "wakeup"
pinctrl state is selected by the UART driver in order to allow wakeup.
Upon resume, the default pinctrl state is selected again.
Kendall Willis [Thu, 12 Feb 2026 17:27:23 +0000 (11:27 -0600)]
arm64: dts: ti: k3-am62l3-evm: Enable Main UART wakeup
The Main UART can resume from suspend to RAM states when PIN_WKUP_EN
is enabled. Add the necessary pins needed to wakeup the system. Add the
system idle states that the Main UART can wakeup the system from.
The UART driver uses the "default" pinctrl state when the system is
active. In the suspend hook, if the UART is wakeup enabled, the "wakeup"
pinctrl state is selected by the UART driver in order to allow wakeup.
Upon resume, the default pinctrl state is selected again.
Kendall Willis [Thu, 12 Feb 2026 17:27:22 +0000 (11:27 -0600)]
arm64: dts: ti: k3-am62p5-sk: Enable Main UART wakeup
The Main UART can resume from suspend to RAM states when PIN_WKUP_EN
is enabled. Add the necessary pins needed to wakeup the system. Add the
system idle states that the Main UART can wakeup the system from.
The UART driver uses the "default" pinctrl state when the system is
active. In the suspend hook, if the UART is wakeup enabled, the "wakeup"
pinctrl state is selected by the UART driver in order to allow wakeup.
Upon resume, the default pinctrl state is selected again.
Kendall Willis [Thu, 12 Feb 2026 17:27:21 +0000 (11:27 -0600)]
arm64: dts: ti: k3-am62a7-sk: Enable Main UART wakeup
The Main UART can resume from suspend to RAM states when PIN_WKUP_EN
is enabled. Add the necessary pins needed to wakeup the system. Add the
system idle states that the Main UART can wakeup the system from.
The UART driver uses the "default" pinctrl state when the system is
active. In the suspend hook, if the UART is wakeup enabled, the "wakeup"
pinctrl state is selected by the UART driver in order to allow wakeup.
Upon resume, the default pinctrl state is selected again.
Kendall Willis [Thu, 12 Feb 2026 17:27:20 +0000 (11:27 -0600)]
arm64: dts: ti: k3-am62x-sk-common: Enable Main UART wakeup
The Main UART can resume from suspend to RAM states when PIN_WKUP_EN
is enabled. Add the necessary pins needed to wakeup the system. Add the
system idle states that the Main UART can wakeup the system from.
The UART driver uses the "default" pinctrl state when the system is
active. In the suspend hook, if the UART is wakeup enabled, the "wakeup"
pinctrl state is selected by the UART driver in order to allow wakeup.
Upon resume, the default pinctrl state is selected again.
net: ethernet: mtk_ppe: avoid NULL deref when gmac0 is disabled
If the gmac0 is disabled, the precheck for a valid ingress device will
cause a NULL pointer deref and crash the system. This happens because
eth->netdev[0] will be NULL but the code will directly try to access
netdev_ops.
Instead of just checking for the first net_device, it must be checked if
any of the mtk_eth net_devices is matching the netdev_ops of the ingress
device.
Cc: stable@vger.kernel.org Fixes: 73cfd947dbdb ("net: ethernet: mtk_eth_soc: ppe: prevent ppe update for non-mtk devices") Signed-off-by: Sven Eckelmann (Plasma Cloud) <se@simonwunderlich.de> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260324-wed-crash-gmac0-disabled-v1-1-3bc388aee565@simonwunderlich.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Dipayaan Roy [Tue, 24 Mar 2026 18:14:28 +0000 (11:14 -0700)]
net: mana: Fix RX skb truesize accounting
MANA passes rxq->alloc_size to napi_build_skb() for all RX buffers.
It is correct for fragment-backed RX buffers, where alloc_size matches
the actual backing allocation used for each packet buffer. However, in
the non-fragment RX path mana allocates a full page, or a higher-order
page, per RX buffer. In that case alloc_size only reflects the usable
packet area and not the actual backing memory.
This causes napi_build_skb() to underestimate the skb backing allocation
in the single-buffer RX path, so skb->truesize is derived from a value
smaller than the real RX buffer allocation.
Fix this by updating alloc_size in the non-fragment RX path to the
actual backing allocation size before it is passed to napi_build_skb().
Yohei Kojima [Tue, 24 Mar 2026 17:20:28 +0000 (02:20 +0900)]
selftests: net: Remove unnecessary backslashes in fq_band_pktlimit.sh
Address "grep: warning: stray \ before white space" warning from GNU
grep 3.12. This warns the misplaced backslashes before whitespaces
(e.g. \\' ' or '\ ') which leads to unspecified behavior [1].
We can just remove the backslashes before whitespaces as POSIX says:
Enclosing characters in single-quotes ('') shall preserve the literal
value of each character within the single-quotes.
Jeremy Kerr [Tue, 24 Mar 2026 07:19:56 +0000 (15:19 +0800)]
net: mctp: avoid copy in fragmentation loop for near-MTU messages
Currently, we incorrectly send messages that are within 4 bytes (a
struct mctp_hdr) smaller than the MTU through mctp_do_fragment_route().
This has no effect on the actual fragmentation, as we will still send as
one packet, but unnecessarily copies the original skb into a new
single-fragment skb.
Instead of having the MTU comparisons in both mctp_local_output() and
mctp_do_fragment_route(), feed all local messages through the latter,
and add the single-packet optimisation there.
This means we can coalesce the routing path of mctp_local_output, so our
out_release path is now solely for errors, so rename the label
accordingly.
Include a check in the route tests for the single-packet case too.
Reported-by: yuanzhaoming <yuanzm2@lenovo.com> Closes: https://github.com/openbmc/linux/commit/269936db5eb3962fe290b1dc4dbf1859cd5a04dd#r175836230 Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260324-dev-mtu-copy-v1-1-7af6bd7027d3@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Justin Iurman [Tue, 24 Mar 2026 09:14:34 +0000 (10:14 +0100)]
selftests: add check for seg6 tunsrc
Extend srv6_hencap_red_l3vpn_test.sh to include checks for the new
"tunsrc" feature. If there is no support for tunsrc, it silently
falls back to the encap config without tunsrc.
Justin Iurman [Tue, 24 Mar 2026 09:14:33 +0000 (10:14 +0100)]
seg6: add per-route tunnel source address
Add SEG6_IPTUNNEL_SRC in the uapi for users to configure a specific
tunnel source address. Make seg6_iptunnel handle the new attribute
correctly. It has priority over the configured per-netns tunnel
source address, if any.
Sabrina Dubroca [Mon, 23 Mar 2026 23:25:57 +0000 (00:25 +0100)]
mpls: add seqcount to protect the platform_label{,s} pair
The RCU-protected codepaths (mpls_forward, mpls_dump_routes) can have
an inconsistent view of platform_labels vs platform_label in case of a
concurrent resize (resize_platform_label_table, under
platform_mutex). This can lead to OOB accesses.
This patch adds a seqcount, so that we get a consistent snapshot.
Note that mpls_label_ok is also susceptible to this, so the check
against RTA_DST in rtm_to_route_config, done outside platform_mutex,
is not sufficient. This value gets passed to mpls_label_ok once more
in both mpls_route_add and mpls_route_del, so there is no issue, but
that additional check must not be removed.
Reported-by: Yuan Tan <tanyuan98@outlook.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Fixes: 7720c01f3f590 ("mpls: Add a sysctl to control the size of the mpls label table") Fixes: dde1b38e873c ("mpls: Convert mpls_dump_routes() to RCU.") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/cd8fca15e3eb7e212b094064cd83652e20fd9d31.1774284088.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phylink: use phylink_expects_phy() in phylink_fwnode_phy_connect()
The tests in phylink_expects_phy() and phylink_fwnode_phy_connect() are
identical (by intention). Use phylink_expects_phy() to decide whether
to ignore a call to phylink_fwnode_phy_connect().
This small series does a bit of cleanup in the dwmad-socfpga glue
driver, especially around the .fix_mac_speed() operation.
It's mostly about re-using existing helpers from the glue driver, as
well as reorganizing the code to make the local private structures a
little bit smaller.
No functionnal changes are intended, this was tested on cyclone V.
====================
net: stmmac: dwmac-sofcpga: Drop the struct device reference
We keep a reference to our the struct device in the socfpga_dwmac priv
structure, but now it's only ever used to produce logs in the
.set_phy_mode() ops, that are specific to this driver.
When we call that ops, we always have a ref to the struct device around,
so let's pass it to .set_phy_mode(). We can now discard that reference
from struct socfpga_dwmac.
Jakub Kicinski [Fri, 27 Mar 2026 01:17:14 +0000 (18:17 -0700)]
Merge tag 'wireless-next-2026-03-26' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
A fairly big set of changes all over, notably with:
- cfg80211: new APIs for NAN (Neighbor Aware Networking,
aka Wi-Fi Aware) so less work must be in firmware
- mt76:
- mt7996/mt7925 MLO fixes/improvements
- mt7996 NPU support (HW eth/wifi traffic offload)
- iwlwifi: UNII-9 and continuing UHR work
* tag 'wireless-next-2026-03-26' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (230 commits)
wifi: mac80211: ignore reserved bits in reconfiguration status
wifi: cfg80211: allow protected action frame TX for NAN
wifi: ieee80211: Add some missing NAN definitions
wifi: nl80211: Add a notification to notify NAN channel evacuation
wifi: nl80211: add NL80211_CMD_NAN_ULW_UPDATE notification
wifi: nl80211: allow reporting spurious NAN Data frames
wifi: cfg80211: allow ToDS=0/FromDS=0 data frames on NAN data interfaces
wifi: nl80211: define an API for configuring the NAN peer's schedule
wifi: nl80211: add support for NAN stations
wifi: cfg80211: separately store HT, VHT and HE capabilities for NAN
wifi: cfg80211: add support for NAN data interface
wifi: cfg80211: make sure NAN chandefs are valid
wifi: cfg80211: Add an API to configure local NAN schedule
wifi: mac80211: cleanup error path of ieee80211_do_open
wifi: mac80211: extract channel logic from link logic
wifi: iwlwifi: mld: set RX_FLAG_RADIOTAP_TLV_AT_END generically
wifi: iwlwifi: reduce the number of prints upon firmware crash
wifi: iwlwifi: fix the description of SESSION_PROTECTION_CMD
wifi: iwlwifi: mld: introduce iwl_mld_vif_fw_id_valid
wifi: iwlwifi: mld: block EMLSR during TDLS connections
...
====================
====================
Add support for Nuvoton MA35D1 GMAC
This patch series is submitted to add GMAC support for Nuvoton MA35D1
SoC platform. This work involves implementing a GMAC driver glue layer
based on Synopsys DWMAC driver framework to leverage MA35D1's dual GMAC
interface capabilities.
Overview:
1. Added a GMAC driver glue layer for MA35D1 SoC, providing support for
the platform's two GMAC interfaces.
2. Added device tree settings, with specific configurations for our
development boards:
a. SOM board: Configured for two RGMII interfaces.
b. IoT board: Configured with one RGMII and one RMII interface.
3. Added dt-bindings for the GMAC interfaces.
====================
Jakub Kicinski [Fri, 27 Mar 2026 00:51:39 +0000 (17:51 -0700)]
Merge tag 'wireless-2026-03-26' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Couple more fixes:
- virt_wifi: remove SET_NETDEV_DEV to avoid UAF on teardown
- iwlwifi:
- fix (some) devices that don't have 6 GHz (WiFi6E)
- fix potential OOB read of firmware notification
- set WiFi generation for firmware to avoid packet drops
- fix multi-link scan timing
- wilc1000: fix integer overflow
- ath11k/ath12k: fix TID during A-MPDU session teardown
- wl1251: don't trust firmware TX status response index
* tag 'wireless-2026-03-26' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free
wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()
wifi: wl1251: validate packet IDs before indexing tx_frames
wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation
wifi: ath12k: Pass the correct value of each TID during a stop AMPDU session
wifi: ath11k: Pass the correct value of each TID during a stop AMPDU session
wifi: iwlwifi: mld: correctly set wifi generation data
wifi: iwlwifi: mvm: don't send a 6E related command when not supported
wifi: iwlwifi: mld: Fix MLO scan timing
====================
The doc-only change is insufficient. The actual fix requires bumping the
minimum pahole version to 1.27 with proper Kconfig and Makefile.btf
changes, and should be routed through the BPF tree.
Kartik Rajput [Tue, 24 Mar 2026 05:58:42 +0000 (11:28 +0530)]
i2c: tegra: Add logic to support different register offsets
Tegra410 use different offsets for existing I2C registers, update
the logic to use appropriate offsets per SoC.
As the register offsets are now defined in the SoC-specific
tegra_i2c_regs structures, the tegra_i2c_reg_addr() function is no
longer needed to translate register offsets and has been removed.
Kartik Rajput [Tue, 24 Mar 2026 05:58:41 +0000 (11:28 +0530)]
i2c: tegra: Introduce tegra_i2c_variant to identify DVC and VI
Replace the per-instance DVC/VI boolean flags with a tegra_i2c_variant
enum and move the variant field into tegra_i2c_hw_feature so it is
populated via SoC match data.
Add dedicated SoC data entries for the "nvidia,tegra20-i2c-dvc" and
"nvidia,tegra210-i2c-vi" compatibles and drop compatible-string checks
from tegra_i2c_parse_dt.
Suggested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260324055843.549808-2-kkartik@nvidia.com
Stephen Brennan [Fri, 20 Mar 2026 23:45:53 +0000 (16:45 -0700)]
perf report: Add comm_nodigit sort key
The "comm" column allows grouping events by the process command. It is
intended to group like programs, despite having different PIDs. But some
workloads may adjust their own command, so that a unique identifier
(e.g. a PID or some other numeric value) is part of the command name.
This destroys the utility of "comm", forcing perf to place each unique
process name into its own bucket, which can contribute to a
combinatorial explosion of memory use in perf report.
Create a less strict version of this column, which ignores digits when
comparing command names. Commands whose names are the same (ignoring
digits) are sorted into the same histogram buckets, and displayed with
the placeholder value "<N>" in the place of digits. For example,
hypothetical command names "kworker/1" "kworker/2" "kworker/3" would
sort into the same bucket and be represented as "kworker/<N>".
Ian Rogers [Thu, 19 Mar 2026 23:33:49 +0000 (16:33 -0700)]
perf stat: Fix opt->value type for parse_cache_level
Commit f5803651b4a4 ("perf stat: Choose the most disaggregate command
line option") changed aggregation option handling for `perf stat` but
not `perf stat report` leading to parse_cache_level being passed a
struct in the `perf stat` case but erroneously an aggr_mode enum value
for `perf stat report`. Change the `perf stat report` aggregation
handling to use the same opt_aggr_mode as `perf stat`. Also, just pass
the boolean for consistency with other boolean argument handling.
Fixes: f5803651b4a4 ("perf stat: Choose the most disaggregate command line option") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Ian Rogers [Thu, 19 Mar 2026 23:33:48 +0000 (16:33 -0700)]
perf lock: Fix option value type in parse_max_stack
The value is a void* and the address of an int, max_stack_depth, is
set up in the perf lock options. The parse_max_stack function treats
the int* as a long*, make this more correct by declaring the value to
be an int*.
Fixes: 0a277b622670 ("perf lock contention: Check --max-stack option") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Thomas Richter [Thu, 19 Mar 2026 08:47:54 +0000 (09:47 +0100)]
perf record: Add support for arch_sdt_arg_parse_op() on s390
commit e5e66adfe45a6 ("perf regs: Remove __weak attributive arch_sdt_arg_parse_op() function")
removes arch_sdt_arg_parse_op() functions and reveals missing s390 support.
The following warning is printed:
Unknown ELF machine 22, standard arguments parse will be skipped.
ELF machine 22 is the EM_S390 host. This happens with command
# ./perf record -v -- stress-ng -t 1s --matrix 0
when the event is not specified.
Add s390 specific __perf_sdt_arg_parse_op_s390() function to support
-architecture calls to arch_sdt_arg_parse_op() for s390.
The warning disappears.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Ian Rogers <irogers@google.com> Tested-by: Jan Polensky <japo@linux.ibm.com> Cc: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The USB ID 2040:8360 was reported as a new revision
of Hauppauge HVR-935 and requested to be added to
the cx231xx driver. The issue is current generation
of Hauppauge 9x5 devices including 935, 955, and 975
have moved to em2828x usb bridge. Support for the
em2828x usb bridge and USB ID's for the new devices
has been submitted.
Signed-off-by: Bradford Love <brad@nextdimension.cc> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Leo Yan [Tue, 17 Mar 2026 18:58:00 +0000 (18:58 +0000)]
tools build: Correct link flags for libopenssl
The perf static build reports that the BPF skeleton is disabled due to
the missing libopenssl feature.
Use PKG_CONFIG to determine the link flags for libopenssl. Add
"--static" to the PKG_CONFIG command for static linking.
Fixes: 7678523109d1 ("tools/build: Add a feature test for libopenssl") Signed-off-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
These guards appear to be leftovers from file renames or copy-paste
errors. Correcting them to follow the standard convention of matching
the file name prevents potential include guard collisions.
Douglas Anderson [Tue, 17 Mar 2026 16:01:20 +0000 (09:01 -0700)]
device property: Make modifications of fwnode "flags" thread safe
In various places in the kernel, we modify the fwnode "flags" member
by doing either:
fwnode->flags |= SOME_FLAG;
fwnode->flags &= ~SOME_FLAG;
This type of modification is not thread-safe. If two threads are both
mucking with the flags at the same time then one can clobber the
other.
While flags are often modified while under the "fwnode_link_lock",
this is not universally true.
Create some accessor functions for setting, clearing, and testing the
FWNODE flags and move all users to these accessor functions. New
accessor functions use set_bit() and clear_bit(), which are
thread-safe.
Cc: stable@vger.kernel.org Fixes: c2c724c868c4 ("driver core: Add fw_devlink_parse_fwtree()") Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Reviewed-by: Saravana Kannan <saravanak@kernel.org> Link: https://patch.msgid.link/20260317090112.v2.1.I0a4d03104ecd5103df3d76f66c8d21b1d15a2e38@changeid
[ Fix fwnode_clear_flag() argument alignment, restore dropped blank
line in fwnode_dev_initialized(), and remove unnecessary parentheses
around fwnode_test_flag() calls. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Andrii Nakryiko [Thu, 26 Mar 2026 20:53:57 +0000 (13:53 -0700)]
Merge branch 'add-btf-layout-to-btf'
Alan Maguire says:
====================
Add BTF layout to BTF
Update struct btf_header to add a new "layout" section containing
a description of how to parse the BTF kinds known about at BTF
encoding time. This provides the opportunity for tools that might
not know all of these kinds - as is the case when older tools run
on more newly-generated BTF - to still parse the BTF provided,
even if it cannot all be used.
The ideas here were discussed at [1], with further discussion
at [2].
Patches for pahole will enable the layout addition during BTF
generation are at [3], but even absent these the addition of the
layout feature in the final patch in this series should not break
anything since such unknown features are simply ignored during pahole
BTF generation.
Separately tested sanitization of BTF location info with separate
small series which simulates feature absence to support testing of
features for older kernels; will follow up with that shortly.
Changes since v15 [4]:
- Fixed endian issues for layout section by swapping flags fields
where needed (sashiko.dev, patch 2)
- Fixed string size issue with swapped endian case, use btf->magic
for comparison to determine endian mismatch (bpf review bot,
sashiko.dev, patch 6)
Changes since v14 [5]:
- Fix potential overflow for swapped endian case (BPF review bot,
patch 2)
- Add global: keyword to libbpf.map (sashiko.dev, patch 4)
- Fix endian issues in sanitization; we use the endian safe
btf->hdr and check for endian mismatch between it and raw original
BTF header to inform how we write the change str_off. Also fix
potential truncation issues due to not including hdr->type_off
(sashiko.dev, patch 6)
- Fix issues with selftests raw BTF file interactions (sashiko.dev,
patch 8)
- Drop feature test test since it will be covered by another series
Changes since v13: [6]:
- add feature check/sanitization of BTF with layout info (Andrii,
patch 6)
- added feature check test for layout support (patch 9)
Changes since v12: [7]:
- add logging of layout off/len to kernel header logging (review bot,
patch 6)
- add mode to open() in selftest (review bot, patch 7)
Changes since v11 [8]:
- Revert unneeded changes to btf__new_empty() (Eduard, review bot,
patch 4)
- Reorder btf_parse_layout_sec() checks to ensure min size check
occurs before multiple check (review bot, patch 6)
Changes since v10 [9]:
- deal with read overflow with small header (review bot, patch 2)
- validate layout length is a multiple of sizeof(struct btf_layout)
(review bot, patch 6)
- fix comment style (Alexei, patches 4,7)
- remove bpftool BTF metadata subcommands for now (Alexei)
Changes since v9: [10]:
- fix memcpy header size overrun (review bot, patch 2)
- return size computation directly (Andrii, patch 333)
- revert to original unknown kind logging (Alexei/review bot,
patch 6)
- gap-checking logic can be simplified now that we have
4-byte aligned types and layout together (patch 6)
- fix naming of layout offset, unconditionally emit a layouts
array in json (Quentin, review bot, patch 8)
- fix metadata output in man page to include flags (review bot,
patch 9)
Changes since v8: [11]:
- updated name from "kind_layout" to "layout" (Andrii)
- moved layout info to inbetween types and strings since
both types and layout info align on 4 bytes (Andrii)
- use embedded btf_header (Eduard)
- when consulting layout, fall back to base BTF if none found in
split BTF; this will allow us to only encode layout info in
vmlinux rather than repeating it for each module.
Changes since v7: [12]:
- Fixed comment style in UAPI headers (Mykyta, patch 1)
- Simplify calcuation of header size using min() (Mykyta, patch 2)
- simplify computation of bounds for kind (Mykyta, patch 3)
- Added utility functions for updating type, string offsets when
data is added; this simplifies the code and encapsulates such
updates more clearly (patch 2)
Changes since v6: [13]:
- BPF review bot caught some memory leaks around freeing
of kind layout; more importantly, it noted that we were
breaking with the contiguous BTF representation for
btf_new_empty_opts(). Doing so meant that freeing kind_layout
could not be predicated on having btf->modifiable set, so
adpoted the contiguous raw data layout for BTF to be
consistent with type/string storage (patches 2,4)
- Moved checks for kind overflow prior to referencing kinds
to avoid any risk of overrun (patches 3, 8)
- Tightened up kind layout header offset/len header validation
to catch invalid combinations early in btf_parse_hdr()
(patch 2)
- Fixed selftest to verify calloc success (patch 7)
Changes since v5: [14]:
- removed flags field from kind layout; it is not really workable
since we would have to define semantics of all possible future
flags today to be usable. Instead stick to parsing only, which
means each kind just needs the length of the singular and
vlen-specified objects (Alexei)
- added documentation for bpftool BTF metadata dump (Quentin, patch 9)
Changes since v4: [15]:
- removed CRC generation since it is not needed to handle modules
built at different time than kernel; distilled base BTF supports
this now
- fixed up bpftool display of empty kind names, comment/documentation
indentation (Quentin, patches 8, 9)
Changes since v3 [16]:
- fixed mismerge issues with kbuild changes for BTF generation
(patches 9, 14)
- fixed a few small issues in libbpf with kind layout representation
(patches 2, 4)
Changes since v2 [17]:
- drop "optional" kind flag (Andrii, patch 1)
- allocate "struct btf_header" for struct btf to ensure
we can always access new fields (Andrii, patch 2)
- use an internal BTF kind array in btf.c to simplify
kind encoding (Andrii, patch 2)
- drop use of kind layout information for in-kernel parsing,
since the kernel needs to be strict in what it accepts
(Andrii, patch 6)
- added CRC verification for BTF objects and for matching
with base object (Alexei, patches 7,8)
- fixed bpftool json output (Quentin, patch 10)
- added standalone module BTF support, tests (patches 13-17)
Changes since RFC
- Terminology change from meta -> kind_layout
(Alexei and Andrii)
- Simplify representation, removing meta header
and just having kind layout section (Alexei)
- Fixed bpftool to have JSON support, support
prefix match, documented changes (Quentin)
- Separated metadata opts into add_kind_layout
and add_crc
- Added additional positive/negative tests
to cover basic unknown kind, one with an
info_sz object following it and one with
N elem_sz elements following it.
- Updated pahole-flags to use help output
rather than version to see if features
are present
Alan Maguire [Thu, 26 Mar 2026 14:54:44 +0000 (14:54 +0000)]
kbuild, bpf: Specify "layout" optional feature
The "layout" feature will add metadata about BTF kinds to the
generated BTF; its absence in pahole will not trigger an error so it
is safe to add unconditionally as it will simply be ignored if pahole
does not support it.
Alan Maguire [Thu, 26 Mar 2026 14:54:43 +0000 (14:54 +0000)]
selftests/bpf: Test kind encoding/decoding
verify btf__new_empty_opts() adds layouts for all kinds supported,
and after adding kind-related types for an unknown kind, ensure that
parsing uses this info when that kind is encountered rather than
giving up.
Alan Maguire [Thu, 26 Mar 2026 14:54:42 +0000 (14:54 +0000)]
btf: Support kernel parsing of BTF with layout info
Validate layout if present, but because the kernel must be
strict in what it accepts, reject BTF with unsupported kinds,
even if they are in the layout information.
Alan Maguire [Thu, 26 Mar 2026 14:54:41 +0000 (14:54 +0000)]
libbpf: Support sanitization of BTF layout for older kernels
Add a FEAT_BTF_LAYOUT feature check which checks if the
kernel supports BTF layout information. Also sanitize
BTF if it contains layout data but the kernel does not
support it. The sanitization requires rewriting raw
BTF data to update the header and eliminate the layout
section (since it lies between the types and strings),
so refactor sanitization to do the raw BTF retrieval
and creation of updated BTF, returning that new BTF
on success.
Alan Maguire [Thu, 26 Mar 2026 14:54:40 +0000 (14:54 +0000)]
libbpf: BTF validation can use layout for unknown kinds
BTF parsing can use layout to navigate unknown kinds, so
btf_validate_type() should take layout information into
account to avoid failure when an unrecognized kind is met.
Alan Maguire [Thu, 26 Mar 2026 14:54:39 +0000 (14:54 +0000)]
libbpf: Add layout encoding support
Support encoding of BTF layout data via btf__new_empty_opts().
Current supported opts are base_btf and add_layout.
Layout information is maintained in btf.c in the layouts[] array;
when BTF is created with the add_layout option it represents the
current view of supported BTF kinds.
Alan Maguire [Thu, 26 Mar 2026 14:54:37 +0000 (14:54 +0000)]
libbpf: Support layout section handling in BTF
Support reading in layout fixing endian issues on reading;
also support writing layout section to raw BTF object.
There is not yet an API to populate the layout with meaningful
information.
As part of this, we need to consider multiple valid BTF header
sizes; the original or the layout-extended headers.
So to support this, the "struct btf" representation is modified
to contain a "struct btf_header" and we copy the valid
portion from the raw data to it; this means we can always safely
check fields like btf->hdr.layout_len .
Note if parsed-in BTF has extra header information beyond
sizeof(struct btf_header) - if so we make that BTF ineligible
for modification by setting btf->has_hdr_extra .
Ensure that we handle endianness issues for BTF layout section,
though currently only field that needs this (flags) is unused.
Alan Maguire [Thu, 26 Mar 2026 14:54:36 +0000 (14:54 +0000)]
btf: Add BTF kind layout encoding to UAPI
BTF kind layouts provide information to parse BTF kinds. By separating
parsing BTF from using all the information it provides, we allow BTF
to encode new features even if they cannot be used by readers. This
will be helpful in particular for cases where older tools are used
to parse newer BTF with kinds the older tools do not recognize;
the BTF can still be parsed in such cases using kind layout.
The intent is to support encoding of kind layouts optionally so that
tools like pahole can add this information. For each kind, we record
- length of singular element following struct btf_type
- length of each of the btf_vlen() elements following
- a (currently unused) flags field
compat.bpf.h defined a fallback SCX_ENQ_IMMED macro using
__COMPAT_ENUM_OR_ZERO(). After 6bf36c68b0a2 ("tools/sched_ext:
Regenerate autogen enum headers") added SCX_ENQ_IMMED to the autogen
headers, including both triggers -Wmacro-redefined warnings.
The autogen definition through const volatile __weak already resolves to
0 on older kernels, providing the same backward compatibility. Remove
the now-redundant compat fallback.
Ilpo Järvinen [Tue, 24 Mar 2026 16:56:24 +0000 (18:56 +0200)]
resource: Add __resource_contains_unbound() for internal contains checks
__find_resource_space() currently uses resource_contains() but for
tentative resources that are not yet crafted into the resource tree. As
resource_contains() checks that IORESOURCE_UNSET is not set for either of
the resources, the caller has to hack around this problem by clearing the
IORESOURCE_UNSET flag (essentially lying to resource_contains()).
Instead of the hack, introduce __resource_contains_unbound() for cases like
this.
Ilpo Järvinen [Fri, 13 Mar 2026 08:45:50 +0000 (10:45 +0200)]
PCI: Fix premature removal from realloc_head list during resource assignment
reassign_resources_sorted() checks for two things:
a) Resource assignment failures for mandatory resources by checking if the
resource remains unassigned, which are known to always repeat, and does
not attempt to assign them again.
b) That resource is not among the ones being processed/assigned at this
stage, leading to skip processing such resources in
reassign_resources_sorted() as well (resource assignment progresses
one PCI hierarchy level at a time).
The problem here is that a) is checked before b), but b) also implies the
resource is not being assigned yet, making also a) true. As a) only skips
resource assignment but still removes the resource from realloc_head, the
later stages that would need to process the information in realloc_head
cannot obtain the optional size information anymore. This leads to
considering only non-optional part for bridge windows deeper in the PCI
hierarchy.
This problem has been observed during rescan (add_size is not considered
while attempting assignment for 0000:e2:00.0 indicating the corresponding
entry was removed from realloc_head while processing resource assignments
for 0000:e1):
Fixes: 96336ec70264 ("PCI: Perform reset_resource() and build fail list in sync") Reported-by: Peter Nisbet <peter.nisbet@intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Peter Nisbet <peter.nisbet@intel.com> Link: https://patch.msgid.link/20260313084551.1934-1-ilpo.jarvinen@linux.intel.com
Linus Torvalds [Thu, 26 Mar 2026 19:42:28 +0000 (12:42 -0700)]
Merge tag 'pm-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix two cpufreq issues, one in the core and one in the
conservative governor, and two issues related to system sleep:
- Restore the cpufreq core behavior changed inadvertently during the
6.19 development cycle to call cpufreq_frequency_table_cpuinfo()
for cpufreq policies getting re-initialized which ensures that
policy->max and policy->cpuinfo_max_freq will be valid going
forward (Viresh Kumar)
- Adjust the cached requested frequency in the conservative cpufreq
governor on policy limits changes to prevent it from becoming stale
in some cases (Viresh Kumar)
- Prevent pm_restore_gfp_mask() from triggering a WARN_ON() in some
code paths in which it is legitimately called without invoking
pm_restrict_gfp_mask() previously (Youngjun Park)
- Update snapshot_write_finalize() to take trailing zero pages into
account properly which prevents user space restore from failing
subsequently in some cases (Alberto Garcia)"
* tag 'pm-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
PM: sleep: Drop spurious WARN_ON() from pm_restore_gfp_mask()
PM: hibernate: Drain trailing zero pages on userspace restore
cpufreq: conservative: Reset requested_freq on limits change
cpufreq: Don't skip cpufreq_frequency_table_cpuinfo()
Ilpo Järvinen [Thu, 19 Feb 2026 15:39:51 +0000 (17:39 +0200)]
PCI: Prevent shrinking bridge window from its required size
Steve reported an eGPU (either Radeon Instinct MI50 32GB or NVIDIA 3080
10GB) connected via Thunderbolt was not assigned sufficient BAR space in
v6.11, so the amdgpu and nvidia drivers were unable to initialize the
device.
pci_bridge_distribute_available_resources() -> ... ->
adjust_bridge_window() is called between __pci_bus_size_bridges()
and assigning the resources. Since the commit 948675736a77 ("PCI: Allow
adjust_bridge_window() to shrink resource if necessary")
adjust_bridge_window() can also shrink the bridge window. The shrunken
size, however, conflicts with what __pci_bus_size_bridges() ->
pbus_size_mem() calculated as the required bridge window size. By shrinking
the size, adjust_bridge_window() prevents the rest of the resource fitting
algorithm from working as intended. Resource fitting logic is expecting
assignment failures when bridge windows need resizing, but there are cases
where failures are no longer happening after the commit 948675736a77 ("PCI:
Allow adjust_bridge_window() to shrink resource if necessary").
The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink
resource if necessary") justifies the change by the extra reservation
made due to hpmemsize parameter, however, the kernel code contradicts
that statement. (For simplicity, finer-grained hpmmiosize and hpmmiopref
parameters that can be used to the same effect as hpmemsize are ignored in
this description.)
pbus_size_mem() calls calculate_memsize() twice. First with add_size=0
to find out the minimal required resource size. The second call occurs
with add_size=hpmemsize (effectively) but the result does not directly
affect the resource size only resulting in an entry on the realloc_head
list (a.k.a. add_list). Yet, adjust_bridge_window() directly changes
the resource size which does not include what is reserved due to
hpmemsize. Also, if the required size for the bridge window exceeds
hpmemsize, the parameter does not have any effect even on the second
size calculation made by pbus_size_mem(); from calculate_memsize():
size = max(size, add_size) + children_add_size;
The commit ae4611f1d7e9 ("PCI: Set resource size directly in
adjust_bridge_window()") that precedes the commit 948675736a77 ("PCI:
Allow adjust_bridge_window() to shrink resource if necessary") is also
related to causing this problem. Its changelog explicitly states
adjust_bridge_window() wants to "guarantee" allocation success.
Guaranteed allocations, however, are incompatible with how the other
parts of the resource fitting algorithm work. The given justification
fails to explain why guaranteed allocations at this stage are required
nor why forcing window to a smaller value than what was calculated by
pbus_size_mem() is correct. While the change might have worked by chance
in some test scenario, too small bridge window does not "guarantee"
success from the point of view of the endpoint device resource
assignments. No issue is mentioned within the changelog so it's unclear
if the change was made to fix some observed issue nor and what that
issue was.
The unwanted shrinking of a bridge window occurs, e.g., when a device with
large BARs such as eGPU is attached using Thunderbolt and the Root Port
holds less than enough resource space for the eGPU. The GPU resources are
in order of GBs and the default hotplug allocation is a mere 2MB
(DEFAULT_HOTPLUG_MMIO_PREF_SIZE). The problem is illustrated by this log
(filtered to the relevant content only):
The initial size of the Root Port's window is 448MB (0x601bffffff -
0x6000000000). __pci_bus_size_bridges() -> pbus_size_mem() calculates the
required size to be 32772 MB (0x10003fffff - 0x800000000) which would fit
the eGPU resources. adjust_bridge_window() then shrinks the bridge window
down to what is guaranteed to fit into the Root Port's bridge window. The
bridge window for 03:00.0 is also eliminated from the add_list (a.k.a.
realloc_head) list by adjust_bridge_window().
After adjustment, the resources are assigned and as the bridge window for
03:00.0 is assigned successfully, no failure is recorded. Without a
failure, no attempt to resize the window of the Root Port is required. The
end result is eGPU not having large enough resources to work.
The commit 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink
resource if necessary") also claims nested bridge windows are sized the
same, which is false. pbus_size_mem() calculates the size for the parent
bridge window by summing all the downstream resources so the resource
fitting calculates larger bridge window for the parent to accommodate the
childen. That is, hpmemsize does not result the same size for the case
where there are nested bridge windows.
In order to fix the most immediate problem, don't shrink the resource size
in adjust_bridge_window() as hpmemsize had nothing to do with it. When
considering add_size, only reduce it up to what is added due to hpmemsize
(if required size is larger than hpmemsize, the parameter has no impact,
see calculate_memsize()). Unfortunately, if the tail of the bridge window
was aligned in calculate_memsize() from below hpmemsize to above it, the
size check will falsely match but the check at least errs to the side of
caution. There's not enough information available in adjust_bridge_window()
to know the calculated size precisely.
This is not exactly a revert of the commits e4611f1d7e9 ("PCI: Set resource
size directly in adjust_bridge_window()") and 948675736a77 ("PCI: Allow
adjust_bridge_window() to shrink resource if necessary") as shrinking still
remains in place but is implemented differently, and the end result behaves
very differently.
It is possible that those two commits fixed some other issue that is not
described with enough detail in the changelog and undoing parts of them
results in another regression due to behavioral change. Nonetheless, as
described above, the solution by those two commits was flawed and the
issue, if one exists, should be solved in a way that is compatible with the
rest of the resource fitting algorithm instead of working against it.
Besides shrinking, the case where adjust_bridge_window() expands the bridge
window is likely somewhat wrong as well because it removes the entry from
add_list (a.k.a. realloc_head), but it is less damaging as that only
impacts optional resources and may have no impact if expanding by hpmemsize
is larger than what add_size was. Fixing it is left as further work.
Fixes: 948675736a77 ("PCI: Allow adjust_bridge_window() to shrink resource if necessary") Fixes: ae4611f1d7e9 ("PCI: Set resource size directly in adjust_bridge_window()") Reported-by: Steve Oswald <stevepeter.oswald@gmail.com> Closes: https://lore.kernel.org/linux-pci/CAN95MYEaO8QYYL=5cN19nv_qDGuuP5QOD17pD_ed6a7UqFVZ-g@mail.gmail.com/ Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260219153951.68869-1-ilpo.jarvinen@linux.intel.com
Ahmed Naseef [Thu, 12 Mar 2026 16:53:32 +0000 (16:53 +0000)]
PCI: Prevent assignment to unsupported bridge windows
Previously, pci_read_bridge_io() and pci_read_bridge_mmio_pref()
unconditionally set resource type flags (IORESOURCE_IO or IORESOURCE_MEM |
IORESOURCE_PREFETCH) when reading bridge window registers. For windows that
are not implemented in hardware, this may cause the allocator to assign
space for a window that doesn't exist.
For example, the EcoNET EN7528 SoC Root Port doesn't support the
prefetchable window, but since a downstream device had a prefetchable BAR,
the allocator mistakenly assigned a prefetchable window:
pci 0001:00:01.0: [14c3:0811] type 01 class 0x060400 PCIe Root Port
pci 0001:00:01.0: PCI bridge to [bus 01-ff]
pci 0001:00:01.0: bridge window [mem 0x28000000-0x280fffff]: assigned
pci 0001:00:01.0: bridge window [mem 0x28100000-0x282fffff pref]: assigned
pci 0001:01:00.0: BAR 0 [mem 0x28100000-0x281fffff 64bit pref]: assigned
pci_read_bridge_windows() already detects unsupported windows by testing
register writability and sets dev->io_window/pref_window accordingly.
Check dev->io_window/pref_window so we don't set the resource flags for
unsupported windows, which prevents the allocator from assigning space to
them.
After this commit, the prefetchable BAR is correctly allocated from the
non-prefetchable window:
Linus Torvalds [Thu, 26 Mar 2026 19:27:17 +0000 (12:27 -0700)]
Merge tag 'thermal-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"This prevents the int340x thermal driver from taking the power slider
offset parameter into account incorrectly in some cases (Srinivas
Pandruvada)"
* tag 'thermal-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: intel: int340x: soc_slider: Set offset only for balanced mode
Abel Vesa [Fri, 13 Mar 2026 12:22:38 +0000 (14:22 +0200)]
dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Document Eliza compatible
The SPMI multi-master Arbiter found on Eliza is version 7.2.0, yet
driver-wise, still compatible with the one featured on Hamoa (X1E80100),
which is 7.0.1.
So document the Eliza compatible and allow Hamoa one as fallback.
Move the content of fdt_reserved_mem_save_node() to
fdt_init_reserved_mem_node() function. Initialization is no longer
performed in two steps as it was initially, so
fdt_reserved_mem_save_node() name is a bit misleading and that function
now performs full initialization of the reserved memory region.
This also fixes the problem of keeping pointers to the regions, which
failed to initialize, what might cause issues when such region is
assigned to the device.
Rename fdt_scan_reserved_mem_reg_nodes() to fdt_scan_reserved_mem_late()
to clearly show how it differs from fdt_scan_reserved_mem() and update
description of both functions.
Marek Szyprowski [Wed, 25 Mar 2026 09:00:21 +0000 (10:00 +0100)]
of: reserved_mem: rearrange code a bit
Move __rmem_check_for_overlap() and __rmem_cmp() functions before
fdt_scan_reserved_mem_reg_nodes() to avoid forward declaration and keep
related code close together.
Marek Szyprowski [Wed, 25 Mar 2026 09:00:19 +0000 (10:00 +0100)]
of: reserved_mem: switch to ops based OF_DECLARE()
Move init function from OF_DECLARE() argument to the given reserved
memory region ops structure and then pass that structure to the
OF_DECLARE() initializer. This node_init callback is mandatory for the
reserved mem driver. Such change makes it possible in the future to add
more functions called by the generic code before given memory region is
initialized and rmem object is created.
Marek Szyprowski [Wed, 25 Mar 2026 09:00:18 +0000 (10:00 +0100)]
of: reserved_mem: use -ENODEV instead of -ENOENT
When given reserved memory region doesn't really support given node,
return -ENODEV instead of -ENOENT. Then fix __reserved_mem_init_node()
function to properly propagate error code different from -ENODEV instead
of silently ignoring it.
Linus Torvalds [Thu, 26 Mar 2026 19:06:40 +0000 (12:06 -0700)]
Merge tag 'acpi-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support fix from Rafael Wysocki:
"Prevent use-after-free from occurring on reduced-hardware ACPI
platforms when -EPROBE_DEFER is returned by ec_install_handlers()
during ACPI EC driver initialization (Weiming Shi)"
* tag 'acpi-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()
Biju Das [Thu, 26 Mar 2026 16:24:51 +0000 (16:24 +0000)]
pinctrl: renesas: rzg2l: Fix save/restore of {IOLH,IEN,PUPD,SMT} registers
The rzg2l_pinctrl_pm_setup_regs() handles save/restore of
{IOLH,IEN,PUPD,SMT} registers during s2ram, but only for ports where all
pins share the same pincfg. Extend the code to also support ports with
variable pincfg per pin, so that {IOLH,IEN,PUPD,SMT} registers are
correctly saved and restored for all pins.
Lad Prabhakar [Thu, 19 Mar 2026 14:15:15 +0000 (14:15 +0000)]
pinctrl: renesas: rzt2h: Add pin configuration support
Add pin configuration support for the Renesas RZ/T2H SoC. The RZ/T2H SoC
allows configuring several electrical characteristics through the DRCTLm
(I/O Buffer Function Switching) registers. These registers control bias
configuration, Schmitt trigger input, output slew rate, and drive
strength.
Implement pinconf_ops to allow reading and updating these properties
through the generic pin configuration framework. The implementation
supports bias-disable, bias-pull-up, bias-pull-down,
input-schmitt-enable, slew-rate, and drive-strength-microamp.
Linus Torvalds [Thu, 26 Mar 2026 19:03:37 +0000 (12:03 -0700)]
Merge tag 'landlock-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux
Pull Landlock fixes from Mickaël Salaün:
"This mainly fixes Landlock TSYNC issues related to interrupts and
unexpected task exit.
Other fixes touch documentation and sample, and a new test extends
coverage"
* tag 'landlock-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
landlock: Expand restrict flags example for ABI version 8
selftests/landlock: Test tsync interruption and cancellation paths
landlock: Clean up interrupted thread logic in TSYNC
landlock: Serialize TSYNC thread restriction
samples/landlock: Bump ABI version to 8
landlock: Improve TSYNC types
landlock: Fully release unused TSYNC work entries
landlock: Fix formatting
Document the pin configuration properties supported by the RZ/T2H
pinctrl driver.
The RZ/T2H SoC allows configuring several electrical characteristics
through the DRCTLm (I/O Buffer Function Switching) registers. These
registers control drive strength, bias configuration, Schmitt trigger
input, and output slew rate.
Matthew Brost [Thu, 26 Mar 2026 01:12:07 +0000 (18:12 -0700)]
drm/xe: Issue GGTT invalidation under lock in ggtt_node_remove
Async work (e.g., GuC queue teardowns) can call ggtt_node_remove, so the
operation must be performed under the GGTT lock to ensure the GGTT
online check remains stable. GGTT insertion and removal are heavyweight
operations (e.g., queue create/destroy), so the additional serialization
cost is negligible compared to ensuring correctness.
Marek Vasut [Thu, 26 Mar 2026 04:54:59 +0000 (05:54 +0100)]
ARM: dts: renesas: Drop KSZ8041 PHY C22 compatible strings
The Microchip KSZ8041 PHY schema indicates that the compatible string
"ethernet-phy-id0022.1537" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Marek Vasut [Thu, 26 Mar 2026 04:54:01 +0000 (05:54 +0100)]
ARM: dts: renesas: rza2mevb: Drop RTL8201F PHY C22 compatible string
The Realtek RTL8201F PHY schema indicates that the compatible string
"ethernet-phy-id001c.c816" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
Marek Vasut [Thu, 26 Mar 2026 04:53:38 +0000 (05:53 +0100)]
ARM: dts: renesas: r8a7742-iwg21d-q7-dbcm-ca: Drop KSZ8081 PHY C22 compatible string
The Microchip KSZ8081 PHY schema indicates that the compatible string
"ethernet-phy-id0022.1560" must not be followed by any other compatible
string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema.
projects / thirdparty / kernel / stable.git / log
