| Age | Commit message (Collapse) | Author |
|---|
|
On start condition of a Buchi automaton, the automaton is executed twice.
This is fine for now, as all the current LTL operators do not care about
this. But it would break the 'next' operator, which will be introduced in a
follow-up patch.
Prepare for the introduction of the 'next' operator, only execute the
automaton once on start condition.
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Gabriele Monaco <gmonaco@redhat.com>
Link: https://lore.kernel.org/9379f4e7b9c1c69a6dca3e20a22936c850a25ca7.1752239482.git.namcao@linutronix.de
Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Fix typo "allocade" -> "allocated".
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/20250710095628.42ed6b06@batman.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Ftrace is tightly coupled with architecture specific code because it
requires the use of trampolines written in assembly. This means that when
a new feature or optimization is made, it must be done for all
architectures. To simplify the approach, CONFIG_HAVE_FTRACE_* configs are
added to denote which architecture has the new enhancement so that other
architectures can still function until they too have been updated.
The CONFIG_HAVE_FTRACE_MCOUNT was added to help simplify the
DYNAMIC_FTRACE work, but now every architecture that implements
DYNAMIC_FTRACE also has HAVE_FTRACE_MCOUNT set too, making it redundant
with the HAVE_DYNAMIC_FTRACE.
Remove the HAVE_FTRACE_MCOUNT config and use DYNAMIC_FTRACE directly where
applicable.
Link: https://lore.kernel.org/all/20250703154916.48e3ada7@gandalf.local.home/
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/20250704104838.27a18690@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
When soft disabling of trace events was first created, it needed to have a
way to know if a file had a user that was using it with soft disabled (for
triggers that need to enable or disable events from a context that can not
really enable or disable the event, it would set SOFT_DISABLED to state it
is disabled). The flag SOFT_MODE was used to denote that an event had a
user that would enable or disable it via the SOFT_DISABLED flag.
Commit 1cf4c0732db3c ("tracing: Modify soft-mode only if there's no other
referrer") fixed a bug where if two users were using the SOFT_DISABLED
flag the accounting would get messed up as the SOFT_MODE flag could only
handle one user. That commit added the sm_ref counter which kept track of
how many users were using the event in "soft mode". This made the
SOFT_MODE flag redundant as it should only be set if the sm_ref counter is
non zero.
Remove the SOFT_MODE flag and just use the sm_ref counter to know the
event is in soft mode or not. This makes the code a bit simpler.
Link: https://lore.kernel.org/all/20250702111908.03759998@batman.local.home/
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Gabriele Paoloni <gpaoloni@redhat.com>
Link: https://lore.kernel.org/20250702143657.18dd1882@batman.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Memory barriers are useful to ensure memory accesses from one CPU appear in
the original order as seen by other CPUs.
Some smp_rmb() and smp_wmb() are used, but they are not ordering multiple
memory accesses.
Remove them.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Gabriele Monaco <gmonaco@redhat.com>
Link: https://lore.kernel.org/20250626151940.1756398-1-namcao@linutronix.de
Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
ftrace has two flavors:
1) static: Where every function always calls the ftrace trampoline
2) dynamic: Where each function has nops that can be changed on demand to
jump to the ftrace trampoline when needed.
The static flavor has very high performance overhead and was only created
to make it easier for architectures to implement the dynamic flavor. An
architecture developer can first implement the static ftrace to make sure
the trampolines work before working on the more complicated dynamic aspect
of ftrace. Once the architecture can support dynamic ftrace, there's no
reason to continue to support the static flavor. In fact, the static
flavor tends to bitrot and bugs start to appear in them.
Remove the prompt to pick DYNAMIC_FTRACE and simply enable it if the
architecture supports it.
Link: https://lore.kernel.org/all/f7e12c6d-892e-4ca3-9ef0-fbb524d04a48@ghiti.fr/
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: ChenMiao <chenmiao.ku@gmail.com>
Link: https://lore.kernel.org/20250703115222.2d7c8cd5@batman.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add a warning if unregister_ftrace_graph() is called without ever
registering it, or if register_ftrace_graph() is called twice. This can
detect errors when they happen and not later when there's a side effect:
Link: https://lore.kernel.org/all/20250617120830.24fbdd62@gandalf.local.home/
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/20250701194451.22e34724@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Add warn_on macro, uses the BUG/WARN feature (lib/bug.c) via assembly
for x86_64/arm64/riscv.
The current Rust code simply wraps BUG() macro but doesn't provide the
proper debug information. The BUG/WARN feature can only be used from
assembly.
This uses the assembly code exported by the C side via ARCH_WARN_ASM
macro. To avoid duplicating the assembly code, this approach follows
the same strategy as the static branch code: it generates the assembly
code for Rust using the C preprocessor at compile time.
Similarly, ARCH_WARN_REACHABLE is also used at compile time to
generate the assembly code; objtool's reachable annotation code. It's
used for only architectures that use objtool.
For now, Loongarch and arm just use a wrapper for WARN macro.
UML doesn't use the assembly BUG/WARN feature; just wrapping generic
BUG/WARN functions implemented in C works.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250502094537.231725-5-fujita.tomonori@gmail.com
[ Avoid evaluating the condition twice (a good idea in general,
but it also matches the C side). Simplify with `as_char_ptr()`
to avoid a cast. Cast to `ffi` integer types for
`warn_slowpath_fmt`. Avoid cast for `null()`. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
When the ring buffer was first introduced, reading the non-consuming
"trace" file required disabling the writing of the ring buffer. To make
sure the writing was fully disabled before iterating the buffer with a
non-consuming read, it would set the disable flag of the buffer and then
call an RCU synchronization to make sure all the buffers were
synchronized.
The function ring_buffer_read_start() originally would initialize the
iterator and call an RCU synchronization, but this was for each individual
per CPU buffer where this would get called many times on a machine with
many CPUs before the trace file could be read. The commit 72c9ddfd4c5bf
("ring-buffer: Make non-consuming read less expensive with lots of cpus.")
separated ring_buffer_read_start into ring_buffer_read_prepare(),
ring_buffer_read_sync() and then ring_buffer_read_start() to allow each of
the per CPU buffers to be prepared, call the read_buffer_read_sync() once,
and then the ring_buffer_read_start() for each of the CPUs which made
things much faster.
The commit 1039221cc278 ("ring-buffer: Do not disable recording when there
is an iterator") removed the requirement of disabling the recording of the
ring buffer in order to iterate it, but it did not remove the
synchronization that was happening that was required to wait for all the
buffers to have no more writers. It's now OK for the buffers to have
writers and no synchronization is needed.
Remove the synchronization and put back the interface for the ring buffer
iterator back before commit 72c9ddfd4c5bf was applied.
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/20250630180440.3eabb514@batman.local.home
Reported-by: David Howells <dhowells@redhat.com>
Fixes: 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator")
Tested-by: David Howells <dhowells@redhat.com>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
|
|
Platforms supporting direct message request v2 [1] can support secure
partitions that support multiple services. For CRB over FF-A interface,
if the firmware TPM or TPM service [1] shares its Secure Partition (SP)
with another service, message requests may fail with a -EBUSY error.
To handle this, replace the single check and call with a retry loop
that attempts the TPM message send operation until it succeeds or a
configurable timeout is reached. Implement a _try_send_receive function
to do a single send/receive and modify the existing send_receive to
add this retry loop.
The retry mechanism introduces a module parameter (`busy_timeout_ms`,
default: 2000ms) to control how long to keep retrying on -EBUSY
responses. Between retries, the code waits briefly (50-100 microseconds)
to avoid busy-waiting and handling TPM BUSY conditions more gracefully.
The parameter can be modified at run-time as such:
echo 3000 | tee /sys/module/tpm_crb_ffa/parameters/busy_timeout_ms
This changes the timeout from the default 2000ms to 3000ms.
[1] TPM Service Command Response Buffer Interface Over FF-A
https://developer.arm.com/documentation/den0138/latest/
Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Simplify initialization of `ffa_send_direct_data2` and
`ffa_send_direct_data` structures by using designated initializers
instead of `memset()` followed by field assignments, reducing code size
and improving readability.
Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Rename *recieve as __tpm_crb_ffa_send_receive
[jarkko: polished commit message]
Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
The current implementation of timeout detection works in the following
way:
1. Read completion status. If completed, return the data
2. Sleep for some time (usleep_range)
3. Check for timeout using current jiffies value. Return an error if
timed out
4. Goto 1
usleep_range doesn't guarantee it's always going to wake up strictly in
(min, max) range, so such a situation is possible:
1. Driver reads completion status. No completion yet
2. Process sleeps indefinitely. In the meantime, TPM responds
3. We check for timeout without checking for the completion again.
Result is lost.
Such a situation also happens for the guest VMs: if vCPU goes to sleep
and doesn't get scheduled for some time, the guest TPM driver will
timeout instantly after waking up without checking for the completion
(which may already be in place).
Perform the completion check once again after exiting the busy loop in
order to give the device the last chance to send us some data.
Since now we check for completion in two places, extract this check into
a separate function.
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Reviewed-by: Jonathan McDowell <noodles@meta.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Use the newly added of_reserved_mem_region_to_resource() function to
handle "memory-region" properties.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
functions
Documentation/filesystems/sysfs.rst mentions that show() should only
use sysfs_emit() or sysfs_emit_at() when formating the value to be
returned to user space. So replace scnprintf() with sysfs_emit().
Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Remove the export of tpm_crb_ffa_get_interface_version() as it has no
callers outside tpm_crb_ffa.
Fixes: eb93f0734ef1 ("tpm_crb: ffa_tpm: Implement driver compliant to CRB over FF-A")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
To generate the boot_aggregate log in the IMA subsystem using TPM PCR
values, the TPM driver must be built as built-in and must be probed
before the IMA subsystem is initialized.
However, when the TPM device operates over the FF-A protocol using the
CRB interface, probing fails and returns -EPROBE_DEFER if the
tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.
This issue occurs because both crb_acpi_driver_init() and
tpm_crb_ffa_driver_init() are registered with device_initcall. As a
result, crb_acpi_driver_init() may be invoked before
tpm_crb_ffa_driver_init(), which is responsible for probing the
tpm_crb_ffa device.
When this happens, IMA fails to detect the TPM device and logs the
following message:
| ima: No TPM chip found, activating TPM-bypass!
Consequently, it cannot generate the boot_aggregate log with the PCR
values provided by the TPM.
To resolve this issue, the tpm_crb_ffa_init() function explicitly
attempts to probe the tpm_crb_ffa by register tpm_crb_ffa driver so that
when tpm_crb_ffa device is created before tpm_crb_ffa_init(), probe the
tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the TPM device
completely.
This ensures that the TPM device using CRB over FF-A can be successfully
probed, even if crb_acpi_driver_init() is called first.
[ jarkko: reformatted some of the paragraphs because they were going past
the 75 character boundary. ]
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
The Linux IMA (Integrity Measurement Architecture) subsystem used for
secure boot, file integrity, or remote attestation cannot be a loadable
module for few reasons listed below:
o Boot-Time Integrity: IMA’s main role is to measure and appraise files
before they are used. This includes measuring critical system files during
early boot (e.g., init, init scripts, login binaries). If IMA were a
module, it would be loaded too late to cover those.
o TPM Dependency: IMA integrates tightly with the TPM to record
measurements into PCRs. The TPM must be initialized early (ideally before
init_ima()), which aligns with IMA being built-in.
o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it
a module would weaken the security model, as a potentially compromised
system could delay or tamper with its initialization.
IMA must be built-in to ensure it starts measuring from the earliest
possible point in boot which inturn implies TPM must be initialised and
ready to use before IMA.
To enable integration of tpm_event_log with the IMA subsystem, the TPM
drivers (tpm_crb and tpm_crb_ffa) also needs to be built-in. However with
FF-A driver also being initialised at device initcall level, it can lead to
an initialization order issue where:
- crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and
ffa_init()
- As a result, probing the TPM device via CRB over FFA is deferred
- ima_init() (called as a late initcall) runs before deferred probe
completes, IMA fails to find the TPM and logs the below error:
| ima: No TPM chip found, activating TPM-bypass!
Eventually it fails to generate boot_aggregate with PCR values.
Because of the above stated dependency, the ffa driver needs to initialised
before tpm_crb_ffa module to ensure IMA finds the TPM successfully when
present.
[ jarkko: reformatted some of the paragraphs because they were going past
the 75 character boundary. ]
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
Keep using the same pre-allocated buffer to avoid having to allocate
it for each command. We need the buffer to have the header required by
the SVSM protocol and the command contiguous in memory.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and .recv() calls.
Introduce a new flag (TPM_CHIP_FLAG_SYNC) to support synchronous send().
If that flag is set by the driver, tpm_try_transmit() will use the send()
callback to send the command and receive the response on the same buffer
synchronously. In that case send() return the number of bytes of the
response on success, or -errno on failure.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `bufsiz` is
not used, but it will be used to implement devices with synchronous send()
to send the command and receive the response on the same buffer.
Also rename the previous parameter `len` to `cmd_len` in the declaration
to make it clear that it contains the length in bytes of the command
stored in the buffer. The semantics don't change and it can be used as
before by drivers. This is an optimization since the drivers could get it
from the header, but let's avoid duplicating code.
While we are here, resolve a checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
#66: FILE: include/linux/tpm.h:90:
+ int (*send) (struct tpm_chip *chip, u8 *buf, size_t bufsiz,
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Query support for Immediate Readiness irrespective of whether or not the
device supports PM capabilities, as nothing in the PCIe spec suggests that
Immediate Readiness is in any way dependent on PM functionality.
Fixes: d6112f8def51 ("PCI: Add support for Immediate Readiness")
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Matlack <dmatlack@google.com>
Cc: Vipin Sharma <vipinsh@google.com>
Cc: Aaron Lewis <aaronlewis@google.com>
Link: https://patch.msgid.link/20250722155926.352248-1-seanjc@google.com
|
|
Convention is to define static data as 'static const ...', not 'static
... const' because of readability, even if the code is functionally
equal.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250707092200.48862-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The M41T65 device does not support the "Halt Update Bit" (HT) feature
as per its datasheet.
This aligns the driver with the actual hardware capabilities.
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Link: https://lore.kernel.org/r/20250704091144.45389-1-eagle.alexander923@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Mux clocks are now described with a customized ccu_mux structure
consisting of ccu_internal and ccu_common substructures, and registered
later with devm_clk_hw_register_mux_parent_data_table(). As this helper
always allocates a new clk_hw structure, it's extremely hard to use mux
clocks as parents statically by clk_hw pointers, since CCF has no
knowledge about the clk_hw structure embedded in ccu_mux.
This scheme already causes issues for clock c910, which takes a mux
clock, c910-i0, as a possible parent. With mainline U-Boot that
reparents c910 to c910-i0 at boottime, c910 is considered as an orphan
by CCF.
This patch refactors handling of mux clocks, embeds a clk_mux structure
in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(),
we could register mux clocks on our own without allocating any new
clk_hw pointer, fixing c910 clock's issue.
Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Signed-off-by: Drew Fustini <fustini@kernel.org>
|
|
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with
Rust to avoid the duplication.
No functional changes.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250502094537.231725-4-fujita.tomonori@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with
Rust to avoid the duplication.
No functional changes.
Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250502094537.231725-3-fujita.tomonori@gmail.com
[ Remove ending newline in `ARCH_WARN_ASM` content to be closer to the
original. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with
Rust to avoid the duplication.
No functional changes.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/r/20250502094537.231725-2-fujita.tomonori@gmail.com
[ Fixed typo in macro parameter name. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The test_kexec_jump program builds correctly when invoked from the top-level
selftests/Makefile, which explicitly sets the OUTPUT variable. However,
building directly in tools/testing/selftests/kexec fails with:
make: *** No rule to make target '/test_kexec_jump', needed by 'test_kexec_jump.sh'. Stop.
This failure occurs because the Makefile rule relies on $(OUTPUT), which is
undefined in direct builds.
Fix this by listing test_kexec_jump in TEST_GEN_PROGS, the standard way to
declare generated test binaries in the kselftest framework. This ensures the
binary is built regardless of invocation context and properly removed by
make clean.
Link: https://lore.kernel.org/r/20250702171704.22559-2-moonhee.lee.ca@gmail.com
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Moon Hee Lee <moonhee.lee.ca@gmail.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into soc/dt
Apple SoC device tree changes for v6.17
- Added the bindings and nodes for Apple SoC GPU. The driver itself
isn't ready for upstreaming yet due to rust dependencies but we're
confident that the bindings are stable at this point.
- Added a missing node for the touchbar framebuffer to Apple T2 device
trees, which is the BMC for some x86 Macs
- Fixed a W=1 warning by adding bit offsets to NVMEM node names. This
required a change to the generic NVMEM cell binding which will be part
of 6.17 through the NVMEM tree.
Signed-off-by: Sven Peter <sven@kernel.org>
* tag 'apple-soc-dt-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux:
arm64: dts: apple: Add Apple SoC GPU
dt-bindings: gpu: Add Apple SoC GPU
arm64: dts: apple: t8012-j132: Include touchbar framebuffer node
arm64: dts: apple: Add bit offset to PMIC NVMEM node names
Link: https://lore.kernel.org/r/20250722163258.62424-2-sven@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt
Microchip AT91 device tree updates for v6.17
This update includes:
- controllers enabled for SAMA7D65 SoC (crypto controllers, PWM, CAN)
- controllers enabled for SAM9X7 SoC (LCD, LVDS)
- cache configuration updates for SAMA5D2, SAMA5D3, SAMA5D4, SAMA7G5,
SAMA7D65
- cleanups
* tag 'at91-dt-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: (22 commits)
ARM: dts: microchip: sama7g5: Add cache configuration for cpu node
ARM: dts: microchip: sama7d65: Add cache configuration for cpu node
ARM: dts: microchip: sama5d4: Update the cache configuration for CPU
ARM: dts: microchip: sama5d3: Update the cache configuration for CPU
ARM: dts: microchip: sama5d2: Update the cache configuration for CPU
ARM: dts: microchip: sam9x7: Add LVDS controller
ARM: dts: microchip: sama5d2_icp: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns
ARM: dts: microchip: sama5d27_wlsom1: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns
ARM: dts: microchip: sama5d27_som1: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns
ARM: dts: microchip: sam9x60ek: rename spi-cs-setup-ns property to spi-cs-setup-delay-ns
ARM: dts: at91-sama5d27_wlsom1: Improve the Wifi compatible
ARM: dts: microchip: gardena-smart-gateway: Fix power LED
ARM: dts: microchip: sam9x7: Add clock name property
ARM: dts: microchip: sama7d65: Add clock name property
ARM: dts: microchip: sama7g5: Adjust clock xtal phandle
ARM: dts: microchip: sam9x7: Add HLCD controller
ARM: dts: microchip: sama7d65: Enable CAN bus
ARM: dts: microchip: sama7d65: Clean up extra space
ARM: dts: microchip: sama7d65: Add CAN bus support
ARM: dts: microchip: sama7d65: Add PWM support
...
Link: https://lore.kernel.org/r/20250721100904.568575-2-claudiu.beznea@tuxon.dev
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into soc/dt
T-HEAD Devicetrees for v6.17
There are several additions for the T-Head TH1520 SoC:
- Add PVT node for thermal sensor which works with the existing Moortec
MR75203 driver.
- Add "gpu-clkgen" reset property to the AON node which allows the power
domain driver to detect the capability to power sequence the GPU.
All of these patches have been tested in linux-next.
Signed-off-by: Drew Fustini <fustini@kernel.org>
* tag 'thead-dt-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux:
riscv: dts: thead: Add PVT node
riscv: dts: thead: th1520: Add GPU clkgen reset to AON node
Link: https://lore.kernel.org/r/aHtnwthmTpfkIBMr@x1
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
New board: FriendlyElec NanoPi M5
Camera support for the PinePhone Pro.
A bunch of cleanups to make DTC happier, fix ordering of DMA uart
channels on rk3528 and some video output enablement as well as some
button definitions.
An interesting tidbit is the reset behaviour addition in that some
boards have specific requirements as to how the PMIC needs to do the
restart. DT-maintainers did not consider the header with helper-constants
as part of the binding, so that header ended up in the Rockchip directory
* tag 'v6.17-rockchip-dts64-2' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (29 commits)
arm64: dts: rockchip: Add maskrom button to NanoPi R5S + R5C
arm64: dts: rockchip: Drop regulator-compatible property on rk3399
arm64: dts: rockchip: Drop unneeded address+size-cells on px30
arm64: dts: rockchip: Fix LCD panel port on rk3566-pinetab2
arm64: dts: rockchip: Move mipi_out node on rk3399 haikou demo dtso
arm64: dts: rockchip: Simplify mipi_out endpoint on rk3399 RP64 dtso
arm64: dts: rockchip: Simplify edp endpoints on several rk3399 boards
arm64: dts: rockchip: Simplify VOP port definition on rk3328
arm64: dts: rockchip: Move dsi address+size-cells from SoC to rk3399 boards
arm64: dts: rockchip: Move dsi address+size-cells from SoC to px30 boards
arm64: dts: rockchip: Fix UART DMA support for RK3528
arm64: dts: rockchip: Add reset button to NanoPi R5S
arm64: dts: rockchip: Add rtc0 alias for NanoPi R5S + R5C
arm64: dts: rockchip: describe the OV8858 user camera on PinePhone Pro
arm64: dts: rockchip: describe I2c Bus 1 and IMX258 world camera on PinePhone Pro
arm64: dts: rockchip: Fix pinctrl node names for RK3528
arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support
dt-bindings: arm: rockchip: add FriendlyElec NanoPi M5 board
arm64: dts: rockchip: force PMIC reset behavior to restart PMU on RK3588 Tiger
arm64: dts: rockchip: force PMIC reset behavior to restart PMU on RK3588 Jaguar
...
Link: https://lore.kernel.org/r/11552292.NyiUUSuA9g@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Common name for Ethernet controllers is "ethernet", not "eth", also
recommended by Devicetree specification in "Generic Names
Recommendation". Verified lack of impact using dtx_diff.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20250717142245.92492-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/defconfig
Enable Rockchip DFI + PM_DEVFREQ_EVENT and RGA modules.
* tag 'v6.17-rockchip-defconfig64-1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: defconfig: enable further Rockchip platform drivers
Link: https://lore.kernel.org/r/9025082.MhkbZ0Pkbq@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/defconfig
Qualcomm Arm64 defconfig updates for v6.17
Enable camera and video clock controllers for SM8450, SM8550, and SM8650
platforms.
* tag 'qcom-arm64-defconfig-for-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable camcc and videocc on Qualcomm SM8450+
Link: https://lore.kernel.org/r/20250720031134.286063-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/defconfig
Microchip AT91 defconfig updates for v6.17
This update includes:
- the WILC1000 SDIO module
* tag 'at91-defconfig-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: configs: sama5_defconfig: Select CONFIG_WILC1000_SDIO
Link: https://lore.kernel.org/r/20250721100904.568575-1-claudiu.beznea@tuxon.dev
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
Qualcomm driver updates for v6.17
Perform input validation in the MDT loader, as this was not properly
done in the non-remoteproc cases.
Fix endian issues in the QMI encoder/decoder.
Support reading DDR statistic using the Qualcomm stats driver.
Add support for reading TME firmware details to the socinfo driver.
Document the Kryo 470 CPU, and add SM7150 to the DCC to DeviceTree
bindings.
* tag 'qcom-drivers-for-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: mdt_loader: Fix error return values in mdt_header_valid()
dt-bindings: sram: qcom,imem: Add a number of missing compatibles
dt-bindings: arm: cpus: Add Kryo 470 CPUs
dt-bindings: sram: qcom,imem: Add the SM7150 compatible
dt-bindings: soc: qcom: aoss-qmp: Add the SM7150 compatible
dt-bindings: soc: qcom,dcc: Add the SM7150 compatible
soc: qcom: socinfo: Add support to retrieve TME build details
soc: qcom: fix endianness for QMI header
soc: qcom: QMI encoding/decoding for big endian
dt-bindings: soc: qcom: add qcom,qcs615-imem compatible
soc: qcom: qcom_stats: Add QMP support for syncing ddr stats
soc: qcom: qcom_stats: Add support to read DDR statistic
soc: qcom: mdt_loader: Actually use the e_phoff
soc: qcom: mdt_loader: Rename mdt_phdr_valid()
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
Link: https://lore.kernel.org/r/20250715021454.14516-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v6.17
1. Several cleanups: Use dev_fwnode() in OMAP GPMX, convert
arm,pl172.txt DT bindings to DT schema, use
syscon_regmap_lookup_by_phandle_args() wrapper, correct kerneldoc.
2. Mediatek MT8186 SMI: Extend hardware bandwidth limits to fix VENC
hardware during stress testing.
3. Broadcom brcmstb_memc: Add additional fallback compatible and
simplify device driver matching. The change comes from Broadcom
SoC maintainer (Florian Fainelli), thus its ABI impact is
acknowledged.
* tag 'memory-controller-drv-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
dt-bindings: memory: renesas,rzg3e-xspi: Document RZ/V2H(P) and RZ/V2N support
memory: brcmstb_memc: Simplify compatible matching
dt-bindings: memory-controller: Define fallback compatible
memory: omap-gpmx: Use dev_fwnode()
memory: mtk-smi: Add ostd setting for mt8186
dt-bindings: memory-controllers: convert arm,pl172.txt to yaml format
memory: stm32_omm: Use syscon_regmap_lookup_by_phandle_args
memory: emif: Add missing kerneldoc for lpmode
Link: https://lore.kernel.org/r/20250715095315.59299-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
32bit version has been added by commit 4a6b93f56296 ("dt-bindings: riscv:
cpus: Add AMD MicroBlaze V compatible") but 64bit version also exists and
should be covered by binding too.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/drivers
i.MX drivers changes for 6.17:
- A couple of MAINTAINERS updates
- A new bus driver for i.MX AIPSTZ bridge and a follow-up fix from
Laurentiu Mihalcea
* tag 'imx-drivers-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
bus: imx-aipstz: allow creating pdevs for child buses
MAINTAINERS: Update i.MX entry
bus: add driver for IMX AIPSTZ bridge
MAINTAINERS: add NXP S32G RTC driver
Link: https://lore.kernel.org/r/20250713055441.221235-1-shawnguo2@yeah.net
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers
memory: tegra: Updates for v6.17-rc1
Enable support for the memory and external memory controllers found on
Tegra264.
* tag 'tegra-for-6.17-memory' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
memory: tegra: Add Tegra264 MC and EMC support
dt-bindings: memory: tegra: Add Tegra264 support
Link: https://lore.kernel.org/r/20250711220943.2389322-4-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers
firmware: tegra: Updates for v6.17-rc1
Add Tegra264 support for the BPMP, fix some dependency issues and clean
up some code using new OF helpers.
* tag 'tegra-for-6.17-firmware' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: bpmp: Fix build failure for tegra264-only config
firmware: tegra: bpmp: Use of_reserved_mem_region_to_resource() for "memory-region"
firmware: tegra: bpmp: Add support on Tegra264
firmware: tegra: Fix IVC dependency problems
Link: https://lore.kernel.org/r/20250711220943.2389322-2-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Sometimes the netdev triggers causes tasks to get blocked for more then
120 seconds, which in turn makes the (WAN) network port on the NanoPi
R5S fail to come up.
This results in the following (partial) trace:
INFO: task kworker/0:1:11 blocked for more than 120 seconds.
Not tainted 6.16-rc6+unreleased-arm64-cknow #1 Debian 6.16~rc6-1~exp1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00000010
Workqueue: events_power_efficient reg_check_chans_work [cfg80211]
Call trace:
__switch_to+0xf8/0x168 (T)
__schedule+0x3f8/0xda8
schedule+0x3c/0x120
schedule_preempt_disabled+0x2c/0x58
__mutex_lock.constprop.0+0x4d0/0xab8
__mutex_lock_slowpath+0x1c/0x30
mutex_lock+0x50/0x68
rtnl_lock+0x20/0x38
reg_check_chans_work+0x40/0x478 [cfg80211]
process_one_work+0x178/0x3e0
worker_thread+0x260/0x390
kthread+0x150/0x250
ret_from_fork+0x10/0x20
INFO: task kworker/0:1:11 is blocked on a mutex likely owned by task dhcpcd:615.
task:dhcpcd state:D stack:0 pid:615 tgid:615 ppid:614 task_flags:0x400140 flags:0x00000018
Call trace:
__switch_to+0xf8/0x168 (T)
__schedule+0x3f8/0xda8
schedule+0x3c/0x120
schedule_preempt_disabled+0x2c/0x58
rwsem_down_write_slowpath+0x1e4/0x750
down_write+0x98/0xb0
led_trigger_register+0x134/0x1c0
phy_led_triggers_register+0xf4/0x258 [libphy]
phy_attach_direct+0x30c/0x390 [libphy]
phylink_fwnode_phy_connect+0xb0/0x138 [phylink]
__stmmac_open+0xec/0x520 [stmmac]
stmmac_open+0x4c/0xe8 [stmmac]
__dev_open+0x130/0x2e0
__dev_change_flags+0x1c4/0x248
netif_change_flags+0x2c/0x80
dev_change_flags+0x88/0xc8
devinet_ioctl+0x35c/0x610
inet_ioctl+0x204/0x260
sock_do_ioctl+0x6c/0x140
sock_ioctl+0x2e4/0x388
__arm64_sys_ioctl+0xb4/0x120
invoke_syscall+0x6c/0x100
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x3c/0x188
el0t_64_sync_handler+0x10c/0x140
el0t_64_sync+0x198/0x1a0
In order to not introduce a regression with kernel 6.16, drop the netdev
triggers for now while the problem is being investigated further.
Fixes: 1631cbdb8089 ("arm64: dts: rockchip: Improve LED config for NanoPi R5S")
Helped-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250722123628.25660-1-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Now that the XGene MSI driver has been mostly rewritten and doesn't
use the CPU hotplug infrastructure, CPUHP_PCI_XGENE_DEAD is unused.
Remove it to reduce the size of cpuhp_hp_states[].
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-14-maz@kernel.org
|
|
Another utterly pointless aspect of the xgene-msi driver is that
it is built around CPU hotplug. Which is quite amusing since this
is one of the few arm64 platforms that, by construction, cannot
do CPU hotplug in a supported way (no EL3, no PSCI, no luck).
Drop the CPU hotplug nonsense and just setup the IRQs and handlers
in a less overdesigned way, grouping things more logically in the
process.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-13-maz@kernel.org
|
|
Now that we have made the dependency between the PCI driver and
the MSI driver explicit, there is no need to use subsys_initcall()
as a probing hook, and we can rely on builtin_platform_driver()
instead.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-12-maz@kernel.org
|
|
Since changing the affinity of an MSI really is about changing
the target address and that it isn't possible to mask an individual
MSI, it is completely possible for an interrupt to race with itself,
usually resulting in a lost interrupt.
Paper over the design blunder by informing the core code of this
sad state of affairs.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-11-maz@kernel.org
|
|
Plugging a device that doesn't use managed affinity on an XGene-1
machine results in messages such as:
genirq: irq_chip PCI-MSIX-0000:01:00.0 did not update eff. affinity mask of irq 39
As it turns out, the driver was never updated to populate the effective
affinity on irq_set_affinity() call, and the core code is prickly about
that.
But upon further investigation, it appears that the driver keeps repainting
the hwirq field of the irq_data structure as a way to track the affinity
of the MSI, something that is very much frowned upon as it breaks the
fundamentals of an IRQ domain (an array indexed by hwirq).
Fixing this results more or less in a rewrite of the driver:
- Define how a hwirq and a CPU affinity map onto the MSI termination
registers
- Allocate a single entry in the bitmap per MSI instead of *8*
- Correctly track CPU affinity
- Fix the documentation so that it actually means something (to me)
- Use standard bitmap iterators
- and plenty of other cleanups
With this, the driver behaves correctly on my vintage Mustang board.
Signed-off-by: Marc Zyngier <maz@kernel.org>
[lpieralisi: replaced open coded GENMASK(6, 4) with MSInRx_HWIRQ_MASK]
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-10-maz@kernel.org
|
