Some platforms make an assumption that the i2c controller's
enabled state indicates also the power state of the
controller. This can create a problem when the controller is
in disabled state, because the hardware may assume
incorrectly that it is then also in low-power state.
To fix this, the controller is kept enabled by taking over
the IC_ENABLE register. The controller has to be disabled
when the configuration is updated and when the target
address or the slave address are assigned, so disabling it
when IC_CON, IC_TAR or IC_SAR registers are programmed, and
then re-enabling it again.
Fixes: f0e53aadd7 ("drm/xe: Support for I2C attached MCUs")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260811121008.1493015-4-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 76cc14e2faed1adae20f4ee144ead0e3a7566c49)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The platforms that support the interrupt from the I2C
adapter can not handle the amount of interrupts the adapter
generates because of the way the IRQ is routed in the
hardware. The I2C controller driver has to be kept in
polling mode because of that.
The AMC MCU can still generate critical alerts that have to
be handled. The interrupt from SMBus Alert is left enabled
and handled separately in the Xe. The alerts from the AMC
will cause the device to be declared wedged for now.
Fixes: f0e53aadd7 ("drm/xe: Support for I2C attached MCUs")
Cc: stable@vger.kernel.org
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Co-developed-by: Ramesh Babu B <ramesh.babu.b@intel.com>
Signed-off-by: Ramesh Babu B <ramesh.babu.b@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260811121008.1493015-3-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit a55b76b8bc2c49b11d753c1c6d06ec3a2c61c85e)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Changes for v7.3
Bindings:
- Added Shikra support
- Document a840, a704, a722
Core:
- Use drm_client buffers for fbdev emulation
- teardown fixes
- ARM32 DMA fixup
- Remove objects from evict list when re-validated
- Bunch of corner case and error path fixes
DPU:
- Dropped dev_pm_opp_set_rate(0) preventing burnout
- Fixed SSPP offsets of Kaanapali
DP:
- Dropped dev_pm_opp_set_rate(0) preventing burnout
- Cleaned up core code in preparation for MST support
- Fixed prepare() to let Pipewire continue in case of the unplugged cable
GPU:
- Add support for a704
- Add support for a722
HDMI:
- Simplifed register access
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <rob.clark@oss.qualcomm.com>
Link: https://patch.msgid.link/CACSVV02Kp=J+w_RjEJbBbQnBYRb+SWdwMvVbCaAL70bq9EBagQ@mail.gmail.com
igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2
(UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind,
a GSC proxy kernel submission can still time out; with the device wedged
and the GuC CT stopped it can never complete, so its kernel job times out.
Tile0: GT1: Kernel-submitted job timed out
WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:...
at guc_exec_queue_timedout_job()
Workqueue: gt-ordered-wq drm_sched_job_timedout
Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even
though the device is already wedged. The timeout handler then treats the
kernel queue timeout as unexpected and taints the kernel.
Honour an already-wedged device even for killed queues so the expected
teardown timeout no longer trips the WARN.
Fixes: 5a2f117a80 ("drm/xe: Do not wedge device on killed exec queues")
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patch.msgid.link/20260814074106.92670-2-nitin.r.gote@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
(cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Linux 7.2
There was a lot of conflicts this round between fixes and next,
and I'd like to get the merge resolutions that we have in drm-tip.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Unlike the CRTC degamma path, which is guarded by
amdgpu_dm_verify_lut_sizes(), the per-plane degamma LUT size was never
validated before use. __set_dm_plane_degamma() passed the user-supplied
size straight into __is_lut_linear() and, for a non-linear LUT, into
__set_input_tf() -> __drm_lut_to_dc_gamma(), the latter always iterating
MAX_COLOR_LUT_ENTRIES entries regardless of the actual LUT size.
A malformed AMD_PLANE_DEGAMMA_LUT blob (e.g. a single entry) could thus
trigger a divide-by-zero in __is_lut_linear() or an out-of-bounds read in
__drm_lut_to_dc_gamma(). Reject any plane degamma LUT whose size does not
match MAX_COLOR_LUT_ENTRIES, mirroring the invariant the code already
asserts a few lines below (and which the CRTC path enforces).
The AMD_PLANE_DEGAMMA_LUT property is only exposed on builds with
AMD_PRIVATE_COLOR defined.
Fixes: 980f871007 ("drm/amd/display: add plane degamma TF and LUT support")
Cc: stable@vger.kernel.org
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
__is_lut_linear() computes the expected value of each entry with
expected = i * MAX_DRM_LUT_VALUE / (size - 1);
If it is ever called with a single-entry LUT, size - 1 is zero and the
kernel takes a divide error (#DE). A LUT with fewer than two entries
cannot describe a linear mapping anyway, so return false early instead
of dividing by zero.
Fixes: 086247a4b2 ("drm/amd/display: Use 4096 lut entries")
Cc: stable@vger.kernel.org
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If we end up emitting a VM fence keep pipeline sync
associated with that fence. If not, emit them as
part of the IB fence.
v2: fix need_pipe_sync handling
v3: simplify the function
Cc: David Rosca <david.rosca@amd.com>
Fixes: cb1e657cca ("drm/amdgpu: handle GDS and SPM without a VM fence")
Reviewed-by: David Rosca <david.rosca@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression
6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting
the parser loop far past the end of the message BO. Triggering it
additionally requires a ~4GiB mapping so that msg[1] survives the
earlier "header does not fit in BO" check.
Rewrite the test in division form, which is overflow-free by
construction. Also update the message to reflect that msg is invalid.
Fixes: b193019860 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg")
Fixes: 0a78f2bac1 ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg")
Cc: stable@vger.kernel.org
Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The Apple iMac11,1 (27-inch, Late 2009) uses a Mobility Radeon HD 4850
(RV770/DCE3.1) with a 2560x1440 internal panel on an internal
DisplayPort path. Without this fix the display stays dark under KMS.
This machine suffers from the same issue as iMac10,1 and iMac11,2:
Apple routes the internal display through Link B of the DIG encoder
instead of Link A. Add iMac11,1 to the existing DMI quirk and move
the Apple-specific encoder assignment into its own block, independent
of the DCE version check.
Additionally, the 2560x1440 panel requires RADEON_PLL_USE_FRAC_FB_DIV
and ATOM_ENCODER_CMD_DP_VIDEO_ON, limited to iMac11,1 via dmi_match()
to avoid affecting other boards.
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Gilles Risch <gilles.risch@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When a queue is hung, the hang_detect_work is the
only way to recover it. However in amdgpu_userq_destroy(),
the hang_detect_work is cancelled too early,
resulting in amdgpu_userq_wait_for_last_fence()
may never return, leaving an uninterruptible dma_fence_wait()
hang there.
To fix this problem, this commit moves the cancelling of
hang_detect_work after amdgpu_userq_wait_for_last_fence(), and it has
to be before the unmap helper, because hang_detect_work resets the
queue, so it races with amdgpu_userq_unmap_helper() for MES operations
and queue state.
This commit splits amdgpu_userq_cleanup() into two parts:
1) amdgpu_userq_detach_doorbell(), which detaches the queue from
userq_doorbell_xa. This has to be called before the cancel, otherwise
the IRQ handlers (for example amdgpu_userq_process_fence_irq)
can re-schedule the hang_detect_work and the cancel is not final.
2) amdgpu_userq_fence_driver_free(), this has to be called after the
unmap helper, because it can release the seq64 slot that the GPU
writes fence values to.
Only one cancel_delayed_work_sync(&queue->hang_detect_work) is needed,
so other redundancies are removed.
Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
profile_lock_device() may return negive error code,
so the type of the return value should be int,
not uint32
Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When amdgpu_init_minimal_xgmi is used, SDMA engines init
is delayed so amdgpu_ttm_enable_buffer_funcs must be
called later.
Without this, the check for num_buffer_funcs_scheds will
fail and using ttm buffer funcs later will fail.
Given that amdgpu_ttm_enable_buffer_funcs is a no-op if
amdgpu_in_reset() returns true, the call has to occur
after the reset lock is dropped.
Cc: stable@vger.kernel.org
Fixes: e4029f7a94 ("drm/amdgpu: only use working sdma schedulers for ttm")
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Introduce a helper to consolidate the vga_switcheroo registration condition
used by the init and fini paths.
Keep the explicit pci_is_thunderbolt_attached() check, as dev_is_removable()
does not provide equivalent coverage for Thunderbolt-attached GPUs.
This ensures such devices remain excluded from switcheroo registration while
preserving the existing PX and Apple gmux handling.
Cc: stable@vger.kernel.org
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a
polling fence, so it is skipped by the force-completion loop in
amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and
survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a
reset the first KIQ submission can poll forever on a seq that is never written
back.
Force complete the KIQ ring fences too so their hw fence is realigned to
sync_seq.
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
rptr and wptr of a userq are 8 bytes aligned, and may
not placed on a page boundary.
This commit checks whether rptr and wptr are 8 bytes
aligned, and expectes 8 bytes when validates rptr/wptr VA.
With above changes, this commit fixes an regression
in amdgpu_userq_input_va_validate, where
end_addr is caculated by:
check_add_overflow(start_addr, expected_size - 1, &end_addr).
Wptr and rptr are very likely not to be page aligned,
when validating rptr and wptr, if they are located in the last
mapped page(or only one page is mapped)
and expected_size is PAGE_SIZE, end_addr will exceed the last
mapped page, means (end_addr >> AMDGPU_GPU_PAGE_SHIFT) > va_map->last,
and causing an -EINVAL, even it is a valid VA.
Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Fixes: c0122bf2cc ("drm/amdgpu: fix userq VA validation for sub-page buffers")
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The MES scheduler ring has no drm scheduler (no_scheduler = true), so it is
skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). It uses
a polling fence whose hw value lives in wb (GTT) memory and survives a MODE1
reset, while fence_drv.sync_seq keeps advancing for every packet.
When the reset is triggered because MES itself stopped responding, the
timed-out packets advance sync_seq past the last hw fence value MES wrote.
After resume the first MES submission polls forever on a seq that is never
written back, failing the resume and wedging the box on a second reset:
amdgpu: MES ring buffer is full.
amdgpu: *ERROR* ring gfx_0.0.0 test failed (-110)
amdgpu: resume of IP block <gfx_v11_0> failed -110
amdgpu: GPU reset end with ret = -110
Force complete the MES scheduler ring fences together with the scheduler rings
so their hw fence is realigned to sync_seq.
v2: cover all XCCs (one scheduler ring each), not just mes.ring[0].
Cc: stable@vger.kernel.org
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In standalone mode the ip_discovery sysfs tree is built from a verbatim
copy of the discovery binary taken before reg_base_init() collapses the
64bit base addresses in place. Decoding as 32bit there yields interleaved
zeros. Decode base_address_64[] in that case; keep reading the already
collapsed adev->discovery.bin as-is otherwise.
Fixes: 402e04f11f ("drm/amdgpu: Export ip_discovery sysfs on probe failure")
Cc: stable@vger.kernel.org
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Custom brightness curves use an 8-bit input signal. After exporting the
full PWM range to userspace, the curve normalizer still divides requests
by the physical PWM span. On panels with a nonzero minimum PWM level,
this can produce a curve input greater than 255 and send an invalid
backlight level to DC.
Scale the userspace [0..max] range to the curve's [0..255] range
instead. This retains the full advertised range and keeps the reverse
readback conversion unchanged.
Fixes: 8dbd72cb79 ("drm/amd/display: Export full brightness range to userspace")
Cc: stable@vger.kernel.org
Signed-off-by: Akhmed Zhitaev <zhitaevakh@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
(Move to amdgpu_dm_backlight.c)
Link: https://patch.msgid.link/20260813170959.22073-1-zhitaevakh@gmail.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_userq_wait_return_fence_info() calls drm_exec_init() without
DRM_EXEC_IGNORE_DUPLICATES. When the same GEM object appears more than
once across the read/write BO handle lists submitted by userspace,
drm_exec_lock_obj() returns -EALREADY the second time it locks that
object, which aborts the fence resolution pass instead of treating the
repeat as a no-op.
Add DRM_EXEC_IGNORE_DUPLICATES so duplicate objects are silently
skipped on the second lock attempt.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_userq_wait_count_fences() calls drm_exec_init() without
DRM_EXEC_IGNORE_DUPLICATES. When the same GEM object appears more than
once across the read/write BO handle lists submitted by userspace,
drm_exec_lock_obj() returns -EALREADY the second time it locks that
object, which aborts the fence-counting pass instead of treating the
repeat as a no-op.
Add DRM_EXEC_IGNORE_DUPLICATES so duplicate objects are silently
skipped on the second lock attempt.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_userq_signal_ioctl() calls drm_exec_init() without
DRM_EXEC_IGNORE_DUPLICATES. When the same GEM object appears more than
once across the read/write BO handle lists submitted by userspace,
drm_exec_lock_obj() returns -EALREADY the second time it locks that
object, which aborts the ioctl instead of treating the repeat as a
no-op.
Add DRM_EXEC_IGNORE_DUPLICATES so duplicate objects are silently
skipped on the second lock attempt, matching the intended semantics of
locking a set of (possibly overlapping) BOs before publishing a fence
on them.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_userq_buffer_vas_mapped() checks whether all VAs
of a queue are mapped before restoring it.
So that HW won't access any invalid addresses.
Currently, this function assumes all VAs are mapped if
any VA of a queue has been mapped, which is wrong.
This commit fixes this problem by examining all VAs of
a queue and reporting false if any of them is not mapped.
Signed-off-by: Zhu Lingshan <lingshan.zhu@amd.com>
Reviewed-by: Sunil Khatri <sunil.khatri@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_pci_probe() calls pm_runtime_use_autosuspend(), but
amdgpu_pci_remove() does not call the matching
pm_runtime_dont_use_autosuspend().
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped and usage_count remains
unbalanced.
The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().
Add the missing pm_runtime_dont_use_autosuspend() call to the remove
path.
This issue was found by manual code inspection.
Fixes: d38ceaf99e ("drm/amdgpu: add core driver (v4)")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260808120934.2813010-1-lgs201920130244@gmail.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci_is_thunderbolt_attached() requires an upstream PCI bridge with
is_thunderbolt set from an Intel Thunderbolt VSEC. This does not cover
the affected ASM4242 USB4 PCI hierarchy:
00:02.2
\- 0f:00.0 [1b21:2421]
+- 10:01.0 [1b21:2423] -> 45:00.0 -> 46:00.0
| -> 47:00.0 -> 48:00.0 -> 49:00.0 [1002:7590]
\- 10:03.0 -> 76:00.0 [1b21:2425] USB4 Host Router
The host router is outside the GPU upstream bridge chain, leaving no
ancestor with is_thunderbolt set. PCI core propagates DEVICE_REMOVABLE
below the external-facing PCIe tunnel. Disable Runtime PM when either
pci_is_thunderbolt_attached() or dev_is_removable() is true.
Cc: stable@vger.kernel.org
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Candice Li <candice.li@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pull scheduler fix from Borislav Petkov:
- Make sure a delayed sched entity's runtime stats are updated at the
right time so that it receives the proper lag compensation
* tag 'sched_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Update time before requeueing delayed entities
Pull timer fixes from Borislav Petkov:
- Detect a broken EL2 virtual timer in the bcm2712 SoC boards (RPi5)
and fallback to the physical one instead
- Fix a build error with ARM rpc_defconfig and function tracer enabled
* tag 'timers_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource/drivers/arm_arch_timer: Workaround bcm2712 broken EL2 virtual timer
tick: Include ktime.h and jiffies.h in linux/tick.h
Pull rseq fix from Borislav Petkov:
- Prevent a lockup when rseq grants a timeslice extension
* tag 'core_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rseq: Prevent hard lockup on granted time slice extension
Split mt7921_mcu_regd_update() into two functions to prevent recursive
mutex acquisition. Introduce __mt7921_mcu_regd_update() as the internal
implementation that assumes the mutex is already held by the caller,
while mt7921_mcu_regd_update() remains as the external interface that
handles mutex acquisition and release.
This fixes a deadlock issue when mt7921_regd_set_6ghz_power_type() is
called with the device mutex already held. Without this change, calling
mt7921_mcu_regd_update() would attempt to acquire the same mutex again,
causing a recursive lock deadlock.
The __mt7921_mcu_regd_update() function can be safely called when the
caller has already acquired the device mutex, avoiding the deadlock
while maintaining proper synchronization for regulatory domain updates.
Fixes: dc2608cf5224 ("wifi: mt76: mt7921: refactor regulatory notifier flow")
Signed-off-by: Charlie-cy Wu <Charlie-cy.Wu@mediatek.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull perf fixes from Borislav Petkov:
- Prevent the use of exited events as group leaders
- Avoid use-after-free of an event's group leader by promoting detached
sibling events to standalone entities and correct related accounting
and state transitions
* tag 'perf_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Fix group leader use-after-free after sibling detach
perf: Reject exited events as group leaders
Pull x86 fix from Borislav Petkov:
- Add a proper kernel cmdline option to control the TLB invalidation
method on x86 prompted mainly by a recent finding on AMD related to
INVLPGB/TYLBSYNC invalidations.
Having the command line option is simply another way to alleviate
the situation short-term
* tag 'x86_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/CPU: Add a tlbi= cmdline switch
Pull block fix from Jens Axboe:
"A single fix for a regression in this cycle, where drbd would leak
shared secrets over netlink. This restores the behavior to match
what we had before"
* tag 'block-7.2-20260815' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
drbd: don't leak the shared secret to unprivileged netlink dumps
Pull io_uring fix from Jens Axboe:
"Just a single fix for a potential issue on 32-bit x86 with PAE"
* tag 'io_uring-7.2-20260815' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/rsrc: reject overflowing regvec bvec byte counts
The conversion to explicit netlink serialization dropped the
exclude_sensitive parameter from net_conf_to_skb(), so each caller has
to sanitize by hand. Two dump paths were missed:
drbd_nl_get_connections_dumpit() and the volume-less connection branch
of get_one_status(). Neither op carries GENL_ADMIN_PERM, so any
unprivileged local user could read the CRAM-HMAC secret.
Add a net_conf_to_skb_sanitized() wrapper and route all three callers
through it.
Fixes: 8098eeb693 ("drbd: replace genl_magic with explicit netlink serialization")
Reported-by: Vivek Parikh <vivek.parikh@breachx.ai>
Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Link: https://patch.msgid.link/20260814151617.73752-1-christoph.boehmwalder@linbit.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Pull SoC fixes from Arnd Bergmann:
"These are three last-minute fixes for the 7.2 release, though nothing
alarming:
- one error handling fix for optee firmware
- incorrect i2c data for the apple M3 that was added in 7.2
- a boot time warning fix for nvidia tegra"
* tag 'soc-fixes-7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
arm64: tegra: Add EL2 virtual timer interrupt for Tegra194
arm64: dts: apple: t8122: Fix I2C resources
optee: ffa: Add NULL check in optee_ffa_lend_protmem
Pull OpenRISC fix from Stafford Horne:
"A bug fix found by researchers:
- mask all privileged bits when restoring the supervisor register
from sigreturn"
* tag 'for-linus' of https://github.com/openrisc/linux:
openrisc: signal: do not restore privileged SR bits on sigreturn
restore_sigcontext() copies the whole supervision register (SR) from the
signal frame and only clears SPR_SR_SM before the value is reloaded into
the hardware SR (through ESR and l.rfe) on the return to user space. All
other SR bits are left under user control.
An unprivileged task can thus return from a signal handler through a
crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the
CPU performs no translation or protection on data accesses, so the task
gains read and write access to arbitrary physical memory, a local
privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH
and the cache-enable bits are exposed the same way. The ptrace GPR regset
already refuses any change to SR for exactly this reason.
Restore only the arithmetic flag bits (F, CY, OV) from the signal frame
and take every privileged control bit from the SR the kernel saved on
signal entry.
Verified with qemu-system-or1k -M or1k-sim: before this change an
unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to
physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the
same PoC receives SIGSEGV and physical memory is unchanged.
Fixes: ac689eb7f9 ("OpenRISC: Signal handling")
Cc: stable@vger.kernel.org
Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Pull input fixes from Dmitry Torokhov:
- A couple of fixes to the sur40 touchscreen driver to correct
registration and teardown ordering, and to fix error path
unwinding when video device registration fails.
* tag 'input-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: sur40 - fix V4L error path cleanup
Input: sur40 - fix input device registration ordering
Pull drm fixes from Dave Airlie:
"While this is large for rc8 time but also AI driven fixes is a lot of
it, we had a more traditional screw up, and a regression was just
found in the fair scheduling patches that went in back in rc1. This
reverts the fair scheduler back to an option and sets the default back
to what it should have been. We might have been a bit overly zealous
in switching over, but at least it feels more normal than the AI
driven fixes.
Apart from the scheduler, it's mostly amdgpu and xe fixes, with some
misc fixes to the log code and connector code.
scheduler:
- revert fair scheduler patches due to regression
- mark fair as experimental
connector:
- fix OOB read in hdmi audio infoframe
log:
- fix divide by 0 if module param is set to 0
- fix OOB read on empty message
- fix infinite loop for too large scale
xe:
- Fix DPT Allocation paths
- Fixes around UM queue BO
- Order ring writes before ring tail updates
- Add termination on resume for PXP
- Document Sentinel and make CTX_TIMESTAMP read TOCTOU-safe
- Fix sync entry leak on OA config emit failure
- Check managed mutex initilization errors
- Fix min frequency setting
- Fix xe_device_probe error path
amdgpu:
- Bounds checking fix in CS IOCTL
- Bounds checking fix in GEM IOCTL
- Display fixes
- GPUVM fix
- ASPM fix
- UVD bounds checking fixes
- VCE 3 fix
- BT.2020 fixes
- NBIF 6.3.1 fix
- IP discovery fix
radeon:
- Runtime pm fix
amdxdna:
- skip attempting to populate unmapped pages"
* tag 'drm-fixes-2026-08-15' of https://gitlab.freedesktop.org/drm/kernel: (51 commits)
drm/log: Fix infinite loop when scale is too large for display
drm/log: Fix out-of-bounds read on empty message length
drm/log: Fix division by zero when scale module parameter is 0
drm/xe: Fix xe_device_probe() failure
drm/xe: Fix a bug in pc_adjust_freq_bounds()
drm/xe/oa: Check managed mutex initialization errors
drm/xe/oa: Fix sync entry leak on OA config emit failure
drm/xe/lrc: document sentinel and make CTX_TIMESTAMP read TOCTOU-safe
drm/xe/pxp: add termination on resume
drm/xe: Order ring writes before ring tail updates
drm/xe/guc_ads: use uncached mapping for UM queue BO
drm/xe/guc_ads: allocate UM queues in VRAM on dGFX
drm/xe/guc_ads: allocate UM queues in a separate BO
drm/xe: Fix DPT allocation paths.
accel/amdxdna: Skip unmapped range in aie2_populate_range()
drm/amdgpu: Prefer default discovery offset
drm/amdgpu: Reject UVD message with invalid number of h265 refs
drm/amdgpu: fix nbif 6.3.1 l1 low power not functional
drm/amd/display: fix BT.2020 YCbCr output CSC matrices for DCE
drm/amd/display: fix BT.2020 YCbCr limited output CSC matrix
...
Pull clk fixes from Stephen Boyd:
"Fixes for the Qualcomm, Rockchip, and SpacemiT clk drivers:
- Keep audio working on Rockchip rk3588 by skipping disabling unused
clks
- Fix SpacemiT USB2 clk data so they actually work and keep the HDMA
bus clk enabled to avoid system hangs
- Avoid clk hangs on Qualcomm Eliza display hardware and revert a
patch that breaks PCIe on some Qualcomm platforms"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
dt-bindings: clock: Replace bouncing emails
Revert "clk: qcom: regmap-phy-mux: Rework the implementation"
clk: spacemit: k3: set hdma clock as critical
clk: spacemit: k3: fix USB2 bus clock
clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK
clk: rockchip: rk3588: don't disable unused I2S MCLK output gates
