-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEL65usyKPHcrRDEicpmLzj2vtYEkFAmnWuXcACgkQpmLzj2vt
YEnxBA/+IUv7shC+2A9VOmVpPKvF7aP82hyUAaALF0JaUtGuwmKNuMy4g13S+go/
5b6MWDlZ2pjN5lY6jFBVLcxfCysKKS3BKgfPza3y0PK1CoVeXzWniTuVjaHY9Mi+
+I64gAa/Ss1C872meBKvzNvgRnHzDFy6v7bp2Ly57Elack9ZZal6KfXBB3sMkVVB
VCcFAODhiPbr4lgRlMdn6WIEnbNM3TAkmPUKTb4iyOV5qyB5/JQPWT7oqTv0FV6A
z8AYAMVmpVFZyQT4NMKFdNPumziPTp4sQZuo9Wt8ybQuIlzaw1E1npkooNU9mfZd
suKwQAEFnGDWA0T/5rySQ9c2P732PyBgGXpTzPAUUVmsK+LYD/CK7gkCkfursDoI
RJQ8KE/RurQ7OKg8ABFpMw3OnmOfpwH7R4/EJ02PbXFEHWXGt37DrRiqJ5ud1UOj
khm6b+nF1NbLzg+B5fZP7DtlPC76wOXHlAbiFloqEkG6gJl0fLfhmgFi5Pg/GZ92
eWJdUJ5ECnJL9UL2FTDxmFEcIyNBrZh+TS0MHdfvhSUHoyGWO5WNzzTqB/RCrgBF
UVthzr/kSuvIkXbdjG1jDD/y+GHMVjv7HSSeh1p/l/1QfWljk6cglpl6LecaHC2Z
ee2Ra2Jnw7l8PvQq6VH9WkRU94CtQtCHEyztjPW9IaR8CQk+2Oo=
=KzYV
-----END PGP SIGNATURE-----
Merge tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
Pull HID fixes from Jiri Kosina:
- handling of new keycodes for contextual AI usages (Akshai Murari)
- fix for UAF in hid-roccat (Benoît Sevens)
- deduplication of error logging in amd_sfh (Maximilian Pezzullo)
- various device-specific quirks and device ID additions (Even Xu, Lode
Willems, Leo Vriska)
* tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
Input: add keycodes for contextual AI usages (HUTRR119)
HID: Kysona: Add support for VXE Dragonfly R1 Pro
HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP
HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3
HID: roccat: fix use-after-free in roccat_report_event
HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs
HID: Intel-thc-hid: Intel-quicki2c: Add NVL Device IDs
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.
Fixes: 56e15a238d ("PCI: tegra: Add Tegra194 PCIe support")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
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>
Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com
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.
Fixes: 56e15a238d ("PCI: tegra: Add Tegra194 PCIe support")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
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>
Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com
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.
Link: https://patch.msgid.link/20260406162434.40767-1-create0818@163.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217447
Signed-off-by: CaoRuichuang <create0818@163.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
김영민 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>
Commit e4d32142d1 ("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: e4d32142d1 ("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>
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.
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/234
Signed-off-by: muhammed Rishal <muhammedrishal7777777@gmail.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
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.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/220
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
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);
SEC("syscall")
int probe(struct hid_bpf_probe_args *ctx)
{
const char *foo = "foo";
UDEV_PROP_SPRINTF(HID_FOO, "%s", foo);
return 0;
}
Then, we can debug it with a simple cat:
sudo cat /sys/fs/bpf/hid/.../UDEV_PROP_HID_FOO
0: {['f','o','o',],}
This way, the property is always accessible without talking to the
device
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/220
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
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
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/228
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
BPF has bpf_htons and friends but those only work with data in Big
Endian format. HID is little endian so we need our own macros.
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
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
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
On udev-hid-bpf, we are now getting warnings here, shut them off.
Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/227
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
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.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
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.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
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.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
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().
Signed-off-by: Jens Axboe <axboe@kernel.dk>
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>
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: 52a0a98549 ("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>
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.
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260327092106.4233-1-chaitanya.msabnis@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: 659ad3492b ("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>
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: 0d11fab327 ("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>
Getting debug_file can trigger warnings if not set. Avoid getting
these warnings by pushing the use under the controlling if.
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
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>
Make symbol_conf::addr2line_disable_warn configurable by reading
the perfconfig file.
Use section core and addr2line-disable-warn = value.
Update documentation.
Example:
# perf config -l
core.addr2line-timeout=5000
core.addr2line-disable-warn=1
#
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>
Rename member symbol_conf::disable_add2line_warn to
symbol_conf::addr2line_disable_warn to make it consistent with other
addr2line_xxx constants.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
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".
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Link: https://patch.msgid.link/adXkf6MWzlB8LA_s@google.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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: 628329d524 ("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>
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>
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>
trans_pgd would be allocated in trans_pgd_create_copy(), so remove the
duplicate allocation before calling trans_pgd_create_copy().
Fixes: 3744b5280e ("arm64: kexec: install a copy of the linear-map")
Signed-off-by: Wang Wensheng <wsw9603@163.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
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: a2a591fb76 ("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>
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>
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>
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>
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: 99eb057ccd ("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>
- 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
v3: more fix (item 4 to 7).
Assisted-by: GitHub Copilot:claude-opus-4.6
Cc: Xin Wang <x.wang@intel.com>
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-7-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
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.
Assisted-by: GitHub Copilot:claude-opus-4.6
Cc: Xin Wang <x.wang@intel.com>
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-6-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
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
Assisted-by: GitHub Copilot:claude-opus-4.6
Suggested-by: Xin Wang <x.wang@intel.com>
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-5-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
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
Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-3-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
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.
This targets a static analysis issue.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/20260316162003.64643-2-jonathan.cavitt@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
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: 3acf517e1a ("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>
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
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260407055107.2782450-2-tejas.upadhyay@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
