Shuicheng Lin [Wed, 8 Apr 2026 17:52:52 +0000 (17:52 +0000)]
drm/xe/bo: Fix bo leak on unaligned size validation in xe_bo_init_locked()
When type is ttm_bo_type_device and aligned_size != size, the function
returns an error without freeing a caller-provided bo, violating the
documented contract that bo is freed on failure.
Shuicheng Lin [Thu, 9 Apr 2026 00:34:49 +0000 (00:34 +0000)]
drm/xe: Fix potential NULL deref in xe_exec_queue_tlb_inval_last_fence_put_unlocked
xe_exec_queue_tlb_inval_last_fence_put_unlocked() uses q->vm->xe as the
first argument to xe_assert(). This function is called unconditionally
from xe_exec_queue_destroy() for all queues, including kernel queues
that have q->vm == NULL (e.g., queues created during GT init in
xe_gt_record_default_lrcs() with vm=NULL).
While current compilers optimize away the q->vm->xe dereference (even
in CONFIG_DRM_XE_DEBUG=y builds, the compiler pushes the dereference
into the WARN branch that is only taken when the assert condition is
false), the code is semantically incorrect and constitutes undefined
behavior in the C abstract machine for the NULL pointer case.
Use gt_to_xe(q->gt) instead, which is always valid for any exec queue.
This is consistent with how xe_exec_queue_destroy() itself obtains the
xe_device pointer in its own xe_assert at the top of the function.
drm/xe/vf: Use drm mm instead of drm sa for CCS read/write
The suballocator algorithm tracks a hole cursor at the last allocation
and tries to allocate after it. This is optimized for fence-ordered
progress, where older allocations are expected to become reusable first.
In fence-enabled mode, that ordering assumption holds. In fence-disabled
mode, allocations may be freed in arbitrary order, so limiting allocation
to the current hole window can miss valid free space and fail allocations
despite sufficient total space.
Use DRM memory manager instead of sub-allocator to get rid of this issue
as CCS read/write operations do not use fences.
Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408110145.1639937-6-satyanarayana.k.v.p@intel.com
(cherry picked from commit 6c84b493012aeb05dec29c709377bf0e17ac6815) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Add a memory pool to allocate sub-ranges from a BO-backed pool
using drm_mm.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260408110145.1639937-5-satyanarayana.k.v.p@intel.com
(cherry picked from commit 1ce3229f8f269a245ff3b8c65ffae36b4d6afb93) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0
For FF-A v1.0 the driver registers a bus notifier to backfill UUID
matching, but the notifier was never unregistered on cleanup paths.
Track the registration state and unregister it during teardown and early
partition-setup failure.
firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue
Per-vcpu notification handling already runs from a per-cpu work item on
the target cpu. Routing that path back through smp_call_function_single()
re-enters the call-function IPI path and executes the notification
handler with interrupts disabled. That makes the framework path unsafe,
since it takes a mutex, allocates memory with GFP_KERNEL, and invokes
client callbacks.
Handle per-vcpu self notifications directly from the existing per-cpu
work item instead. This keeps the per-vcpu path in task context and
avoids the extra IPI hop entirely.
firmware: arm_ffa: Avoid collapsing NPI work from different CPUs
Notification pending interrupts are registered as per-CPU IRQs, but the
driver queues all NPI handling through a single shared work_struct.
That allows queue_work_on() calls from different CPUs to collapse onto a
single pending work item even though the work function uses the CPU it
runs on to fetch and handle per-CPU notifications.
Move notif_pcpu_work into the per-CPU ffa_pcpu_irq state and initialize
one work item per CPU. This keeps NPI handling independent per CPU and
avoids losing notifications when multiple CPUs queue work concurrently.
firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
If the RX buffer allocation fails in ffa_init(), the error path jumps to
free_pages even though no buffer has been allocated yet. Route that case
directly to free_drv_info so the cleanup path is only used after at
least one RX/TX buffer allocation has succeeded.
firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
The bus match callback assumes that every FF-A driver provides an
id_table and dereferences it unconditionally. Enforce that contract at
registration time so a buggy client driver cannot crash the bus during
match.
Matt Roper [Wed, 8 Apr 2026 22:27:44 +0000 (15:27 -0700)]
drm/xe/debugfs: Correct printing of register whitelist ranges
The register-save-restore debugfs prints whitelist entries as offset
ranges. E.g.,
REG[0x39319c-0x39319f]: allow read access
for a single dword-sized register. However the GENMASK value used to
set the lower bits to '1' for the upper bound of the whitelist range
incorrectly included one more bit than it should have, causing the
whitelist ranges to sometimes appear twice as large as they really were.
For example,
REG[0x6210-0x6217]: allow rw access
was also intended to be a single dword-sized register whitelist (with a
range 0x6210-0x6213) but was printed incorrectly as a qword-sized range
because one too many bits was flipped on. Similar 'off by one' logic
was applied when printing 4-dword register ranges and 64-dword register
ranges as well.
Correct the GENMASK logic to print these ranges in debugfs correctly.
No impact outside of correcting the misleading debugfs output.
Matt Roper [Fri, 10 Apr 2026 22:50:30 +0000 (15:50 -0700)]
drm/xe: Mark ROW_CHICKEN5 as a masked register
ROW_CHICKEN5 is a masked register (i.e., to adjust the value of any of
the lower 16 bits, the corresponding bit in the upper 16 bits must also
be set). Add the XE_REG_OPTION_MASKED to its definition; failure to do
so will cause workaround updates of this register to not apply properly.
Matt Roper [Fri, 10 Apr 2026 22:50:29 +0000 (15:50 -0700)]
drm/xe/tuning: Use proper register offset for GAMSTLB_CTRL
From Xe2 onward (i.e., all platforms officially supported by the Xe
driver), the GAMSTLB_CTRL register is located at offset 0x477C and
represented by the macro "GAMSTLB_CTRL" in code. However the register
formerly resided at offset 0xCF4C on Xe1-era platforms, and we also have
macro XEHP_GAMSTLB_CTRL that represents this old offset in the
unofficial/developer-only Xe1 code. When tuning for the register was
added for Xe3p_LPG, the old Xe1-era macro was accidentally used instead
of the proper macro for Xe2 and beyond, causing the tuning to not be
applied properly. Use the proper definition so that the correct offset
is written to.
drm/xe/xe3p_lpg: Add missing indirect ring state feature flag
Even though commit 8fcb7dfb8bbf ("drm/xe/xe3p_lpg: Add support for
graphics IP 35.10") mentions that the support for Indirect Ring State
exists for Xe3p_LPG, it missed actually setting the feature flag in
graphics_xe3p_lpg. Fix that by adding the missing member.
Matt Roper [Wed, 1 Apr 2026 20:12:44 +0000 (13:12 -0700)]
drm/xe: Drop redundant rtp entries for Wa_14019988906 & Wa_14019877138
There appears to have been a silent merge conflict between some commits
updating the workaround tables on Xe's -fixes and -next branches:
- Commit bc6387a2e0c1 ("drm/xe/xe2_hpg: Fix handling of Wa_14019988906
& Wa_14019877138") from the fixes branch moved the Xe2_HPG instance
of two workarounds touching the PSS_CHICKEN register from the
engine_was[] table to the lrc_was[] table; the equivalent
implementation for all other platforms/IPs were already properly
located on lrc_was[]. This commit on the fixes branch is a
cherry-pick of commit e04c609eedf4 ("drm/xe/xe2_hpg: Fix handling of
Wa_14019988906 & Wa_14019877138") that already existed on the next
branch.
- Commit 55b19abb6c44 ("drm/xe: Consolidate workaround entries for
Wa_14019877138") and commit c2142a1a8415 ("drm/xe: Consolidate
workaround entries for Wa_14019988906") consolidated the individual
entries per IP generation for each workaround into single, larger
range-based entries.
During merge conflict resolution the Xe2_HPG-specific entries (i.e.,
those with rule "GRAPHICS_VERSION_RANGE(2001, 2002)") were accidentally
resurrected, even though the table already contains the consolidated
entries that match a superset of thse ranges. These redundant entries
don't cause any build failures but do trigger a dmesg error during probe
on BMG-G21 devices:
Matthew Brost [Thu, 26 Mar 2026 21:01:16 +0000 (14:01 -0700)]
drm/xe: Drop registration of guc_submit_wedged_fini from xe_guc_submit_wedge()
xe_guc_submit_wedge() runs in the DMA-fence signaling path, where
GFP_KERNEL memory allocations are not permitted. However, registering
guc_submit_wedged_fini via drmm_add_action_or_reset() triggers such an
allocation.
Avoid this by moving the logic from guc_submit_wedged_fini() into
guc_submit_fini(), where wedged exec queue references are dropped during
normal teardown.
DaeMyung Kang [Sat, 25 Apr 2026 09:38:28 +0000 (18:38 +0900)]
ksmbd: rewrite stop_sessions() with restartable iteration
stop_sessions() walks conn_list with hash_for_each() and, for every
entry, drops conn_list_lock across the transport ->shutdown() call
before re-acquiring the read lock to continue the loop. The hash
walk relies on cross-iteration state (the current bucket and the
hlist position), which is not preserved across unlock/relock: if
another thread performs a list mutation during the unlocked window,
the ongoing iteration becomes unreliable and can re-visit
connections that have already been handled or skip connections that
have not. The outer `if (!hash_empty(conn_list)) goto again;` retry
masks the symptom in the common case but does not address the
unsafe iteration itself.
Reframe the loop so it never relies on iterator state across
unlock/relock. Under conn_list_lock held for read, pick the first
connection whose ->shutdown() has not yet been issued by this path,
pin it by taking an extra reference, record that fact on the
connection and mark it EXITING while still inside the locked walk,
then drop the lock. Then call ->shutdown() outside the lock, drop
the pin (freeing the connection if the handler already released its
reference), and restart from the top.
Use a new per-connection flag, conn->stop_called, as the "shutdown
issued from stop_sessions()" marker rather than reusing the status
state. ksmbd_conn_set_exiting() is also invoked by
ksmbd_sessions_deregister() on sibling channels of a multichannel
session without issuing a transport shutdown, so treating
KSMBD_SESS_EXITING as "already handled here" would skip connections
that still need shutdown() to wake their handler out of recv(),
leaving the outer retry waiting indefinitely for the hash to drain.
stop_sessions() is serialised by init_lock in
ksmbd_conn_transport_destroy(), so writing stop_called under the
read lock has no other writer.
Set EXITING inside the locked walk so the selection, the stop_called
marker, and the status transition all happen together, and guard
against regressing a connection that has already advanced to
KSMBD_SESS_RELEASING on its own (for example, if the handler exited
its receive loop for an unrelated reason between teardown steps).
When the pin drop is the last put, release the transport and pair
ida_destroy(&target->async_ida) with the ida_init() done in
ksmbd_conn_alloc(), so stop_sessions() retiring a connection on its
own does not leak the xarray backing of the embedded async_ida.
The outer retry with msleep() is kept to wait for handler threads to
reach ksmbd_conn_free() and drain the hash.
Observed with an instrumented build that logs one line per visit and
widens the unlocked window before ->shutdown() by 200 ms, under
five concurrent cifs mounts (nosharesock, one connection each):
* Current code: the same connection address is revisited many
times during a single stop_sessions() call and ->shutdown() is
invoked well beyond the number of live connections before the
hash finally drains.
* Rewritten code: each live connection produces exactly one
->shutdown() call; the function returns as soon as the hash is
empty.
Functional teardown via `ksmbd.control --shutdown` with the same
five mounts completes cleanly on the rewritten path.
Performance is observably unchanged. Tearing down N concurrent
nosharesock cifs connections with `ksmbd.control --shutdown` +
`rmmod ksmbd` takes essentially the same wall time before and after
the rewrite:
N before after
10 4.93s 5.34s
30 7.34s 7.03s
50 7.31s 7.01s (3-run avg: 7.04s vs 7.25s)
100 6.98s 6.78s
200 6.77s 6.89s
and the number of ->shutdown() calls equals the number of live
connections on both paths when the race is not widened. The
teardown is dominated by the msleep(100)-based outer retry waiting
for handler threads to run ksmbd_conn_free(), not by the iteration
itself; the restartable loop's worst-case O(N^2) visit cost is in
the microseconds even at N=200 and sits far below the msleep(100)
granularity.
Applied alone on top of ksmbd-for-next-next, this patch does not
introduce a new leak site. Under the same reproducer (10x
concurrent-holders + ss -K + ksmbd.control --shutdown + rmmod), the
tree still shows the pre-existing per-connection transport leak
count that arises when the last refcount drop lands in one of
ksmbd_conn_r_count_dec(), __free_opinfo() or session_fd_check() -
all of which end with a bare kfree() today. kmemleak backtraces
for the unreferenced objects point into the TCP accept path
(sk_clone -> inet_csk_clone_lock, sock_alloc_inode) and none
involve stop_sessions(). Plugging those bare-kfree sites is the
responsibility of the follow-up patch.
Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: DaeMyung Kang <charsyam@gmail.com> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
Cássio Gabriel [Wed, 29 Apr 2026 13:20:02 +0000 (10:20 -0300)]
ALSA: usb-audio: Update Babyface Pro control caches only after successful writes
snd_bbfpro_ctl_put() and snd_bbfpro_vol_put()
cache the requested packed control state in
kcontrol->private_value before issuing the USB write.
Their get and resume paths use that cached value directly,
so a failed write can leave the driver reporting and later
replaying a setting the hardware never accepted.
Update the cached state only after a successful USB write.
Cássio Gabriel [Wed, 29 Apr 2026 13:20:01 +0000 (10:20 -0300)]
ALSA: usb-audio: Roll back quirk control caches on write errors
Several mixer quirk callbacks cache the requested
control value in kcontrol->private_value before
issuing a single vendor or class write.
Their paired get and resume paths consume that cache
directly, so a failed write currently leaves software
state changed even though the update did not succeed.
That can make later reads report a value the device
never accepted and can replay the stale cache on resume.
Restore the previous cached value on failure in
the Audigy2NX LED, Emu0204 channel switch,
Xonar U1 output switch, Native Instruments controls,
FTU effect program switch, and Sound Blaster E1 input source switch.
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm updates from Paolo Bonzini:
"On top of a lot of Arm fixes, this includes a massive rename of types
and variables in tools/testing/selftests/kvm - these were
unnecessarily different from what the kernel uses, so they're being
made consistent.
arm64:
- Allow tracing for non-pKVM, which was accidentally disabled when
the series was merged
- Rationalise the way the pKVM hypercall ranges are defined by using
the same mechanism as already used for the vcpu_sysreg enum
- Enforce that SMCCC function numbers relayed by the pKVM proxy are
actually compliant with the specification
- Fix a couple of feature to idreg mappings which resulted in the
wrong sanitisation being applied
- Fix the GICD_IIDR revision number field that could never been
written correctly by userspace
- Make kvm_vcpu_initialized() correctly use its parameter instead of
relying on the surrounding context
- Enforce correct ordering in __pkvm_init_vcpu(), plugging a
potential pin leak at the same time
- Move __pkvm_init_finalise() to a less dangerous spot, avoiding
future problems
- Restore functional userspace irqchip support after a four year
breakage (last functional kernel was 5.18...)
- Spelling fixes
Selftests:
- Rename types across all KVM selftests to more closely align with
types used in the kernel:
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (31 commits)
KVM: selftests: Add check_steal_time_uapi() implementation for LoongArch
KVM: arm64: Wake-up from WFI when iqrchip is in userspace
KVM: arm64: Fix initialisation order in __pkvm_init_finalise()
KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()
KVM: arm64: Fix kvm_vcpu_initialized() macro parameter
KVM: arm64: Fix FEAT_SPE_FnE to use PMSIDR_EL1.FnE, not PMSVer
KVM: arm64: Fix typo in feature check comments
KVM: arm64: Fix FEAT_Debugv8p9 to check DebugVer, not PMUVer
KVM: arm64: Reject non compliant SMCCC function calls in pKVM
KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
KVM: selftests: Replace "paddr" with "gpa" throughout
KVM: selftests: Replace "u64 nested_paddr" with "gpa_t l2_gpa"
KVM: selftests: Replace "u64 gpa" with "gpa_t" throughout
KVM: selftests: Replace "vaddr" with "gva" throughout
KVM: selftests: Clarify that arm64's inject_uer() takes a host PA, not a guest PA
KVM: selftests: Rename translate_to_host_paddr() => translate_hva_to_hpa()
KVM: selftests: Rename vm_vaddr_populate_bitmap() => vm_populate_gva_bitmap()
KVM: selftests: Rename vm_vaddr_unused_gap() => vm_unused_gva_gap()
KVM: selftests: Drop "vaddr_" from APIs that allocate memory for a given VM
KVM: selftests: Use u8 instead of uint8_t
...
gpiolib: acpi: Only trigger ActiveBoth interrupts on boot
Commit ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at
least once on boot") introduced logic to trigger edge-based GPIO
interrupts during initialization to ensure proper initial state setup
when firmware doesn't initialize it.
However, according to the Microsoft GPIO documentation, triggering GPIO
interrupts during initialization should only happen for interrupts
marked as ActiveBoth (both IRQF_TRIGGER_RISING and IRQF_TRIGGER_FALLING)
and only when the associated GPIO line is already asserted (logic level
low).
The current implementation incorrectly triggers:
1. Any edge-triggered interrupt (RISING-only or FALLING-only)
2. RISING interrupts when value is high and FALLING when value is low
This causes problems at bootup for single-edge interrupts that
don't follow the ActiveBoth pattern.
Fix this by:
- Only triggering when BOTH rising and falling edges are configured
- Only triggering when the GPIO line is asserted (value == 0)
Reported-by: Francesco Lauritano <francesco.lauritano1@protonmail.com> Closes: https://lore.kernel.org/all/6iFCwGH2vssb7NRUTWGpkubGMNbgIlBHSz40z8ZsezjxngXpoiiRiJaijviNvhiDAGIr43bfUmdxLmxYoHDjyft4DgwFc3Pnu5hzPguTa0s=@protonmail.com/ Tested-by: Marco Scardovi <mscardovi95@gmail.com> Fixes: ca876c7483b69 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/general-purpose-i-o--gpio- Suggested-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
firewire: core: split functions for iso_resource once operation
Unlike FW_CDEV_IOC_ALLOCATE_ISO_RESOURCE operation, the operations of
FW_CDEV_IOC_[DE]ALLOCATE_ISO_RESOURCE_ONCE require no client resource,
thus they keeps no handle value.
This commit adds the series of functions to separate these operations,
according to divide-and-conquer methodology.
firewire: core: code refactoring for helper function to fill iso_resource parameters
This change is a preparation for future changes. The added helper function
will be reused in the changes to fill iso_resource parameters according to
the users' request.
firewire: core: code refactoring to queue work item for iso_resource
The add_client_resource() function checks the type of client resource
every time to be called. If the type is for iso_resource, it schedules
work item.
However, the iso_resource client resource is only added by the call of
init_iso_resource(). There is no need to check the type every time adding
any client resource.
firewire: core: code refactoring for early return at client resource allocation
The add_client_resource() function returns zero at success or negative
value at error. The critical section is already protected by
scoped_guard() macro. In this case, the programming pattern of early
return improves code readability.
drm/i915/display: Use ceiling division for NV12 UV surface offset calculation
For LNL+, odd source size and panning for YUV 422/420 surfaces is
supported. However, it requires the UV (chroma) surface Start X/Y and
width/height to be calculated as ceiling(half of Y plane value) rather
than floor.
The current code uses (>> 17) which combines the U16.16 fixed-point to
integer conversion (>> 16) with a divide-by-2 for chroma subsampling
(>> 1) into a single floor division. For odd Y plane values this
produces an off-by-one error in the UV plane offset.
On Android systems we see PLANE ATS fault when NV12 overlays are
used with odd source dimensions:
[ 126.854200] xe 0000:00:02.0: [drm:intel_atomic_setup_scaler [xe]] [CRTC:148:pipe A] attached scaler id 0.0 to PLANE:33
[ 126.854617] xe 0000:00:02.0: [drm:skl_update_scaler [xe]] [CRTC:148:pipe A] scaler_user index 0.0: staged scaling request for 1279x719->1340x753
[ 126.854837] xe 0000:00:02.0: [drm:intel_plane_atomic_check [xe]] UV plane [PLANE:33:plane 1A] using Y plane [PLANE:123:plane 4A]
[ 126.854926] xe 0000:00:02.0: [drm] *ERROR* [CRTC:148:pipe A] PLANE ATS fault
With Y plane width 1279:
floor(1279/2) = 639 (current)
ceil(1279/2) = 640 (required)
Introduce fp_16_16_div2() and fp_16_16_to_int_ceil() helpers to cleanly
separate the two operations: first halve the U16.16 fixed-point value
for chroma subsampling (staying in fixed-point domain), then convert
to integer with ceiling rounding.
v2: Use DIV_ROUND_UP(value, 1 << 17) to preserve sub-pixel precision
while making the ceiling division readable (Jani, Uma)
v3: Split into two helpers - fp_16_16_div2() for fixed-point division
by 2 and fp_16_16_to_int_ceil() for ceiling conversion to integer,
cleanly separating chroma subsampling from fixed-point to integer
conversion (Jani)
Jani Nikula [Wed, 8 Apr 2026 08:22:11 +0000 (11:22 +0300)]
drm/bridge: prefer drm_printf_indent() over inline \t
We have a helper drm_printf_indent() for tab indenting the prints. It
makes the actual strings more readable, and highlights the indented
parts better in source.
Jani Nikula [Wed, 8 Apr 2026 08:22:10 +0000 (11:22 +0300)]
drm/atomic: prefer drm_printf_indent() over inline \t
We have a helper drm_printf_indent() for tab indenting the prints. It
makes the actual strings more readable, and highlights the indented
parts better in source.
Michal Kosiorek [Wed, 29 Apr 2026 08:54:51 +0000 (10:54 +0200)]
xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete
KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s
hlist_del_rcu calls under syzkaller load on linux-6.12.y stable
(reproduced on 6.12.47, also reachable via the same code path on
torvalds/master and on the ipsec tree). Nine unique signatures cluster
in the xfrm_state lifecycle, the load-bearing one being:
BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline]
BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline]
BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c
Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435
The other observed signatures hit the same slab object from
__xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB
write variant of __xfrm_state_delete, all on the byseq/byspi
hash chains.
__xfrm_state_delete() guards its byseq and byspi unhashes with
value-based predicates:
if (x->km.seq)
hlist_del_rcu(&x->byseq);
if (x->id.spi)
hlist_del_rcu(&x->byspi);
while everywhere else in the file (e.g. state_cache, state_cache_input)
the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets
x->id.spi = newspi inside xfrm_state_lock and then immediately inserts
into byspi, but a path that observes x->id.spi != 0 outside of
xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently
with whether x is actually on the list. The same holds for x->km.seq
versus byseq, and the bydst/bysrc unhashes have no predicate at all,
so a second __xfrm_state_delete() on the same object writes through
LIST_POISON pprev.
The defensive change here:
- Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst,
bysrc, byseq and byspi so a second deletion is a no-op rather
than a write through LIST_POISON pprev. The byseq/byspi nodes
are already initialised in xfrm_state_alloc().
- Test hlist_unhashed() rather than the value predicate for
byseq/byspi, so the unhash decision tracks list state rather than
mutable scalar fields.
Empirical verification: applied this patch on top of v6.12.47, rebuilt,
and re-ran the same syzkaller harness for 1h16m on a previously-crashy
configuration that produced ~100 hits each of slab-use-after-free
Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in
__xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at
~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo
confirms the xfrm_state slab is actively allocated and freed during
the run (~143 KiB resident), so the fuzzer is still exercising those
code paths -- they just no longer crash.
Reproduction:
- Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV
- syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db
- 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal
- 9 unique signatures collected in ~9h, all within xfrm_state
lifecycle
Fixes: fe9f1d8779cb ("xfrm: add state hashtable keyed by seq") Fixes: 7b4dc3600e48 ("[XFRM]: Do not add a state whose SPI is zero to the SPI hash.") Reported-by: Michal Kosiorek <mkosiorek121@gmail.com> Tested-by: Michal Kosiorek <mkosiorek121@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Michal Kosiorek <mkosiorek121@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Changwoo Min [Wed, 29 Apr 2026 08:23:18 +0000 (17:23 +0900)]
sched_ext: Expose exit_cpu to BPF and userspace
Extend struct user_exit_info with an exit_cpu field so BPF schedulers
and the userspace report path can see the CPU that triggered the exit,
matching the kernel-side dump.
UEI_RECORD() defaults the field to -1 before the CO-RE-gated copy so
that running against an older kernel without exit_cpu stays
distinguishable from "exit happened on CPU 0".
UEI_REPORT() appends "on CPU N" to the EXIT line when the value is
valid, surfacing the most diagnostically useful piece of exit info to
any sched_ext userspace tool without needing to crack open the debug
dump.
Signed-off-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Changwoo Min [Wed, 29 Apr 2026 08:23:17 +0000 (17:23 +0900)]
sched_ext: Dump the exit CPU first
When sched_ext is disabled by an error, the CPU that triggered the exit
is the most relevant piece of information for diagnosing the problem.
However, if there are many CPUs, the dump can get truncated and that
CPU's information may not appear in the output.
Add an exit_cpu field to scx_exit_info and thread it through scx_vexit()
/ __scx_exit(). For the watchdog stall path, populate it from cpu_of(rq)
in check_rq_for_timeouts(). For all other exit paths, define a scx_exit()
macro that wraps __scx_exit() with raw_smp_processor_id(), so the CPU
that initiated the exit is captured automatically, with no call-site
changes needed.
In scx_dump_state(), report the exit CPU in the dump header ("on cpu N")
and dump that CPU first, skipping it in the per-CPU loop, so the most
relevant CPU is never truncated out of the dump. The SysRq-D path
initializes exit_cpu to -1 so debug dumps not tied to an exit don't
arbitrarily promote CPU 0.
Signed-off-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Changwoo Min [Wed, 29 Apr 2026 08:23:16 +0000 (17:23 +0900)]
sched_ext: Extract scx_dump_cpu() from scx_dump_state()
Factor out the per-CPU state dump logic from the for_each_possible_cpu
loop in scx_dump_state() into a new scx_dump_cpu() helper to improve
readability. No functional change.
Signed-off-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Replace sprintf() function calls with sysfs_emit() in the configfs show
callbacks. This will help harden the driver and will bring the driver
up-to-date with more modern functions.
accel/ivpu: Add support for limiting NPU frequency
Add configurable frequency limits to allow users to constrain the NPU
operating frequency range for power and thermal management. This support
requires firmware API version 3.34.0 or newer.
New sysfs interface:
The freq/ subdirectory contains the following attributes:
- hw_min_freq: Minimum frequency supported by hardware (read-only)
- hw_max_freq: Maximum frequency supported by hardware (read-only)
- hw_efficient_freq: Hardware's optimal operating frequency (read-only)
- current_freq: Current NPU frequency in MHz (read-only)
- set_min_freq: Configure minimum operating frequency (50XX+ devices)
- set_max_freq: Configure maximum operating frequency (50XX+ devices)
Legacy attributes npu_max_frequency_mhz and npu_current_frequency_mhz
are maintained for backward compatibility.
Implementation details:
- Frequency configuration is communicated to firmware via JSM messages
- User-specified frequency values are clamped to hardware limits
- Power-efficient frequency (pn_ratio) is adjusted dynamically to stay
within the configured range
- Frequency configuration is initialized during device boot
- The JSM API header is updated to version 3.34.0 to support the new
VPU_JSM_MSG_FREQ_CONFIG firmware message
Added description for the sysfs attributes in the Documentation/ABI.
Replace the open-coded manual cleanup in the error path of
xfrm_add_policy() with xfrm_policy_destroy(), which already
handles all the necessary cleanup internally. This is consistent
with how xfrm_policy_construct() handles its own error paths.
The walk.dead flag must be set before calling xfrm_policy_destroy()
as required by BUG_ON(!policy->walk.dead).
Task B acquires both hb locks and attempts to acquire the PI-lock of the
top most waiter (task B). Task A is leaving early due to a signal/
timeout and started removing itself from the queue. It updates its
requeue_state but can not remove it from the list because this requires
the hb lock which is owned by task B.
Usually task A is able to swoop the lock after task B unlocked it.
However if task B is of higher priority then task A may not be able to
wake up in time and acquire the lock before task B gets it again.
Especially on a UP system where A is never scheduled.
As a result task A blocks on the lock and task B busy loops, trying to
make progress but live locks the system instead. Tragic.
This can be fixed by removing the top most waiter from the list in this
case. This allows task B to grab the next top waiter (if any) in the
next iteration and make progress.
Remove the top most waiter if futex_requeue_pi_prepare() fails.
Let the waiter conditionally remove itself from the list in
handle_early_requeue_pi_wakeup().
Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT") Reported-by: Moritz Klammler <Moritz.Klammler@ferchau.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260428103425.dywXyPd3@linutronix.de Closes: https://lore.kernel.org/all/VE1PR06MB6894BE61C173D802365BE19DFF4CA@VE1PR06MB6894.eurprd06.prod.outlook.com
WANG Rui [Mon, 27 Apr 2026 08:47:21 +0000 (16:47 +0800)]
efi/libstub: Synchronize instruction cache after kernel relocation
The relocated kernel image is copied to its new location using memcpy().
On architectures with separate instruction and data caches, the copied
instructions may remain stale in the instruction cache, leading to the
execution of outdated contents.
Call efi_cache_sync_image() after the relocation copy to ensure the
instruction cache is synchronized with the updated memory contents before
control is transferred to the relocated kernel.
efi/libstub: Move efi_relocate_kernel() into its only remaining user
LoongArch is the only arch that still uses efi_relocate_kernel(), so
before making changes to it that LoongArch needs, turn it into a private
function. Move efi_low_alloc_above() into mem.c while at it, and drop
the relocate.c source file altogether.
Tested-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cássio Gabriel [Mon, 27 Apr 2026 22:13:28 +0000 (19:13 -0300)]
sound: oss: dmasound: kick queued output before extending tail fragment
sq_write() currently clears POST and then immediately appends
to the current rear fragment.
If the queue already contains complete fragments ahead of that
incomplete tail, playback is not kicked until the queue-full wait
path or the final sq_play() at the end of the write. That wastes
the slack those queued samples would otherwise provide while the driver
spends more time copying and translating more data into the tail fragment.
All in-tree dmasound playback backends still refuse to queue
an incomplete last fragment while !syncing, but they can start
earlier complete fragments.
Call sq_play() immediately after clearing POST and before extending
the rear fragment so already-queued complete output can start earlier.
Cássio Gabriel [Mon, 27 Apr 2026 15:36:49 +0000 (12:36 -0300)]
ALSA: wavefront: add suspend and resume support
The WaveFront driver still lacks support for suspend and resume
in both the ISA and PnP driver tables.
Wire the driver into ALSA PM by storing the WSS codec pointer in the card
private data and adding shared suspend/resume callbacks. Resume cannot
simply rerun snd_wavefront_start(), because with the default fx_raw=1
setting that would reset the synth on every resume and discard uploaded
WaveFront RAM contents.
Cache wavefront.os for PM, probe the ICS2115 after resume and only run
the full reset/bootstrap path when the board comes back raw. When the
firmware is still running, refresh the software slot bookkeeping and
restore the MIDI routing state without forcing a synth reset.
Also quiesce and restart the WaveFront MIDI output timer across suspend
and resume so active rawmidi output does not race the PM transition.
This restores the card to a usable baseline after resume while preserving
uploaded samples and programs when the hardware state survives suspend.
If the board resumes raw, userspace still needs to reload custom synth
contents.
ALSA: hda/tas2781: Fix incorrect bit update for non-book-zero or book 0 pages >1
In TAS2781 SPI mode, when accessing non-book-zero or page numbers greater
than 1 in book 0, an additional byte must be read. The first byte in such
cases is a dummy byte and should be ignored.
Bitterblue Smith [Sat, 25 Apr 2026 19:32:58 +0000 (22:32 +0300)]
wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor
Bit 28 of double word 2 in the RX descriptor indicates if the packet is
a normal 802.11 frame, or a message from the wifi firmware to the
driver (Card 2 Host).
Commit f5678bfe1cdc ("rtlwifi: rtl8821ae: Replace local bit manipulation
macros") mistakenly made the driver look for this bit in double word 1,
causing packet loss and Bluetooth coexistence problems.
Fixes: f5678bfe1cdc ("rtlwifi: rtl8821ae: Replace local bit manipulation macros") Cc: <stable@vger.kernel.org> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/04da7398-cedb-425a-a810-5772ab10139d@gmail.com
ALSA: hda: cs35l56: Fix uninitialized value in cs35l56_hda_read_acpi()
Eliminate the uninitialized 'nval' in cs35l56_hda_read_acpi() if a
system-specific quirk overrides processing of the dev-index property.
The value is now stored in a new 'num_amps' member of struct cs35l56_hda
so that the quirk handler can set the value.
The quirk for the Lenovo Yoga Book 9i GenX replaces the values from the
dev-index property with hardcoded indexes. So cs35l56_hda_read_acpi() would
then skip reading the property. But this left the 'nval' local variable
uninitialized when it is later passed to cirrus_scodec_get_speaker_id().
Fixes: 40b1c2f9b299 ("ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX") Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/linux-sound/aenFesLAStjrVNy8@stanley.mountain/T/#u Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260428130531.169600-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda/conexant: Fix missing error check for jack detection
In cx_probe(), the return value of snd_hda_jack_detect_enable_callback()
is ignored. This function returns a pointer, and if it fails (e.g., due
to memory allocation failure), it returns an error pointer which must
be checked using IS_ERR().
If the registration fails, the driver continues to probe, but the jack
detection callback will not be registered. This can lead to a kernel
crash later when the driver attempts to handle jack events or accesses
the uninitialized structure.
Check the return value using IS_ERR() and propagate the error via
PTR_ERR() to the probe caller.
ALSA: hda: Avoid WARN_ON() for HDMI chmap slot checks
At parsing the channel mapping for HDMI, the current code may spew
WARN_ON() unnecessarily for the case where only invalid (zero) channel
maps are given from the hardware. Drop WARN_ON() and reorganize the
code a bit for avoiding the hdmi_slot over the array size.
Dian-Syuan Yang [Fri, 24 Apr 2026 07:25:52 +0000 (15:25 +0800)]
wifi: rtw89: disable CSI STBC for VHT 160MHz
Fix interoperability problem where CSI feedback with STBC enabled at
VHT 160MHz BW cannot be properly decoded by certain APs, causing CSI
reports to be rejected. This problem is specific to Wi-Fi 7 chips,
as Wi-Fi 6 defaults to 20MHz CSI BW. Therefore, disable STBC encoding
for CSI transmission in VHT 160MHz mode to ensure CSI feedback is
accepted by these APs and maintain smooth throughput.
wifi: rtw89: pci: no need to wait CLK ready for RTL8922DE
The bit is to wait for CLK ready when entering PCIE L1SS. However, a
certain host might not enable CLK for a situation, causing device state
stuck and trigger PCIE SER. Unset this bit as default like earlier chips.
wifi: rtw89: add bounds check on firmware mac_id in link lookup
The mac_id field in RX descriptors is 8 bits wide (0-255), but
assoc_link_on_macid[] has only RTW89_MAX_MAC_ID_NUM (128) entries.
While the driver currently assigns mac_id values below 128, the
descriptor value comes from firmware and is not validated before use
as an array index. Add a defensive bounds check in
rtw89_assoc_link_rcu_dereference() to guard against out-of-range
firmware values.
In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit
descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both
firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478),
causing an out-of-bounds read from the pre-allocated DMA buffer when
skb_put_data copies new_len bytes. The USB transport already validates
this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the
PCIe path does not.
Add a check that new_len does not exceed the DMA buffer size.
Zong-Zhe Yang [Mon, 20 Apr 2026 03:40:51 +0000 (11:40 +0800)]
wifi: rtw89: 8922d: update RF calibration flow for MLD
RF calibration (RFK) will record the results in HW RFK tables. SW can
select and configure the target HW RFK table to reuse the RFK result
on the target channel. Though the above can work as before, when MLD
runs eMLSR mode, a faster switching between links than SW is needed.
So, introduce a new working flow for MLD. With the new settings, HW
can easily switch RFK results between links during eMLSR mode.
Zong-Zhe Yang [Mon, 20 Apr 2026 03:40:50 +0000 (11:40 +0800)]
wifi: rtw89: chan: introduce new helper to get entity current configuration
The original helper can only queries target channel, but cannot determine
current role's status, e.g. is it MLD or not. These things should be a set.
Adding more and more helpers to query them individually without synchronous
doesn't seem right. Introduce a new helper to query current channel set and
role status.
Besides, when single channel, e.g. MLO_2_PLUS_0_1RF and MLO_0_PLUS_2_1RF,
the target channel pointer will be duplicated to fill the returned channel
set. So, some callers can save trivial things for these cases. The returned
channels will be non-NULL, so callers don't need trivial NULL check either.
The PD (Packet Detection) lower bound is set after the STA interface
connects. When the P2P interface attempts to find peers, it enters
the remain-on-channel flow to listen for probe requests. However, if
the RSSI of the connected AP is too high, the P2P interface fails to
receive it. To resolve this, suspend the DIG during the
remain-on-channel period.
The original flow checks the scan offload C2H event done ack to increase
the scan sequence. However, the scan offload response C2H event may be
received earlier than the scan offload C2H event done ack, which causes
these C2H event to be dropped by rtw89_fw_c2h_purge_obsoleted_scan_events()
check because the scan sequence of the scan offload response C2H event
is less than the scan offload C2H event done ack. Therefore, checking
the scan offload C2H event recv ack instead of C2H event done ack to fix
this issue.
Eric Huang [Mon, 20 Apr 2026 03:40:45 +0000 (11:40 +0800)]
wifi: rtw89: use firmware offload for PHY and RF batch register writes
Use firmware offload to perform batch register writes for PHY and RF.
This reduces I/O operations, improves bus transfer efficiency, and
decreases hardware initialization time.
Performance improvement on USB 2.0 HCI:
- rtw89_phy_init_bb_reg: 61 ms -> 5 ms
- rtw89_phy_init_rf_reg: 587 ms -> 106 ms
Use offload-aware delay functions (do_udelay and do_mdelay) for the
delay calls in rtw89_phy_init_reg, rtw89_phy_config_rf_reg, and
rtw89_phy_config_rf_reg_v1 to ensure compatibility with batch register
writes.
Chia-Yuan Li [Mon, 20 Apr 2026 03:40:44 +0000 (11:40 +0800)]
wifi: rtw89: offload DMAC and CMAC init IO to firmware
During the initialization of DMAC and CMAC, the driver performs a
large number of consecutive register writes. Sending these I/O
requests individually over the host interface introduces significant
latency and delays the device bring-up process.
Optimize the initialization flow by wrapping the register write
sequences in mac.c and mac_be.c with rtw89_io_pack() and
rtw89_io_unpack(). This batches the operations and offloads them
to the firmware via H2C commands, which significantly accelerates
the overall initialization time.
(8852C USB2.0 AMD B450 1379 ms -> 1273 ms)
Chia-Yuan Li [Mon, 20 Apr 2026 03:40:43 +0000 (11:40 +0800)]
wifi: rtw89: add IO offload support via firmware
Offload register write operations to the firmware to improve IO efficiency.
Instead of the host performing direct bus access for every register, the
operations are now encapsulated into firmware commands.
This implementation allows the host to aggregate multiple register write
actions into a single command buffer. By batching these operations, we
reduce the number of individual transactions on the bus and minimize
per-transfer overhead, leading to faster overall IO performance.
Add a support_fw_cmd_ofld field to the chip_info structure to control
whether firmware-offloaded batch writes are enabled. Enable it by
default for RTL8832CU.
Co-developed-by: Eric Huang <echuang@realtek.com> Signed-off-by: Eric Huang <echuang@realtek.com> Co-developed-by: Johnson Tsai <wenjie.tsai@realtek.com> Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com> Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260420034051.17666-9-pkshih@realtek.com
Shin-Yi Lin [Mon, 20 Apr 2026 03:40:41 +0000 (11:40 +0800)]
wifi: rtw89: Correct data type for scan index to avoid infinite loop
A kernel soft lockup was observed during Wi-Fi scanning on the 6GHz band.
The CPU becomes stuck in rtw89_hw_scan_add_chan_ax for over 20 seconds,
leading to a system panic.
RIP points to 0f b6 c3 (movzbl %bl, %eax), which zero-extends
the low 8 bits of RBX into RAX.
RBX (the counter i) has reached a huge value: 0x137466a1.
Eric Huang [Mon, 20 Apr 2026 03:40:40 +0000 (11:40 +0800)]
wifi: rtw89: phy: support static PD level setting
PD (Packet Detection) threshold is a key parameter in the DIG
(Dynamic Initial Gain) algorithm that determines the sensitivity
of packet detection. Current implementation only supports dynamic
PD adjustment based on environment. This patch adds support for
static PD threshold via debugfs allowing users to set a fixed PD
value for testing or specific scenarios.
Johnson Tsai [Mon, 20 Apr 2026 03:40:39 +0000 (11:40 +0800)]
wifi: rtw89: debug: disable inactive power save to reduce bus overhead
This helps avoid excessive bus traffic and I/O overhead on
slower HCIs (e.g., USB, SDIO) caused by frequent power state
transitions.
Add RTW89_DM_INACTIVE_PS to the disabled_dm bitmap via debugfs and
check it in the rtw89_enter_ips path. When set, the driver skips
entering inactive power save and returns immediately.
Johnson Tsai [Mon, 20 Apr 2026 03:40:38 +0000 (11:40 +0800)]
wifi: rtw89: debug: disable hw_scan for latency-sensitive scenarios
This helps avoid scan-triggered off-channel activity during
latency-sensitive scenarios.
Add RTW89_DM_HW_SCAN to the disabled_dm bitmap via debugfs and
check it in the hw_scan path. When set, the driver rejects hw_scan
requests and returns -EBUSY.
wifi: rtw89: 8852a: refine power save to lower latency
Improve user experience while using interactive applications.
Adjust power saving decisions under different scenarios.
Minimize latency for delay-sensitive connections by exiting
power-save on packet bursts and maintain active until a period
of inactivity is reached. For connections that are not that
sensitive to delays, keep the current aggressive power save logic.
The commit 127ea8d0b068 ("wifi: rtw89: fix typo "frome" -> "from" in rx_freq_frome_ie")
change the struct field to correct the typo, but miss to fix this for
RTL8922D because it is submitting at the same time.
As RTL8922D is not enabled yet, this build error doesn't appear.
Johan Hovold [Tue, 7 Apr 2026 09:50:27 +0000 (11:50 +0200)]
clk: rk808: fix OF node reference imbalance
The driver reuses the OF node of the parent multi-function device but
fails to take another reference to balance the one dropped by the
platform bus code when unbinding the MFD and deregistering the child
devices.
Fix this by using the intended helper for reusing OF nodes.
Fixes: 2dc51ca822e4 ("clk: RK808: Reduce 'struct rk808' usage") Cc: stable@vger.kernel.org # 6.5 Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Brian Masney [Wed, 15 Apr 2026 20:30:49 +0000 (16:30 -0400)]
MAINTAINERS: add myself as a reviewer for the clk subsystem
I've reviewed a lot clk patches for parts of the subsystem that
typically doesn't get much review. Add myself as a reviewer so that I
don't miss anything.
J. Neuschäfer [Tue, 3 Mar 2026 15:25:18 +0000 (16:25 +0100)]
clk: hisilicon: Improve deallocation in error path
Unmap 'base' if an error occurs after it has been mapped.
Reported-by: Tao Lan <taolan@huawei.com> Closes: https://lore.kernel.org/lkml/ZNlSH+eWV8Sk3FYn@probook/ Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
projects / thirdparty / kernel / linux.git / log
