PCI: tegra194: Disable PERST# IRQ only in Endpoint mode
The PERST# GPIO interrupt is only registered when the controller is
operating in Endpoint mode. In Root Port mode, the PERST# GPIO is
configured as an output to control downstream devices, and no interrupt is
registered for it.
Currently, tegra_pcie_dw_stop_link() unconditionally calls disable_irq()
on pex_rst_irq, which causes issues in Root Port mode where this IRQ is
not registered.
Fix this by only disabling the PERST# IRQ when operating in Endpoint mode,
where the interrupt is actually registered and used to detect PERST#
assertion/deassertion from the host.
Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-6-mmaddireddy@nvidia.com
Vidya Sagar [Tue, 24 Mar 2026 19:07:45 +0000 (00:37 +0530)]
PCI: tegra194: Don't force the device into the D0 state before L2
As per PCIe CEM r6.0, sec 2.3, the PCIe Endpoint device should be in D3cold
to assert WAKE# pin. The previous workaround that forced downstream devices
to D0 before taking the link to L2 cited PCIe r4.0, sec 5.2, "Link State
Power Management"; however, that spec does not explicitly require putting
the device into D0 and only indicates that power removal may be initiated
without transitioning to D3hot.
Remove the D0 workaround so that Endpoint devices can use wake
functionality (WAKE# from D3). With some Endpoints the link may not enter
L2 when they remain in D3, but the Root Port continues with the usual flow
after PME timeout, so there is no functional issue.
PCI: tegra194: Disable LTSSM after transition to Detect on surprise link down
After the link reaches a Detect-related LTSSM state, disable LTSSM so it
does not keep toggling between Polling and Detect. Do this by polling for
the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both
tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert().
The fsck tool detected that Extended Attributes b-tree is corrupted.
Namely, the free nodes number is incorrect and map node
bitmap has inconsistent state. Analysis has shown that during
b-tree closing there are still some lost b-tree's nodes in
the hash out of b-tree structure. But this orphaned b-tree nodes
are still accounted as used in map node bitmap:
This issue happens in hfs_bnode_split() logic during detection
the possibility of moving half ot the records out of the node.
The hfs_bnode_split() contains a loop that implements
a roughly 50/50 split of the B-tree node's records by scanning
the offset table to find where the data crosses the node's midpoint.
If this logic detects the incapability of spliting the node, then
it simply calls hfs_bnode_put() for newly created node. However,
node is not set as HFS_BNODE_DELETED and real deletion of node
doesn't happen. As a result, the empty node becomes orphaned but
it is still accounted as used. Finally, fsck tool detects this
inconsistency of HFS+ volume.
This patch adds call of hfs_bnode_unlink() before hfs_bnode_put()
for the case if new node cannot be used for spliting the existing
node.
hfsplus: rework logic of map nodes creation in xattr b-tree
In hfsplus_init_header_node() when node_count > 63488
(header bitmap capacity), the code calculates map_nodes,
subtracts them from free_nodes, and marks their positions
used in the bitmap. However, it doesn't write the actual
map node structure (type, record offsets, bitmap) for
those physical positions, only node 0 is written.
This patch reworks hfsplus_create_attributes_file()
logic by introducing a specialized method of
hfsplus_init_map_node() and writing the allocated
map b-tree's nodes by means of
hfsplus_write_attributes_file_node() method.
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-5-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
The hfs_bmap_alloc() and hfs_bmap_free() modify
the b-tree's counters and nodes' bitmap of b-tree.
However, hfs_btree_write() synchronizes the state of
in-core b-tree's counters and node's bitmap with
b-tree's descriptor in header node. Postponing this
synchronization could result in inconsistent state of
file system volume. This patch adds calling of
hfs_btree_write() in hfs_bmap_alloc() and hfs_bmap_free()
methods.
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-4-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
hfsplus: fix error processing issue in hfs_bmap_free()
Currently, we check only -EINVAL error code in hfs_bmap_free()
after calling the hfs_bmap_clear_bit(). It means that other
error codes will be silently ignored. This patch adds the checking
of all other error codes.
cc: Shardul Bankar <shardul.b@mpiricsoftware.com>
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-3-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
hfsplus: fix potential race conditions in b-tree functionality
The HFS_BNODE_DELETED flag is checked in hfs_bnode_put()
under locked tree->hash_lock. This patch adds locking
for the case of setting the HFS_BNODE_DELETED flag in
hfs_bnode_unlink() with the goal to avoid potential
race conditions.
The hfs_btree_write() method should be called under
tree->tree_lock. This patch reworks logic by adding
locking the tree->tree_lock for the calls of
hfs_btree_write() in hfsplus_cat_write_inode() and
hfsplus_system_write_inode().
This patch adds also the lockdep_assert_held() in
hfs_bmap_reserve(), hfs_bmap_alloc(), and hfs_bmap_free().
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
PCI: tegra194: Increase LTSSM poll time on surprise link down
On surprise link down, LTSSM state transits from L0 -> Recovery.RcvrLock ->
Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock
and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so
the total time from L0 to Detect is ~96 ms. Increase the poll timeout to
120 ms to account for this.
While at it, add LTSSM state defines for Detect-related states and use them
in the poll condition. Use readl_poll_timeout() instead of
readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path
runs in non-atomic context.
Vidya Sagar [Tue, 24 Mar 2026 19:07:42 +0000 (00:37 +0530)]
PCI: tegra194: Fix polling delay for L2 state
As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root
Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is
polling for 10 msec with 1 usec delay which is aggressive. Use existing
macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay.
Since this function is used in non-atomic context only, use non-atomic poll
function.
Bugzilla 217447 points out that ftrace bitmask fields still use the
legacy dynamic-array format, which makes trace consumers treat them
as unsigned long arrays instead of bitmaps.
This is visible in the ipi events today: ipi_send_cpumask already
reports its CPU mask as '__data_loc cpumask_t', but ipi_raise still
exposes target_cpus as '__data_loc unsigned long[]'.
Switch ipi_raise to __cpumask() and the matching helpers so its
tracefs format matches the existing cpumask representation used by
the other ipi event. The underlying storage size stays the same, but
trace data consumers can now recognize the field as a cpumask
directly.
x86: shadow stacks: proper error handling for mmap lock
김영민 reports that shstk_pop_sigframe() doesn't check for errors from
mmap_read_lock_killable(), which is a silly oversight, and also shows
that we haven't marked those functions with "__must_check", which would
have immediately caught it.
So let's fix both issues.
Reported-by: 김영민 <osori@hspace.io> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Dave Hansen <dave.hansen@intel.com> Acked-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
David Carlier [Sat, 4 Apr 2026 13:47:47 +0000 (14:47 +0100)]
tracefs: Fix default permissions not being applied on initial mount
Commit e4d32142d1de ("tracing: Fix tracefs mount options") moved the
option application from tracefs_fill_super() to tracefs_reconfigure()
called from tracefs_get_tree(). This fixed mount options being ignored
on user-space mounts when the superblock already exists, but introduced
a regression for the initial kernel-internal mount.
On the first mount (via simple_pin_fs during init), sget_fc() transfers
fc->s_fs_info to sb->s_fs_info and sets fc->s_fs_info to NULL. When
tracefs_get_tree() then calls tracefs_reconfigure(), it sees a NULL
fc->s_fs_info and returns early without applying any options. The root
inode keeps mode 0755 from simple_fill_super() instead of the intended
TRACEFS_DEFAULT_MODE (0700).
Furthermore, even on subsequent user-space mounts without an explicit
mode= option, tracefs_apply_options(sb, true) gates the mode behind
fsi->opts & BIT(Opt_mode), which is unset for the defaults. So the
mode is never corrected unless the user explicitly passes mode=0700.
Restore the tracefs_apply_options(sb, false) call in tracefs_fill_super()
to apply default permissions on initial superblock creation, matching
what debugfs does in debugfs_fill_super().
Cc: stable@vger.kernel.org Fixes: e4d32142d1de ("tracing: Fix tracefs mount options") Link: https://patch.msgid.link/20260404134747.98867-1-devnexen@gmail.com Signed-off-by: David Carlier <devnexen@gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
muhammed Rishal [Fri, 3 Apr 2026 16:12:26 +0000 (18:12 +0200)]
bpf: Add fix for Trust Philips SPK6327 (145f:024b) modifier keys
The Trust Philips SPK6327 keyboard (USB ID 145f:024b) has a broken HID
descriptor on interface 1. Byte 101 is 0x00 (Input Array) but should be
0x02 (Input Variable), causing LCtrl, LAlt, Super, RAlt, RCtrl and
RShift to all report as LShift on Linux.
This BPF fix patches byte 101 at runtime fixing all affected modifier
keys.
HID: bpf: Add support for the Huion KeyDial K20 over bluetooth
When connected over bluetooth this device is just different enough that
forcing it into the same source file as the USB connection doesn't gain
us much benefit. So let's duplicate this.
Code and tests originally produced by Claude code.
Currently the kernel is scheduled to do this call by itself, but it
requires a kernel v6.18 at least to have the INPUT_PROP set. For older
kernels, we can try to query the property from a HID-BPF probe, and set
a udev property based on that. This way we can provide the information
to old kernels without modifying them.
hid: bpf: hid_bpf_helpers: add helper for having read/write udev properties
We want udev-hid-bpf to be able to set udev properties by printing them
out after the BPF object has been loaded. This allows to make a query to
the device, and set a udev prop based on the answer.
Because the way udev works, the properties are cleared on bind/unbind,
and we need a way to store them. After several attempts to keep the
property alive without re-running the udev-hid-bpf tool to communicate
with the device, it came out that HID-BPF maps are pinned in the bpffs
and we can then query them.
So the following would export a UDEV property in the bpffs:
EXPORT_UDEV_PROP(HID_FOO, 32);
HID: bpf: handle injected report descriptor in HID-BPF
udev-hid-bpf is now capable of injecting the parsed report descriptor in
the program. Provide the macros required for it.
Sync up from udev-hid-bpf commits:
bpf: inject the parsed report descriptor in HID_REPORT_DESCRIPTOR
hid_bpf_helpers: provide iterator macros for walking the HID report descriptor
hid_bpf_helpers: Add extract_bits function
bpf: add hid_usages.h
bpf: move the report descriptor structs into their own header
HID: bpf: hid_bpf_helpers: provide a cleanup functions
Combination of 2 udev-hid-bpf commits:
bpf: hid_bpf_helpers: provide a cleanup function for hid_bpf_release_context
bpf: helpers: add guard(bpf_spin) macro
Christian Bruel [Tue, 7 Apr 2026 12:04:08 +0000 (14:04 +0200)]
selftests: pci_endpoint: Skip BAR subrange test on -ENOSPC
In pci-epf-test.c, set the STATUS_NO_RESOURCE status bit if
pci_epc_set_bar() returns -ENOSPC. This status bit is used to indicate
that there are not enough inbound window resources to allocate the
subrange.
In pci_endpoint_test.c, return -ENOSPC instead of -EIO when
STATUS_NO_RESOURCE is set.
In pci_endpoint_test.c, skip the BAR subrange test if -ENOSPC, i.e., there
are not enough inbound window resources to run the test.
io_uring: unify getting ctx from passed in file descriptor
io_uring_enter() and io_uring_register() end up having duplicated code
for getting a ctx from a passed in file descriptor, for either a
registered ring descriptor or a normal file descriptor. Move the
io_uring_register_get_file() into io_uring.c and name it a bit more
generically, and use it from both callsites rather than have that logic
and handling duplicated.
io_uring/register: don't get a reference to the registered ring fd
This isn't necessary and was only done because the register path isn't a
hot path and hence the extra ref/put doesn't matter, and to have the
exit path be able to unconditionally put whatever file was gotten
regardless of the type.
In preparation for sharing this code with the main io_uring_enter(2)
syscall, drop the reference and have the caller conditionally put the
file if it was a normal file descriptor.
io_uring/tctx: clean up __io_uring_add_tctx_node() error handling
Refactor __io_uring_add_tctx_node() so that on error it never leaves
current->io_uring pointing at a half-setup tctx. This moves the
assignment of current->io_uring to the end of the function post any
failure points.
Separate out the node installation into io_tctx_install_node() to
further clean this up.
io_uring/tctx: have io_uring_alloc_task_context() return tctx
Instead of having io_uring_alloc_task_context() return an int and
assign tsk->io_uring, just have it return the task context directly.
This enables cleaner error handling in callers, which may have
failure points post calling io_uring_alloc_task_context().
nvmet-tcp: remove redundant calls to nvmet_tcp_fatal_error()
Executing nvmet_tcp_fatal_error() is generally the responsibility
of the caller (nvmet_tcp_try_recv); all other functions should
just return the error code.
Remove the nvmet_tcp_fatal_error() function, it's not needed
anymore.
Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers
Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds
PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue)
and returns early. However, because the function returns void, the
callers are entirely unaware that a fatal error has occurred and
that the cmd->recv_msg.msg_iter was left uninitialized.
Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly
overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA
Consequently, the socket receiving loop may attempt to read incoming
network data into the uninitialized iterator.
Fix this by shifting the error handling responsibility to the callers.
Fixes: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec") Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Yunje Shin <ioerts@kookmin.ac.kr> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
Chaitanya Sabnis [Fri, 27 Mar 2026 09:21:06 +0000 (14:51 +0530)]
ASoC: dt-bindings: hisilicon: Convert hi6210 I2S to dt-schema
Convert the Hisilicon hi6210 I2S controller hardware binding from
legacy plain text to modern YAML dt-schema format.
During the conversion, the order of the dma-names properties in the
example was corrected to "tx", "rx" to match the official property
description, resolving a contradiction in the original text binding.
Ian Rogers [Wed, 8 Apr 2026 02:08:38 +0000 (19:08 -0700)]
perf maps: Fix copy_from that can break sorted by name order
When an parent is copied into a child the name array is populated in
address not name order. Make sure the name array isn't flagged as sorted.
Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Ian Rogers [Wed, 8 Apr 2026 02:08:37 +0000 (19:08 -0700)]
perf maps: Fix fixup_overlap_and_insert that can break sorted by name order
When an entry in the address array is replaced, the corresponding name
entry is replaced. The entries names may sort differently and so it is
important that the sorted by name property be cleared on the maps.
Fixes: 0d11fab32714 ("perf maps: Fixup maps_by_name when modifying maps_by_address") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Thomas Richter [Tue, 7 Apr 2026 10:08:35 +0000 (12:08 +0200)]
perf addr2line: Remove global variable addr2line_timeout_ms
Remove global variable addr2line_timeout_ms and add it as a member
to symbol_conf structure.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Ian Rogers <irogers@google.com>
[namhyung: move the initialization to util/symbol.c] Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Thomas Richter [Tue, 7 Apr 2026 10:08:34 +0000 (12:08 +0200)]
perf config: Make symbol_conf::addr2line_disable_warn configurable
Make symbol_conf::addr2line_disable_warn configurable by reading
the perfconfig file.
Use section core and addr2line-disable-warn = value.
Update documentation.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Ian Rogers <irogers@google.com> Suggested-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Input: uinput - take event lock when submitting FF request "event"
To avoid racing with FF playback events and corrupting device's event
queue take event_lock spinlock when calling uinput_dev_event() when
submitting a FF upload or erase "event".
Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()
The `ims_pcu_process_data()` processes incoming URB data byte by byte.
However, it fails to check if the `read_pos` index exceeds
IMS_PCU_BUF_SIZE.
If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE,
`read_pos` will increment indefinitely. Moreover, since `read_pos` is
located immediately after `read_buf`, the attacker can overwrite
`read_pos` itself to arbitrarily control the index.
This manipulated `read_pos` is subsequently used in
`ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a
heap buffer overflow.
Specifically, an attacker can overwrite the `cmd_done.wait.head` located
at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`.
Consequently, when the driver calls `complete(&pcu->cmd_done)`, it
triggers a control flow hijack by using the manipulated pointer.
Fix this by adding a bounds check for `read_pos` before writing to
`read_buf`. If the packet is too long, discard it, log a warning,
and reset the parser state.
Fixes: 628329d524743 ("Input: add IMS Passenger Control Unit driver") Co-developed-by: Sanghoon Choi <csh0052@gmail.com> Signed-off-by: Sanghoon Choi <csh0052@gmail.com> Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Link: https://patch.msgid.link/20251221211442.841549-2-eeodqql09@gmail.com
[dtor: factor out resetting packet state, reset checksum as well] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Amit Pundir [Tue, 7 Apr 2026 06:43:55 +0000 (08:43 +0200)]
wifi: ath10k: Add device-tree quirk to skip host cap QMI requests
Some firmware versions do not support the host capability QMI request.
Since this request occurs before firmware-N.bin and board-M.bin are
loaded, the quirk cannot be expressed in the firmware itself.
The root cause is unclear, but there appears to be a generation of
firmware that lacks host capability support.
Without this quirk, ath10k_qmi_host_cap_send_sync() returns
QMI_ERR_MALFORMED_MSG_V01 before loading the firmware. This error is not
fatal - Wi-Fi services still come up successfully if the request is simply
skipped.
Add a device-tree quirk to skip the host capability QMI request on devices
whose firmware does not support it.
For example, firmware build
"QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
on Xiaomi Poco F1 phone requires this quirk.
Suggested-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Tested-by: Paul Sajna <sajattack@postmarketos.org> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20260407-skip-host-cam-qmi-req-v5-2-dfa8a05c6538@ixit.cz Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Amit Pundir [Tue, 7 Apr 2026 06:43:54 +0000 (08:43 +0200)]
dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
Some firmware versions do not support the host-capability QMI request.
Since this request occurs before firmware and board files are loaded,
the quirk cannot be expressed in the firmware itself and must be described
in the device tree.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Co-developed-by: David Heidelberg <david@ixit.cz> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260407-skip-host-cam-qmi-req-v5-1-dfa8a05c6538@ixit.cz Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Haoyu Lu [Tue, 7 Apr 2026 03:31:15 +0000 (11:31 +0800)]
ACPI: AGDI: fix missing newline in error message
Add the missing trailing newline to the dev_err() message
printed when SDEI event registration fails.
This keeps the error output as a properly terminated log line.
Fixes: a2a591fb76e6 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device") Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Rutland [Tue, 7 Apr 2026 13:16:50 +0000 (14:16 +0100)]
arm64: Check DAIF (and PMR) at task-switch time
When __switch_to() switches from a 'prev' task to a 'next' task, various
pieces of CPU state are expected to have specific values, such that
these do not need to be saved/restored. If any of these hold an
unexpected value when switching away from the prev task, they could lead
to surprising behaviour in the context of the next task, and it would be
difficult to determine where they were configured to their unexpected
value.
Add some checks for DAIF and PMR at task-switch time so that we can
detect such issues.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jinjie Ruan <ruanjinjie@huawei.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Will Deacon <will@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Rutland [Tue, 7 Apr 2026 13:16:49 +0000 (14:16 +0100)]
arm64: entry: Use split preemption logic
The generic irqentry code now provides
irqentry_exit_to_kernel_mode_preempt() and
irqentry_exit_to_kernel_mode_after_preempt(), which can be used
where architectures have different state requirements for involuntary
preemption and exception return, as is the case on arm64.
Use the new functions on arm64, aligning our exit to kernel mode logic
with the style of our exit to user mode logic. This removes the need for
the recently-added bodge in arch_irqentry_exit_need_resched(), and
allows preemption to occur when returning from any exception taken from
kernel mode, which is nicer for RT.
In an ideal world, we'd remove arch_irqentry_exit_need_resched(), and
fold the conditionality directly into the architecture-specific entry
code. That way all the logic necessary to avoid preempting from a
pseudo-NMI could be constrained specifically to the EL1 IRQ/FIQ paths,
avoiding redundant work for other exceptions, and making the flow a bit
clearer. At present it looks like that would require a larger
refactoring (e.g. for the PREEMPT_DYNAMIC logic), and so I've left that
as-is for now.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jinjie Ruan <ruanjinjie@huawei.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Rutland [Tue, 7 Apr 2026 13:16:48 +0000 (14:16 +0100)]
arm64: entry: Use irqentry_{enter_from,exit_to}_kernel_mode()
The generic irqentry code now provides irqentry_enter_from_kernel_mode()
and irqentry_exit_to_kernel_mode(), which can be used when an exception
is known to be taken from kernel mode. These can be inlined into
architecture-specific entry code, and avoid redundant work to test
whether the exception was taken from user mode.
Use these in arm64_enter_from_kernel_mode() and
arm64_exit_to_kernel_mode(), which are only used for exceptions known to
be taken from kernel mode. This will remove a small amount of redundant
work, and will permit further changes to arm64_exit_to_kernel_mode() in
subsequent patches.
There should be no funcitonal change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jinjie Ruan <ruanjinjie@huawei.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
For historical reasons, arm64's entry code has arm64-specific functions
named enter_from_kernel_mode() and exit_to_kernel_mode(), which are
wrappers for similarly-named functions from the generic irqentry code.
Other arm64-specific wrappers have an 'arm64_' prefix to clearly
distinguish them from their generic counterparts, e.g.
arm64_enter_from_user_mode() and arm64_exit_to_user_mode().
For consistency and clarity, add an 'arm64_' prefix to these functions.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jinjie Ruan <ruanjinjie@huawei.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Rutland [Tue, 7 Apr 2026 13:16:46 +0000 (14:16 +0100)]
arm64: entry: Don't preempt with SError or Debug masked
On arm64, involuntary kernel preemption has been subtly broken since the
move to the generic irqentry code. When preemption occurs, the new task
may run with SError and Debug exceptions masked unexpectedly, leading to
a loss of RAS events, breakpoints, watchpoints, and single-step
exceptions.
Prior to moving to the generic irqentry code, involuntary preemption of
kernel mode would only occur when returning from regular interrupts, in
a state where interrupts were masked and all other arm64-specific
exceptions (SError, Debug, and pseudo-NMI) were unmasked. This is the
only state in which it is valid to switch tasks.
As part of moving to the generic irqentry code, the involuntary
preemption logic was moved such that involuntary preemption could occur
when returning from any (non-NMI) exception. As most exception handlers
mask all arm64-specific exceptions before this point, preemption could
occur in a state where arm64-specific exceptions were masked. This is
not a valid state to switch tasks, and resulted in the loss of
exceptions described above.
As a temporary bodge, avoid the loss of exceptions by avoiding
involuntary preemption when SError and/or Debug exceptions are masked.
Practically speaking this means that involuntary preemption will only
occur when returning from regular interrupts, as was the case before
moving to the generic irqentry code.
Fixes: 99eb057ccd67 ("arm64: entry: Move arm64_preempt_schedule_irq() into __exit_to_kernel_mode()") Reported-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Reported-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jinjie Ruan <ruanjinjie@huawei.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Shuicheng Lin [Tue, 7 Apr 2026 03:00:46 +0000 (03:00 +0000)]
drm/xe/uapi: Fix doc formatting and completeness in xe_drm.h
- Fix missing leading space before closing */ in
comment block
- Add DRM_IOCTL_XE_EXEC_QUEUE_SET_PROPERTY to the
IOCTL overview list
- Add missing query types to the device query doc list:
DRM_XE_DEVICE_QUERY_UC_FW_VERSION,
DRM_XE_DEVICE_QUERY_OA_UNITS,
DRM_XE_DEVICE_QUERY_EU_STALL
- Fix ioctl's -> ioctls (not possessive, 2 occurrences)
- Remove duplicate parameter docs from
drm_xe_mem_range_attr overview (already documented
as inline member comments)
- Fix extra whitespace before /** on 2 lines in
drm_xe_mem_range_attr
- Add missing blank line before DRM_XE_VM_BIND_FLAG_DECOMPRESS
bullet to fix RST block quote warning
Shuicheng Lin [Tue, 7 Apr 2026 03:00:45 +0000 (03:00 +0000)]
drm/xe/uapi: Fix code examples in xe_drm.h documentation
Fix incorrect field names and formatting in code examples:
- .num_bb_per_exec -> .width (renamed struct field
in exec_queue_create examples)
- .num_eng_per_bb -> .num_placements (renamed struct
field in exec_queue_create examples)
- .atomic_val -> .atomic.val (correct nested struct
field access in madvise example)
- Remove unnecessary backslash escaping in UUID format
string (%\08x -> %08x)
- Fix descriptive text trapped inside code-block in
exec_queue_create doc (split into two code blocks)
v3: one more fix of split code-block in exec_queue_create doc.
Shuicheng Lin [Tue, 7 Apr 2026 03:00:44 +0000 (03:00 +0000)]
drm/xe/uapi: Fix kernel-doc cross-reference syntax in xe_drm.h
Fix incorrect kernel-doc cross-reference markup syntax
throughout xe_drm.h:
- @struct_name -> &struct name for cross-references to other
structs (19 occurrences)
- struct @name -> &struct name where struct keyword was
mixed with @ syntax (8 occurrences)
- enum @name -> &enum name for cross-references to other
enums (5 occurrences)
- &CONSTANT / @CONSTANT -> %CONSTANT for defines and enum
values (15 occurrences)
- @field references to members of other structs -> plain text,
since @ only applies to the current struct's members
(9 occurrences)
Per kernel-doc conventions (Documentation/doc-guide/kernel-doc.rst):
- '&struct name' creates hyperlinks to struct definitions
- '&enum name' creates hyperlinks to enum definitions
- '%NAME' references constants and defines
- '@name' is only for parameters/members of the current context
Shuicheng Lin [Tue, 7 Apr 2026 03:00:42 +0000 (03:00 +0000)]
drm/xe/uapi: Fix grammar errors in xe_drm.h documentation
Fix various grammar issues in doc comments:
- flag are only valid -> flag is only valid
- should only ever used -> should only ever be used
- if isn't already -> if it isn't already
- Type of the this -> Type of this
- When sync passed in -> When sync is passed in
- the users responsibility -> the user's responsibility
- must qword aligned -> must be qword aligned
- for a observation -> for an observation
- a memory ranges -> memory ranges
- for each memory ranges -> for each memory range.
- Second ioctl call -> second ioctl call
Jonathan Cavitt [Mon, 16 Mar 2026 16:20:04 +0000 (16:20 +0000)]
drm/xe/tlb: Init range tilemask err to zero
Initialize err = 0 in xe_tlb_inval_range_tilemask_submit to prevent a
possible uninitialized value return in the case where the tile_mask
somehow doesn't match any available tile ids.
ASoC: amd: acp: update DMI quirk and add ACP DMIC for Lenovo platforms
Replace DMI_EXACT_MATCH with DMI_MATCH for Lenovo SKU entries (21YW,
21YX) so the quirk applies to all variants of these models, not just
exact SKU matches.
Add ASOC_SDW_ACP_DMIC flag alongside ASOC_SDW_CODEC_SPKR in driver_data
for these Lenovo platform entries, as these platforms use ACP PDM DMIC
instead of SoundWire DMIC for digital microphone support.
Fixes: 3acf517e1ae0 ("ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models") Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Syed Saba Kareem <Syed.SabaKareem@amd.com> Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://patch.msgid.link/20260408133029.1368317-1-syed.sabakareem@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
Use xe_map_resource_to_region helper instead of direct access
Renaming:
The helper function res_to_mem_region is now xe_map_resource_to_region.
Abstraction:
The patch removes instances where block->private was accessed directly
to obtain VRAM region data allowing VRAM manager to own block->private
for future use cases.
V2(MattB): Add more detail about patch also adjust variable placement
ASoC: SDCA: Unregister IRQ handlers on module remove
Ensure that all interrupt handlers are unregistered before the parent
regmap_irq is unregistered.
sdca_irq_cleanup() was only called from the component_remove(). If the
module was loaded and removed without ever being component probed the
FDL interrupts would not be unregistered and this would hit a WARN
when devm called regmap_del_irq_chip() during the removal of the
parent IRQ.
Fixes: 4e53116437e9 ("ASoC: SDCA: Fix errors in IRQ cleanup") Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260408093835.2881486-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Maciej Strozek [Wed, 8 Apr 2026 09:38:31 +0000 (10:38 +0100)]
ASoC: SDCA: Fix overwritten var within for loop
mask variable should not be overwritten within the for loop or it will
skip certain bits. Change to using BIT() macro.
Fixes: b9ab3b618241 ("ASoC: SDCA: Add some initial IRQ handlers") Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260408093835.2881486-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Using this port configuration, one will be able to set the Maximum Data
Transfer Size (MDTS) for any controller that will be associated to the
configured port. The default value remains 0 (no limit).
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by: Aurelien Aptel <aaptel@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
Geliang Tang [Tue, 31 Mar 2026 08:17:31 +0000 (16:17 +0800)]
nvme: add missing MODULE_ALIAS for fabrics transports
The generic fabrics layer uses request_module("nvme-%s", opts->transport)
to auto-load transport modules. Currently, the nvme-tcp, nvme-rdma, and
nvme-fc modules lack MODULE_ALIAS entries for these names, which prevents
the kernel from automatically finding and loading them when requested.
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Signed-off-by: Keith Busch <kbusch@kernel.org>
Dmitry Torokhov [Thu, 8 Aug 2024 17:27:31 +0000 (10:27 -0700)]
Input: ct82c710 - remove driver
This is a PS/2 mouse interface chip from Chips & Technologies that was
used in TI TravelMate and Gateway Nomad laptops, which used 386 and 486
CPUs. With 486 support being removed from the kernel (and 386 support is
long gone) it is time to retire this driver as well.
Mark Brown [Wed, 8 Apr 2026 14:57:55 +0000 (15:57 +0100)]
Add Renesas RZ/G3L RSPI support
Biju <biju.das.au@gmail.com> says:
This patch series adds binding and driver support for RSPI IP found on the
RZ/G3L SoC. The RSPI is compatible with RZ/V2H RSPI, but has 2 clocks
compared to 3 on RZ/V2H.
Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260408085418.18770-2-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Dmitry Torokhov [Thu, 8 Aug 2024 17:27:30 +0000 (10:27 -0700)]
Input: mk712 - remove driver
This touchscreen controller was used om Gateway AOL Connected Touchpad
released in 2000 and, according to Wikipedia, removed from the market
in October 2001 due to slow sales.
It looks like it can still be bought on eBay for $1000 but I really
doubt anyone will actually use it.
Dmitry Torokhov [Thu, 8 Aug 2024 17:27:27 +0000 (10:27 -0700)]
Input: inport - remove driver
Inport (ATI XL and Microsoft) mice use specialized bus interface
implemented via an ISA add-in card. Have been superseded by PS/2 and
then USB, and are historical curiosity by now.
firmware: efi: Never declare sysfb_primary_display on x86
The x86 architecture comes with its own instance of the global
state variable sysfb_primary_display. Never declare it in the EFI
subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Steven Price [Wed, 8 Apr 2026 09:12:42 +0000 (10:12 +0100)]
drm/panthor: Fix kernel-doc in panthor_sched.c so it's visible
Various substructures defined in panthor_sched.c have kernel-doc which
is silently ignored because it doesn't include the full path to the
member. Fix these issues so that the kernel-doc text is actually output
by including the name of the parent.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260408091242.799074-1-steven.price@arm.com
Documentation: gpio: update the preferred method for using software node lookup
In its current version, the manual for converting of board files from
using GPIO lookup tables to software nodes recommends leaving the
software nodes representing GPIO controllers as "free-floating", not
attached objects and relying on the matching of their names against the
GPIO controller's name. This is an abuse of the software node API and
makes it impossible to create fw_devlinks between GPIO suppliers and
consumers in this case. We want to remove this behavior from GPIOLIB and
to this end, work on converting all existing drivers to using "attached"
software nodes.
Except for a few corner-cases where board files define consumers
depending on GPIO controllers described in firmware - where we need to
reference a real firmware node from a software node - which requires a
more complex approach, most board files can easily be converted to using
propert firmware node lookup.
Update the documentation to recommend attaching the GPIO chip's software
nodes to the actual platform devices and show how to do it.
Randy Dunlap [Tue, 7 Apr 2026 04:36:48 +0000 (21:36 -0700)]
dma-fence: correct kernel-doc function parameter @flags
'make htmldocs' complains that dma_fence_unlock_irqrestore() is missing
a description of its @flags parameter. The description is there but it is
missing a ':' sign. Add that and correct the possessive form of "its".
WARNING: ../include/linux/dma-fence.h:414 function parameter 'flags' not described in 'dma_fence_unlock_irqrestore'
Fixes: 3e5067931b5d ("dma-buf: abstract fence locking v2") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20260407043649.2015894-1-rdunlap@infradead.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Merge tag 'md-7.1-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux into for-7.1/block
Pull MD changes from Yu Kuai:
"Bug Fixes:
- avoid a sysfs deadlock when clearing array state (Yu Kuai)
- validate raid5 journal payloads before reading metadata (Junrui Luo)
- fall back to the correct bitmap operations after version mismatches
(Yu Kuai)
- serialize overlapping writes on writemostly raid1 disks (Xiao Ni)
- wake raid456 reshape waiters before suspend (Yu Kuai)
- prevent retry_aligned_read() from triggering soft lockups
(Chia-Ming Chang)
Improvements:
- switch raid0 strip zone and devlist allocations to kvmalloc helpers
(Gregory Price)
- track clean unwritten stripes for proactive RAID5 parity building
(Yu Kuai)
- speed up initial llbitmap sync with write_zeroes_unmap support
(Yu Kuai)
* tag 'md-7.1-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux:
md/raid5: fix soft lockup in retry_aligned_read()
md: wake raid456 reshape waiters before suspend
md/raid1: serialize overlap io for writemostly disk
md/md-llbitmap: optimize initial sync with write_zeroes_unmap support
md/md-llbitmap: add CleanUnwritten state for RAID-5 proactive parity building
md: add fallback to correct bitmap_ops on version mismatch
md/raid5: validate payload size before accessing journal metadata
md: remove unused static md_wq workqueue
md/raid0: use kvzalloc/kvfree for strip_zone and devlist allocations
md: fix array_state=clear sysfs deadlock
Tomasz Merta [Wed, 8 Apr 2026 08:40:56 +0000 (10:40 +0200)]
ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J
The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A,
DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK
edge when SND_SOC_DAIFMT_NB_NF is used.
Per ALSA convention, NB_NF requires sampling on the rising BCLK edge.
The STM32MP25 SAI reference manual states that CKSTR=1 is required for
signals received by the SAI to be sampled on the SCK rising edge.
Without setting CKSTR=1, the SAI samples on the falling edge, violating
the NB_NF convention. For comparison, the NXP FSL SAI driver correctly
sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its
I2S handling.
This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in
stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec.
RIGHT_J (LSB) is not investigated and addressed by this patch.
Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue
for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified
and is left for a separate investigation.
Kai Vehmanen [Wed, 8 Apr 2026 08:45:14 +0000 (11:45 +0300)]
ASoC: SOF: Intel: hda: modify period size constraints for ACE4
Intel ACE4 based products set more strict constraints on HDA BDLE start
address and length alignment. Add a constraint to align period size to
128 bytes.
The commit removes the "minimum as per HDA spec" comment. This comment
was misleading as spec actually does allow a 2 byte BDLE length, and
more importantly, period size also directly impacts how the BDLE start
addresses are aligned, so it is not sufficient just to consider allowed
buffer length.
Fixes: d3df422f66e8 ("ASoC: SOF: Intel: add initial support for NVL-S") Cc: stable@vger.kernel.org Reported-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20260408084514.24325-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Kai Vehmanen [Wed, 8 Apr 2026 08:45:13 +0000 (11:45 +0300)]
ALSA: hda/intel: enforce stricter period-size alignment for Intel NVL
Intel ACE4 based products set more strict constraints on HDA BDLE start
address and length alignment. Modify capability flags to drop
AZX_DCAPS_NO_ALIGN_BUFSIZE for Intel Nova Lake platforms.
Fixes: 7f428282fde3 ("ALSA: hda: controllers: intel: add support for Nova Lake") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260408084514.24325-2-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, the driver only performs a hardware reset during the I2C probe
sequence. To ensure all internal states of the codec are properly cleared
without affecting the configuration registers, a software reset is also
required.
According to the hardware specification, writing to the Software Reset
register (R01) twice will reset all internal states safely.
This patch adds the nau8325_software_reset() function, executes it right
after the hardware reset in the probe function, and marks the R01 register
as writeable in the regmap configuration.
Ville Syrjälä [Tue, 7 Apr 2026 17:52:43 +0000 (20:52 +0300)]
drm/i915/casf: Integrate the sharpness filter properly into the scaler code
The sharpness filter is just a special mode of the pipe scaler.
It doesn't warrant all this special casing everywhere. Just
integrate it properly into the scaler code so that it's treated
no different from the other pipe scaler uses (scaling,centering,
YCbCr 4:2:0 output).
Ville Syrjälä [Tue, 7 Apr 2026 17:52:42 +0000 (20:52 +0300)]
drm/i915/pfit: Call intel_pfit_compute_config() unconditionally on (e)DP/HDMI
We now have three different reasons for calling
intel_pfit_compute_config():
- actual pfit scaling/centering
- YCbCr 4:2:0 output
- sharpness filter
So let's just call intel_pfit_compute_config() unconditionally
from both the DP and HDMI code. Both gmch and ilk+ pfit code
should be capable of judging whether anything actually
needs the pfit.
The only slightly questionable thing in the gmch code is
the dithering knob, but that's only a thing on gen2/3 which
don't even have HDMI/DP outputs, and so not an issue here.
Ville Syrjälä [Tue, 7 Apr 2026 17:52:39 +0000 (20:52 +0300)]
drm/i915/casf: Handle CASF in skl_scaler_get_filter_select()
Nuke the duplicate CASF_SCALER_FILTER_SELECT and just have
skl_scaler_get_filter_select() return the proper value for
sharpness filter use. It is the same "use programmable coefficients"
value we already use for the nearest neighbor filtering.
Ville Syrjälä [Tue, 7 Apr 2026 17:52:37 +0000 (20:52 +0300)]
drm/i915/casf: Move the casf state to better place
The casf state is placed inside the 'hw' state for some reason.
That is only really meant for things we have to duplicate from
the uapi state. The rest can live on its own in our actual state.
And since casf is just one aspect of the pfit/pipe scaler the
proper place for it seems to be under pch_pfit.
selftests: nft_queue.sh: add a parallel stress test
Introduce a new stress test to check for race conditions in the
nfnetlink_queue subsystem, where an entry is freed while another CPU is
concurrently walking the global rhashtable.
To trigger this, `nf_queue.c` is extended with two new flags:
* -O (out-of-order): Buffers packet IDs and flushes them in reverse.
* -b (bogus verdicts): Floods the kernel with non-existent packet IDs.
The bogus verdict loop forces the kernel's lookup function to perform
full rhashtable bucket traversals (-ENOENT). Combined with reverse-order
flushing and heavy parallel UDP/ping flooding across 8 queues, this puts
the nfnetlink_queue code under pressure.
Joint work with Florian Westphal.
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de> Signed-off-by: Florian Westphal <fw@strlen.de>
Tuan Do [Fri, 3 Apr 2026 07:33:17 +0000 (00:33 -0700)]
netfilter: nft_ct: fix use-after-free in timeout object destroy
nft_ct_timeout_obj_destroy() frees the timeout object with kfree()
immediately after nf_ct_untimeout(), without waiting for an RCU grace
period. Concurrent packet processing on other CPUs may still hold
RCU-protected references to the timeout object obtained via
rcu_dereference() in nf_ct_timeout_data().
Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer
freeing until after an RCU grace period, matching the approach already
used in nfnetlink_cttimeout.c.
KASAN report:
BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0
Read of size 4 at addr ffff8881035fe19c by task exploit/80
netfilter: ip6t_eui64: reject invalid MAC header for all packets
`eui64_mt6()` derives a modified EUI-64 from the Ethernet source address
and compares it with the low 64 bits of the IPv6 source address.
The existing guard only rejects an invalid MAC header when
`par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()`
can still reach `eth_hdr(skb)` even when the MAC header is not valid.
Fix this by removing the `par->fragoff != 0` condition so that packets
with an invalid MAC header are rejected before accessing `eth_hdr(skb)`.
Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Signed-off-by: Florian Westphal <fw@strlen.de>
projects / thirdparty / linux.git / log
