Anna Schumaker [Tue, 30 Jun 2026 19:39:45 +0000 (15:39 -0400)]
NFS: Decrement refcounts if allocating nfs_free_stateid_data fails
I noticed that we were immediately exiting this function if the
allocation fails, leaving the client and server object refcounts bumped.
Fix this by creating a common exit point to clean up dangling
references.
Fixes: 576acc259146 ("nfs4: take a reference on the nfs_client when running FREE_STATEID") Signed-off-by: Anna Schumaker <anna.schumaker@hammerspace.com>
Anna Schumaker [Tue, 30 Jun 2026 18:31:00 +0000 (14:31 -0400)]
NFS: Pin the 'struct nfs_server' during a FREE_STATEID call
Dan Aloni reports that he was able to hit a use-after-free bug if a
FREE_STATEID operation gets delayed for whatever reason. Fix this by
bumping the refcount of the 'struct nfs_server' object for the duration
of the FREE_STATEID so it doesn't get cleaned up from underneath us
while operations are still in flight.
Reported-by: Dan Aloni <dan.aloni@vastdata.com> Fixes: 7c1d5fae4a87 ("NFSv4: Convert nfs41_free_stateid to use an asynchronous RPC call") Tested-by: Dan Aloni <dan.aloni@vastdata.com> Signed-off-by: Anna Schumaker <anna.schumaker@hammerspace.com>
ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup
In max98095_probe(), the -EPROBE_DEFER check after devm_clk_get() is
broken due to a missing IS_ERR() guard.
The code intends to return -EPROBE_DEFER only when the clock lookup
fails with that specific error. However, without IS_ERR() the check:
if (PTR_ERR(max98095->mclk) == -EPROBE_DEFER)
is called unconditionally, including when devm_clk_get() succeeds and
returns a valid pointer. Calling PTR_ERR() on a valid pointer
reinterprets its address as a signed long; the result is arbitrary
and is almost never equal to -EPROBE_DEFER, so the check silently
does nothing in the success case. When devm_clk_get() fails with
any error other than -EPROBE_DEFER the check is also skipped, leaving
max98095->mclk holding an error pointer with no indication to the caller.
This means a deferred probe will never actually be triggered for this
device, and any non-EPROBE_DEFER clock error is silently swallowed with
the error pointer left in the mclk field.
Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call,
matching the pattern already used in the sibling max98088 and wm8960
drivers.
do_boot_mode() copies the firmware payload, excluding its four-byte prefix,
into a fixed 15.5 KiB staging buffer. check_fw_sanity() already proves that
the image contains its seven-byte header and validates the declared image
length and checksum, but it does not impose this boot-mode destination
limit.
Reject images whose payload does not fit before allocating and filling the
staging buffer.
Fixes: d12b219a228e ("edgeport-ti: use request_firmware()") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Johan Hovold <johan@kernel.org>
The OCC poll response parser walks a counted list of sensor data blocks.
It used the static backing-array capacity as the parse boundary, but a
transport response makes only data_length bytes current and valid. A
truncated response can therefore make the parser consume a block header or
block extent outside the current response.
Use data_length as the parent boundary, prove the fixed poll header and
each current block header before reading them, and prove the complete block
before advancing. Keep parsed sensor metadata local until the complete
response has passed validation, then publish it. Propagate
malformed-response errors before publishing the OCC as active.
Marco Baffo [Mon, 8 Jun 2026 14:06:42 +0000 (16:06 +0200)]
ovpn: use monotonic clock for peer keepalive timeouts
Replace ktime_get_real_seconds() with the monotonic
ktime_get_boottime_seconds() to ensure the keepalive mechanism is robust
against system clock modifications.
Right now, the driver uses ktime_get_real_seconds() to track peer
timeouts, relying on the system wall-clock.
An administrative time adjustment or an NTP sync that steps the clock
forward can cause `now' to instantly exceed `last_recv + timeout'.
When this occurs, the driver artificially expires healthy peers.
Depending on the OpenVPN user-space configuration, this triggers a
premature tunnel restart (if --keepalive or --ping-restart is used) or
a complete disconnection of the client (if --ping-exit is used).
Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Signed-off-by: Marco Baffo <marco@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
mxuport_probe() reads version bytes at fixed offsets after
request_firmware() succeeds. Firmware loading success does not prove that
the blob reaches the highest version offset.
Reject short firmware images before reading the version bytes. This is
source-level parser hardening; no affected device or crash was observed.
drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM
The drm gpuvm code doesn't protect find operation against map operation,
and the driver needs to ensure a map operation shouldn't happen when a
find operation is in progress.
In some cases a find operation will be in progress when doing map/unmap
operations, and the find operation will do a NULL pointer dereference.
An example of the stack trace of such NULL dereference is shown below:
```
Unable to handle kernel access to user memory without uaccess routines at
virtual address 0000000000000010
As all occurences of drm_gpuva_find*() are already guarded by
vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent
disturbing any find operation. This fixes the NULL deference problem in
drm_gpuva_find*().
Cc: stable@vger.kernel.org Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260714073641.1935075-1-zhengxingda@iscas.ac.cn Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
Marco Baffo [Mon, 8 Jun 2026 14:04:46 +0000 (16:04 +0200)]
ovpn: fix use after free in unlock_ovpn()
unlock_ovpn() iterates over the release_list using llist_for_each_entry()
and drops the peer reference inside the loop body via ovpn_peer_put().
If this drops the last reference, the peer is eventually freed. However,
llist_for_each_entry() reads peer->release_entry.next in the loop advance
expression, which runs after the body. By that time the peer may have
already been freed, resulting in a use after free when advancing to the
next list entry.
Fix this by using llist_for_each_entry_safe(), which caches the next
pointer before executing the loop body.
Fixes: 80747caef33d ("ovpn: introduce the ovpn_peer object") Signed-off-by: Marco Baffo <marco@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
longlong yan [Wed, 3 Jun 2026 07:27:41 +0000 (15:27 +0800)]
selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote()
The ovpn_parse_remote() function has two memory management issues:
1. When both 'host' and 'vpnip' are non-NULL, the first getaddrinfo()
allocation is leaked because 'result' is overwritten by the second
getaddrinfo() call without freeing the first allocation.
2. When both 'host' and 'vpnip' are NULL, 'result' is an uninitialized
stack variable passed to freeaddrinfo(), which is undefined behavior.
Fix by initializing 'result' to NULL and calling freeaddrinfo() after
the first getaddrinfo() result is consumed.
Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module") Signed-off-by: longlong yan <yanlonglong@kylinos.cn> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Shuvam Pandey [Sat, 23 May 2026 14:53:27 +0000 (20:38 +0545)]
ovpn: hold peer before scheduling keepalive work
ovpn_peer_keepalive_send() passes its peer reference to
ovpn_xmit_special(), which ultimately drops it. The keepalive scheduler
currently queues the work first and takes the reference only after
schedule_work() reports that the work was queued.
Once schedule_work() queues the item, another CPU may run the worker
before the caller gets to ovpn_peer_hold(). In that case the worker can
consume a reference that was not acquired for it, corrupting the peer
lifetime accounting.
Take the peer reference before queueing the work and drop it again when
the work was already pending.
Pavitra Jha [Sat, 23 May 2026 09:02:43 +0000 (05:02 -0400)]
ovpn: fix peer refcount leak in TCP error paths
When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&peer->tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.
Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point.
Fixes: a6a5e87b3ee4 ("ovpn: avoid sleep in atomic context in TCP RX error path") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Qing Ming [Sat, 23 May 2026 08:15:43 +0000 (16:15 +0800)]
ovpn: avoid putting unrelated P2P peer on socket release
ovpn_peer_release_p2p() is called when an OVPN UDP socket is being
destroyed. It checks the currently published P2P peer and releases it only
if that peer still uses the socket being destroyed.
A peer replacement can publish a new peer before the old UDP socket is
destroyed. When the old socket destruction path runs afterwards,
ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the
new peer uses a different socket, the function takes the socket mismatch
branch.
That branch still calls ovpn_peer_put(peer). At this point, however, peer
is the currently published replacement peer, not the peer associated with
the socket being destroyed. Dropping its reference can free it while
ovpn->peer still points to it, leading to later use-after-free accesses
from the peer and socket cleanup paths.
KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer
object. In the reproducer, the object is allocated from ovpn_peer_new() via
ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU
callback processing. Observed access sites include ovpn_peer_remove(),
ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn().
Fix this by returning from the socket mismatch branch without putting the
peer.
Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Qing Ming <a0yami@mailbox.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
phy: rockchip: naneng-combphy: Always configure SSC spread direction
Commit 0b31f297557f ("phy: rockchip: naneng-combphy: Consolidate SSC
configuration") moved the SSC spread spectrum direction setup into the
new rk_combphy_common_cfg_ssc() helper. That helper returns early when
the 'rockchip,enable-ssc' property is absent, whereas the equivalent
RK3568_PHYREG32 direction writes previously ran unconditionally in the
per-type switch statements, independent of whether SSC modulation was
actually enabled.
As no in-tree board sets 'rockchip,enable-ssc', this changed the behavior
at least for USB3 on RK3576, which now fails to bring up the link.
USB 2.0 still enumerates, but USB 3.0 does not, and the SuperSpeed root
port floods the log every second with:
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
This was observed on two different RK3576 devices with a CoreChips SL6341
USB 2.0/3.0 hub connected to the USB DRD controller running in host mode.
Perform the SSC direction writes for PCIe/USB3 (and SATA) before the
enable_ssc check so that they always run, as they did before the
consolidation.
phy: qcom: m31-eusb2: Fix return value of init call
The init call currently returns success irrespective of any failures
during repeater init or clock enablement. Return appropriate error value
in the init call failure path.
drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD backlight
Turns out some panels allow only AUX based backlight
by just setting the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
not setting the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP.
If we make DP_EDP_BACKLIGHT_AUX_ENABLE_CAP a necessity for AUX
based DPCD backlight these panels loose the ability to manipulate
backlight via AUX, especially ones with no PWM controller.
Remove this check from function so that panels who do not advertise
DP_EDP_BACKLIGHT_AUX_ENABLE_CAP but advertise
DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP are able to manipulate
backlight again.
Fixes: ed8be780bdbc ("drm/i915/backlight: Fix VESA backlight possible check condition") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16507 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260716030959.436430-1-suraj.kandpal@intel.com
(cherry picked from commit 7d594b24c915afb4b0c5fb8875403253daef5b24) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
ALSA: timer: drain a slave's callback before its master detaches it
snd_timer_close_locked() drains the closing instance's own in-flight
callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a
master instance is closed, remove_slave_links() clears each slave's
->timer; the slave's own close then reads timer == NULL and takes the
branch that skips the drain entirely (snd_timer_stop_slave() also no-ops
on a NULL timer). So a slave whose callback is still running when the
master is closed is freed underneath the live callback, leading to
use-after-free.
Drain the slaves too before remove_slave_links() severs them.
snd_timer_stop() has already taken this instance off the active list, so
no new slave callback can be queued. Take the slaves off the ack list so
a pending one can't fire either, then wait for any that is already in
flight.
ALSA: timer: don't re-enter an instance callback that is still running
The userspace-driven timer (utimer) TRIGGER ioctl calls
snd_timer_interrupt() directly with no serialization, so two threads
triggering the same utimer can run snd_timer_interrupt() on one
snd_timer concurrently.
snd_timer_process_callbacks() drops timer->lock around each instance
callback and marks the in-flight callback with the single
SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that
bit to drain an in-flight callback before freeing the instance. The bit
cannot represent two concurrent callbacks: when a second interrupt
re-queues an instance whose callback is still running, both run at once,
the first to finish clears the bit, and the close-path drain then frees
the instance (and its callback_data) while the other callback is still
live - a use-after-free reachable by any user able to open
/dev/snd/timer, both via a user timer instance and via a sequencer queue
timer bound to the utimer.
snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so
a concurrent interrupt already observes it under the lock. Skip
re-queuing an instance (and its slaves) to the ack/sack list while its
callback is in flight; the accumulated pticks are delivered on the next
tick, so no event is lost.
Jay Vadayath [Sat, 18 Jul 2026 00:21:22 +0000 (17:21 -0700)]
smb: client: bound dirent name against end of SMB response in cifs_filldir
cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST /
FIND_NEXT response using a length (de.namelen) supplied by the server.
The kmalloc'd SMB response buffer is bounded, but nothing checks that
de.name + de.namelen still lies inside that buffer before the eventual
filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes.
A hostile SMB1 server that returns an oversized FileNameLength in a
directory entry therefore causes memchr() to read past the end of the
response slab buffer. Reachable from any user who can list a directory
on a CIFS mount served by an attacker-controlled server (getdents64()
on the mounted directory):
BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80
Read of size 1 at addr ffff88800e0640cc by task poc/115
Call Trace:
dump_stack_lvl+0x64/0x80
print_report+0xce/0x620
kasan_report+0xec/0x120
memchr+0x71/0x80
filldir64+0x4c/0x6a0
cifs_filldir.constprop.0+0x9bb/0x1e00
cifs_readdir+0x2101/0x3380
iterate_dir+0x19c/0x520
__x64_sys_getdents64+0x126/0x210
do_syscall_64+0x107/0x5a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Pass the end-of-response pointer down to cifs_filldir() and reject
entries whose name would extend past that boundary.
This bug was discovered by Artiphishell's vTriage pipeline, which
generated a userspace reproducer (an emulated hostile SMB1 server plus
a getdents64() client) that reliably triggers the KASAN report on an
unpatched kernel. The fix below was drafted with the Claude coding
assistant; a userspace reproducer is available on request.
Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Jay Vadayath <jay@artiphishell.com> Signed-off-by: Steve French <stfrench@microsoft.com>
parse_dfs_referrals() validates that the response contains the fixed
referral entry array and, on for-next, the per-referral string offsets.
However, the response also contains a PathConsumed value that is later
used for DFS path parsing.
If a malformed response provides a PathConsumed value larger than the
search name, later DFS parsing can advance beyond the end of the path.
Validate PathConsumed against the search name length before storing it in
the parsed referral.
Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: Steve French <stfrench@microsoft.com>
When two commands enter aie2_sched_job_timedout() concurrently, both
check the timeout detection state. The first scheduler thread observes
tdr_status as SIGNALED and updates it to WAIT. The second thread then
observes the updated state instead of the original SIGNALED state, which
may cause the command timeout to be handled incorrectly.
Replace tdr_status with last_signal_ts, which records the timestamp of
the last driver signal. Timeout detection now only reads
last_signal_ts and never modifies it, allowing multiple serialized
detect() calls under dev_lock to evaluate the same signal timestamp
independently. If there is not any new job scheduled or completed
within tdr_timeout_ms, the command will timeout.
Fixes: 9022f010977f ("accel/amdxdna: Check for device hang on job timeout") Signed-off-by: Wendy Liang <wendy.liang@amd.com> Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260718083409.1825940-1-lizhi.hou@amd.com
m68k: coldfire: fix breakage of missed IO access update
Fix the last remaining breakage caused by missing a SoC IO access
update. Commit e1f3a00670d1 ("m68k: coldfire: use ColdFire specifc
IO access in SoC code") missed this read16() call which should be
mcf_read16().
Fixes: e1f3a00670d1 ("m68k: coldfire: use ColdFire specifc IO access in SoC code") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607180731.U4tiwFcQ-lkp@intel.com/ Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Mark Brown [Sun, 19 Jul 2026 21:25:13 +0000 (22:25 +0100)]
ASoC: fsl: fix m2m_init error path cleanup in fsl_asrc and fsl_easrc
Shengjiu Wang <shengjiu.wang@nxp.com> says:
Both fsl_asrc_probe() and fsl_easrc_probe() call fsl_asrc_m2m_init()
near the end of their probe functions. On failure, the original code
did a bare return ret, bypassing the existing error labels that call
pm_runtime_disable(). This leaves runtime PM enabled and the device
in an inconsistent state after a failed probe.
Fix both drivers by replacing the bare return with a goto to the
appropriate cleanup label (err_pm_get_sync for fsl_asrc and
err_pm_disable for fsl_easrc), ensuring pm_runtime_disable() is
always called on the probe error path.
Shengjiu Wang [Wed, 15 Jul 2026 02:47:58 +0000 (10:47 +0800)]
ASoC: fsl_easrc: fix m2m_init error path to use goto instead of bare return
When fsl_asrc_m2m_init() fails in fsl_easrc_probe(), the code did a
bare return ret, bypassing pm_runtime_disable() in err_pm_disable.
Use goto err_pm_disable to ensure proper cleanup on failure.
Shengjiu Wang [Wed, 15 Jul 2026 02:47:57 +0000 (10:47 +0800)]
ASoC: fsl_asrc: fix m2m_init error path to use goto instead of bare return
When fsl_asrc_m2m_init() fails in fsl_asrc_probe(), the code did a
bare return ret, bypassing pm_runtime_disable() in err_pm_get_sync.
Use goto err_pm_get_sync to ensure proper cleanup on failure.
Zhengyu He [Wed, 15 Jul 2026 12:52:15 +0000 (20:52 +0800)]
spi: spacemit: Correct TX FIFO slot calculation
In k1_spi_write, the count variable is intended to represent the number
of slots available for writing into the TX FIFO.
The current implementation uses FIELD_GET(SSP_STATUS_TFL, val) in an
attempt to determine this count, but this register field returns the
number of occupied slots, not the available space. The previous
implementation attempted to handle this via a ternary operator (? :
K1_SPI_FIFO_SIZE), which incorrectly assumed that the hardware returned
0 when the FIFO was empty (meaning all slots were available), leading to
incorrect accounting of the buffer space.
Fix this by calculating the free slots: count = K1_SPI_FIFO_SIZE -
FIELD_GET(SSP_STATUS_TFL, val);
The associated comment has been updated to reflect the logic change: The
old comment reflected an incorrect assumption about the hardware
behavior, which was the root cause of the previous buggy logic.
This patch accurately and concisely describes the purpose of the new
calculation.
Mark Brown [Sun, 19 Jul 2026 21:06:01 +0000 (22:06 +0100)]
ASoC: tas2562: Volume setting fixes
Mark Brown <broonie@kernel.org> says:
While reviewing another fix for the tas2562 volume control I noticed a
few issues with the put() operation, this series fixes them.
It's also a bit weird that the volume control is defined with twice as
many values as can actually be set, probably the best fix there is to
regnerate the table of volume values with the intermediate values.
Mark Brown [Wed, 15 Jul 2026 20:18:11 +0000 (21:18 +0100)]
ASoC: tas2562: Fix default digital volume
The tas2562 digital volume is spread over four registers and is implemented
as lookups into a table so the driver stores the value for the userspace
control in the driver data. This defaults to 0 due to kzalloc() but the
register default is 0x40400000 which maps onto something a bit over the
largest value defined in the lookup table. While it's not an exact match
update the default to the largest value, avoiding user surprise due to a
sudden change on first write.
Mark Brown [Wed, 15 Jul 2026 20:18:10 +0000 (21:18 +0100)]
ASoC: tas2562: Fix event generation for volume control
ALSA put() operations should return 0 for noop updates and 1 if the
value of the control changed, this is used by the ALSA core to generate
events to userspace. tas2562_volume_control_put() does not implement
this, it just writes whatever value userspace wrote to the device and
returns 0 regardless of what the previous value was. Fix this by
suppressing writes if the value is unchanged and returning 1 if the
writes succeed.
Mark Brown [Wed, 15 Jul 2026 20:18:09 +0000 (21:18 +0100)]
ASoC: tas2562: Validate values for volume writes
tas2562_volume_control_put() does not do any validation of the control
value written by userspace, it uses it to look up a value in a fixed
size array which can easily be overflowed and then writes whatever value
it gets back to the device. Add validation that we are loading a value
we have in the array.
Mark Brown [Sun, 19 Jul 2026 21:00:13 +0000 (22:00 +0100)]
ASoC: tas2562: fix Digital Volume Control
Haidar Lee <haidar.lee@adlinktech.com> says:
The 'Digital Volume Control' added in v5.7 has never worked correctly:
the driver writes the 32-bit DVC coefficient LSB first, but the device
latches the whole coefficient on the write to the last byte (DVC_CFG4),
so every volume change applies a mix of the previous coefficient's
upper bytes and the new LSB. Depending on the sequence of values this
mutes the output entirely or plays at full volume regardless of the
requested level.
Debugged on a TAS2562 (ADLINK OSM-520 / MT8189): traced the I2C writes
with ftrace to confirm the driver writes the intended bytes, then
reproduced both behaviours by writing the same coefficients manually in
each byte order. Patch 1 fixes the write order; patch 2 fixes two wrong
entries in the volume lookup table found while debugging this.
Haidar Lee [Wed, 15 Jul 2026 06:04:41 +0000 (14:04 +0800)]
ASoC: tas2562: fix broken entries in the volume lookup table
The float_vol_db_lookup table is supposed to hold
round(10^(dB/20) * 2^30) for every 2 dB step from -110 dB to 0 dB,
which is 56 entries, but it only has 55: the -90 dB entry duplicates
the -92 dB value (0x0000695b) and the -20 dB entry (0x06666666) is
missing altogether. As a result every step between -90 dB and -22 dB
is off by 2 dB, and the control's maximum raw value of 110 indexes one
element past the end of the array.
Replace the duplicated -90 dB entry with the correct value 0x000084a3
and add the missing -20 dB entry, bringing the table to the full 56
entries so index 55 (raw value 110, 0 dB) is in range again.
Haidar Lee [Wed, 15 Jul 2026 06:04:40 +0000 (14:04 +0800)]
ASoC: tas2562: fix DVC coefficient write order
The TAS2562 applies the 32-bit digital volume coefficient to the
playback path when the last byte, DVC_CFG4 (book 0 page 2 reg 0x0F), is
written. tas2562_volume_control_put() wrote DVC_CFG4 first and DVC_CFG1
(the MSB) last, so every volume change latched a value made of the
previous coefficient's upper three bytes combined with the new LSB; the
remaining bytes only took effect on the next volume change.
In practice the control was unusable: the first setting after power-on
always played at roughly 0 dB no matter what value was requested (the
chip's default upper bytes were still latched), and most subsequent
changes muted the output entirely or produced a distorted, over-unity
gain.
Verified on a TAS2562 (ADLINK OSM-520 / MT8189 board) by tracing the
I2C writes with ftrace and by writing the same coefficients manually in
both byte orders: written MSB-first the register block behaves exactly
as the driver expects, LSB-first reproduces the broken behaviour.
Write the bytes MSB first with DVC_CFG4 last so the complete new
coefficient is latched atomically.
Merge tag 'riscv-for-linus-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- Call flush_cache_vmap() after populating new vmemmap pages, on all
architectures. This avoids spurious faults on RISC-V
microarchitectures that cache PTEs marked as non-present
- Disable LTO for the vDSO to prevent the compiler from eliding
functions that are used, but which don't appear to be
- Fix an issue with libgcc's unwinder and signal handlers by dropping
an unnecessary CFI landing pad instruction in __vdso_rt_sigreturn
(similar to what was done on ARM64)
- Avoid reading uninitialized memory under certain conditions in
hwprobe_get_cpus()
- Save some memory and I$ when CONFIG_DYNAMIC_FTRACE=n by avoiding our
four-byte function alignment requirement in that case
- Avoid clang warnings about null-pointer arithmetic in the I/O-port
accessor macros (inb, outb, etc.) by ifdeffing them out when
!CONFIG_HAS_IOPORT
- Make the build of the lazy TLB flushing code in the vmalloc path
depend on CONFIG_64BIT and CONFIG_MMU (since those platforms are the
only ones that use it)
* tag 'riscv-for-linus-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()
arch/riscv: vdso: remove CFI landing pad from rt_sigreturn
riscv: vdso: Do not use LTO for the vDSO
riscv: io: avoid null-pointer arithmetic in PIO helpers
riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE
mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap
riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMU
ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum650 Wireless
JBL Quantum650 Wireless (0ecb:2125) requires the same workaround that
was used for JBL Quantum610 and Quantum810 for limiting the sample rate.
Without it, the capture (microphone) stream fails to work. Setting the
QUIRK_FLAG_FIXED_RATE flag, as done for the sibling models, makes both
playback and capture work correctly.
Merge tag 'block-7.2-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- Fixes for the dio bounce buffer helpers: correct the alignment of
bounced dio read bios to avoid a double unpin, handle huge zero
folios in bio_free_folios(), and don't warn on the larger-order folio
attempts in the greedy allocation path.
- Try a slab allocation in bio_alloc_bioset() before falling back to
the mempool, restoring the previous behavior for non-sleeping
allocations from a cache-enabled bioset.
- Serialize elevator changes for the same queue using the writer lock.
- Fix a race in blk_time_get_ns() where a task preempted between
setting PF_BLOCK_TS and the cached-timestamp reload could return 0.
- blk-cgroup fix for leaks and the online flag on a radix_tree_insert()
failure in blkg_create().
- Free the copied pages when blk_rq_map_kern() fails after
blk_rq_append_bio() rejects the bio.
- Remove manually added partitions on loop device detach, fixing dead
partition devices left behind and a subsequent LOOP_CONFIGURE -EBUSY
- Bound the AIX partition lvd scan to the sector that was actually
read.
- Show the block operation in error injection rules (Jackie)
* tag 'block-7.2-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
block: fix aligning of bounced dio read bios
block: handle huge zero folios in bio_free_folios
block: try slab allocation in bio_alloc_bioset() before mempool
block: show operation in error injection rules
block: serialize elevator changes for the same queue using a writer lock
block: free copied pages when blk_rq_map_kern() fails
block: do not warn when doing greedy allocation in folio_alloc_greedy()
partitions: aix: bound the lvd scan to one sector
blk-cgroup: fix leaks and online flag on radix_tree_insert failure
loop: remove manually added partitions on detach
block: fix race in blk_time_get_ns() returning 0
Merge tag 'io_uring-7.2-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Fix a use-after-free in the bpf-ops struct_ops path, where the same
io_uring_bpf_ops map could be registered more than once.
- Fix the deferred iovec free for the provided-buffer grow path, which
could leave the caller with a dangling iovec and result in repeated
frees. Follow-up to the earlier fix in this series.
- Zero-check the unused addr3/pad2 SQE fields for unlinkat
* tag 'io_uring-7.2-20260717' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/bpf-ops: reject re-registration of an already-bound ops
io_uring/fs: check unused sqe fields for unlinkat
io_uring/kbuf: free the replaced iovec after a successful grow
Merge tag 'spi-fix-v7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A couple of fairly routine driver fixes, nothing too remarkable"
* tag 'spi-fix-v7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: cadence-quadspi: Fix indirect write timeout when DMA read mode is enabled
spi: dw-dma: Wait for controller idle before completing Tx
Ming Lei [Sun, 19 Jul 2026 13:45:40 +0000 (08:45 -0500)]
ublk: wait on ublk_dev_ready() instead of ub->completion
ub->completion is only re-armed by a successful START_USER_RECOVERY. If
the ublk server sends END_USER_RECOVERY without one - e.g. its START
failed with -EBUSY and the error was ignored - the wait is satisfied by
the stale completion of the previous recovery cycle, and the device is
marked LIVE and the requeue list kicked while the FETCH stream is still
running and ubq->canceling is still set. The kick redispatches a
previously requeued request, __ublk_queue_rq_common() sees ->canceling
and parks it again via __ublk_abort_rq(), and after the last FETCH
clears ->canceling nothing ever kicks the requeue list again: the
request is stranded there while holding its tag. If it is the flush
machinery's flush_rq, every subsequent fsync piles up in uninterruptible
sleep and teardown hangs on tag draining. This matches a report of a
lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.
ub->completion is an edge-triggered latch used as a proxy for the level
condition "every queue has fetched all I/O commands", which can regress
(F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop
it and wait on the real condition instead: the new helper
ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then
re-checks it under ub->mutex, waiting again on regression, and returns
with the mutex held and readiness guaranteed.
Readiness becomes true in the same ub->mutex critical section that
clears the last queue's ->canceling, so END_USER_RECOVERY marks the
device LIVE and kicks the requeue list strictly after ->canceling
clears. The wait stays interruptible, so a server whose daemon died can
still be signalled out. For ublk_ctrl_start_dev() this replaces the
fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting
until the device is ready again.
Reported-by: George Salisbury <gsalisbury@apnic.net> Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <tom.leiming@gmail.com> Link: https://patch.msgid.link/20260719134540.120269-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Merge tag 'regulator-fix-v7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"One straightforward driver fix for some incorrectly described
bitfields in the ltc3676 driver"
* tag 'regulator-fix-v7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: ltc3676: Fix incorrect IRQSTAT bit offsets
Merge tag 'x86-urgent-2026-07-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Reject too long acpi_rsdp= boot parameter values (Thorsten Blum)
- Validate console=uart8250 baud rate to fix early boot hang (Thorsten
Blum)
- Remove dead Makefile rule (Ethan Nelson-Moore)
* tag 'x86-urgent-2026-07-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/boot: Validate console=uart8250 baud rate to fix early boot hang
x86/boot: Reject too long acpi_rsdp= values
x86/cpu: Remove Makefile rule for removed UMC CPU support
hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers
MAX34451 and ADPM chips do not support standard PMBus VIN/IIN limit
registers, manufacturer specific min/max registers, or undercurrent
or undertemperature fault limits. STATUS_BYTE and STATUS_OTHER are also
not available. Accessing these non-existent registers during driver
initialization triggers a CML error and asserts ALERT. Handled by
blocking these functions during read/write.
Fixes: 7a001dbab4ad ("hwmon: (pmbus/max34440) Add support for MAX34451.") Fixes: 629cf8f6c23a ("hwmon: (pmbus/max34440) Add support for ADPM12160") Fixes: 2e0b52f1ae88 ("hwmon: (pmbus/max34440): add support adpm12200") Fixes: 479bfeba2eb6 ("hwmon: (pmbus/max34440): add support adpm12250") Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com> Link: https://lore.kernel.org/r/20260716-max34451_fixes-v1-1-a941b27eaecb@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Merge tag 's390-7.2-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- Fix checksum lib on machines without the vector facility where the
non-vector fallback made csum_partial() calculate the checksum from
address 0 instead of the provided buffer
- Fix cpum_cf perf event initialization missing speculation barrier for
user controlled event numbers used as generic event array indexes
* tag 's390-7.2-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/perf_cpum_cf: Add missing array_index_nospec() to __hw_perf_event_init()
s390/checksum: Fix csum_partial() without vector facility
Merge tag 'arc-7.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
- Misc fixes and config updates
* tag 'arc-7.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: configs: Drop redundant I2C_DESIGNWARE_PLATFORM
arc: validate DT CPU map strings before parsing them
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"The biggest core change is the reliable wake fix for scsi_schedule_eh
which is used by both libata and libsas which could otherwise cause
error handler hangs due to rare races.
All other fixes are in drivers (well except the export symbol removal)
the next biggest being the target PR-OUT transportid parsing fix"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path
scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()
scsi: elx: efct: Fix I/O leak on unsupported additional CDB
scsi: core: wake eh reliably when using scsi_schedule_eh
scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE
scsi: target: Bound PR-OUT TransportID parsing to the received buffer
scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()
scsi: sg: Report request-table problems when any status is set
scsi: ufs: core: tracing: Do not dereference pointers in TP_printk()
scsi: bfa: Reduce kernel stack usage in bfa_fcs_lport_fdmi_build_portattr_block()
scsi: xen: scsiback: Free the command tag on the TMR submit-failure path
scsi: xen: scsiback: Free unsubmitted command instead of double-putting it
scsi: core: Remove export for scsi_device_from_queue()
Merge tag 'i2c-fixes-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux
Pull i2c fixes from Andi Shyti:
"A handful of small fixes for host controller drivers.
One patch also adds Wolfram Sang to CREDITS after more than a decade
of work on I2C"
* tag 'i2c-fixes-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux:
i2c: mediatek: fix WRRD for SoCs without auto_restart option
i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()
i2c: spacemit: fix spurious IRQ handling returning IRQ_HANDLED
i2c: imx: fix locked bus on SMBus block-read of 0 (IRQ)
i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)
CREDITS: Add Wolfram Sang
HP Pavilion x360 sets a bogus PCI SSID (103c:0000), hence the driver
picks up a wrong quirk entry, resulting in an almost silent output.
And yet, the existing quirk for x390 doesn't seem sufficing, and we
need the extra setup for the amp.
This patch adds the quirk entry for the codec SSID (103c:8486) to
initialize the amp via COEF verbs and chains to the existing quirk for
another x360 model to address the silent output.
sched_ext: Don't enable non-ext tasks in the sub-sched task loops
Root enable and scx_post_fork() enable a task only if it's on the ext class.
Tasks on other classes, possible under an SCX_OPS_SWITCH_PARTIAL root, are
left READY and enabled by switching_to_scx() when they switch over. The sub
enable-commit pass and the sub-disable re-home loop enable unconditionally,
so a fair-class READY task in the subtree becomes ENABLED while not on
sched_ext. A later switch to SCHED_EXT then trips the task state validation
WARN (ENABLED with the previous state not READY) and calls ops.enable() a
second time.
Gate scx_enable_task() on the task's class in both loops.
Fixes: 337ec00b1d9c ("sched_ext: Implement cgroup sub-sched enabling and disabling") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
sched_ext: Skip sub-disable teardown for never-linked sub-schedulers
A sub-scheduler enable can fail before scx_link_sched() links the sched into
the hierarchy, e.g. when the parent is already being disabled, and cleanup
still runs the full scx_sub_disable().
That is racy against root disable: drain_descendants() is the only ordering
between a sub's disable-time task walk and root disable's all-task teardown,
and an unlinked sub is invisible to it. Root's teardown can thus run between
the never-linked sub's drain and its walk, exiting every task to no
scheduler.
The walk then trips the membership WARN and re-homes the exited tasks onto
the dying hierarchy, a use-after-free.
Skip the cgroup ownership reset and the task walk if @sch was never linked,
indicated by the empty ->sibling as unlinking only happens later in the same
function. The membership WARN remains valid: a linked sub is always waited
on by an ancestor's drain.
Fixes: 337ec00b1d9c ("sched_ext: Implement cgroup sub-sched enabling and disabling") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
The enable path waits for the rmdir to release cgroup_mutex. The rmdir,
deactivating the cpu controller's files, waits in kernfs_drain() for the
write's active reference. The write, in scx_group_set_weight(), waits for
the rwsem behind the pending writer.
Take cgroup_lock() first. The set_* paths take no cgroup locks inside the
read side, so a pending write-lock then only waits for read sections that
always run to completion, and no dependency from the rwsem back to
cgroup_mutex remains.
Fixes: a5bd6ba30b33 ("sched_ext: Use cgroup_lock/unlock() to synchronize against cgroup operations") Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
sched_ext: Reject setting disallow from init_task outside the enable path
The p->scx.disallow revert assumes the root enable path, where the switching
loop reads the reverted policy right afterwards and leaves the task off SCX.
The sub-scheduler disable path also reaches it when re-initializing the
returned tasks on a root parent. Nothing reads the policy there: the task is
enabled on root anyway and keeps running on the ext class with a silently
rewritten policy.
Kill the sched instead, matching the fork and non-root branches, and update
the disallow documentation, which equated !fork with the load path and
pointed at a stale debugfs path for nr_rejected.
Fixes: 337ec00b1d9c ("sched_ext: Implement cgroup sub-sched enabling and disabling") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
Merge tag 'v7.2-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd
Pull smb server fixes from Steve French:
"ksmbd server fixes, mostly addressing malformed SMB request
handling and connection/session lifetime issues, including
two information-disclosure or memory-safety bugs in the SMB2
request/response paths.
- validate FILE_ALLOCATION_INFORMATION before block rounding to
prevent a client-controlled overflow from truncating a file.
- pin connections while asynchronous oplock and lease-break
notifications are pending.
- release the allocated alternate-stream xattr name after rename.
- size multichannel binding session-key buffers for the largest
permitted key, avoiding a stack buffer overflow.
- remove a disconnecting connection's channels from every session,
including channels whose binding state has since changed.
- serialize binding preauthentication-session lookup and update
against its teardown.
- check that every compound request element contains StructureSize2
before reading it"
* tag 'v7.2-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd:
ksmbd: validate compound request size before reading StructureSize2
ksmbd: lock the binding preauth session in smb3_preauth_hash_rsp
ksmbd: remove stale channels from all sessions on teardown
ksmbd: fix stack buffer overflow in multichannel session-key copy
ksmbd: fix memory leak of xattr_stream_name in smb2_rename()
ksmbd: zero the smb2_read alignment tail to avoid an infoleak
ksmbd: pin conn during async oplock break notification
ksmbd: fix integer overflow in set_file_allocation_info()
ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources()
On phy_init() failure the error path fallsthrough to disable_rsts, which
deasserts the controller reset and then enters disable_phys calling
phy_power_off() on PHYs that were never powered on. That corrupts the PHY
power_count and triggers an extra runtime PM put.
Use a separate exit_phys path that unwinds with phy_exit() only and falls
through to disable_clks while the controller remains in reset. Reserve
phy_power_off() for the phy_power_on() failure path only, and skip
masked-out ports in both unwind loops.
On phy_power_on() failure re-assert the controller reset before disabling
clocks and regulators, matching the teardown order used by
ahci_platform_enable_resources() and ahci_platform_disable_resources().
Fixes: 26c8404e162b ("ata: ahci_ceva: fix error handling for Xilinx GT PHY support") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
ata: sata_mv: accept 1 or 2 resources in platform probe
Board files in arch/arm/plat-orion, arch/arm/mach-dove,
arch/arm/mach-mv78xx0 and arch/arm/mach-orion5x still register the
"sata_mv" device with two resources (IORESOURCE_MEM plus IORESOURCE_IRQ).
Those devices are rejected with -EINVAL, so SATA no longer probes on
legacy Marvell Orion/Kirkwood-style boards.
Accept both 1 resource (DT, IRQ fetched via platform_get_irq()) and 2
resources (legacy, IRQ supplied as a second resource) so both probing
paths work.
Fixes: b3b2bec9646e ("ata: sata_mv: Fixes expected number of resources now IRQs are gone") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
ntfs: preserve RECALL_ON_OPEN on WSL special-file reparse points
When creating a WSL special file (socket, fifo, character or block
device), __ntfs_create() sets FILE_ATTRIBUTE_RECALL_ON_OPEN in ni->flags
as valid_reparse_data() requires for these tags. This flag is
intentionally absent from $FILE_NAME, so the subsequent reload
ni->flags = fn->file_attributes;
drops it from ni->flags, the authoritative copy written back to
$STANDARD_INFORMATION. The on-disk file_attributes becomes 0x00000404
instead of 0x00040404, and after a remount valid_reparse_data() rejects
the reparse point while fsck reports "$REPARSE_POINT data is corrupted".
Preserve the RECALL_ON_OPEN bit across the reload. Symlinks do not set
that bit, so they are unaffected.
Merge tag 'ata-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fixes from Damien Le Moal:
- Interrupt initialization and handling fixes for the Designware
ahci_dwc driver (Rosen)
- Avoid possible infinite loop when scanning completion in the
Designware ahci_dwc driver (Rosen)
* tag 'ata-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning
ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending interrupts
ata: sata_dwc_460ex: use platform_get_irq()
ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered
Merge tag 'drm-fixes-2026-07-18-1' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Daie Airlie:
"Weekly drm fixes, there is amdgpu, xe and i915 and then a lot of
scattered fixes.
Looks about the right level for the new right.
ttm:
- Handle NULL pages and backup handles in ttm_pool_backup() correctly
gpusvm:
- Improve unmap and error handling on gpusvm
udmabuf:
- Always synchronize for CPU in begin_cpu_udmabuf
xe:
- Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOCK
- Hold a dma-buf reference for imported BOs
- Fix writable override for CRI
- Fix VF CCS attach/detach race with in-flight BO moves
- Fix WOPCM size for LNL+
- Reset current_op in xe_pt_update_ops_init
- Keep scheduler timeline name alive
- Hold device ref until queue teardown completes
- Disable display in admin only PF mode
i915:
- NV12 display fix for bigjoiner
- clear watermark on plane disable
- GT selftest fixes
amdkfd:
- Fix potential overflow in CWSR size calculation
- DQM error clean up fixes
* tag 'drm-fixes-2026-07-18-1' of https://gitlab.freedesktop.org/drm/kernel: (61 commits)
Revert "drm/amd/display: Restore 5s vbl offdelay for NV3x+ DGPUs"
drm/amd/display: check GRPH_FLIP status before sending event
drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock
drm/amd: Create a device link between APU display and XHCI devices
drm/amd/display: wire DCN42B mcache programming callback
drm/amd/display: set new_stream to NULL after release
drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05
drm/amdkfd: free MQD managers on DQM init failures
drm/amdgpu/ttm: Consider concurrent VM flushes for buffer entities
drm/amd/pm/smu7: Fix AC/DC switch notification
drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge
drm/amdgpu: always emit the job vm fence
drm/amd/pm/si: Fix AC/DC switch notification
drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized
drm/amd/display: dce100: skip non-DP stream encoders for DP MST
drm/amd/display: Set native cursor mode for disabled CRTCs
drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
drm/amd/display: fix __udivdi3 link error
drm/amdgpu: Reserve space for IB contents in devcoredumps
drm/amdgpu: Print vmid, pasid and more task info in devcoredump
...
Leo Li [Fri, 12 Jun 2026 19:49:03 +0000 (15:49 -0400)]
drm/amd/display: check GRPH_FLIP status before sending event
[Why]
After unifying DCN interrupt sources under VUPDATE_NO_LOCK, we have two
remaining issues to clean up:
1. On DCN, flip completion is now delivered from VUPDATE_NO_LOCK
(dm_crtc_high_irq_handler) instead of GRPH_PFLIP. But VUPDATE_NO_LOCK
fires every frame, regardless of whether a flip has latched.
2. There is a window during commit where a flip is armed (pflip_status =
SUBMITTED) but not yet programmed into HW. If the VUPDATE_NO_LOCK
fires in that window, its handler would deliver a flip event to
userspace before HW has latched to it. If userspace then renders to
what it believes is now the back buffer (but HW is still latched to
it!), it will cause display corruption. This issue seemed to have
been introduced by:
commit 1159898a88db ("drm/amd/display: Handle commit plane with no FB.")
Enabling replay or psr extended the duration of this window, and
hence made corruption more likely to be observed.
[How]
* Move acrtc->event/pflip_status arming to after
update_planes_and_stream_adapter() has programmed the flip into HW.
This closes the window where pflip_status is SUBMITTED but the flip is
not yet programmed.
* Add dc_get_flip_pending_on_otg(), which reads the HUBP flip-pending
status straight from HW for the pipe(s) bound to an OTG instance. It
is keyed only by otg_inst and does not take or mutate a
dc_plane_state, so it is safe to call from the OTG interrupt handler
without racing a concurrent commit that may be modifying plane state.
* Optimistically query for flip-pending after programming, in the event
that HW latched to the new fb between programming start and arming
event. If it latched, send the vblank event immediately, rather than
wait for the next vblank IRQ.
* In the VUPDATE_NO_LOCK handler, only deliver flip completion once
dc_get_flip_pending_on_otg() reports the flip is no longer pending.
Otherwise leave the flip armed and retry on the next vupdate.
* For DCE, maintain the existing behavior of arming flips before
programming, and relying on GRPH_FLIP to fire at HW latch.
v2:
* Drop flip_programmed completion object, instead move
event/pflip_status arming after programming.
* For DCN, optimistically query for flip pending immediately after
programming, and if it latched, send event right away.
v3:
* Fix event timestamps on optimistic flip latch detection, where it's
possible for it to run *before* the vupdate IRQ updates the timestamp.
* Add more docstrings for DCN vblank handling.
* Clean up if conditions in dm_arm_vblank_event().
* Code style cleanup on braces surrounding multi-line statements.
Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141 Assisted-by: Copilot:claude-opus-4.8 Tested-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f64a9be5653689ff43e148cd8a6483077488c8e5) Cc: stable@vger.kernel.org # 8382cd234981: drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock Cc: stable@vger.kernel.org
On DCN, vblank events were delivered from VSTARTUP/VUPDATE
(dm_crtc_high_irq/dm_vupdate_high_irq) and pageflip completion from
GRPH_PFLIP (dm_pflip_high_irq). These signals can be masked by hardware
by a few things:
* DPG - DCN can Dynamically Power Gate parts of the display pipe when a
self-refresh capable eDP is connected. DPG is engaged when there's
enough static frames (detected through drm_vblank_off). Once gated,
even though the OTG (output timing generator) is still enabled,
VSTARTUP and GRPH_FLIP are masked.
* GSL - Driver can use the Global Sync Lock to block HW from latching
onto double-buffered registers during programming, to prevent HW from
latching onto a partially programmed state. This will mask VSTARTUP,
GRPH_FLIP, and VUPDATE. See dcn20_pipe_control_lock().
* MALL - A DCN accessible cache introduced in DCN32+ DGPUs that can
store fb data to allow for longer DRAM sleep. When scanning out from
MALL, VSTARTUP is masked.
When masked, events are never delivered, which can show up as flip_done
timeouts in the wild.
However, there is an interrupt source on DCN that is never masked:
VUPDATE_NO_LOCK. It's simply an unmasked variant of VUPDATE, which fires
while the OTG is active, at the exact point hardware latches
double-buffered registers. It is therefore the natural single signal for
delivering both vblank and flip-completion events on DCN, and the
correct point to timestamp both VRR and non-VRR vblanks.
DCE's interrupt sources are different, it does not have an unmaskable
VUPDATE_NO_LOCK. The only unmaskable DCE interrupt is VLINE0, but it can
only be programmed as a vline offset from vsync_start, making it
unsuitable for VRR. Thus, we keep DCE untouched and use the existing mix
of interrupt sources.
[How]
For DCN1 and newer only:
* Factor the body of dm_crtc_high_irq() into dm_crtc_high_irq_handler()
and drive it from dm_vupdate_high_irq() (VUPDATE_NO_LOCK). DCE keeps
using dm_crtc_high_irq() (VSTARTUP) and dm_pflip_high_irq()
(GRPH_PFLIP) unchanged.
* Stop registering VSTARTUP (crtc_irq) and GRPH_PFLIP (pageflip_irq) on
DCN, and stop enabling them in amdgpu_dm_crtc_set_vblank() /
manage_dm_interrupts(). Enable VUPDATE whenever vblank is enabled on
DCN (previously only in VRR mode). The secure-display vline0 interrupt
is left untouched.
* VUPDATE_NO_LOCK does not early-fire on an immediate (tearing / async)
flip, since HW latches the new address right away. Deliver the flip
completion event immediately after programming such flips in
amdgpu_dm_commit_planes(), and clear pflip_status so the next vupdate
handler does not double-send.
v2: Do not gate VUPDATE_NO_LOCK on DCN in dm_handle_vrr_transition()
Also toggle VUPDATE_NO_LOCK on DCN in dm_gpureset_toggle_interrupts()
Re-cook vblank event count and timestamp for immediate flips
Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141 Assisted-by: Copilot:claude-opus-4.8 Co-developed-by: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Tested-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c87e6635d2db02c88ae8d09529362da672d34770) Cc: stable@vger.kernel.org
drm/amd: Create a device link between APU display and XHCI devices
Some AMD APU multi-function devices expose an integrated USB xHCI
controller. In some circumstances (such as larger VRAM), the PM core
can resume can fail when the xHCI controller is resuming in parallel
with the GPU/display function.
On affected systems, the xHCI controller can complete pci_pm_resume
and start resuming USB devices while the GPU is still in its much
longer resume path. This race condition leads to USB device resume
failures followed by:
xhci_hcd ...: xHCI host not responding to stop endpoint command
xhci_hcd ...: HC died; cleaning up
Create a device link from any xHCI controller sharing the same PCIe
root port as the APU display function. The link uses DL_FLAG_STATELESS
and DL_FLAG_PM_RUNTIME to ensure the GPU completes its resume before
the xHCI controller begins resuming USB devices.
This device link is done specifically in amdgpu so that if the
platform firmware has been modified such that this issue doesn't happen
the version can be detected and the workaround skipped.
Suggested-by: Aaron Ma <aaron.ma@canonical.com> Reported-by: mrh@frame.work Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221073 Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Tested-by: Alexander F <superveridical@gmail.com> Tested-by: Francis DB <francisdb@gmail.com> Link: https://patch.msgid.link/20260713195313.1739762-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 07c93d7eeb0d990bc1b8e3b1eafa464bc9feee97) Cc: stable@vger.kernel.org
DCN42B enables DML2 and DML21 by default and defines
dcn42b_prepare_mcache_programming(), but the resource function table only
wires the callback when CONFIG_DRM_AMD_DC_DML21 is defined.
There is no in-tree Kconfig symbol named DRM_AMD_DC_DML21, so the
preprocessor always removes the callback entry. Sibling DCN42 and DCN401
resource tables wire their prepare_mcache_programming callbacks
unconditionally, and the core DC code already checks whether the callback
pointer is present before calling it.
Remove the stale guard so DCN42B exposes the callback relation that its
source and DML21 build world already provide.
This is an RFC patch draft from static conditional callback legality
auditing. It needs AMD display maintainer review before submission as a
final fix.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 85453fb4ff726e1ddb9984ee83dca260903c5353)
WenTao Liang [Sun, 28 Jun 2026 07:27:40 +0000 (15:27 +0800)]
drm/amd/display: set new_stream to NULL after release
In dm_update_crtc_state(), the skip_modeset path releases new_stream
via dc_stream_release() but does not set the pointer to NULL.
If a later error (e.g., color management failure) triggers the fail
label, the error path calls dc_stream_release() again on the same
dangling pointer, causing a double release and potential use-after-free.
Fix this by setting new_stream to NULL after the initial release.
Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required") Signed-off-by: WenTao Liang <vulab@iscas.ac.cn> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28) Cc: stable@vger.kernel.org
drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05
The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that
advertises AUX/DPCD backlight control, so amdgpu's automatic detection
(amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight
path has no effect: brightness writes are accepted but the panel level
never changes, the display is stuck at a fixed brightness and
max_brightness is reported as a bogus 511000. As a result neither the
desktop brightness slider nor the brightness hotkeys do anything.
Forcing PWM backlight (amdgpu.backlight=0) restores working control:
max_brightness becomes 65535 and the level tracks writes. This has long
been applied by users as a manual kernel-parameter workaround.
Extend the generic panel backlight quirk with a force_pwm flag, add an
entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu
disable AUX backlight (use PWM) when the quirk matches and the user
lets the driver auto-select the backlight type.
Signed-off-by: Alessandro Rinaldi <ale@alerinaldi.it> Tested-by: Alessandro Rinaldi <ale@alerinaldi.it> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 81b39f43e7e53589491e2eef6bad5389626b4b9c) Cc: stable@vger.kernel.org
Guangshuo Li [Wed, 8 Jul 2026 10:51:15 +0000 (18:51 +0800)]
drm/amdkfd: free MQD managers on DQM init failures
The change referenced by the Fixes tag releases the HIQ SDMA MQD trunk
buffer when device_queue_manager_init() fails after it has been
allocated.
However, the same failure path can also be reached after
init_mqd_managers() has succeeded. At that point dqm->mqd_mgrs[] contains
per-type MQD manager objects owned by the device queue manager. The
normal teardown path frees those objects from uninitialize(), but the
initialization error path only frees dqm itself.
Free the MQD managers from the initialization error path as well. This is
safe for earlier failures because dqm is zeroed when allocated and
init_mqd_managers() clears the entries it rolls back internally.
Fixes: b7cccc8286bb ("drm/amdkfd: fix a memory leak in device_queue_manager_init()") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1fff2e07b6670bc5b8f7344a8708c136259cb176) Cc: stable@vger.kernel.org
Timur Kristóf [Sat, 11 Jul 2026 11:49:58 +0000 (13:49 +0200)]
drm/amdgpu/ttm: Consider concurrent VM flushes for buffer entities
Allow using multiple SDMA schedulers only on GPUs where
we are allowed to do concurrent VM flushes.
This consideration is necessary because all GART windows
are mapped in VMID 0 (the kernel VMID) so each buffer
entity would flush VMID 0 concurrently.
Practically this means that we can't use multiple SDMA
engines for TTM on GFX6-8 and Navi 1x.
Fixes: 01c836788b37 ("drm/amdgpu: pass all the sdma scheds to amdgpu_mman") Fixes: e4029f7a9474 ("drm/amdgpu: only use working sdma schedulers for ttm") Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a8171229bc836607fbc225d323ebc4d14489cfbb)
Timur Kristóf [Sun, 12 Jul 2026 17:39:28 +0000 (19:39 +0200)]
drm/amd/pm/smu7: Fix AC/DC switch notification
There were two mistakes in the previous implementation:
The check for AutomaticDCTransition should be inverted.
We recently learned that the kernel should send
PPSMC_MSG_RunningOnAC when the flag is set, and not the
other way around.
The clocks also need to be recomputed, because the code in
the smu7_apply_state_adjust_rules() function selects
different limits on AC and DC.
Fixes: 96da0d86614e ("drm/amd/pm/smu7: Notify SMU7 of DC->AC switch") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 516f8fc30a1b56af03f39e93c18707d13419fb1f) Cc: stable@vger.kernel.org
drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge
AMD Ryzen Pinnacle Ridge (Zen+, family 0x17 model 0x08) CPUs have
PCI controllers that don't support PCIe dynamic speed switching,
causing system freezes during GPU initialization when enabled.
Disable dynamic speed switching when this CPU is detected.
Assisted-by: Claude:sonnet Fixes: 466a7d115326 ("drm/amd: Use the first non-dGPU PCI device for BW limits") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5436 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Link: https://patch.msgid.link/20260709031520.841611-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9ceb4e034a327a04155f32f1cd1a5031dfa5fe02) Cc: stable@vger.kernel.org
Alex Deucher [Wed, 3 Jun 2026 19:41:28 +0000 (15:41 -0400)]
drm/amdgpu: always emit the job vm fence
We need the fence to reemit the gds switch or spm update
after a queue reset.
Fixes: a17ef941212b ("drm/amdgpu: rework ring reset backup and reemit v9") Cc: timur.kristof@gmail.com Cc: christian.koenig@amd.com Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bc639a9eadc75822f7f15a4315c198a4b5513bd2) Cc: stable@vger.kernel.org
Timur Kristóf [Sun, 12 Jul 2026 17:39:27 +0000 (19:39 +0200)]
drm/amd/pm/si: Fix AC/DC switch notification
There were two mistakes in the previous implementation:
The check for ATOM_PP_PLATFORM_CAP_HARDWAREDC should be
inverted. We recently learned that the kernel should send
PPSMC_MSG_RunningOnAC when the flag is set, and not the
other way around.
The clocks also need to be recomputed, because the code in
the si_apply_state_adjust_rules() function selects different
limits on AC and DC.
Fixes: 2d071f6457af ("drm/amd/pm/si: Notify the SMC when switching to AC") Tested-by: Jeremy Klarenbeek <jeremy.klarenbeek99@gmail.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 358dd0a9ce66d898fa934887385327547d599d88) Cc: stable@vger.kernel.org
Timur Kristóf [Sun, 12 Jul 2026 17:39:26 +0000 (19:39 +0200)]
drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized
When DPM is turned off with the amdgpu.dpm=0 module parameter,
the thermal work queue isn't initialized so we shouldn't
schedule any work on it.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bd018d36171a695952c6d391471c279c9e05c8b2)
drm/amd/display: dce100: skip non-DP stream encoders for DP MST
On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital
DIG stream encoders plus one analog DAC encoder. When assigning a stream
encoder for a second DisplayPort MST stream, if the preferred digital
encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link()
falls back to the first free pool entry. That entry may be the analog
encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute.
The subsequent atomic commit then dereferences NULL function pointers in
link_set_dpms_on() and crashes.
Skip encoders without dp_set_stream_attribute when the stream uses a DP
signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST
fallback path instead of checking only the link connector signal.
Tested on:
- GPU: AMD Radeon R7 260X (Bonaire / DCE8)
- Board: Supermicro C9X299-PG300
- Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot
- Kernel: 7.1.3 (issue observed since 6.19)
- Result: kernel oops without patch; dual monitors stable with patch
Signed-off-by: Andriy Korud <a.korud@gmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5162 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8) Cc: stable@vger.kernel.org
Timur Kristóf [Sat, 11 Jul 2026 11:34:35 +0000 (13:34 +0200)]
drm/amd/display: Set native cursor mode for disabled CRTCs
Always set native cursor mode when the CRTC is disabled,
to make sure it doesn't cause atomic commits to fail when
they are trying to disable the CRTC.
Fixes: 41af6215cdbc ("drm/amd/display: Reject cursor plane on DCE when scaled differently than primary") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5432 Cc: Leo Li <sunpeng.li@amd.com> Cc: Michel Dänzer <michel.daenzer@mailbox.org> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2f79f0130f828cf26fe2dcf45291821616af7b47) Cc: stable@vger.kernel.org
Timur Kristóf [Mon, 13 Jul 2026 06:14:43 +0000 (08:14 +0200)]
drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)
The old radeon driver has a documented workaround in ci_dpm.c
which claims that Bonaire 0x6658 with old memory controller
firmware is unstable with MCLK DPM, so as a precaution I
disabled MCLK DPM on this ASIC in amdgpu.
Note that the old MC firmware is not actually used with
amdgpu, but in theory it's possible that the VBIOS sets
up the ASIC with an old MC firmware that is already running
when amdgpu initializes (in which case amdgpu doesn't
load its own firmware).
What I expected to happen is that the GPU would simply use
its maximum memory clock, and indeed this is what seemed
to happen according to amdgpu_pm_info which reads the
current MCLK value from the SMU.
However, some users reported a huge perf regression
and upon a closer look it seems that the GPU seems to
not actually use the highest MCLK value, despite the SMU
reporting that it does.
Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X).
Keep MCLK DPM disabled on R9 M380 in the 2015 iMac
because that still hangs if we enable it.
Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit d34acad064ee7d82bd18f5d87592c422d4d323ac) Cc: stable@vger.kernel.org
When compiling the AMDGPU display driver for 32-bit architectures,
the linker reports undefined reference to `__udivdi3` in functions
get_dp_dto_frequency_100hz() and dcn401_get_dp_dto_frequency_100hz().
This is because the code uses 64-bit division (/) on 32-bit systems,
which GCC cannot handle directly and instead tries to call the missing
__udivdi3 helper function.
Replace the raw division with div_u64(), the kernel's standard 64-bit
division helper, to avoid the link error.
Signed-off-by: Linlin Yang <yanglinlin@kylinos.cn> Reported-by: k2ci <kernel-bot@kylinos.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0421fc6ab3a8514e99156ff3c2cee13ee9af3fa7) Cc: stable@vger.kernel.org
Timur Kristóf [Sat, 11 Jul 2026 11:21:08 +0000 (13:21 +0200)]
drm/amdgpu: Reserve space for IB contents in devcoredumps
Currently the contents of IBs are abruptly cut off and don't
show the full contents. This patch makes sure to reserve
space for those contents too so they may be printed.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4e2c0821509fed754e8c31d5053d152fbb3484a5) Cc: stable@vger.kernel.org
Timur Kristóf [Sat, 11 Jul 2026 11:21:07 +0000 (13:21 +0200)]
drm/amdgpu: Print vmid, pasid and more task info in devcoredump
These are in the dmesg logs but are missing from devcoredumps.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fed7aa36d79802c3e02acd05aeae8b0a877e47c2) Cc: stable@vger.kernel.org
amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table()
but never releases it. acpi_get_table() takes a reference on the
table (incrementing its validation_count and mapping it on the 0->1
transition); without a paired acpi_put_table() the mapping is leaked
on every call, whether or not a matching VBIOS image is found.
Route all exit paths after the table is acquired through a common
acpi_put_table(). The VBIOS image is copied out with kmemdup() before
the table is released, so it remains valid for the caller.
drm/amdgpu: Fix VFCT bus number matching with soft filter
On systems where PCI bus renumbering occurs (e.g. pci=realloc,
resource conflicts), the runtime bus number may differ from the
BIOS POST bus number recorded in the VFCT table. This causes
amdgpu_acpi_vfct_bios() to fail finding the VBIOS even though
the correct device entry exists.
Introduce amdgpu_acpi_vfct_match() which treats the bus number
as a soft filter: vendor/device/function identity is the hard
requirement, while exact bus match is the preferred path. When
bus numbers disagree but device identity matches, accept the
VFCT entry and log a dev_notice for diagnostics.
Reported-by: Oz Tiram <oz@shift-computing.de> Closes: https://lore.kernel.org/amd-gfx/20260621173211.28443-1-oz@shift-computing.de/ Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260708193518.702584-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 11c141672045ffc0187aa604f2c0f597bc334fb2) Cc: stable@vger.kernel.org
drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved
amdgpu_bo_create_reserved() only allocates a new BO when
*bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is
NULL, it simply skips creation when *bo_ptr is non-NULL.
But it unconditionally reserves, pins, gart allocates
and maps the BO afterwards.
When the same non-NULL BO pointer is passed in again,
for example firmware buffers that live in adev and are
re-loaded on every resume / cp_resume / start
under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases
pin_count unconditionally, however the matching teardown only unpins
once, so pin_count never drops to zero, so TTM is not able
to move, swap or evict a BO, causing BO leaks.
This commit fixes this issue by only pinning the bo
once at creation, and repeated calls no longer
take additional pin references.
Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf) Cc: stable@vger.kernel.org
drm/amdgpu/userq: fix indefinite fence wait during GPU reset
pre_reset only force-completes fences of MAPPED queues. A queue in any
other state (e.g. mid-eviction) keeps its last_fence pending; after a
GPU reset that fence never signals, so the eviction/suspend worker and
process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and
wedge the machine:
INFO: task kworker/6:28 blocked for more than 120 seconds.
Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu]
Call Trace:
dma_fence_wait_timeout+0x7e/0x130
amdgpu_userq_evict+0x67/0x140 [amdgpu]
amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu]
process_scheduled_works+0xa6/0x420
Force-complete every queue's fence regardless of state. The unmap and
mark-hung step stays gated on MAPPED, since unmapping a queue that is
not mapped is invalid.
Fixes: 290f46cf5726 ("drm/amdgpu: Implement user queue reset functionality") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0) Cc: stable@vger.kernel.org
drm/amd/display: Fix backlight max_brightness to match exported range
[Why]
FWTS autobrightness fails on eDP panels because actual_brightness can
read higher than the advertised max_brightness (e.g. 63576 vs 62451).
The conversion helpers expose the firmware PWM range to userspace as
[0..max]. But max_brightness is advertised as (max - min), which is
smaller. So reading the level can return a value above max_brightness.
This regressed in commit 4b61b8a39051 ("drm/amd/display: Add debugging
message for brightness caps"), which changed max_brightness to
(max - min) and undid commit 8dbd72cb7900 ("drm/amd/display: Export full
brightness range to userspace").
[How]
Advertise max_brightness as max, and scale the initial AC/DC brightness
against max too. Update the KUnit expectations to match.
Fixes: 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps") Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bd9e2b5b0473c75abc0f4134dfe79ecbfb16610d) Cc: stable@vger.kernel.org
Fangzhi Zuo [Wed, 24 Jun 2026 20:54:30 +0000 (16:54 -0400)]
drm/amd/display: Fix 8K Mode Not Parsed by EDID
[why]
The 8K120/8K240 timings live in DisplayID extension blocks 2 and 3
of this EDID. The EDID is a 4-block (512-byte) HDMI 2.1 EDID
that uses HF-EEODB.
drm core reads and parses this correctly, but amdgpu rebuilds its own copy.
Only 2 of 4 blocks were copied into sink->dc_edid, that leads to
drm_edid_connector_add_modes() never sees blocks 2 and 3.
[how]
Directly populate edid_blob_ptr with a blob whose length is the full,
and HF-EEODB-aware size.
Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 11a90eaf5c808ba800249dda0d481c35d0888589)
Timur Kristóf [Fri, 29 May 2026 09:09:09 +0000 (11:09 +0200)]
drm/amd/display: Add dp_skip_rbr flag for NUTMEG
No functional changes. Just clean up a conceptual mismatch.
Based on feedback on the NUTMEG code in DC, the
preferred_link_setting is meant to force the DP link to a
specific setting, meaning both the link rate and lane count
should be locked to an exact value. What NUTMEG needs is
a lower bound on the link rate, which is not the same concept.
Implement this as a HW workaround flag instead.
Suggested-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 871ceb853841bcaa4e6cec3723b16c4887a760be) Cc: stable@vger.kernel.org
Timur Kristóf [Fri, 29 May 2026 09:09:08 +0000 (11:09 +0200)]
drm/amd/display: Fix preferred link rate for NUTMEG
When there is a preferred link rate setting, it needs to be
applied to both the current and initial link rate.
This was regressed by a "coding style" fix, which caused
the current link rate to not respect the preferred value.
This commit restores the functionality of NUTMEG,
the DP bridge encoder found on old APUs such as Kaveri.
projects / thirdparty / kernel / linux.git / log
