firmware: tegra: Make TEGRA_IVC a hidden Kconfig symbol
kconfiglint reports:
K002: config TEGRA_BPMP selects visible symbol TEGRA_IVC which has
dependencies
TEGRA_IVC was originally introduced in
commit ca791d7f4256 ("firmware: tegra:
Add IVC library") as a user-visible
bool with a prompt ("Tegra IVC protocol"). At that time, TEGRA_BPMP
depended on TEGRA_IVC, requiring users to manually enable it.
Recently,
commit 78eb18020a88 ("firmware: tegra: Fix IVC dependency problems")
recognized that TEGRA_IVC is library code that should be activated via
`select` rather than user selection. That commit changed TEGRA_BPMP from
`depends on TEGRA_IVC` to `select TEGRA_IVC`, and restricted TEGRA_IVC's
prompt to only appear under COMPILE_TEST
(`bool "Tegra IVC protocol" if COMPILE_TEST`). The commit message
explicitly states: "The IVC code is library code that other drivers need to
select if they need that library."
However, the `if COMPILE_TEST` qualifier still leaves TEGRA_IVC as a
technically visible symbol, triggering K002 when TEGRA_BPMP selects it.
Since TEGRA_IVC depends on ARCH_TEGRA, it cannot be independently enabled
under COMPILE_TEST without ARCH_TEGRA anyway, limiting the value of the
standalone COMPILE_TEST path. TEGRA_BPMP itself provides adequate
COMPILE_TEST coverage for the IVC library through its own dependency chain.
Complete the transition to a pure library symbol by removing the prompt
entirely, making TEGRA_IVC a hidden bool activated only via select from
TEGRA_BPMP. This is consistent with the intent expressed in 78eb18020a88.
Arnd Bergmann [Thu, 28 May 2026 21:59:09 +0000 (23:59 +0200)]
Merge tag 'imx-soc-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
i.MX SoC fixes for v7.1
Fix CAAM driver probe failures caused by missing SoC information by
retrieving the match data directly through of_machine_get_match_data(),
which provides the correct SoC-specific data.
* tag 'imx-soc-fixes-for-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
soc: imx8m: Fix match data lookup for soc device
The series introduces stack_map_get_build_id_offset_sleepable(),
fixing a gap with parsing build_id in sleepable context in stackmap.c
In particular, this fixes a deadlock in
stack_map_get_build_id_offset() doing a blocking __kernel_read(),
which happens since commit 777a8560fd29 ("lib/buildid: use
__kernel_read() for sleepable context").
See previous revisions for more details.
---
v6->v7:
* Addressed feedback from Andrii (mostly patch #2):
* implement proper CONFIG_PER_VMA_LOCK=n support, following a
VMA locking pattern similar to one used in PROCMAP_QUERY
* change the contract of stack_map_lock_vma(): if a non-NULL VMA
is returned, then a read lock is held
* remove now unnecessary vma_locked flag
* and various other nits
* Add vma_is_anonymous() checks where appropriate (AIs)
v6: https://lore.kernel.org/bpf/20260521225022.2695755-1-ihor.solodrai@linux.dev/
v5->v6:
* Misc refactoring (Andrii):
* add stack_map_build_id_set_valid() helper
* simplify control flow in stack_map_get_build_id_offset_sleepable()
v5: https://lore.kernel.org/bpf/20260515005244.1333013-1-ihor.solodrai@linux.dev/
v4->v5:
* Add comments explaining mmap_read_trylock() (Shakeel)
* Rebase on bpf-next (Alexei)
v4: https://lore.kernel.org/bpf/20260514184727.1067141-1-ihor.solodrai@linux.dev/
v3->v4:
* Change Fixes tag in patch #2 (AI)
* Nit in caching implementation (Mykyta)
v3: https://lore.kernel.org/bpf/20260512032906.2670326-1-ihor.solodrai@linux.dev/
v2->v3:
* Split patch #2 in two: stack_map_get_build_id_offset_sleepable()
implementation, and then introduce caching
* Drop taking mmap_lock if CONFIG_PER_VMA_LOCK=n, fall back to raw
IPs instead
* Cache vm_{start,end} in addition to prev_file (Mykyta)
v2: https://lore.kernel.org/bpf/20260409010604.1439087-1-ihor.solodrai@linux.dev/
v1->v2:
* Addressed feedback from Puranjay:
* split out a small refactoring patch
* use mmap_read_trylock()
* take into account CONFIG_PER_VMA_LOCK
* replace find_vma() with vma_lookup()
* cache prev_build_id to avoid re-parsing the same file
* Snapshot vm_pgoff and vm_start before unlocking (AI)
* To avoid repetitive unlocking statements, introduce struct
stack_map_vma_lock to hold relevant lock state info and add an
unlock helper
v1: https://lore.kernel.org/bpf/20260407223003.720428-1-ihor.solodrai@linux.dev/
Ihor Solodrai [Mon, 25 May 2026 22:39:48 +0000 (15:39 -0700)]
bpf: Cache build IDs in sleepable stackmap path
Stack traces often contain adjacent IPs from the same VMA or from
different VMAs backed by the same ELF file. Cache the last successfully
parsed build id together with the resolved VMA range and backing file
so the sleepable build id path can avoid repeated VMA locking and file
parsing in common cases.
Ihor Solodrai [Mon, 25 May 2026 22:39:47 +0000 (15:39 -0700)]
bpf: Avoid faultable build ID reads under mm locks
Sleepable build ID parsing can block in __kernel_read() [1], so the
stackmap sleepable path must not call it while holding mmap_lock or a
per-VMA read lock.
The issue and the fix are conceptually similar to a recent procfs
patch [2]. A similar VMA locking pattern has already been used in
PROCMAP_QUERY [3].
Resolve each covered VMA with a stable read-side reference, preferring
lock_vma_under_rcu() and falling back to mmap_read_trylock() only long
enough to acquire the VMA read lock. Take a reference to the backing
file, drop the VMA lock, and then parse the build ID through
(sleepable) build_id_parse_file().
We have to use mmap_read_trylock() (and give up on failure) in this
context because taking mmap_read_lock() is generally unsafe on code
paths reachable from BPF programs [4], and may lead to deadlocks.
Ihor Solodrai [Mon, 25 May 2026 22:39:46 +0000 (15:39 -0700)]
bpf: Factor out stack_map build ID helpers
Factor out helpers from stack_map_get_build_id_offset() in
preparation for adding a sleepable build ID resolution path:
stack_map_build_id_set_ip(), stack_map_build_id_offset(), and
stack_map_build_id_set_valid().
While here, refactor stack_map_get_build_id_offset():
* use continue-driven control flow in the main loop and remove
build_id_valid label
* update prev_vma and prev_build_id on the fall-back-to-IP branch so
the cache reflects the actual VMA seen on the previous IP [1]
* guard fetch_build_id() with vma_is_anonymous() [2] to skip parse
attempts that would otherwise fail the ELF magic check
Arnd Bergmann [Thu, 28 May 2026 21:57:25 +0000 (23:57 +0200)]
Merge tag 'qcom-arm64-defconfig-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm Arm64 defconfig fixes for v7.1
A number of targets now depends on the M.2 PCIe power sequencing driver,
enable this to keep these devices functional with a defconfig build.
* tag 'qcom-arm64-defconfig-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable PCI M.2 power sequencing driver
Arnd Bergmann [Thu, 28 May 2026 21:55:17 +0000 (23:55 +0200)]
Merge tag 'qcom-arm64-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm Arm64 DeviceTree fixes for v7.1
Add missing power-domain and iface clocks for the ICE node of Eliza and
Milos to avoid the validation errors that resulted from late binding
changes. Also drop the reference clock for the USB QMP PHYs, for the
same reason.
Avoid touching the 20'th I2C bus on the Hamoa-based (X Elite) Dell
laptops, as this conflicts with the battery management firmware.
* tag 'qcom-arm64-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
arm64: dts: qcom: x1-dell-thena: remove i2c20 (battery SMBus) and reserve its pins
arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYs
Rick Edgecombe [Wed, 27 May 2026 22:13:42 +0000 (15:13 -0700)]
MAINTAINERS: Move Rick Edgecombe to TDX maintainer
Per some offline discussion with Kiryl, he could use some help on the TDX
host side. I have worked on the TDX host side for the past few years
including wrangling the initial KVM support, and can help with this.
I am already listed as TDX reviewer. Move it to maintainer.
Xuan Zhuo [Wed, 27 May 2026 12:09:36 +0000 (20:09 +0800)]
net: remove SIOCSHWTSTAMP and SIOCGHWTSTAMP from ndo_eth_ioctl comment
Since commit 4ee58e1e5680 ("net: promote SIOCSHWTSTAMP and SIOCGHWTSTAMP
ioctls to dedicated handlers"), SIOCSHWTSTAMP and SIOCGHWTSTAMP are no
longer dispatched through dev_eth_ioctl() / ndo_eth_ioctl(). They are
now handled by their own dedicated functions dev_set_hwtstamp() and
dev_get_hwtstamp() in the ioctl path.
However, the comment describing ndo_eth_ioctl in netdevice.h still
lists these two ioctls, which is misleading for driver developers who
may incorrectly assume they need to handle hardware timestamping
commands in their ndo_eth_ioctl implementation.
Remove the stale references from the comment to accurately reflect that
ndo_eth_ioctl only handles SIOCGMIIPHY, SIOCGMIIREG and SIOCSMIIREG.
Arnd Bergmann [Thu, 28 May 2026 21:47:31 +0000 (23:47 +0200)]
Merge tag 'qcom-drivers-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm driver fixes for v7.1
The Qualcomm ICE driver suffers from race conditions between probe() and
get() and will in certain cases return the wrong error code, which
results in storage drivers failing to probe. Fix these issues.
Also correct the DeviceTree binding, to ensure that relevant clocks are
described and voted for, to prevent the driver from accessing unclocked
hardware during boot.
* tag 'qcom-drivers-fixes-for-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: ice: Fix the error code when 'qcom,ice' property is not found
scsi: ufs: ufs-qcom: Remove NULL check from devm_of_qcom_ice_get()
mmc: sdhci-msm: Remove NULL check from devm_of_qcom_ice_get()
soc: qcom: ice: Return proper error codes from devm_of_qcom_ice_get() instead of NULL
soc: qcom: ice: Return -ENODEV if the ICE platform device is not found
soc: qcom: ice: Fix race between qcom_ice_probe() and of_qcom_ice_get()
soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE
dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
Jakub Kicinski [Wed, 27 May 2026 16:25:22 +0000 (09:25 -0700)]
net: ethtool: don't take rtnl_lock for global string dump
ETHTOOL_MSG_STRSET_GET is the only op which sets allow_nodev_do.
When no device is provided it dumps static tables, there's no
need to hold rtnl_lock for this.
Not taking rtnl_lock is a minor win in itself so I think this
patch stands on its own merits. Later on it will be useful
to do locking only in paths which have access to a netdev,
so that we can decide which locks to take per-netdev.
Revert "vsock/virtio: fix skb overhead overflow on 32-bit builds"
This reverts commit 4157501b9a8f ("vsock/virtio: fix skb overhead
overflow on 32-bit builds"). The fix was semantically correct (although
it would have been better to use mul_u32_u32(), as David pointed out),
but in practice we are estimating the memory used to allocate the SKBs,
and this will never cause a 32-bit variable to overflow on a 32-bit
system, since the memory would have run out long before that. On 64-bit,
SKB_TRUESIZE() already evaluates to size_t, so the multiplication is
already in 64-bit arithmetic without the cast.
Let's revert this to avoid unnecessary 64-bit multiplies on the
per-packet receive path on 32-bit systems.
Reported-by: David Laight <david.laight.linux@gmail.com> Closes: https://lore.kernel.org/netdev/20260523173557.5cc4f4f6@pumpkin Suggested-by: "Michael S. Tsirkin" <mst@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Laight <david.laight.linux@gmail.com> Link: https://patch.msgid.link/20260527171046.130211-1-sgarzare@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Tegra194 PCIe driver converts aspm-l1-entry-delay-ns to whole ms
with ceiling division, then derives the Synopsys DesignWare PORT_AFR L1
entrance latency encoding as min(order_base_2(us), 7).
The nanosecond values from the Fixes tag below round up to 4, 8, and 16 us,
selecting PORT_AFR L1 entrance latency codes 2, 3, and 4 respectively.
Raise the programmed latency so the PORT_AFR codes are 3 / 4 / 5
(8 / 16 / 32 us buckets) instead of 2 / 3 / 4 (4 / 8 / 16 us).
Kartik Rajput [Thu, 14 May 2026 05:48:31 +0000 (11:18 +0530)]
soc/tegra: fuse: Register nvmem lookups at probe
Register nvmem lookups in tegra_fuse_probe(), after the nvmem device has
been registered, since they can only be used after the nvmem device is
registered.
Tiezhu Yang [Tue, 26 May 2026 06:39:36 +0000 (14:39 +0800)]
libbpf: Add __NR_bpf definition for LoongArch
LoongArch uses the generic syscall table, where __NR_bpf is defined
as 280 in include/uapi/asm-generic/unistd.h.
To align with other architectures, add the __NR_bpf definition for
LoongArch to avoid a potential compilation failure: "error __NR_bpf
not defined. libbpf does not support your arch."
This is a follow up patch of:
commit b0c47807d31d ("bpf: Add sparc support to tools and samples.")
commit bad1926dd2f6 ("bpf, s390: fix build for libbpf and selftest suite")
commit ca31ca8247e2 ("tools/bpf: fix perf build error with uClibc (seen on ARC)")
commit e32cb12ff52a ("bpf, mips: Fix build errors about __NR_bpf undeclared")
====================
docs: net: updates for old and cobwebbed docs
I'm hoping to start feeding our docs into the AI review tools, instead
of maintaining a separate repo with review prompts. To experiment with
that we have to refresh the docs a little bit.
A read thru our current docs makes one slightly question the value
of including them in reviews. But directionally, I feel, it's probably
still right. I'm hoping the Rx Checksum section about not dropping packets
for example to be impactful. I don't think the current AI agents or
review docs include this guidance.
====================
Jakub Kicinski [Tue, 26 May 2026 16:01:49 +0000 (09:01 -0700)]
docs: net: add Rx notes to the checksum guide
The Rx checksum processing gives people pause. The two main questions
in my experience are:
- what to do with bad IPv4 checksum; and
- what to do with packets with bad checksum.
Folks often feel the urge to drop the latter, to "avoid overloading
the host".
Jakub Kicinski [Tue, 26 May 2026 16:01:48 +0000 (09:01 -0700)]
docs: net: fix minor issues with checksum offloads
Update the checksum offload documentation to match current code:
- SCTP CRC32c offload requires NETIF_F_SCTP_CRC, not ordinary IP
checksum offload
- NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM are restricted legacy
features; new devices should use NETIF_F_HW_CSUM
- GRE LCO is handled by the shared gre_build_header() helper used by
both IPv4 and IPv6 GRE
- VXLAN_F_REMCSUM_TX is a VXLAN configuration flag, not a field of
struct vxlan_rdst
Jakub Kicinski [Tue, 26 May 2026 16:01:47 +0000 (09:01 -0700)]
docs: net: refresh netdev feature guidance
Update netdev feature documentation for current locking rules and
feature semantics. Clarify hw_features updates and netdev_update_features()
locking, keep the NETIF_F_NEVER_CHANGE rule with the VLAN challenged
exception, fix the HSR duplication wording, and document netdev->netmem_tx
as a device flag rather than a feature bit.
Split the list of basic feature sets from the "extra" ones like
vlan_features. A bunch of the newer fields weren't documented and
having them all together would be confusing.
Jakub Kicinski [Tue, 26 May 2026 16:01:46 +0000 (09:01 -0700)]
docs: net: fix minor issues with the NAPI guide
Update the NAPI documentation to match current API behavior:
- repeated napi_disable() calls hang waiting for ownership, rather
than deadlock
- NAPI IDs are exposed through SO_INCOMING_NAPI_ID and netdev Netlink
- epoll uses the maxevents parameter spelling
- add that drivers holding the netdev instance lock may need _locked()
variants
Jakub Kicinski [Tue, 26 May 2026 16:01:44 +0000 (09:01 -0700)]
docs: net: statistics: fix kernel-internal stats list
Update the kernel-internal ethtool stats list to match current code:
- spell the entries as "struct ethtool_*_stats", not as functions
- list the full set of structures, not only pause and fec
- mention that fields are pre-initialized to ETHTOOL_STAT_NOT_SET by
ethtool_stats_init() and drivers should leave unsupported fields at
that value rather than zeroing them
Jakub Kicinski [Tue, 26 May 2026 16:01:43 +0000 (09:01 -0700)]
docs: net: fix minor issues with driver guide
Update the driver documentation TX queue example to match current APIs:
- use the ring-local tx_ring_mask field in drv_tx_avail()
- stop the selected netdev_queue with netif_tx_stop_queue() instead of
stopping queue 0 with netif_stop_queue()
Jakub Kicinski [Tue, 26 May 2026 16:01:42 +0000 (09:01 -0700)]
docs: net: netdevices: small fixes and clarifications
A handful of unrelated nits:
- free_netdevice() does not exist; replace two stray references
with free_netdev().
- The simple-driver probe example fell through into err_undo after
register_netdev() success; add return 0 for clarity.
- Clarify the netdev_priv() paragraph: "(netdev_priv())" was easy
to misread as the thing that needs explicit freeing; spell out
that it refers to extra pointers stored in the device private
struct.
- ndo_setup_tc synchronization note: TC_SETUP_BLOCK / TC_SETUP_FT
actually run under block->cb_lock, not "NFT locks", and rtnl_lock
may or may not be held depending on path.
- ->lltx guidance reads as very outdated, it's not really deprecated.
I suspect people may have been trying to use it for HW drivers
in the past but I can't think of such a case in the last decade.
When rustc prints an error containing a long type that doesn't fit in a
line, it will write the whole thing in a .txt file and print messages
like:
note: the full type name has been written to
'path/to/subsystem/module_name.long-type-11621316855315349594.txt'
[ Depending on the compiler version and the kind of error, there are
two possible spellings -- copying them here for reference:
= note: the full name for the type has been written to '...long-type-...txt'
= note: the full type name has been written to '...long-type-...txt'
In addition, we could clean the files as well in one of our
cleaning Make targets [1][2].
Another option would be `--verbose` (but it implies more things
that we probably don't want) or `-Zwrite-long-types-to-disk=no`
(unstable so far, but a possible alternative if we prefer to
avoid the files and simply see the long types in the output
-- I asked upstream Rust about it [3]).
Long types like core::result::Result<core::pin::Pin<Box<_, Kmalloc,
kernel::error::Error>: pin_init::PinInit<Box<_, Kmalloc>, _> are common
during development, so add a gitignore entry.
Carlos Llamas [Sat, 23 May 2026 16:27:21 +0000 (16:27 +0000)]
libbpf: Fix UAF in strset__add_str()
strset_add_str_mem() might reallocate the strset data buffer in order to
accommodate the provided string 's'. However, if 's' points to a string
already present in the buffer, it becomes dangling after the realloc.
This leads to a use-after-free when attempting to memcpy() the string
into the new buffer.
One scenario that triggers this problematic path is when resolve_btfids
attempts to patch kfunc prototypes using existing BTF parameter names:
| resolve_btfids: function bpf_list_push_back_impl already exists in BTF
| Segmentation fault (core dumped)
Compiling resolve_btfids with fsanitize=address generates a detailed
report of the UAF:
| =================================================================
| ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4
| ==1507892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 at pc 0x55d25155a2a8 bp 0x7ffcef879060 sp 0x7ffcef878818
| READ of size 5 at 0x7f4c4a500bd4 thread T0
| #0 0x55d25155a2a7 in memcpy (tools/bpf/resolve_btfids/resolve_btfids+0xcf2a7)
| #1 0x55d2515d708e in strset__add_str tools/lib/bpf/strset.c:162:2
| #2 0x55d2515c730b in btf__add_str tools/lib/bpf/btf.c:2109:8
| #3 0x55d2515c9020 in btf__add_func_param tools/lib/bpf/btf.c:3108:14
| #4 0x55d25159f0b5 in process_kfunc_with_implicit_args tools/bpf/resolve_btfids/main.c:1196:9
| #5 0x55d25159e004 in btf2btf tools/bpf/resolve_btfids/main.c:1229:9
| #6 0x55d25159cee7 in main tools/bpf/resolve_btfids/main.c:1535:6
| #7 0x7f4c78e29f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
| #8 0x7f4c78e2a026 in __libc_start_main csu/../csu/libc-start.c:360:3
| #9 0x55d2514bb860 in _start (tools/bpf/resolve_btfids/resolve_btfids+0x30860)
|
| 0x7f4c4a500bd4 is located 13268 bytes inside of 2829000-byte region [0x7f4c4a4fd800,0x7f4c4a7b02c8)
| freed by thread T0 here:
| #0 0x55d25155b700 in realloc (tools/bpf/resolve_btfids/resolve_btfids+0xd0700)
| #1 0x55d2515c426c in libbpf_reallocarray tools/lib/bpf/./libbpf_internal.h:220:9
| #2 0x55d2515c426c in libbpf_add_mem tools/lib/bpf/btf.c:224:13
|
| previously allocated by thread T0 here:
| #0 0x55d25155b2e3 in malloc (tools/bpf/resolve_btfids/resolve_btfids+0xd02e3)
| #1 0x55d2515d6e7d in strset__new tools/lib/bpf/strset.c:58:20
While resolve_btfids could be refactored to avoid this call path, let's
instead fix this issue at the source in strset__add_str() and avoid
similar scenarios.
Let's check if set->strs_data was reallocated and whether 's' points to
an internal string within the old strset buffer. In such case, 's' is
reconstructed to point to the new buffer.
While already here, also fix strset__find_str() which suffers from the
same problem by factoring out the common operations into a new helper
function strset_str_append().
Siddharth Nayyar [Wed, 20 May 2026 09:40:44 +0000 (09:40 +0000)]
bpftool: Fix typo in struct_ops map FD generation for light skeleton
When generating light skeletons for BPF programs containing struct_ops
maps, bpftool incorrectly outputs a stray literal 't' instead of a tab
character for the map file descriptor member in the links structure.
This causes a compilation error when the generated light skeleton is
used.
Correct the format string by replacing 't' with '\t'.
parse_vma_segs() in tools/lib/bpf/usdt.c parses /proc/<pid>/maps
with two widthless scansets, "%s" into mode[16] and "%[^\n]"
into line[4096]. A VMA name in maps is not limited to that local
buffer; a deeply nested backing path can produce a maps record long
enough to overflow the stack buffer.
Bound both scansets to the declared buffer sizes ("%15s" for mode[16]
and "%4095[^\n]" for line[4096]) and drain any residue past line[4094]
with "%*[^\n]" before the trailing "\n". Without the drain, the residue
of an over-long record would stay in the stream and break the next
"%zx-%zx" parse, so the loop would exit early and silently skip later
maps records.
Also stop using sscanf(..., "%s") to peel the /proc/<pid>/root prefix
from lib_path. Parse the pid and prefix length with "%n", check for the
following slash, and copy the remainder with libbpf_strlcpy(). That
removes a second unbounded stack write and preserves paths containing
spaces.
Fixes: 74cc6311cec9 ("libbpf: Add USDT notes parsing and resolution logic") Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260522201353.1454653-1-michael.bommarito@gmail.com
Prathamesh Shete [Mon, 18 May 2026 10:14:19 +0000 (10:14 +0000)]
dt-bindings: tegra: pmc: Add Tegra238 compatible
The PMC found on Tegra238 is similar to the version in earlier chips but
some of the register offsets and bitfields differ, so add a specific
compatible string for this new variant.
net/sched/sch_netem.c a2f6ed7b4873 ("net/sched: netem: add per-impairment extended statistics") 9552b11e3eda ("net/sched: fix packet loop on netem when duplicate is on")
Adjacent changes:
drivers/dpll/zl3073x/core.c c1224569cef0 ("dpll: zl3073x: make frequency monitor a per-device attribute") 54e65df8cf18 ("dpll: zl3073x: report FFO as DPLL vs input reference offset")
net/iucv/af_iucv.c 347fdd4df85f ("af_iucv: convert to getsockopt_iter") 3589d20a666c ("net/iucv: fix locking in .getsockopt")
Thierry Reding [Mon, 3 Feb 2025 15:31:14 +0000 (16:31 +0100)]
usb: xhci: tegra: Explicitly specify PMC instance to use
Currently the kernel relies on a global variable to reference the PMC
context. Use an explicit lookup for the PMC and pass that to the public
PMC APIs.
Thierry Reding [Mon, 3 Feb 2025 15:30:24 +0000 (16:30 +0100)]
PCI: tegra: Explicitly specify PMC instance to use
Currently the kernel relies on a global variable to reference the PMC
context. Use an explicit lookup for the PMC and pass that to the public
PMC APIs.
Thierry Reding [Mon, 3 Feb 2025 15:29:35 +0000 (16:29 +0100)]
media: vde: Explicitly specify PMC instance to use
Currently the kernel relies on a global variable to reference the PMC
context. Use an explicit lookup for the PMC and pass that to the public
PMC APIs.
Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thierry Reding [Mon, 3 Feb 2025 15:28:38 +0000 (16:28 +0100)]
drm/tegra: Explicitly specify PMC instance to use
Currently the kernel relies on a global variable to reference the PMC
context. Use an explicit lookup for the PMC and pass that to the public
PMC APIs.
Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thierry Reding [Mon, 3 Feb 2025 15:27:02 +0000 (16:27 +0100)]
drm/nouveau: tegra: Explicitly specify PMC instance to use
Currently the kernel relies on a global variable to reference the PMC
context. Use an explicit lookup for the PMC and pass that to the public
PMC APIs.
Thierry Reding [Mon, 3 Feb 2025 15:25:29 +0000 (16:25 +0100)]
ata: ahci_tegra: Explicitly specify PMC instance to use
Currently the kernel relies on a global variable to reference the PMC
context. Use an explicit lookup for the PMC and pass that to the public
PMC APIs.
Acked-by: Damien Le Moal <dlemoal@kernel.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Linus Torvalds [Thu, 28 May 2026 20:45:10 +0000 (13:45 -0700)]
Merge tag 'acpi-7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support fixes from Rafael Wysocki:
"Fix three issues in the ACPI button driver: a possible crash due to a
button press after unloading the driver (introduced during the 6.15
development cycle), function keys breakage on Toshiba Tecra X40 due to
missing ACPI events (introduced during the 7.0 development cycle), and
a missing probe rollback path item that has not been added by mistake
during a recent update"
* tag 'acpi-7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: button: Add missing device class clearing on probe failures
ACPI: button: Enable wakeup GPEs for ACPI buttons at probe time
ACPI: button: Fix ACPI GPE handler leak during removal
Thierry Reding [Fri, 16 Jan 2026 19:18:36 +0000 (20:18 +0100)]
MAINTAINERS: Move Peter De Schrijver to CREDITS
Peter sadly passed away a while back. Paul did a much better job at
finding the right words to mourn this loss than I ever could, so I will
leave this link here:
Ivan Lipski [Wed, 27 May 2026 18:57:17 +0000 (14:57 -0400)]
drm/amd/display: Add a default case for dc_status_to_str
[Why&How]
If a parsed dc_status case is not covered by the dc_status_to_str, the
switch case is skipped, and the function returns
"Unexpected status error".
This causes build failures when new dc_status enums are introduced.
Changing the 'return "Unexpected status error"' into default resolves it.
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
Tweak the NEON intrinsics crc64 code written for arm64 so it can be
built for 32-bit ARM as well. The only workaround needed is to provide
alternatives for vmull_p64() and vmull_high_p64() on Clang, which only
defines those when building for the AArch64 or arm64ec ISA. Use the same
helpers for GCC too, to avoid doubling the size of the test/validation
matrix.
lib/crc: Turn NEON intrinsics crc64 implementation into common code
Move and rename the CRC64 NEON intrinsics implementation source file and
rename the function name to reflect that it is NEON code that can be
shared. This will be wired up for 32-bit ARM in a subsequent patch.
xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
Tweak the arm64 code so that the pure NEON intrinsics implementation of
XOR is shared between arm64 and ARM. While at it, rename the arm64
specific piece xor-eor3.c to reflect that only the version based on the
EOR3 instruction is kept there.
xor/arm: Replace vectorized implementation with arm64's intrinsics
Drop the XOR implementation generated by the vectorizer: this has always
been a bit of a hack, and now that arm64 has an intrinsics version that
works on ARM too, let's use that instead.
So copy the part of the arm64 code that can be shared (so not the EOR3
version). The arm64 code will be updated in a subsequent patch to share
this implementation.
Performance (QEMU mach-virt VM running on Synquacer [Cortex-A53 @ 1 GHz]
Add a header asm/neon-intrinsics.h similar to the one that arm64 has.
This makes it possible for NEON intrinsics code to be shared seamlessly
between ARM and arm64.
Linus Torvalds [Thu, 28 May 2026 20:13:48 +0000 (13:13 -0700)]
Merge tag 'net-7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Paolo Abeni:
"This is again significantly bigger than the same point into the
previous cycle, but at least smaller than last week.
I'm not aware of any pending regression for the current cycle.
Including fixes from netfilter.
Current release - regressions:
- netfilter: walk fib6_siblings under RCU
Previous releases - regressions:
- netlink: fix sending unassigned nsid after assigned one
- bridge: fix sleep in atomic context in netlink path
- eth: tun: free page on short-frame rejection in tun_xdp_one()
Previous releases - always broken:
- skbuff: fix missing zerocopy reference in pskb_carve helpers
- handshake: drain pending requests at net namespace exit
- ethtool:
- rss: avoid modifying the RSS context response
- module: avoid leaking a netdev ref on module flash errors
- coalesce: cap profile updates at NET_DIM_PARAMS_NUM_PROFILES
- netfilter: fix dst corruption in same register operation
- nfc: hci: fix out-of-bounds read in HCP header parsing
- ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()
- eth:
- vti: use ip6_tnl.net in vti6_changelink().
- vxlan: do not reuse cached ip_hdr() value after
skb_tunnel_check_pmtu()"
* tag 'net-7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (94 commits)
dpll: zl3073x: make frequency monitor a per-device attribute
dpll: zl3073x: use __dpll_device_change_ntf() and remove change_work
dpll: export __dpll_device_change_ntf() for use under dpll_lock
net/handshake: Drain pending requests at net namespace exit
net/handshake: Verify file-reference balance in submit paths
net/handshake: Close the submit-side sock_hold race
net/handshake: hand off the pinned file reference to accept_doit
net/handshake: Take a long-lived file reference at submit
net/handshake: Pass negative errno through handshake_complete()
nvme-tcp: store negative errno in queue->tls_err
net/handshake: Use spin_lock_bh for hn_lock
net: skbuff: fix missing zerocopy reference in pskb_carve helpers
net: hibmcge: move dma_rmb() after dma_sync_single_for_cpu() in RX path
net: hibmcge: disable Relaxed Ordering to fix RX packet corruption
selftests/tc-testing: Add netem test case exercising loops
selftests/tc-testing: Add mirred test cases exercising loops
net/sched: act_mirred: Fix return code in early mirred redirect error paths
net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow
net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop
net/sched: fix packet loop on netem when duplicate is on
...
Danilo Krummrich [Thu, 28 May 2026 18:04:24 +0000 (20:04 +0200)]
Merge remote-tracking branch 'drm/drm-next' into drm-rust-next
Backmerge to pull in commit 838d852da850 ("rust: allow
`clippy::collapsible_match` globally"), in order to get rid of spurious
warnings messing with developer tooling.
Linus Torvalds [Thu, 28 May 2026 19:36:39 +0000 (12:36 -0700)]
Merge tag 'gpio-fixes-for-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix interrupt handling in gpio-mxc
- fix scoped_guard() usage in gpio-adnp
- don't accept partial writes in gpio-virtuser debugfs interface as
they can't really work correctly
- fix resource leaks in gpio-rockchip
- fix locking issues in remove path in shared GPIO management
- undo the vote of a GPIO shared proxy virtual device on GPIO release
* tag 'gpio-fixes-for-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: rockchip: teardown bugs and resource leaks
gpio: rockchip: convert bank->clk to devm_clk_get_enabled()
gpio: virtuser: Fix uninitialized data bug in gpio_virtuser_direction_do_write()
gpio: shared: fix lockdep false positive by removing unneeded lock
gpio: shared: fix deadlock on shared proxy's parent removal
gpio: adnp: fix flow control regression caused by scoped_guard()
gpio: shared: undo the vote of the proxy on GPIO free
gpio: mxc: fix irq_high handling
Michael Riesch [Fri, 22 May 2026 21:23:09 +0000 (23:23 +0200)]
media: rockchip: rkcif: add support for rk3588 vicap mipi capture
The RK3588 Video Capture (VICAP) unit features a Digital Video Port (DVP)
and six MIPI CSI-2 capture interfaces. Add initial support for this variant
to the rkcif driver and enable the MIPI CSI-2 capture interfaces.
Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Michael Riesch [Fri, 22 May 2026 21:23:08 +0000 (23:23 +0200)]
media: dt-bindings: add rockchip rk3588 vicap
Add documentation for the Rockchip RK3588 Video Capture (VICAP) unit. To
that end, make the existing rockchip,rk3568-vicap documentation more
general and introduce variant specific constraints.
Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Add a section that describes the Rockchip RK3588 VICAP.
Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Linus Torvalds [Thu, 28 May 2026 18:45:41 +0000 (11:45 -0700)]
security/keys: fix missed RCU read section on lookup
Nicholas Carlini reports that the keyring code calls assoc_array_find()
in find_key_to_update() without holding the RCU read lock, while the
assoc_array_gc() code really is designed around removing the node from
the tree and then freeing it after an RCU grace-period.
The regular key handling doesn't see this because holding the keyring
semaphore hides any lifetime issues, but the persistent key handling
uses a different model.
Instead of extending the keyring locking, just do the simple RCU locking
that the assoc_array was designed for.
Reported-by: Nicholas Carlini <npc@anthropic.com> Cc: David Howells <dhowells@redhat.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Paul Moore <paul@paul-moore.com> Cc: James Morris James Morris <jmorris@namei.org> Cc: Serge E. Hallyn <serge@hallyn.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dinh Nguyen [Thu, 21 May 2026 02:54:57 +0000 (21:54 -0500)]
firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe
rsu_send_msg() can return -ETIMEDOUT when
wait_for_completion_interruptible_timeout() fires while the SMC call is still
pending. In stratix10_rsu_probe(), the error paths for COMMAND_RSU_DCMF_VERSION,
COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY and COMMAND_RSU_GET_SPT_TABLE
call stratix10_svc_free_channel() - which sets chan->scl to NULL - but then
fall through and queue the next request on the same channel. The next svc
kthread that runs will dereference pdata->chan->scl in its receive callback
path, triggering a NULL pointer dereference identical to the one fixed by
commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference
when RSU is disabled") for the COMMAND_RSU_STATUS path.
Apply the same cleanup pattern to the remaining failure paths: remove the
async client, free the channel, and return early so no further messages are
queued on a channel whose scl has been cleared.
While at it, clean up stratix10_rsu_probe() in two ways without changing
behavior:
- Drop redundant zero-initialization of fields already cleared by
devm_kzalloc(): client.receive_cb, status.* and spt0/1_address
(INVALID_SPT_ADDRESS is 0x0).
- Replace five identical 3-line error-cleanup blocks
(stratix10_svc_remove_async_client() + stratix10_svc_free_channel() +
return ret) with goto labels (remove_async_client, free_channel),
matching the standard kernel resource-unwinding pattern and making it
easier to extend the probe sequence without forgetting matching
cleanup.
Also move init_completion() next to mutex_init() so sync-primitive
initialization is grouped before anything that could trigger a
callback.
Fixes: 15847537b623 ("firmware: stratix10-rsu: Migrate RSU driver to use stratix10 asynchronous framework.") Cc: stable@kernel.org Assisted-by: Claude:claude-4.7-opus-high Cursor Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v2: Add a minor clean-up of the function stratix10_rsu_probe() to have a
centralize exit for all the rsu_send_async_msg() and rsu_send_msg().
firmware: stratix10-svc: Don't fail probe when async ops unsupported
When the ATF version is too old to support SIP SVC v3 asynchronous
operations (e.g. ATF 2.5), stratix10_svc_async_init() returns
-EOPNOTSUPP. The probe function currently treats any non-zero return
as fatal and aborts, logging:
stratix10-svc firmware:svc: Intel Service Layer Driver: ATF version \
is not compatible for async operation
stratix10-svc firmware:svc: probe with driver stratix10-svc failed \
with error -95
This prevents the SVC driver from loading entirely, causing all
dependent client drivers (hwmon, RSU, FCS) to also fail to probe even
though they can operate correctly via the synchronous V1 SMC path.
Fix this by treating -EOPNOTSUPP from stratix10_svc_async_init() as a
non-fatal degraded condition. The driver loads in sync-only mode and
logs:
stratix10-svc firmware:svc: Intel Service Layer Driver Initialized \
(sync-only mode)
Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian <muhammad.amirul.asyraf.mohamad.jamian@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
firmware: stratix10-svc: Return -EOPNOTSUPP when ATF async unsupported
Add a 'supported' flag to struct stratix10_async_ctrl to indicate
whether the secure firmware supports SIP SVC v3 asynchronous
communication. When the ATF version check in stratix10_svc_async_init()
fails, set supported=false and return -EOPNOTSUPP instead of -EINVAL.
This allows callers to distinguish between "async not supported by this
ATF version" (-EOPNOTSUPP) and "programming error / bad argument"
(-EINVAL), and take appropriate action (e.g. fall back to synchronous
V1 SMC path) rather than treating both as fatal.
Also update stratix10_svc_add_async_client() to return -EOPNOTSUPP
immediately when async is not supported, rather than -EINVAL from the
!actrl->initialized check, so client drivers receive a consistent and
meaningful error code.
This patch is a prerequisite for the following fix and must be applied
together with it to correctly restore functionality on old ATF versions.
Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Suggested-by: Anders Hedlund <anders.hedlund@windriver.com> Signed-off-by: Mahesh Rao <mahesh.rao@altera.com> Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian <muhammad.amirul.asyraf.mohamad.jamian@altera.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Chen Ni [Fri, 22 May 2026 01:57:34 +0000 (09:57 +0800)]
media: ti: j721e-csi2rx: Fix error handling for media_entity_remote_source_pad_unique()
The media_entity_remote_source_pad_unique() function returns an error
pointer on failure, not NULL. Fix the check to use IS_ERR() and return
PTR_ERR() to correctly handle allocation failures.
Fixes: 982135c0eac6 ("media: ti: j721e-csi2rx: add a subdev for the core device") Fixes: 3ed9c0a1fdba ("media: ti: j721e-csi2rx: add multistream support") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
media: ti: j721e-csi2rx: Minor cleanup of loop variables
Replace open-coded `i--; for (; i >= 0; i--)` patterns with the
idiomatic `while (i--)` in the error unwind paths of
csi_async_notifier_complete() and ti_csi2rx_probe().
Also scope loop variables directly in the for statement instead of
declaring them at the top of the function in ti_csi2rx_suspend(),
ti_csi2rx_resume() and ti_csi2rx_remove(). Change the type to
unsigned int in the first two to match csi->num_ctx.
Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Miguel Vadillo [Wed, 27 May 2026 17:05:30 +0000 (10:05 -0700)]
media: pci: intel: Add CVS support for IPU bridge driver
CVS is located between IPU device and sensors and is available in
existing commercial platforms from multiple OEMs. The connection
information between them in firmware is not enough to build a V4L2
connection graph. This patch parses the connection properties from the
SSDB buffer in DSDT and builds the connection using software nodes.
From the IPU bridge point of view, CVS is just like IVSC.
Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com> Tested-by: Mehdi Djait <mehdi.djait@linux.intel.com> # Dell XPS 13 9350 + IPU7 Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Add driver for Intel Computer Vision Sensing (CVS) devices found on
Intel Luna Lake (LNL), Panther Lake (PTL), and Arrow Lake (ARL)
platforms.
The CVS device acts as a V4L2 sub-device bridge that manages CSI-2
link ownership between the host (Linux) and firmware for camera
sensors. It provides:
- Query the device status via sysfs interface
- CSI-2 link ownership arbitration between host and CVS firmware
- MIPI CSI-2 configuration management
- Privacy LED control coordination
- Power management integration with runtime PM
The driver consists of two main components:
core.c: Core driver with probe, command transport, and power management
v4l2.c: V4L2 sub-device and media framework integration
Hardware Interface:
- I2C for command/control communication with device firmware
- GPIO signals for ownership handshaking (request/response)
- Optional reset and wake interrupt for full-capability variants
- Integration with Intel IPU via ipu_bridge
The driver supports two hardware capability levels:
- Light capability: Basic GPIO-based ownership (2 GPIOs)
- Full capability: Enhanced with reset control and wake IRQ (4 GPIOs)
Device-specific quirks are handled via a quirk table to accommodate
variations across different CVS implementations (Lattice, Synaptics).
In addition to I2C-based operation, the driver supports platform
device instantiation for systems where CVS is exposed without I2C
transport, falling back to GPIO-only ownership control.
The CVS driver integrates with the IPU bridge for automatic device
discovery via ACPI on supported platforms.
PCI device IDs for Intel IPU7 (0x645d, shared by MTL and LNL) and
IPU7.5 (0xb05d, shared by ARL and PTL) are included in the
driver-local icvs_pci_tbl lookup table, enabling CVS to locate these
IPU variants without modifying the shared ipu6-pci-table header.
A PM runtime device link is established between IPU (consumer) and CVS
(supplier) so that the PM framework automatically resumes CVS before
IPU begins streaming, triggering cvs_runtime_resume() to claim CSI-2
link ownership. Ownership is released via cvs_runtime_suspend() after
the autosuspend delay.
Signed-off-by: Miguel Vadillo <miguel.vadillo@intel.com> Tested-by: Mehdi Djait <mehdi.djait@linux.intel.com> # Dell XPS 13 9350 + IPU7 Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Mark Brown [Thu, 28 May 2026 18:12:52 +0000 (19:12 +0100)]
ASoC: Intel: catpt: Error handling and debug improvements
Cezary Rojewski <cezary.rojewski@intel.com> says:
Outcome of a long debug to solve one, long-standing bug ocurring very
rarely on Haswell/Broadwell machines during the boot procedure of the
AudioDSP firmware. Clever/unfortunate user can increase the
reproduction rare to 100%.
The bug: an exception occurring early during FW boot (firmware side, not
the software one) leaves the firmware hanging and the existing software
code is incappable of recognizing such problem. The only solution a
user currently has is: rmmod and then modprobe the driver.
Recently, together with Krzysztof from the firmware team decided to take
it up and clear the dashboard.
The exception handling takes just a few lines of code (all part of the
first patch), everything else that this patchset is composed of improves
the debugability and logging. If anything similar pops up, the
developers can see what's going on.
Cezary Rojewski [Thu, 28 May 2026 08:34:42 +0000 (10:34 +0200)]
ASoC: Intel: catpt: Complete coredump handling
An exception may occur during the firmware booting procedure. In such
case the firmware sends COREDUMP_REQUESTS and expects the driver to dump
relevant information and finish with the COREDUMP_RELEASE write.
To distinguish such situation from generic timeout, always signal
fw_ready completion when a coredump request is received and translate
it to -EREMOTEIO in catpt_boot_firmware().
The "FW READY" print makes the success clearly visible even when
the event-traces are not enabled.
Since commit fe49fd940e22 ("KVM: arm64: Move VTCR_EL2 into struct s2_mmu"),
@arch is no longer required to obtain the per-kvm_s2_mmu vtcr and can be
removed from __load_stage2().
Timur Tabi [Thu, 30 Apr 2026 22:38:37 +0000 (17:38 -0500)]
drm/nouveau/gsp: require GSP-RM for GA100 support
Nouveau supports Turing and Ampere GPUs with or without GSP-RM.
Support without GSP-RM is mostly academic, since GSP-RM is
needed to run the GPU at full clocks. It is also the default
mode for these GPUs.
GA100 is a special case, however. The current code has some support
for running GA100 without GSP-RM, but several features are missing.
More importantly, some required firmware images like ucode_ahesasc.bin
are not available and would need to be provided by Nvidia.
To prevent Nouveau from even trying to boot on GA100 without GSP-RM,
remove the non-GSP fallback option in the ga100_gsps[] array.
Timur Tabi [Thu, 30 Apr 2026 22:38:36 +0000 (17:38 -0500)]
drm/nouveau/bios: skip the IFR header if present
The GPU's ROM may begin with an Init-from-ROM (IFR) header that precedes
the PCI Expansion ROM images (VBIOS). When present, the PROM shadow
method must parse this header to determine the offset where the PCI ROM
images actually begin, and adjust all subsequent reads accordingly.
On most GPUs this is not needed because either the PRAMIN shadow method
(which reads from VRAM via the display engine) succeeds first, or the IFR
microcode has already applied the ROM offset so that PROM reads
transparently skip the header. However, on GA100 neither of these
applies: GA100 has no display engine (so PRAMIN is unavailable), and the
IFR offset is not applied to PROM reads on this GPU.
Timur Tabi [Thu, 30 Apr 2026 22:38:35 +0000 (17:38 -0500)]
drm/nouveau/bios: specify correct display fuse register for Ampere and Ada
The NV_FUSE_STATUS_OPT_DISPLAY register is used to determine whether
the GPU has display hardware. The current code that normally reads
this register is instead hard-coded to check for GA100 vs later GPUs.
Since this function is called only on pre-Hopper GPUs, and this
if-statement applies only to GA100 and later, the check works
because GA100 is the only non-display Ampere and Ada GPU.
However, there actually is a register that can be read, so we should
use it.
Fixes: a34632482f1e ("drm/nouveau/bios/ga10[024]: initial support") Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20260430223838.2530778-8-ttabi@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Timur Tabi [Thu, 30 Apr 2026 22:38:34 +0000 (17:38 -0500)]
drm/nouveau: GA100 has an FRTS region size of zero
When booting with GSP-RM, the FRTS data region normally needs to be
allocated. However, on GA100, this region is not used and so its
size needs to be set to zero.
The truth is that GA100 is just special, and the simplest way to
determine the proper FRTS data region size is to check for this
GPU specifically.
Timur Tabi [Thu, 30 Apr 2026 22:38:32 +0000 (17:38 -0500)]
drm/nouveau/gsp: read MMU_LOCK to fix WPR placement on GA100
On GA100, the row remapper hardware reserves a small amount of DRAM at
the end of framebuffer for spare rows used to repair memory errors at
runtime. When an uncorrectable ECC error is detected in a DRAM row,
the row remapper redirects accesses to a spare row, transparently
repairing the fault.
The LOCAL_MEMORY_RANGE register (0x100ce0) reports the GPU's FB address
range, but its encoding rounds to 1GB boundaries. On GA100, VBIOS
originally rounded this value down, which could lose up to ~1GB of
usable FB. As a workaround, newer VBIOS instead rounds up to the next
1GB boundary and programs MMU_LOCK (registers 0x1fa82c/0x1fa830) to
mark the gap between the actual usable FB and the rounded-up range as
reserved.
OpenRM's kgspCalculateFbLayout_TU102() handles this by reading the
MMU_LOCK registers and computing the WPR top boundary as:
Without this, the WPR region is placed at the top of LOCAL_MEMORY_RANGE,
which overlaps the reserved region. The booter firmware detects this
and rejects the WPR layout.
Add ga100_gsp_mmu_lock_lo() to read the MMU_LOCK range and clamp
gsp->fb.bios.addr accordingly, mirroring OpenRM's behavior.
This is a GA100-only issue. GA102 and later add the
NV_USABLE_FB_SIZE_IN_MB register which reports the correct usable FB
size directly, eliminating the need for the MMU_LOCK workaround.
The VGA workspace offset is one input into this calculation, not the
direct source of gspFwWprEnd. vbiosReservedOffset is the effective
top boundary for WPR2 placement, and it may be lower than the VGA
workspace when VBIOS has locked a region via MMU_LOCK.
In Nouveau, gsp->fb.bios.addr is the equivalent of vbiosReservedOffset,
while gsp->fb.bios.vga_workspace.addr corresponds to the raw VGA
workspace location. The original code assigned vga_workspace.addr to
gspFwWprEnd, which produced the correct result only because bios.addr
was always set equal to vga_workspace.addr and never adjusted.
Use gsp->fb.bios.addr for gspFwWprEnd to correctly mirror OpenRM's
layout logic, so that future adjustments to bios.addr (such as clamping
it to an MMU_LOCK boundary) are properly reflected in the WPR metadata
passed to the booter.
Timur Tabi [Thu, 30 Apr 2026 22:38:30 +0000 (17:38 -0500)]
drm/nouveau/gsp: add SEC2 to GA100 chip table
The booter-load and booter-unload firmware run on the SEC2 falcon.
During tu102_gsp_oneinit(), the booter constructor needs device->sec2
to access the SEC2 falcon.
Without the .sec2 entry, device->sec2 is NULL and this dereference
crashes during GSP-RM boot.
scripts: modpost: detect and report truncated buf_printf() output
buf_printf() uses a fixed-size stack buffer. vsnprintf() returns the
number of bytes that *would* have been written to that buffer, which can
be larger than the size of said buffer if the formatted string is too
long.
The problem is that whenever this happens buf_printf() currently passes
this length, unchecked, to buf_write(), which silently reads past the
stack buffer and copies invalid data into the output buffer.
Fix this by detecting vsnprintf() failures and truncations before
appending to the output buffer, and report a fatal error instead of
producing corrupt symbol names.
Yafang Shao [Tue, 26 May 2026 06:27:32 +0000 (14:27 +0800)]
kbuild: rpm-pkg: append %{?dist} macro to Release tag
Add support for the %{?dist} macro in the kernel.spec file. This enables
building and releasing kernel RPMs with a custom distribution suffix
(e.g., via rpmbuild's --define option) to better match production
environment tracking.
Hongling Zeng [Thu, 28 May 2026 06:24:50 +0000 (14:24 +0800)]
nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)
Replace WARN_ON(IS_ERR_OR_NULL()) with WARN_ON(IS_ERR()) in various
GSP-RM files. The underlying functions return error pointers, so
checking for NULL is redundant.
This affects:
- r535_bar_bar2_update_pde() in bar.c
Hongling Zeng [Thu, 28 May 2026 06:24:49 +0000 (14:24 +0800)]
nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation
Clean up IS_ERR_OR_NULL() checks in the core RPC and alloc
implementation files. The underlying functions return error pointers,
so IS_ERR() is sufficient.
This affects:
- r535_gsp_rpc_rm_free() in alloc.c
- r535_gsp_rpc_rm_alloc_push() in alloc.c
- r535_gsp_msgq_recv() in rpc.c
projects / thirdparty / kernel / stable.git / log
