Add test to validate support for the two cases of tail adjustment: 1)
tail extension, and 2) tail shrinking across different frame sizes and
offset values. For each of the two cases, test both the single and
multi-buffer cases by choosing appropriate packet size.
The negative offset value result in growing of tailroom (shrinking of
payload) while the positive offset result in shrinking of tailroom
(growing of payload).
Since the support for tail adjustment varies across drivers, classify the
test as pass if at least one combination of packet size and offset from a
pre-selected list results in a successful run. In case of an unsuccessful
run, report the failure and highlight the packet size and offset values
that caused the test to fail, as well as the values that resulted in the
last successful run.
Note: The growing part of this test for netdevsim may appear flaky when
the offset value is larger than 1. This behavior occurs because tailroom
is not explicitly reserved for netdevsim, with 1 being the typical
tailroom value. However, in certain cases, such as payload being the last
in the page with additional available space, the truesize is expanded.
This also result increases the tailroom causing the test to pass
intermittently. In contrast, when tailrrom is explicitly reserved, such
as in the of fbnic, the test results are deterministic.
./drivers/net/xdp.py
TAP version 13
1..7
ok 1 xdp.test_xdp_native_pass_sb
ok 2 xdp.test_xdp_native_pass_mb
ok 3 xdp.test_xdp_native_drop_sb
ok 4 xdp.test_xdp_native_drop_mb
ok 5 xdp.test_xdp_native_tx_mb
\# Failed run: ... successful run: ... offset 1. Reason: Adjustment failed
ok 6 xdp.test_xdp_native_adjst_tail_grow_data
ok 7 xdp.test_xdp_native_adjst_tail_shrnk_data
\# Totals: pass:7 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Link: https://patch.msgid.link/20250719083059.3209169-5-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add test to verify the XDP_TX functionality by generating traffic from a
remote node on a specific UDP port and redirecting it back to the sender.
./drivers/net/xdp.py
TAP version 13
1..5
ok 1 xdp.test_xdp_native_pass_sb
ok 2 xdp.test_xdp_native_pass_mb
ok 3 xdp.test_xdp_native_drop_sb
ok 4 xdp.test_xdp_native_drop_mb
ok 5 xdp.test_xdp_native_tx_mb
\# Totals: pass:5 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Link: https://patch.msgid.link/20250719083059.3209169-4-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test XDP_PASS/DROP in single buffer and multi buffer mode when
XDP native support is available.
./drivers/net/xdp.py
TAP version 13
1..4
ok 1 xdp.test_xdp_native_pass_sb
ok 2 xdp.test_xdp_native_pass_mb
ok 3 xdp.test_xdp_native_drop_sb
ok 4 xdp.test_xdp_native_drop_mb
\# Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Link: https://patch.msgid.link/20250719083059.3209169-3-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add basic XDP support by hooking in do_xdp_generic().
This should be enough to validate most basic XDP tests.
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Link: https://patch.msgid.link/20250719083059.3209169-2-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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>
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 1cf4c0732d ("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 72c9ddfd4c
("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 1039221cc2 ("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 72c9ddfd4c 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: 1039221cc2 ("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>
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>
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: eb93f0734e ("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: d6112f8def ("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: ae81b69fd2 ("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>
- 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>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS3vz815OHsEaWy0u9EEX0kKnUe6QUCaH+8XwAKCRBEEX0kKnUe
6ZgFAQCOqbUyJPz0oxSTrrHQRwumhx0P6CIhVBtSaOtDnHYBJwD8CpPxfXXqMvgm
Wqr/bugw4pnR/LZRTScSoiqlwT3gZQs=
=L1MH
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh//I8ACgkQmmx57+YA
GNmY9RAAmw4mkjv7ptPq1s323GHuqUFMDhmrScTeg5W3+rrlWSOYDkWYJFBcUdMa
d+camZ2Ey4RHcRDqOmcQvx93lcUoyBzoa9EQ8xU8wm1G2p4myIF2eFBlR6LiggZN
bV9naAl+4/7lRKzD35scGRlsvD2TRhYpff6ow1Kw8QfRk9N4P4j8TVHu+niE5088
lMtNTLnli7HUu2TbqgwZ8tG8CdJVJb3n5Xxi/V8gnG+tYnxQAEGBXkR3JznQZuSG
5PHZnyRhkk8/Qbcfb9W87OWIEhW53K2IVrqp2uStdv4AqvEyZYtMI4TOToZGi0t0
EpV2EZIEMq+fgu2DnihQ702JbjkxReqky+86mYkXWAfxJ+BW2mO4xqqZ+LQsjhbk
/Vxfvaf5y1iUh/W+hETaAePOFvo00m+ur+Rh2FG8/TG7Avow01cbOTmj37Mt6L3l
gT31yxv5Ys3YsClpQygvrnZPQj6Fxc3khbU8VRyL3GJJKQWs14+Bw3/q/zXnZdpq
oTrkMwGd9EdW/6p/ReL8deL1Lfc4mWkf9BwpbGzFdvkKmuiv0+okRxwslBqvK3l2
Jx59AkkdyqBvsQ1a5F5/6tvPnyUynF7PAaAW6jnnK8FZfuDetnfxoNpMfoB2O4fS
d1lScQGR9CPDiTiL94XN2DKAJQLNNeAtuzhaayUjHvAN+Mq+Acw=
=um3t
-----END PGP SIGNATURE-----
Merge tag 'apple-soc-dt-6.17' of 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>
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>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSy8G7QpEpV9aCf6Lbb7CzD2SixDAUCaHtRSAAKCRDb7CzD2Six
DMonAP4jtzBtR4SnzrruTktZ27Q4zXsWs4JmnbQQaL+gl4x3VAD8Dcq+rlzAUHsT
YmyQckLo6ioMbzsETuw2/lUGKkwL+Qg=
=+LQL
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh//DAACgkQmmx57+YA
GNke3w//Zbyeby/GC5uEfMw/Wh/evyn3tTwITFfVlRXNJxQVusU3FFsCnNXnQQYd
QavMb5htZIUAGAdINANxJnDSMm+8hTrWIW5B0Tw9TJIVoJIyAAKkwP4j6UnCWyqt
WODGt+2/1L1ykGSYBHZWaRT8nnDo3s35Duip7DgA2Xoq4tUdLNYCeKYWM+YV0VNC
84YHH3kktLzT5FULk+SMPfEutNYUWlPFF9nwPlP7iEWpiK/PkFS8BzDzQGWfJNPS
Iskrq6Dh7hfI5IMZnSzcwUvvB2nZS4/f4h0vl2U9YVXQIExKK6Fp8o3zvKsdw8HR
4kiGczWmzNGv28empHjg5HiuSz0HCY9fpH2ptjCCx0YdbQ5RI8qUQfQ+AdJxuKji
+wOxpSXu+6oO6QAO/1MSa8eidCw1NMA8emj8B+GYkiva0FjlcTCJ2gM7IpkMZFYg
CbRbpdR4P3akexl4RMHNGEijnX5QrVCZO3v+kYKTYepYZ1NshAaS6c+xwQbyP2Vp
VAfwqvf9TCjKVFJHY7zELeAFt9IL7eXK6Syxq55FjXBNCh7J6e7A1cw4FMeP38Eb
wtGIzmAOb7tNo7Nj1u3v4bOyC1ujuKEpXJaCZTaJu2XckGOv4MnB13S5PdC1vEaP
ku2B4X3Ea7EO2OXB+T80JnC1KgbWaVMQmsBejdk/sGLFe+CFyyw=
=PdaW
-----END PGP SIGNATURE-----
Merge tag 'thead-dt-for-v6.17' of 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>
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
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmh6tRwQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgbsjCACMBjOtz2pLx0K76/51SGDzM12+ORi5K/ev
In1kcYSOIJySrQCUPDpma+k/JwptphdQlOfy4pewu/QFUaFln8ei9YGaQtmmyHTi
d/tDbv9/1bnCvTG8m9wbOkVYpLxvGMfpFZFH3WvNib4oaSxyc34q4zW0T1VTl0DZ
s3Q57dZsH0VnijFoj1VKz7gjz8jSuO6LksaYVcb7U4b9GQOCfMS1iDs1UJnfG1Xg
z4molRvAU5rfzlNNRnHIEAeh42b9tOU+jFy7Qlig7RD2eM0BudyziGau3nQGjEP3
WjDCfwHRo62EOoUSBRbdD9wCD6QsZJteSLMCA/J8EAA0xraEvKYy
=65EK
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh/++kACgkQmmx57+YA
GNmHIxAAr9aW2c1JkYwquZcD1dWoR/+vsdyoukha3KAWUftYL2/kK0LTL3Dfi4yR
V8F21OPExHC/n2B93bTPYBSBJ8wvJqhZHdX7dcOeglu+M+4iwm+5PPkR0LwelcyI
/NFVMLAQuvcoBOVv2bX+bJHpQDELBu7M0PhJLiIwtJFFLvW/8Dj8RLXAIOQ4yEQg
kYBbjLzeotd+QjvRyw2PdA+Mj7hnA/E2c6aIQoWf60ey62hZaXRIIAEveuW4lR84
raM8gDE9XsiD00wPOctsPkIg4aD6R0z/HqNhan2zbUVH/6wW5qd8fXuwpEk7jE53
WFP0ZEVYEVrRzMiHn+FOhw7S8m/btKVsDrmqF4SNuTrVqXwfkEomFfiNcEWAp3FY
rmkY1KNGsc7oK9mRwKl2Qv84VgPM92E4nyCuUbsTGAlTED0E1FuT7KmGW+vvKtL5
TryUA5UdqBzmiAnxzEblcHpmXw38JsAwNxZqtRysLFt9/GUdDEAz34ZfO3qk8P49
naxASDEAJmYISdpUtk9Xw6CO5vQMuGFKTvaW+m9R5b2ig+USihuDg46JRMFyg7wG
4eIc9DIPN/mgJy2dP0CRkoNkU9+9KW3DvuI88cOaAEJhvLG/iqeymDHsrsecns14
RdfdJdeIHwPMSoOW5n/MUEjx3GdIHMICu/CHt88PcfuQGiAK7t0=
=bA8m
-----END PGP SIGNATURE-----
Merge tag 'v6.17-rockchip-dts64-2' of 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>
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.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmh1uXIVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FZvEQAIoDwwkAySjthXxfuh7ajhVKbT5j
GMAua5ZdK0jI/SoKKb+y4MSCaJncmB2tScuqxoElVS/4Hjsz/+RSFPIM/TlK9Vab
6FVI4zC5bdre8153H6JqiucSGyaup1gpwbNB6WGkgHxuX2NcRp9tFa/7bJR0HbO4
bfXBU10G1f3Cy4QtZG1+Q1wgfMgqDLcsCKVtj/7TifuFN9YW/858lyzZ4xC+oYnS
WkMz6r98VwA5xasC6vtC0S9KDfXfbpjD3PViaGdrBqHQ7Zn8xWwDKjB6ZuyHyV/l
NwzmQoNn+jLb5TCepBUvJyekdlICawLnGahJ1UNvA07ASz/Dsu0LpzTxA9bbr2b7
Towt1ffJ186J6vcrxO67xN3W/fYE9CUgd2U/ISIMLkmbZZ1l2m/PlTVawvkxwlJC
0DF3UeUhwQgE6aogjyeSUAuOBsPNBxEZhZaKDdjigC8yhyt8Gifiq2W2ar667zbp
E/IoyJ5dzfO/0DTRsdfWx2hAUMB8to4b5PPbccccuAbNI9Bx4FBa7cXc4atRHRdB
Uy1v/hVqStRGGwGu0O5Q07Pq+4DVNx0Nrrujlh53jqAh+gdALJgDgVb8Fd7+KjcF
KhA6rDWO941pDVeyDIIjs+Y95g8xDVKKGuObPkLifcfpKSDkwHVYSM+ksnYwRRKc
badJm1kmFIqjFZOV
=jo4F
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh/+PMACgkQmmx57+YA
GNnYlhAAqiwfs+qnSYtn9Mwk9qviDns8ptfXlYulwCxTMLGL/hGwXJbURI/wVFsj
hlqQDDC3iTCkgQBDXN340EIktRsCJ9ElqOiAGEF0Q6PhQ/idK4r2qIM6yNDCzf/F
5XJFcKpyrJXB3W5MB0Xcbw80RNsh6+fCCDdhwZxNzMaIVG3KfmYHylH7xmk5sg+w
nkm6g03ovmrYDg++IbKXxPp80neqJu0KmMBXIZlrKTkTNI/kmqmrVsvmeo0gi3nz
n9wL7WEXjJMSu4TXYgNx2hp0RWGKDcl91ab7QKG+n0+tqcPbkfjdSAfq71mUAbAq
uHO2WaMfnl2Sxp3xDv83/Dk5qNoL2CDj33sdxWhEmJVg157OKN5qaFzwmALdGEjI
h3DndeGSQLk7MVNjfQA8W/ZcJgk51Ef6sKqYbRZjiiHKW2tKE1XK/VLceldGMYyI
F1ngCJTVL/rg6py+ia6l3RqqfDijJ1jUH1Q4Rf6DoH5RqfHcjcEaEUXP6+wvd2NW
uUKd/OXYItc4T3DJ33d6T94TjRBtl6GyE794u4rRo1frskOScMF85HUOUbGdGobc
7uE6Xs4AQ20EcolJcuAPi2HBn66q9OFqQPHQgK5jkvw/pb1hKdbIVMiOoMNpdtHz
oBxBG6ElPsVDrNB1nqQ+POuIqDmtKJ9NJOngGUsy1NRQfCxnT6Q=
=ZBKF
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-6.17' of 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>
32bit version has been added by commit 4a6b93f562 ("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>
- A couple of MAINTAINERS updates
- A new bus driver for i.MX AIPSTZ bridge and a follow-up fix from
Laurentiu Mihalcea
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmhzO50ACgkQUFdYWoew
fM4kRwf/dvp+FsIahhfr1tACaoGvpLsLQwQ/l6ufjAJJk+vyVfFNh1/ttxInQqdL
OHot1qbdf8Zo8wfoYNTpSWqo50TfK4wQfvr6JBvUsfdpkkLWeyQOtu/0vKVvve8o
8AQhJc3tS73iLFScp+moUD4fyXiL9GnyRSmHyXxP4DdfM3wQRfZc9pNmXXAX00LV
R8xkAv+CeshVqgEPLliSB9269Yq9vCCBcapuVtW5ewW0anSb8ifzuiKNbOo6rY9j
LGxXCxx2OUiaxNiP0xa6RxITyPvAExl4+M5/up4+wjyIK5n9QHZNPjlI+etongAy
bbrgLKVSZYM1B4k9ANORElxxa+cdYA==
=6puG
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh/+G0ACgkQmmx57+YA
GNn+yg//TZpDqdLvMdT7NsYa6z0qHgm9LiiAR57cSXZGwi0YlCc3prEQNfKclwfN
zjmPv6OR5wlNfiD9zUVlu39deWvpGraYfgcX/P8j4w4J7msMRnr0AxZbWPGaIiJT
3SNXOfeVe8267g/nC30QYDQYEKUkY5c0nvIesiojnF4mMTsuIromioECLJkpED4M
ISFCbK6zHkvjzOKpLJpdmo+XwaIZaLeO5PMKcTrGNw/dHYfNNakpfKh0BwQKqoKL
ux2r4XZL0WrqmUAMRTuEWYo1tPQrBT9A2C6cy8ZVn/8fc2JJkxy3UYC1i2bIqft+
cAC2/EczqwAwXHcMD0lBnhG/pg3nrd9/2OPqnMTBBdeUqHiz4dNiIJwVrvUVNW75
ZFuUEdwGNASRur+nf5t/YxTQcWHx+fXY+G5PW89TSCE5O+MdoKhRjQHO6leUJhLh
pUZWqA8881IeCYYBLWi4J3wMXqCeHp2f7rGUFTNPTuI+N0/sp1S73hPqJ47rK5VM
NU2viC3L/1gHXcaQzIepIPdlHf1b+Etbff0b5N1LKRsV6+JKHlGes2tSreBDQb0V
pdG18TYGLz0VPYObJJQryPJHRvMX8oX46bR032nfBXUzUrROktkrD0PP/4rxVMJ+
f1p8FUd50rYCJPNYM8KB0tpvYwYRnC3tsmgF3kiiC/zwisjCyxk=
=/Bru
-----END PGP SIGNATURE-----
Merge tag 'imx-drivers-6.17' of 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>
Enable support for the memory and external memory controllers found on
Tegra264.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmhxiZwACgkQ3SOs138+
s6GwjA//WLLmpGF1BVk2o4tiREwMttyQ8FW5aJF0XUl2CP6H1D+aekbrSZaQ0TIU
vDxmtXZwaud8TWQ1OAsc2jVCzwEsowChQ8EO6+AcKejUlJNeFmJ+qm1OqP9OxzJY
9InZeTzYexsqxR4y9XPGAd6MWwCBlIrCzjfOZSRwEULCFlvzdZ1qFUbXBKboMMT7
Az2BFWiH8ecjlVAx0Ejy4rhrVTcGNznPDkPutUgQmWbamdET51h2/4tvUlNpM6jU
Zpmj7rfma8u318RRz0gcGXMHNg8w8JGUM8TPl9hYrl9Y1hd56EKENxUf+uOw5i8M
6iE7gYuglhfXQ9FVjMkoE5ISecLQpGnT5nNC6mmSoG4KTFGhwoo2AMBGf4MLlm1O
uE3F9+HTZzn0eZA6ney1EKcqpaf+MqdRVAduxYNXZpZN+Fe2QbwQ8ztRyAt3kOKL
XRmuofsS7fe9TLWB6uRCabA84UbGvQlnn9CwBaCqtaGcYHWojO942PPO6Rg0nRaM
V2WjmcIexXiiIp80xPQTp/+onj+STE+K/R0QzDjvImZQyXvUxBX8SY6TTAvO3gZm
EoVbdDQc+9KhmQnUmlSg4WVdD21NmlfM6goloHA3EJVOyjyrehIzjLVrVppu3dy4
LEA6xl1Jy5xkufFdeF8jLugtkoPLYY0PM5cXJLgooakayujEru4=
=4VeH
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh/+DQACgkQmmx57+YA
GNmgmg/+MEcHxmHS+Eh394bl8dqHlqSBKIG5rijCZduUKYJUcws68B0+IeW2Gswd
s3Wk9y8O3lb8yACxDXdW9+Lt4AZEvUtM9ZFU2Wb09H0P83aqdNBWHWkwBrMuMlMH
Bg7OGA5SLjJ3ke1RJQ00ba6dMKhfhxAUkRFeySzqMq843hRGObIZFAp6BpADJf31
7UjSz+yePlA5ZdzCeUssDyZvRRVQdUj1Hg2+nJE8g5MGZK04yoFz4hWPxXLb2PEw
vcbQ4n7WZb3/MD2qdASAXk81vKYala8MHCdvBFALva5a1JjlY2h0JK/2jrcylx2W
RgbBXThAiOSJ46KipO1qn1jSoyS8SQre8OKCiLRSdg73xoE5on8wRnLul4SbIGyo
fzgC993YS2wCe3UUuhoa+Nm5dI630t0xdSFDeUEfAurDiNcLjsvOv0atHW572/fi
ZPifQW0Rd69zPG/dXJxBFuXJjrcXW2XXJiDuXq/YTxFmMiWqHXu0XvxwH346gY9V
P77MjSa2EJ1C8ZTTph5WOzkf2tO7gMKBL8shmHXz4DO/F81khKu6CIl275+JiEzn
nDz4e9bcFAbvsnb39ItdA1vTdpP0SiQ05VRVrRER1gBl+1EvJ/QMIuQi8Izky8DB
N3fiyuzxRhDaApXGRTWp/rrF6GEulzI7LEN9bCm6an/egYePQWQ=
=oTmk
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-6.17-memory' of 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>
Add Tegra264 support for the BPMP, fix some dependency issues and clean
up some code using new OF helpers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmhxiPMACgkQ3SOs138+
s6E/7BAAuYCphrnsKIwDydV4ipgZ+kZ0oHk7uJ2pFLg6BIjdqtKZhEyXk9Wbg3Ko
6HRofsiT8WPvtWxZ8adreB1nvgNt/Ak50jQgLjEVGTyqHpUoQgGUudz5umTK0pnT
SoHH0VgSk0xToShcdYaMIG2XM7O2e77ohMQnVC2jrY7nnDCO8i7NgPlKTqKHORth
KO5U9JlaVhvap+HAGqDQq7ZO6QNuM3XDjAmuvantTwd89tADvwWTEO86VPDrHgoh
e6MjUgWlvMgZLY9nXL3K2IhSTyVivxXzxxGyPHtsOZXEsI46KhMnSjMtX80q6NOp
gnPKumNyC/5+SCCiLesCDTMyAHBfmtT1I9OEPiq203x9xck9yLmjtpUEhHFl0++i
TJw7cm4YHf3AWnhVU49uMK285XMPL0HxvxaTFErbK0Mdg3SkGN0vJqyh7T1kQvU0
Rp7R1Le8jM7zczdY4wOqlJoMtZaGKSAoahKD2QhQNhZxNjmWimotApPI7oIXipez
WqumClMsl8dIxfKdoW+HhfBuoHHbpAXUcej0qjdgGNYrx8cVKJcQmj9xgiEZVJJW
Hg0CPfZMwKjRPFZOtreHsWpLpYoWMUFz7lxS7zbWO3nNhRNNDKmTpAy39WJOfA1e
uENI9uNyBD0FNnZ44urTqO3XlpWmo3axQlOZu4wTF1E/BqhacWw=
=UtKj
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh/+AsACgkQmmx57+YA
GNlJgRAAmZooeXTkOcoyDaErbteExqLsEcvKbv6LgH5V/dd4uqGF5TX4tFumW6cC
+Gznd1gW60qdTwAWKHCuXiiLflYcyJPA8/KasW4jFZJZ+M/ZN+bIFlM6DlWV8eeo
+KXN24w3CQjU4JRcL18aw6k4MtDShLgRhldCb7nAwM91vZw6z4P9URyWtyqNEn48
Hey1sLMx8Mk3weErFhiIFMxIBi0zJI81MUE1Eake5U9FL95Vu/+m4i+crUXWzsVA
+fTPQ6H5AuSwQ2g7LA+7HIufBe6fGxIPU59acGV1Sc2ReuW2KpRMs7kAOdkIwJ1r
TZW4vu/tjO6DKVRlmV6GOfSQvrVxkGBe0j+wHUnmYuH+SReVKw8BtUsJJYpH12gx
ysyPU5sVPASOKIBbeMg3OHtfpMh7BFRjtHlXpqP1D9yzgEuTcGx80VNLFOnVZCcZ
OML481qUCc2PJw5K9Otd782Kud17/IgHitKem6jIrlvBUNNfrVlLyaggZuoaxn1C
PUwsikL0YaKhlIuCa7Qm+FMktCPDhmYdYdFvb5hwRZUKU7aSAJmRASodmRWOT3Za
VVFDgqsVipijqUjQ5WowvpTOPm3ecAlAt8Rev6ctCn4hQw1GL7PAcwWDhup/sEvM
2YchQtVc0E7+HCKhv0MWMTFgdMh34Vx1GfDGCPAi+Hea5MFadxY=
=QiXC
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-6.17-firmware' of 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>
