- Fix timerlat top actions triggering on signal
Fix a bug in RTLA's timerlat top actions feature where on-threshold
actions are triggered on any signal, regardless of whether a latency
spike had actually occurred during the measurement.
The return retval was checked for non-zero to do actions. But if a
signal came in, it returns a negative and actions were being
incorrectly triggered when they should not have been.
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCamzXpBQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6qnQHAQDso34IvlbyNqDUroLLfV7f+Qsikyvz
OVxp9Q+b2F+57QD9H7k0OxDFfkycTFUpBaCKv1jmOXIqaGE9M1QbwE+eZgA=
=3ND6
-----END PGP SIGNATURE-----
Merge tag 'trace-tools-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull RTLA fix from Steven Rostedt:
- Fix timerlat top actions triggering on signal
Fix a bug in RTLA's timerlat top actions feature where on-threshold
actions are triggered on any signal, regardless of whether a latency
spike had actually occurred during the measurement.
The return retval was checked for non-zero to do actions. But if a
signal came in, it returns a negative and actions were being
incorrectly triggered when they should not have been.
* tag 'trace-tools-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
rtla/timerlat_top: Fix on-threshold actions firing on signal
utf8_normalize() was added in 2019 as part of
commit 9d53690f0d ("unicode: implement higher level API for string
handling")
but has remained unused.
(I think because the other higher level routines added by that patch
normalise as part of their operations)
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
cpu is taken from pgoff & 0xffff. cpu_online() does not reject cpu >=
nr_cpu_ids, and per_cpu_ptr() can then walk off __per_cpu_offset.
Signed-off-by: Yi Xie <xieyi@kylinos.cn>
Reviewed-by: Naman Jain <namjain@linux.microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
mshv_partition_ioctl_create_vp() called anon_inode_getfd() before
publishing the new VP into partition->pt_vp_array. anon_inode_getfd()
includes fd_install(), so the fd was live in current->files before the
publish ran.
A concurrent MSHV_RUN_VP ioctl on that fd does not serialise against the
in-progress MSHV_CREATE_VP — it takes vp->vp_mutex, not the partition
mutex. Once the VP starts running and traps, mshv_intercept_isr() can look
up partition->pt_vp_array[vp_index] and observe NULL, silently dropping the
intercept message.
Split the fd creation: reserve an fd with get_unused_fd_flags(), create the
file with anon_inode_getfile(), publish the VP via smp_store_release(), and
finally call fd_install() as the userspace-visibility commit point.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
VMBus sends CHANNELMSG_INITIATE_CONTACT through a Hyper-V message
connection ID. Older protocol versions use VMBUS_MESSAGE_CONNECTION_ID,
while protocol version 5.0 and newer normally use
VMBUS_MESSAGE_CONNECTION_ID_4.
For a VTL2 kernel using VMBus protocol 5.0 or newer, the host
may expect INITIATE_CONTACT on either the redirect connection ID or
VMBUS_MESSAGE_CONNECTION_ID_4. There is no capability indication that
identifies which ID is active, so the driver must determine it at runtime.
During VMBus negotiation, the redirect ID is tried first because it is
used by VTL2 configurations with VMBus redirection enabled. If the
redirect ID is unavailable, the host rejects it synchronously with
HV_STATUS_INVALID_CONNECTION_ID, allowing fallback to the standard ID.
Return a distinct error for an invalid Initiate Contact connection ID so
this fallback does not mask other post-message failures or
protocol-version rejections. Preserve the existing connection ID
selection for older protocol versions or when running below VTL2.
Signed-off-by: Hardik Garg <hargar@linux.microsoft.com>
Reviewed-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
Reviewed-by: Naman Jain <namjain@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
mshv_partition_ioctl_create_vp() initialises a VP struct (allocations,
mutex_init, init_waitqueue_head, page mappings) and then publishes the
pointer into partition->pt_vp_array. Several ISR paths read this array
locklessly: the intercept ISR, the two scheduler ISRs, and
mshv_try_assert_irq_fast() on the irqfd fast path.
Of these, only mshv_try_assert_irq_fast() can structurally race the
publish. It runs from an eventfd waker without holding pt_mutex, and
MSHV_IRQFD does not require the target lapic_apic_id (== vp_index) to
refer to an existing VP at registration time. A user can therefore
register an irqfd targeting a yet-to-be-created VP, then trigger
mshv_try_assert_irq_fast() concurrently with MSHV_CREATE_VP for the
same index. On weakly-ordered architectures the reader can observe a
non-NULL pointer in pt_vp_array before the initialising stores to the
VP struct become visible, leading to use of partially-initialised
fields (e.g. vp_register_page).
The other ISR readers cannot reach this race: the hypervisor will not
generate intercept or scheduler messages for a VP that has never been
told to run, and the user can only call MSHV_RUN_VP on the VP fd
returned by MSHV_CREATE_VP, which by construction is returned after
the publish. Leave those readers as plain loads.
Use smp_store_release() in mshv_partition_ioctl_create_vp() to publish
the pointer, and pair it with smp_load_acquire() in
mshv_try_assert_irq_fast(). On x86 these compile to plain accesses
under TSO; on ARM64 they emit one-instruction acquire/release barriers,
acceptable on this fast path.
The destroy-side path (destroy_partition() clearing pt_vp_array[i] to
NULL after kfree(vp)) has a separate ordering and lifetime concern
that is out of scope here.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
In mshv_partition_ioctl_create_vp(), when kzalloc for the VP struct
fails, the code jumps to the cleanup path without setting ret. At that
point ret is 0 from the preceding successful mshv_vp_stats_map() call,
so the function returns success to userspace despite having failed to
create the VP. No fd is installed and no VP is registered in pt_vp_array,
but userspace has no way to know the operation failed.
Set ret to -ENOMEM before jumping to the cleanup path.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
In mshv_irqfd_assign(), the level-triggered validation for resample
irqfds checks irqfd_lapic_irq.lapic_control.level_triggered before
mshv_irqfd_update() has populated the field. Since the irqfd struct is
zero-allocated, level_triggered is always 0 at that point, causing the
check to always reject resample irqfds with -EINVAL. This makes
level-triggered interrupt resampling — used to avoid interrupt storms
with assigned devices — completely non-functional.
Move the check after the mshv_irqfd_update() call, which resolves the
IRQ routing entry and populates irqfd_lapic_irq with the actual trigger
mode.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
mshv_irqfd_deactivate() and the hlist traversal of pt_irqfds_list
require pt->pt_irqfds_lock to be held, but mshv_irqfd_deassign()
omits it. This races with the EPOLLHUP path in mshv_irqfd_wakeup(),
which does take the lock before calling mshv_irqfd_deactivate().
Additionally, mshv_irqfd_deactivate() uses hlist_del() which poisons
the node pointers rather than resetting them. Since
mshv_irqfd_is_active() relies on hlist_unhashed() (checks pprev ==
NULL), a poisoned node still appears active. If a concurrent path calls
mshv_irqfd_deactivate() again on the same irqfd, the guard fails to
prevent a double hlist_del() on poisoned pointers.
Fix both issues:
- Add the missing spin_lock_irq/spin_unlock_irq around the list
traversal in mshv_irqfd_deassign(), matching mshv_irqfd_release().
- Use hlist_del_init() instead of hlist_del() so the node is properly
marked as unhashed after removal, making the is_active guard reliable.
Fixes: 621191d709 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
mshv_portid_free() uses synchronize_rcu() followed by kfree() to
reclaim port table entries. This blocks the caller until a full RCU
grace period elapses, which is unnecessary since the same module already
uses the non-blocking kfree_rcu() pattern in mshv_port_table_fini().
Replace with kfree_rcu() to avoid the blocking wait and keep the
reclamation strategy consistent across the file.
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Reviewed-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
We have seen cases when the delay reporting unexpectedly behaves incorrectly,
counters are not counting in hardware registers under seemingly random
conditions.
It turned out that there are few cases that the driver must handle in order
to make sure that LLP, PPLC counters are working correctly:
- non-alt links must not be reset during probe
- Concurrent (cross-direction) hazard: when SoundWire shares a physical
link DMA stream index with HDaudio, iDisp or UAOL across the two
directions, the LLP and timestamp values for the affected stream are
wrong. SSP and DMIC are not affected because every DMA request from
those links carries one sample block.
- Sequential (playback only) hazard: once a HDaudio or iDisp link has
used a playback stream index, that index cannot drive any non
HDA/iDisp link in the same direction until the next controller
reset (CRST#).
For users the impact was not visible as the link counter issue only affected
the delay reporting which already have defensive path to filter out
incorrect delays and the DSP caused delay for normal PCMs are negligible to
cause A/V sync issues for example.
Link: https://patch.msgid.link/20260730125130.29887-1-peter.ujfalusi@linux.intel.com
On ACE2+ platforms the link DMA stream allocator must avoid two
hardware errata in mlink-capable systems:
- Concurrent (cross-direction) hazard: when SoundWire shares a physical
link DMA stream index with HDaudio, iDisp or UAOL across the two
directions, the LLP and timestamp values for the affected stream are
wrong. SSP and DMIC are not affected because every DMA request from
those links carries one sample block.
- Sequential (playback only) hazard: once a HDaudio or iDisp link has
used a playback stream index, that index cannot drive any non
HDA/iDisp link in the same direction until the next controller
reset (CRST#).
Track the active link type per direction in two masks (one for SoundWire,
one for HDA/iDisp/UAOL) and the persistent set of playback stream
indices touched by HDA/iDisp in a third mask. The link DMA allocator
skips streams that would violate either rule. Streams are released from
the active masks when the stream is released; all masks are cleared in
hda_dsp_ctrl_init_chip() because the CRST# performed there clears the
hardware state as well.
A new helper hda_bus_ml_link_get_type() returns the link type from the
existing extended link descriptor so the SOF allocator can tell
SoundWire, HDA/iDisp and UAOL apart without duplicating the parsing.
The implementation is generic. On platforms older than ACE2 every link
is reported as HDA, only the sequential mask is ever set and it has no
effect because no other link types are present, so behavior is
unchanged.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The helper became unused after probe no longer drops all non-alt
links, so remove the dead API and implementation.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop the hda_bus_ml_put_all() call at the end of hda_init_caps().
On multi-link (mlink) capable platforms the non-alternate links
(HDaudio and iDisp) are powered on by hardware when CRST# is
de-asserted (LCTL.SPA = 1) and their ref_count is pre-charged to 1 in
hda_ml_alloc_h2link() to match this state. The put_all call
immediately dropped that reference and toggled LCTL.SPA back to 0,
relying on the first stream open to power the link up again.
On ACE2+ platforms this redundant SPA 1->0->1 toggle at probe leaves
the Processing Pipe Capability (PPLC) Linear Link Position counters in
a state where they do not advance on the first stream after boot. The
counters only start working after the first full runtime suspend/resume
cycle, which includes a CRST# assert/deassert that fully resets the PPC
AON block.
Keep the non-alt links powered from CRST# de-assert through first use.
System suspend still powers them down via hda_bus_ml_suspend(), and
resume relies on CRST# de-assert to bring them back up, so no other
path is affected.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the hda_bus_ml_init() call from hda_init_caps() into
hda_dsp_ctrl_init_chip(), right after the HDA controller reset has
been de-asserted and unsolicited responses have been accepted.
hda_dsp_ctrl_init_chip() already calls hda_bus_ml_reset_losidv() at
the end of its sequence to clear the stream-to-link mapping. On first
boot this call was a no-op because the multi-link list had not yet
been populated: hda_bus_ml_init() only runs later in hda_init_caps().
Enumerating the links inside init_chip() makes the LOSIDV reset
effective on first boot as well, without adding a second reset call
from the probe path.
hda_bus_ml_init() now returns early when the hlink_list is already
populated, so the subsequent invocations from the D3 resume path
(hda_resume() -> hda_dsp_ctrl_init_chip(false)) are no-ops.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Yiyang Chen says:
====================
bpf: Preserve pointer state for commuted arithmetic
This series fixes pointer-state propagation for commuted scalar += pointer
arithmetic in the verifier.
Patch 1 simplifies sanitize_err() before the pointer-state change. Patch 2
keeps the full pointer register state when the pointer operand is the source
of the add, preserving fields such as the stack frame number and parent id.
Patch 3 moves the untrusted PTR_TO_MEM early return after state propagation,
so scalar += untrusted_pointer remains usable through the probe-read path.
Patch 4 adds verifier selftests for stack frame number preservation,
readonly-untrusted memory access, and dynptr data-slice invalidation.
Changes in v4:
- Target the bpf fixes tree because the affected behavior is present in
released kernels.
- Add Eduard's sanitize_err() cleanup and revised pointer-state patch, reusing
the caller's temporary offset register instead of verifier-env scratch
storage.
- Correct the stack-frame Fixes tag to the BPF-to-BPF call verification
commit identified by Shung-Hsi.
- Fix the dynptr test comment style and retain the source-register clear so
the test isolates parent-id propagation.
- Carry Daniel Wade's Tested-by and Eduard's selftest Acked-by from the v3
thread.
- Rebase to bpf base 0ce37745d4.
Changes in v3:
- Preserve the complete pointer register state with verifier-env scratch
storage, addressing Eduard's comment that copying selected fields is
fragile and avoiding a temporary bpf_reg_state on the verifier stack.
- Keep the existing RUN(verifier_basic_stack) dispatch unchanged and add the
stack regression directly to the existing verifier_basic_stack program.
- Keep the original operand direction inside adjust_ptr_min_max_vals() by
saving the scalar operand in env->fake_reg[0].
- Move untrusted PTR_TO_MEM handling after the unified pointer-state copy so
the commuted form remains PTR_TO_MEM before the early return.
- Add readonly-untrusted and dynptr selftest coverage, responding to the
bpf-ci/static review finding that the untrusted pointer case needs a
regression test.
- Clear the original dynptr data-slice register after deriving the commuted
alias so the regression test isolates parent-id propagation.
- Make the readonly-untrusted return value endian-neutral by loading an int.
- Rebase to bpf-next base a23a718233.
v3: https://lore.kernel.org/bpf/cover.1784696371.git.chenyy23@mails.tsinghua.edu.cn/
v2: https://lore.kernel.org/bpf/cover.1784563950.git.chenyy23@mails.tsinghua.edu.cn/
v1: https://lore.kernel.org/bpf/cover.1784563939.git.chenyy23@mails.tsinghua.edu.cn/
---
====================
Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-0-8ee297e2346b@mails.tsinghua.edu.cn
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Add verifier coverage for the three cases affected by preserving the full
pointer state across scalar += pointer: stack frame number inheritance,
readonly-untrusted memory access, and dynptr data-slice invalidation.
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
Tested-by: Daniel Wade <danjwade95@gmail.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-4-8ee297e2346b@mails.tsinghua.edu.cn
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
The untrusted PTR_TO_MEM early return skips pointer offset tracking
because accesses go through probe-read handling. Moving it after full
pointer-state propagation ensures scalar += untrusted_pointer leaves the
destination as PTR_TO_MEM instead of an unrelated scalar.
Fixes: f2362a57ae ("bpf: allow void* cast using bpf_rdonly_cast()")
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
Tested-by: Daniel Wade <danjwade95@gmail.com>
Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-3-8ee297e2346b@mails.tsinghua.edu.cn
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
When scalar += pointer is handled in adjust_ptr_min_max_vals(), the
destination register inherits the pointer state from the source pointer.
Copying only selected fields is fragile because pointer provenance is
tracked by several bpf_reg_state fields.
Use the caller's temporary offset register to preserve the scalar operand
while replacing the destination with the full pointer state. This preserves
the frame number for PTR_TO_STACK registers and keeps parent identity
fields consistent.
Fixes: f4d7e40a5b ("bpf: introduce function calls (verification)")
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
Tested-by: Daniel Wade <danjwade95@gmail.com>
Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-2-8ee297e2346b@mails.tsinghua.edu.cn
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
The sanitize_err() function is called when:
- ptr += scalar
- scalar += ptr
- scalar += scalar
ALU operations are processed.
This commit drops offset and pointer registers parameters from its
signature to simplify the follow-up changes for 'scalar += ptr' case.
regs[src].type is safe to access, as it is not mutated by the callers.
Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-1-8ee297e2346b@mails.tsinghua.edu.cn
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
It is expected that the DSP is in power down state when the firmware boot
is attempted.
If the DSP for any reason was left powered up then the DSP boot will
fail since the ROM boot sequence might not be able to run.
Make sure that the DSP is off before proceeding to boot it up.
We have seen reports that for some undetermined reasons the DSP was on
during system boot and this caused firmware boot failure as the DSP
cannot be booted up - it was already in booted up state.
Link: https://patch.msgid.link/20260730122857.5294-1-peter.ujfalusi@linux.intel.com
It is expected that the DSP is in power down state when the firmware boot
is attempted.
If the DSP for any reason was left powered up then the DSP boot will
fail since the ROM boot sequence might not be able to run.
Make sure that the DSP is off before proceeding to boot it up.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730122857.5294-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is expected that the DSP is in power down state when the firmware boot
is attempted.
If the DSP for any reason was left powered up then the DSP boot will
fail since the ROM boot sequence might not be able to run.
Make sure that the DSP is off before proceeding to boot it up.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730122857.5294-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to make "cc -E" output less annoying, this commit converts
cond_resched_tasks_rcu_qs() to static inline. You know, the READ_ONCE()
and WRITE_ONCE() macros used to be *so* simple. ;-)
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
The drip of driver specific fixes, mostly from the device vendors
themselves, keeps on coming in. There's more than I'd like right now
but equally nothing hugely alarming.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmps47sACgkQJNaLcl1U
h9DonAf/S1AkgEGMws3rJCTH+Bcb7ON9Xvsbjv2rU/CI7lINpSJzbUUJ1Z0qk8KX
NaK8ByXBDvn06qS/6hirwuNl/lfJ69XNWSlV8MJGWXHfui2sN6ngFJy9jnTIQY72
bq0rTEPapAFg86Loare1i1nHSomLnICoq/KveE08muiPoBtjFKzP7AF7gDmfN0ot
g3x39WL6bLY/qrqVw1aT/tqdVl97os/e2EJIx8lxh1M5waN/kpfFoRD/dVbdO6ZU
8iOKPzIeMco0r1JOtGq2q7JCiHN9DP8+Enyf6hkkgBS/HPEHJkO10t9PAY/ArR12
/KNB7i/i/O35ChESDgk70mcuToLbgg==
=g0xm
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"The drip of driver specific fixes, mostly from the device vendors
themselves, keeps on coming in. There's more than I'd like right now
but equally nothing hugely alarming"
* tag 'spi-fix-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: spi-nxp-fspi: propagate clock reconfig failures in nxp_fspi_select_mem()
spi: spi-nxp-fspi: enter stop mode before reconfiguring MCR0 and DLL
spi: spi-nxp-fspi: add per-SoC SDR/DTR clock rate limits for all supported SoCs
spi: spi-qpic-snand: write the feature value before executing SET_FEATURE
spi: spi-cadence: Move TX FIFO full busy-wait into FIFO
spi: qcom-qspi: Correct max DMA length to avoid 64K boundary failure
spi: spacemit: prepare both DMA descriptors before submitting
Two error paths in amdxdna_insert_pages() called vma->vm_ops->close(vma)
before returning an error code to the caller. This is incorrect:
amdxdna_gem_obj_mmap() registers an HMM interval notifier before calling
amdxdna_insert_pages(), and on a hard error it jumps to hmm_unreg to undo
that registration. Calling vm_ops->close() manually — which drops the
shmem pages_pin_count and the GEM object reference that backs the VMA —
before the mmap syscall has even returned causes those resources to be
released while the VMA is still alive. The kernel VMA teardown will call
vm_ops->close() a second time when the process later unmaps the range,
producing a reference count underflow.
Replace both hard-error returns with a deferred-fault approach that keeps
the VMA alive and retries page insertion through the HMM range-fault path.
Fixes: e486147c91 ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260723074256.2435143-1-lizhi.hou@amd.com
The VPOSNEG_table[] mapping does not match the FP9931 datasheet.
The datasheet defines the VPOS/VNEG voltage mapping as:
00h-04h -> 7.04V (-7.04V)
05h -> 7.26V (-7.26V)
06h -> 7.49V (-7.49V)
...
28h-3Fh -> 15.06V (-15.06V)
However, VPOSNEG_table[] has two issues:
1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the
table has 6 entries of 7.04V, causing all subsequent entries to be
shifted by one position.
2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but
the table has only 41 entries. Any selector value above 0x28
would result in an out-of-bounds table access.
Fix both issues by removing the duplicate 7.04V entry and appending
the missing 23 clamped 15.06V entries, bringing the table to the
correct size of 64 entries (0x00~0x3F).
Fixes: 12d821bd13 ("regulator: Add FP9931/JD9930 driver")
Signed-off-by: Robby Cai <robby.cai@nxp.com>
Link: https://patch.msgid.link/20260724103441.800522-2-robby.cai@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
* Changes for dynamic EPP
* Adjustments to the bios min perf feature
* Fixes to kernel doc
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEECwtuSU6dXvs5GA2aLRkspiR3AnYFAmprwUITHHN1cGVybTFA
a2VybmVsLm9yZwAKCRAtGSymJHcCdobfD/9dkDCf6Go6vAt31Z1PnnJfPKtl7+2n
CzwKu5+Fx+/4nsJ/MiiDtQ5gJ6q9Pn0NA05vm6fuLhXznzAoWYExi+b3YRNWttyh
0om7PZfrLWS6oCYl+DC/zu6cL8TBZJweqAEYcNBxRKAKXP5Icgpefrpj+lOW5asr
YSl9b1cU2NboUksfWqfRGDmDCwKMKsBuZGlEMV8DgpnVJo0A2t8UmXCesUmd+hzP
LOupRKZlVUkYHeHOGuRnwSkKMoSyzcJjW7oCbkZfLOTjM2KXZ3AEadyNG257H4U5
PqGSA56EkDqycBuQzZKE6Ayz/mCWmNrB+jd/RjViARVNkUdNy+S8qafVuHEwG0RB
L5rWef76BKvhK1dAVZ512cidWEfp4Rw2iDaF7o4LUDysCmThAI2VZ+e6uxs6We4R
2Qe8l6KIxXt9bmf704q9jo62DKzdIve9PV5Y/WRcBft3NqvNmIu/VReIm29LqdDq
3cYWODH3Lg0kVwaB1jY5n8XAEThhEnB1T4iVWJyfeAX+F4WuSRslM/8sJgdZG3uf
kIkCbzMa3z5y7cASQCKdfQDzaxf6Vw7oX8c30UzZE5+PYcTuWuLQl6fclddXj1W7
TEYG1NskvtgETTLA1QXb5JTJYNcGHvUwd+Ng5O7robQ7QSaUGvIw4uHUsLQXG9DI
JvjxN/NNdJTRQg==
=8o8O
-----END PGP SIGNATURE-----
Merge tag 'amd-pstate-v7.3-2026-07-30' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux
Pull amd-pstate 7.3 content (07/30/26) from Mario Limonciello:
"* Changes for dynamic EPP
* Adjustments to the bios min perf feature
* Fixes to kernel doc"
* tag 'amd-pstate-v7.3-2026-07-30' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
cpufreq/amd-pstate: Document missing kernel-doc members
cpufreq/amd-pstate-ut: Add unit test for CPPC Performance Priority
cpufreq/amd-pstate-ut: Add unit test for "dynamic" EPP mode
cpufreq/amd-pstate: Reduce the scope of exported symbols
Documentation/amd-pstate: Update dynamic_epp documentation with new behavior
cpufreq/amd-pstate: Remove "amd_dynamic_epp" cmdline and "dynamic_epp" sysfs
cpufreq/amd-pstate: Add dynamic EPP as an "energy_performance_preference" mode
cpufreq/amd-pstate: Extract platform profile to EPP conversion into a helper
cpufreq/amd-pstate: Remove the defensive check for bios_min_perf
cpufreq/amd-pstate: Set min_limit_freq based on bios_min_perf
Since arch_freq_get_on_cpu() on x86 falls back to cpufreq_quick_get(),
which effectively causes policy->cur to be returned when intel_pstate
is used, adjust intel_pstate_set_policy() to set policy->cur to reflect
the P-state that is actually going to be requested in the "performance"
policy case instead of setting it to policy->min (which is confusing
because it causes scaling_cur_freq to show the minimum frequency while
the CPU is likely running at the maximum one).
For this purpose, rearrange intel_pstate_set_policy() to handle the HWP
case separately, to avoid calling intel_pstate_set_pstate() pointlessly
with HWP enabled, and use the observation that with HWP enabled in the
active mode, the utilization update hook is only needed when HWP boost
is used and the policy is not "performance".
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Doug Smythies <dsmythies@telus.net>
Tested-by: Doug Smythies <dsmythies@telus.net>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/5144014.31r3eYUQgx@rafael.j.wysocki
A call to listxattr() with a buffer size of 0 returns the actual
size of the buffer needed for a subsequent call. On an NFSv4.2
mount this triggers the following oops:
[ 399.768687] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 399.768705] RIP: 0010:_copy_from_pages+0x44/0xe0
[ 399.768722] Call Trace:
[ 399.768723] nfs4_xattr_alloc_entry+0x1bf/0x1e0
[ 399.768730] nfs4_xattr_cache_set_list+0x43/0x1f0
[ 399.768731] nfs4_listxattr+0x21f/0x250
[ 399.768733] vfs_listxattr+0x55/0xa0
[ 399.768736] listxattr+0x23/0x160
[ 399.768737] path_listxattrat+0xba/0x1e0
[ 399.768739] do_syscall_64+0xe2/0x680
security_inode_listsecurity() (via the xattr_list_one() helper) now
decrements the remaining size even when the buffer pointer is NULL, so
in the size-query case, 'left' underflows to a huge size_t value. As a
result, nfs4_listxattr_nfs4_user() treats the NULL buffer as a real one,
leading to a NULL pointer dereference in _copy_from_pages().
security_inode_listsecurity() does not return the number of bytes
it added to the list, so the code derived it as
'size - error - left'. That is also wrong in the size-query case:
the generic_listxattr() contribution is only subtracted from 'left'
when a buffer is present. Thus, the query result comes up short by
exactly that contribution (e.g., "system.nfs4_acl" on a mount with
ACL support), and a caller that allocates the returned size gets
-ERANGE on the subsequent call.
Declare 'left' as ssize_t, use a scratch copy to measure security
hook consumption, and only decrement 'left' if a buffer is present.
Fixes: f71ece9712 ("security,fs,nfs,net: update security_inode_listsecurity() interface")
Suggested-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Achilles Gaikwad <achillesgaikwad@gmail.com>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Anna Schumaker <anna.schumaker@hammerspace.com>
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmpsv30UHGJoZWxnYWFz
QGdvb2dsZS5jb20ACgkQWYigwDrT+vx05BAAlX0ggF2vDuKKQK1Q67oBANG+ANZq
wAyMibleGWHvUfknsxcioGoXr+oZrI2fbuvaz1id2Tlx3vByfYiSihrNz4BrDbny
H+YD2Mqhz0aaanb+G1WEqRndCyRLtYmsr0cUAp7giBh22t43tgdIBvKr2PsCsKCo
WiEUP/QvxYuiJ73g6s7RqbwIYSzk/9MMSDhoO83c/gRZcY/r47KY19ysLevQ/176
h0xC73EV6UF0dqe485jt24/zzYkN70zV3FscPMLkU7s0Fd2jzRm/zktS7tbLTUg2
PZwqCnHc4dytoqEmcycrQHGNiPRQCCOnqcsSlWcMzPPBdYCR1EUictiYXgq0Bd4T
EvvjHHl3/9IVCWgkz7rKmLz8V7GWoJSH11Ykh3AWWc7roFsTn1UH2YY+85/Asfv+
/vuo2G7zskKE5WOSaEOLBvYi84FRge3FxA3XPgMYTOePTqIpjjJ6eglZRmxEhid5
IrJhaB0O9kNuRR3Nu85lgHqL35Pp5AUVOLqyXELvcbBBJHtm1PTgjAZjyRIm0Rn7
YINhuQr3gw+3vKaXGB8qHqXMG1/hdMkHH9t6LEqAqFtRrTZjzquGg5oFnJOYINCL
VinNH6/G1qIYBThTVDMeVSTUqCbkz97eedzyGo92oqpUdhseWyaaV4vwW1ss4DWv
QSN25brLKheYiKk=
=YyK4
-----END PGP SIGNATURE-----
Merge tag 'pci-v7.2-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull pci fixes from Bjorn Helgaas:
- Remove Karthikeyan Mitran from Mobiveil MAINTAINERS PCIe entry since
email bounces (Manivannan Sadhasivam)
- Preserve i.MX6Q, i.MX6QP, and i.MX6SX Root Port MSI/MSI-X
Capabilities when using iMSI-RX to work around hardware defect
(Soeren Moch)
- Reorder i.MX6Q/DL PHY power up to fix boot hang regression (Richard
Zhu)
* tag 'pci-v7.2-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI: imx6: Fix i.MX6Q/DL boot hang caused by improper PHY power sequencing
PCI: imx6: Keep i.MX6 Root Port MSI/MSI-X Capabilities with iMSI-RX to work around hardware bug
MAINTAINERS: Drop Karthikeyan Mitran from Mobiveil PCIe entry
Some host bridge devices require resetting the Root Ports in a platform
specific way to recover them from error conditions such as Fatal AER
errors, Link Down, etc. Introduce pci_host_bridge::reset_root_port()
callback and call it from pcibios_reset_secondary_bus() if available. Also,
save the Root Port config space before reset and restore it afterwards.
The .reset_root_port() callback is responsible for resetting the given Root
Port referenced by the 'pci_dev' pointer in a platform-specific way and
bring it back to the working state if possible. If any error occurs during
the reset operation, relevant errno should be returned.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Tested-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-2-53570b92064d@oss.qualcomm.com
Link to the VFIO library only on architectures where it's actually needed,
i.e. only on architectures that support irq_test, which is currently
x86-only. The irq_test series, which pulled in VFIO support, effectively
raced with commit e65f1bf8a2 ("vfio: selftests: Extend container/iommufd
setup for passing vf_token"). I.e. when the KVM test was posted, pulling
in libvfio.mk didn't require linking to any new libraries other than VFIO
itself.
Now that libvfio.mk pulls in luuid, unconditionally linking in support for
VFIO is quite onerous, especially when cross-compiling, as it requires
installing what is effectively an unused library on four architectures.
Eventually KVM selftests will likely support irq_test and thus need to link
to VFIO on architectures other than x86, but at least then there will be
some amount of gain for the pain.
Fixes: a262fc49e0 ("KVM: selftests: Build and link selftests/vfio/lib into KVM selftests")
Cc: David Matlack <dmatlack@google.com>
Cc: Josh Hilke <jrhilke@google.com>
Link: https://patch.msgid.link/20260730165159.1988017-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
- adt7470:
* Fix PWM auto temp state array and bounds check
* Fix divide-by-zero TOCTOU crash in fan speed read
* Use cached PWM frequency value
* Fix swapped PWM3 and PWM4 auto mode masks
* Fix temperature alarm logic in hwmon_temp_read()
* Fix busy-loop and I2C flooding in update thread
* Fix cache updated before hardware write on I2C error
* Fix fans stuck in manual mode on I2C errors
- ina2xx: Fix various overflow issues
- ltc4282: Fix reading the minimum alarm voltage
- lm63: Mask PWM frequency multiplier to supported bits
- lm90: Only report alarms if driver is ready
- nct6775-core:
* Prevent access to unsupported weight registers
* Fix number of temperature registers for NCT6116
- npcm750-pwm-fan: stop fan timer on device detach
- nzxt-smart2: DMA-align output buffer
- pmbus:
* Fix return value from pmbus_update_byte_data()
* Notify on the hwmon device, not the i2c client
- sht3x: Fix unaligned accesses
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmpstKMACgkQyx8mb86f
mYEaJhAAiSUjVllgPxCrdaACCodYm7KrW1zhVN1z1eDDSsx2CLJbOSilewV/Hdn8
B0N+HzS3kNkv6JGs9dl7+KSVpYqnISIF9XnNSSHSGezeHTuAmua0JB+G4SNsBsJ0
dQF9h+XtWsF3vE/enyvW/lYXT3QHNsZzssODfbNshTUKMs9az7fDojhbcCQXb7XA
ZWCoJDPiB5PnfXS8uJuzriW3MqhqKqTzCQld6VvRNxpU4JdC5FVluinK9ZLaZDCX
quflzWt7wiMVLWOhqFkYvN+J9yAkKIeu13t1FsbwsL5wm84yDTrG/VEiDBOz76CZ
dOQPZFwQpWtcXI5WEPofso61LWzejtqOFt+VjGYGF2d3kMaD0bJHt7lhfhGEoAUy
/FFx/YKEgnzg/utJzHISUFfuA+lO3uS3/MKXyCgxVYLjedu0sNxuxtQ97fd/76ha
up+Jomg/ENwzpo1p50WVa2ME/ZydQy5xdv+TMEqj8OWw/tnFGq6jzHUx6gQ6l4RB
R4X47y2hswW3rFvGC8SE3daklwo7qr7Wx1G6uUC6BPW/7NXdMmLYT6RBMiV+ylb8
kj+5/OZMqLm/O3yO3Ze9haSRU/efhs+tns0QQYBQKBXJ/Odn90KOguADBNM0YB1X
Ra8/Xk1TZpMTQM/T8n31NvDmhO80YDIQ1nVlLmy7WWPzzDAWSWw=
=2AWw
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
Pull hwmon fixes from Guenter Roeck:
"Most of the patches are fixes for pre-existing issues reported by
Sashiko. I suspect we'll see a lot of those for a while.
- adt7470:
- Fix PWM auto temp state array and bounds check
- Fix divide-by-zero TOCTOU crash in fan speed read
- Use cached PWM frequency value
- Fix swapped PWM3 and PWM4 auto mode masks
- Fix temperature alarm logic in hwmon_temp_read()
- Fix busy-loop and I2C flooding in update thread
- Fix cache updated before hardware write on I2C error
- Fix fans stuck in manual mode on I2C errors
- ina2xx: Fix various overflow issues
- ltc4282: Fix reading the minimum alarm voltage
- lm63: Mask PWM frequency multiplier to supported bits
- lm90: Only report alarms if driver is ready
- nct6775-core:
- Prevent access to unsupported weight registers
- Fix number of temperature registers for NCT6116
- npcm750-pwm-fan: stop fan timer on device detach
- nzxt-smart2: DMA-align output buffer
- pmbus:
- Fix return value from pmbus_update_byte_data()
- Notify on the hwmon device, not the i2c client
- sht3x: Fix unaligned accesses"
* tag 'hwmon-for-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
hwmon: (npcm750-pwm-fan): stop fan timer on device detach
hwmon: (pmbus) Fix return value from pmbus_update_byte_data()
hwmon: (adt7470) Fix PWM auto temp state array and bounds check
hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read
hwmon: (adt7470) Use cached PWM frequency value
hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks
hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read()
hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread
hwmon: (adt7470) Fix cache updated before hardware write on I2C error
hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors
hwmon: (nct6775-core) Prevent access to unsupported weight registers
hwmon: (lm63) Mask PWM frequency multiplier to supported bits
hwmon: (nzxt-smart2) DMA-align output buffer
hwmon: (lm90) Only report alarms if driver is ready
hwmon: (sht3x) Fix unaligned accesses
hwmon: (ltc4282) Fix reading the minimum alarm voltage
hwmon: (ina2xx) Fix various overflow issues
hwmon: (pmbus/core) notify on the hwmon device, not the i2c client
hwmon: (nct6775-core) Fix number of temperature registers for NCT6116
Qcom PCIe Root Ports advertise the Attention Button Present (ABP) bit in
the Slot Capabilities register, but the slots have no attention button.
When ABP is set, pcie_enable_notification() in the pciehp driver enables
the Attention Button Pressed interrupt (ABPE) and leaves the Presence
Detect Changed interrupt (PDCE) disabled. As a result, presence detect
changes are never reported, and surprise hot-plug detection that relies on
Presence Detect Changed events does not work.
Clear the Attention Button Present (ABP) bit in the Slot Capabilities
register so pciehp Presence Detect Changed events work.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: say what the patch does in the commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713-b4-clear_abp_0713-v2-2-4f0333a98d4e@oss.qualcomm.com
A collection of sound fixes for the 7.2-rc6 cycle. Again, it became
far larger than wished; I'll throttle from now on.
There are no major changes, just a normal flow of small fixes.
The majority of them are device-specific quirks and ASoC SDCA/codec
updates, but it includes a few ALSA core fixes as well.
ALSA Core:
- Fix for ALSA sequencer timer division-by-zero
- Fix potential race in ALSA timer core
- Wake up linked drain waiters on PCM stream unlink
- Fix double-free of converter objects on UMP rawmidi error path
USB-audio:
- Fix a few potential out-of-bounds access bugs
- Prevent stack info leak in RME Digiface status
- Fix UAF during UMP endpoint destruction
- Fix UAF at error handling during probe in Line6 6fire driver
- Quirks for C-Media CM6206, Corsair Virtuoso, Razer Barracuda X 2.4,
JKY Technology, and generic USB headphones
HD-audio:
- Quirks for HP Victus 16, HP Dragonfly Folio G3, Lenovo Legion 7, HP
Laptop 14s, Acer Nitro 5, TongFang X6SP45xU, Infinix INBOOK X3, and
HP Pavilion All-in-One
ASoC:
- Comprehensive cleanups and bug fixes for SoundWire/SDCA drivers
- DMI quirks for AMD ACP/YC on Lenovo Legion 7, Acer Aspire, MSI
Crosshair A16, and ASUS ExpertBook
- ACPI match table entry for SOF RT5682 on Intel Nova Lake
- Device-specific mixer / clock, irq fixes for TI TAS2562, TI TAS2781,
Sophgo cv1800b ADC, Maxim MAX98090/98095, FSL ASRC/EASRC and Realtek
RT5640
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmprXj0OHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/G4hAApuJ3FolNsTbzn3POYf/gFFngvfCNLnZPQumi
XTMDq/G1tgRBHHFpKvkadWmqB/8MnxhfofKycIfQIAwzs6zIAz8ED/p1MXL/pPj7
A7Mrn6pb583TXMeo9tt+8UTOGGECDNswUoaYfpObFBeqdGKWZdx51bpZz9KzBNee
KAfbbijvleRJpHHumP0rPL/qMGazhlA8rBCIqWYcp+YBNLXPnEYbF4wq2hjP06Fo
X9vNaBAuwuPAxjFVg+2LtaEQt4fAD+xOPSRlhlnPUPrmUKIe4kVTY5JYU9CW8Ywo
8M+U3Z/gqw37Lkko/ctu6CZrgzvmsNQWjGzFmen2I0viCGklZtJrOPTGMdu3L13o
tVoQ+nK5Pofjgk3ik5qxXu+kdZVDbSbvhQiRW50JAmhD/pLNRQxy1M6WZcS5RvDa
6AnK0sTB6nlNVd+rfXRf6lbnOyk4JI10WEXb6eWyh1PvaGcOQm3D1Sq9sq7e+1se
YWZJQsutOYv5wk+bnpfZMm+uhm3t61ibZYubz4nYqPDuC+yt3ZVSdDU3iIFTZwQ1
oHAdWYbgSNd2OAVghjzomsPL+099HDgAk1uYUrIPtb2Q+pHQ8wIYSXKpGarPA5Kp
pDnKcjfV80CT8hMGD00zOhgYXMnWNZmOPXQMq7jNaiDQPH+07Yo8tVhgg7HUxlXe
i4oMZEk=
=nkW9
-----END PGP SIGNATURE-----
Merge tag 'sound-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of sound fixes for the 7.2-rc6 cycle. Again, it became
far larger than wished; I'll throttle from now on.
There are no major changes, just a normal flow of small fixes. The
majority of them are device-specific quirks and ASoC SDCA/codec
updates, but it includes a few ALSA core fixes as well.
ALSA Core:
- Fix for ALSA sequencer timer division-by-zero
- Fix potential race in ALSA timer core
- Wake up linked drain waiters on PCM stream unlink
- Fix double-free of converter objects on UMP rawmidi error path
USB-audio:
- Fix a few potential out-of-bounds access bugs
- Prevent stack info leak in RME Digiface status
- Fix UAF during UMP endpoint destruction
- Fix UAF at error handling during probe in Line6 6fire driver
- Quirks for C-Media CM6206, Corsair Virtuoso, Razer Barracuda X 2.4,
JKY Technology, and generic USB headphones
HD-audio:
- Quirks for HP Victus 16, HP Dragonfly Folio G3, Lenovo Legion 7, HP
Laptop 14s, Acer Nitro 5, TongFang X6SP45xU, Infinix INBOOK X3, and
HP Pavilion All-in-One
ASoC:
- Comprehensive cleanups and bug fixes for SoundWire/SDCA drivers
- DMI quirks for AMD ACP/YC on Lenovo Legion 7, Acer Aspire, MSI
Crosshair A16, and ASUS ExpertBook
- ACPI match table entry for SOF RT5682 on Intel Nova Lake
- Device-specific mixer / clock, irq fixes for TI TAS2562, TI
TAS2781, Sophgo cv1800b ADC, Maxim MAX98090/98095, FSL ASRC/EASRC
and Realtek RT5640"
* tag 'sound-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (53 commits)
ASoC: rt722: reset codec to fix abnormal sound
ASoC: dt-bindings: realtek,rt5640: Make interrupts optional
ALSA: hda/realtek: Add mute LED quirk for HP Victus 16-e0xxx (MB 88ED)
ALSA: usb-audio: Add GET_SAMPLE_RATE quirk for C-Media CM6206
ALSA: usb-audio: Clamp frame size in implicit-feedback mode
ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set
ALSA: usb-audio: Add quirk for Corsair Virtuoso (later revision)
ALSA: pcm: wake linked drain waiters on unlink
ASoC: amd: acp: Add DMI quirk for Lenovo Legion 7 15ASH11
ASoC: sophgo: return 1 on volume change in cv1800b_adc_volume_set()
ASoC: tas2781: Use correct calibration data for SINEGAIN2 register
ASoC: SDCA: Move kcontrol search out of IRQ
ASoC: SDCA: Switch to fixup_controls callback for IRQ registration
ASoC: Add a component fixup_controls callback
ASoC: SDCA: Populate IRQ data earlier
ASoC: SDCA: Remove devm from primary IRQ cleanup
ASoC: SDCA: Add sdca_irq_cleanup_late()
ASoC: SDCA: Rename sdca_irq_allocate() to include devm
ALSA: hda/realtek: Add quirk for HP Dragonfly Folio G3 2-in-1 (103c:8a05)
ALSA:hda/realtek:ALC269 fixup for Legion 7 15ASH11 Mic Mute LED
...
The DWC PCIe Time-Based Analysis Data Register (the counter for time-based
events) is architected as 64-bit, but some hardware implementations do not
implement the full width. On these implementations the counter stops after
reaching its implemented width. This will limit the usage for short time
monitoring only. The counter will only cover ~15s for monitoring RX TLP
payloads on our platform.
Add an optional hrtimer that fires every 2 seconds. It'll take the role
as the counter overflow interrupt to read-update-reset the counter and
event counts to break the limits of the narrow counters. It'll only
apply on timer-based counter. The 2 seconds update period is the half
of the maximum counting period (4s) of the time-based counter under
period counting mode of the hardware.
Because fully-implemented 64-bit counters do not need this workaround,
enable this hrtimer on the platforms known to have narrowed counter.
Before this patch, when counting fio for 10m the counts is incorrect:
root@localhost:/tmp# perf stat -e dwc_rootport_20000/rx_pcie_tlp_data_payload/ -- fio --runtime=10m fio_job.config
[...]
Run status group 0 (all jobs):
READ: bw=5594MiB/s (5865MB/s), 5594MiB/s-5594MiB/s (5865MB/s-5865MB/s), io=3278GiB (3519GB), run=600010-600010msec
[...]
Performance counter stats for 'system wide':
137,438,953,456 dwc_rootport_20000/rx_pcie_tlp_data_payload/
After this patch the counts is as expected:
root@localhost:/tmp# perf stat -e dwc_rootport_20000/rx_pcie_tlp_data_payload/ -- fio --runtime=10m fio_job.config
[...]
Run status group 0 (all jobs):
READ: bw=5632MiB/s (5905MB/s), 5632MiB/s-5632MiB/s (5905MB/s-5905MB/s), io=3300GiB (3543GB), run=600013-600013msec
[...]
Performance counter stats for 'system wide':
3,543,850,268,576 dwc_rootport_20000/rx_pcie_tlp_data_payload/
Signed-off-by: Yufan Dou <douyufan@picoheart.com>
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
Signed-off-by: Will Deacon <will@kernel.org>
Add PCI_VENDOR_ID_PICOHEART in pci_ids.h. Update the DWC PCIe
vendor table with Picoheart PCIe Vendor ID to enable the PCIe
PMU support.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
Signed-off-by: Will Deacon <will@kernel.org>
Joy Zou <joy.zou@oss.nxp.com> says:
The regulator_init_complete_work fires ~30s after boot to disable
unused regulators via I2C. When this work races with PM suspend, the
I2C adapter may already be suspended, causing a -ESHUTDOWN warning
dump.
This series addresses the race and adds proper suspend power
management for unused LDO regulators.
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-0-a406c8737fdb@oss.nxp.com
Add a set_suspend_disable callback to pfuze100_ldo_regulator_ops to
support the regulator-off-in-suspend DTS property for the VGEN LDO
regulators. This allows unused LDO regulators to be properly disabled
during system suspend, reducing power consumption.
The callback is only used by the LDO ops, so name it accordingly:
pfuze100_ldo_set_suspend_disable. It uses the per-regulator
stby_reg/stby_mask that already describe the standby control for
each LDO, so it works for every LDO covered by these ops.
Signed-off-by: Joy Zou <joy.zou@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-2-a406c8737fdb@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
schedule_delayed_work() uses system_wq, which is non-freezable, allowing
regulator_init_complete_work to run concurrently with system suspend. This
work fires ~30s after boot to disable unused regulators via I2C. When it
races with PM suspend, the I2C adapter may already be suspended, triggering
a -ESHUTDOWN warning in __i2c_transfer():
WARNING: ... at __i2c_transfer+0x36c/0x3c8
Call trace:
__i2c_transfer
i2c_transfer
regmap_i2c_write
_regmap_update_bits
regulator_disable_regmap
_regulator_do_disable
regulator_late_cleanup
regulator_init_complete_work_function
process_one_work
Switch to system_freezable_wq so the work is frozen before any device
is suspended, eliminating the race.
Fixes: 55576cf185 ("regulator: Defer init completion for a while after late_initcall")
Signed-off-by: Joy Zou <joy.zou@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-1-a406c8737fdb@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There's a two-patch series from Nico which fixes a couple of PMD level
mTHP accounting bugs and a two-patch series from Chris Gellermann which
addresses mishandling of getline() in selftests. All the remainder are
singletons - please see the changelogs for details.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCamwI1gAKCRDdBJ7gKXxA
jlrXAP4z1XsAoqUj+dG9ixjXhCpTPDkbjarsbyeAofFo441jrwEAgs8n7owl0x2Z
OsmuzmeTOkB4j7Y0XLi3/8GOcj1+Gg4=
=qrVd
-----END PGP SIGNATURE-----
Merge tag 'mm-hotfixes-stable-2026-07-30-19-30' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull misc fixes from Andrew Morton:
"12 hotfixes. 6 are cc:stable. 9 are for MM.
There's a two-patch series from Nico which fixes a couple of PMD level
mTHP accounting bugs and a two-patch series from Chris Gellermann
which addresses mishandling of getline() in selftests. All the
remainder are singletons - please see the changelogs for details"
* tag 'mm-hotfixes-stable-2026-07-30-19-30' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
selftests/mm: fix potential wild pointer access of getline due to missing init
selftests/clone3: fix wild pointer access of getline due to missing init
mm/page_reporting: use system_freezable_wq to fix UAF during suspend
mm: vmscan: abort proactive reclaim early when freezing for suspend
MAINTAINERS: update Nico Pache's email address
arm64, mailmap: update email address for Peter Collingbourne
MAINTAINERS: update address for Burak Emir
mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios
riscv/mm: use physical alignment for vmemmap_start_pfn
mm/migrate: exclude hugetlb folios from MTHP_STAT_NR_ANON accounting
mm: decrement MTHP_STAT_NR_ANON in free_zone_device_folio()
mm: memcg: initialize *locked in memcg1_oom_prepare() stub
kconfiglint reports:
K006: config SOC_TEGRA_PMC selects PM_GENERIC_DOMAINS which depends on PM,
but SOC_TEGRA_PMC does not depend on PM
SOC_TEGRA_PMC is an internal bool symbol (no prompt) that is selected by
ARCH_TEGRA_*_SOC options to enable the Power Management Controller driver.
It was originally introduced in commit 5e7d4c6529 ("soc/tegra: Implement
Tegra186 PMC support") as a bare `bool` with no
selects of its own.
Over time, additional selects were added:
- Commit 5098e2b95e ("soc/tegra: pmc: Select GENERIC_PINCONF") added
select GENERIC_PINCONF
- Commit 28dbe82310 ("soc/tegra: pmc: Select IRQ_DOMAIN_HIERARCHY") added
select IRQ_DOMAIN_HIERARCHY
- Commit f880ee9e96 ("soc/tegra: pmc: Add core power domain") added select PM_OPP and select PM_GENERIC_DOMAINS to
support core power domain voltage scaling
PM_GENERIC_DOMAINS is defined in kernel/power/Kconfig as:
config PM_GENERIC_DOMAINS
bool
depends on PM
When commit f880ee9e96 ("soc/tegra: pmc: Add core power domain") added
the select, it did not add a corresponding `depends on PM` to
SOC_TEGRA_PMC. This was not a functional problem because all callers of
SOC_TEGRA_PMC are inside `if ARCH_TEGRA` blocks, and both the ARM32
definition (arch/arm/mach-tegra/Kconfig) and the ARM64 definition
(arch/arm64/Kconfig.platforms) of ARCH_TEGRA select PM. Thus PM is always
enabled when SOC_TEGRA_PMC is selected in practice.
However, the dependency chain is implicit rather than explicit. Add
`depends on PM` to SOC_TEGRA_PMC to make the requirement explicit and
prevent a theoretical misconfiguration if SOC_TEGRA_PMC were ever selected
outside the ARCH_TEGRA context.
Assisted-by: Claude:claude-opus-4-6 kconfiglint
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5640 codec driver requests interrupt on rising edge, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5640 codec driver requests interrupt on rising edge, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning:
1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
Realtek RT5658 codec driver requests interrupt on both edges, so correct
the interrupt flags, assuming the author of the code wanted the similar
logical behavior behind the name "ACTIVE_xxx", this is:
ACTIVE_HIGH => IRQ_TYPE_EDGE_RISING
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
