The x509 public key code gained a dependency on the sha256 hash
implementation, causing a rare link time failure in randconfig
builds:

arm-linux-gnueabi-ld: crypto/asymmetric_keys/x509_public_key.o: in function `x509_get_sig_params':
x509_public_key.c:(.text.x509_get_sig_params+0x12): undefined reference to `sha256'
arm-linux-gnueabi-ld: (sha256): Unknown destination type (ARM/Thumb) in crypto/asymmetric_keys/x509_public_key.o
x509_public_key.c:(.text.x509_get_sig_params+0x12): dangerous relocation: unsupported relocation

Select the necessary library code from Kconfig.

Fixes: 2c62068ac86b ("x509: Separately calculate sha256 for blacklist")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Align to the commit bf4afc53b77a ("Convert 'alloc_obj' family to use the
new default GFP_KERNEL argument") update the 'kmalloc_obj' declaration
for userspace to fix below compile error:

In file included from arch/arm/boot/compressed/../../../../lib/decompress_unxz.c:241,
from arch/arm/boot/compressed/decompress.c:56:
arch/arm/boot/compressed/../../../../lib/xz/xz_dec_stream.c: In function 'xz_dec_init':
arch/arm/boot/compressed/../../../../lib/xz/xz_dec_stream.c:787:28: error: implicit declaration of function 'kmalloc_obj'; did you mean 'kmalloc'? [-Wimplicit-function-declaration]
787 | struct xz_dec *s = kmalloc_obj(*s);
| ^~~~~~~~~~~
| kmalloc

Signed-off-by: Haiyue Wang <haiyuewa@163.com>
Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
Fixes: bf4afc53b77a ("Convert 'alloc_obj' family to use the new default GFP_KERNEL argument")
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull RTC updates from Alexandre Belloni:

- loongson: Loongson-2K0300 support

- s35390a: nvmem support

- zynqmp: rework calibration

* tag 'rtc-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
rtc: ds1390: fix number of bytes read from RTC
rtc: class: Remove duplicate check for alarm
rtc: optee: simplify OP-TEE context match
rtc: interface: Alarm race handling should not discard preceding error
rtc: s35390a: implement nvmem support
rtc: loongson: Add Loongson-2K0300 support
dt-bindings: rtc: loongson: Document Loongson-2K0300 compatible
dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
dt-bindings: rtc: cpcap: convert to schema
rtc: zynqmp: use dynamic max and min offset ranges
rtc: zynqmp: rework set_offset
rtc: zynqmp: rework read_offset
rtc: zynqmp: check calibration max value
rtc: zynqmp: correct frequency value
rtc: amlogic-a4: Remove IRQF_ONESHOT
rtc: pcf8563: use correct of_node for output clock
rtc: max31335: use correct CONFIG symbol in IS_REACHABLE()
rtc: nvvrs: Add ARCH_TEGRA to the NV VRS RTC driver

Pull rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:

- Pass '-Zunstable-options' flag required by the future Rust 1.95.0

- Fix 'objtool' warning for Rust 1.84.0

'kernel' crate:

- 'irq' module: add missing bound detected by the future Rust 1.95.0

- 'list' module: add missing 'unsafe' blocks and placeholder safety
comments to macros (an issue for future callers within the crate)

'pin-init' crate:

- Clean Clippy warning that changed behavior in the future Rust
1.95.0"

* tag 'rust-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: list: Add unsafe blocks for container_of and safety comments
rust: pin-init: replace clippy `expect` with `allow`
rust: irq: add `'static` bounds to irq callbacks
objtool/rust: add one more `noreturn` Rust function
rust: kbuild: pass `-Zunstable-options` for Rust 1.95.0

The spi_write_then_read() reads 8 bytes starting from
DS1390_REG_SECONDS (== 0x01), so the last byte read would already
be part of the alarm (Tenths and Hundredths of Seconds) feature.

However 7 bytes are engouh -- seconds (0x01), minutes (0x02), hours (0x03),
day (0x04), date (0x05), month/century (0x06) and year (0x07).

Signed-off-by: Andreas Gabriel-Platschek <andi.platschek@gmail.com>
Link: https://patch.msgid.link/20260209053439.313825-1-andi.platschek@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Pull runtime verifier fix from Steven Rostedt:

- Fix multiple definition of __pcpu_unique_da_mon_this

After refactoring monitors, we used static per-cpu variables with the
same names across different per-cpu monitors. This is explicitly
disallowed for modules on some architectures (alpha) or if
CONFIG_DEBUG_FORCE_WEAK_PER_CPU is enabled (e.g. Fedora's debug
kernel). Make sure all those variables have different names to avoid
compilation issues.

* tag 'trace-rv-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
rv: Fix multiple definition of __pcpu_unique_da_mon_this

impl_list_item_mod.rs calls container_of! without unsafe blocks at a
couple of places. Since container_of! is unsafe, the blocks are strictly
necessary.

The problem was so far not visible because the "unsafe-op-in-unsafe-fn"
check is a lint rather than a hard compiler error, and Rust suppresses
lints triggered inside of a macro from another crate.

Thus, the error becomes only visible once someone from within the kernel
crate tries to use linked lists:

error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub`
is unsafe and requires unsafe block
--> rust/kernel/lib.rs:252:29
|
252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
|
note: an unsafe function restricts its caller, but its body is safe by default
--> rust/kernel/list/impl_list_item_mod.rs:216:13
|
216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
= note: requested on the command line with `-D unsafe-op-in-unsafe-fn`
= note: this error originates in the macro `$crate::container_of` which comes
from the expansion of the macro `impl_list_item`

Therefore, add unsafe blocks to container_of! calls to fix the issue.

[ As discussed, let's fix the build for those that want to use the
macro within the `kernel` crate now and we can discuss the proper
safety comments afterwards. Thus I removed the ones from the patch.

However, we cannot just avoid the comments with `CLIPPY=1`, so I
provided placeholders for now, like we did in the past. They were
also needed for an `unsafe impl`.

While I am not happy about it, it isn't worse than the current
status (the comments were meant to be there), and at least this
shows what is missing -- our pre-existing "good first issue" [1]
may motivate new contributors to complete them properly.

Finally, I moved one of the existing safety comments one line down
so that Clippy could locate it.

Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]

- Miguel ]

Cc: stable@vger.kernel.org
Fixes: c77f85b347dd ("rust: list: remove OFFSET constants")
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260216131613.45344-3-phasta@kernel.org
[ Fixed formatting. Reworded to fix the lint suppression
explanation. Indent build error. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

In __devm_rtc_register_device(), the callee rtc_initialize_alarm()
will check the alarm, there is no need to check in advance,
so remove it.

Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20260122090031.3871746-1-ruanjinjie@huawei.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Conversion performed via this Coccinelle script:

// SPDX-License-Identifier: GPL-2.0-only
// Options: --include-headers-for-types --all-includes --include-headers --keep-comments
virtual patch

@gfp depends on patch && !(file in "tools") && !(file in "samples")@
identifier ALLOC = {kmalloc_obj,kmalloc_objs,kmalloc_flex,
kzalloc_obj,kzalloc_objs,kzalloc_flex,
kvmalloc_obj,kvmalloc_objs,kvmalloc_flex,
kvzalloc_obj,kvzalloc_objs,kvzalloc_flex};
@@

ALLOC(...
- , GFP_KERNEL
)

$ make coccicheck MODE=patch COCCI=gfp.cocci

Build and boot tested x86_64 with Fedora 42's GCC and Clang:

Linux version 6.19.0+ (user@host) (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version 2.44-12.fc42) #1 SMP PREEMPT_DYNAMIC 1970-01-01
Linux version 6.19.0+ (user@host) (clang version 20.1.8 (Fedora 20.1.8-4.fc42), LLD 20.1.8) #1 SMP PREEMPT_DYNAMIC 1970-01-01

Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The refactoring in commit 30984ccf31b7 ("rv: Refactor da_monitor to
minimise macros") replaced per-monitor unique variable names
(da_mon_##name) with a fixed name (da_mon_this).

While this works for 'static' variables (each translation unit gets its
own copy), DEFINE_PER_CPU internally generates a non-static dummy
variable __pcpu_unique_<n> for each per-cpu definition. The requirement
for this variable to be unique although static exists for modules on
specific architectures (alpha) and if the kernel is built with
CONFIG_DEBUG_FORCE_WEAK_PER_CPU (e.g. Fedora's debug kernel).

When multiple per-cpu monitors (e.g. sco and sts) are built-in
simultaneously, they all produce the same __pcpu_unique_da_mon_this
symbol, causing a link error:

ld: kernel/trace/rv/monitors/sts/sts.o: multiple definition of
`__pcpu_unique_da_mon_this';
kernel/trace/rv/monitors/sco/sco.o: first defined here

Fix this by introducing a DA_MON_NAME macro that expands to a
per-monitor unique name (da_mon_<MONITOR_NAME>) via the existing
CONCATENATE helper. This restores the uniqueness that was present
before the refactoring.

Fixes: 30984ccf31b7 ("rv: Refactor da_monitor to minimise macros")
Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Link: https://lore.kernel.org/r/20260216172707.1441516-1-mikhail.v.gavrilov@gmail.com
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>

`clippy` has changed behavior in [1] (Rust 1.95) where it no longer
warns about the `let_and_return` lint when a comment is placed between
the let binding and the return expression. Nightly thus fails to build,
because the expectation is no longer fulfilled.

Thus replace the expectation with an `allow`.

[ The errors were:

error: this lint expectation is unfulfilled
--> rust/pin-init/src/lib.rs:1279:10
|
1279 | #[expect(clippy::let_and_return)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: `-D unfulfilled-lint-expectations` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unfulfilled_lint_expectations)]`

error: this lint expectation is unfulfilled
--> rust/pin-init/src/lib.rs:1295:10
|
1295 | #[expect(clippy::let_and_return)]
| ^^^^^^^^^^^^^^^^^^^^^^

- Miguel ]

Link: https://github.com/rust-lang/rust-clippy/pull/16461 [1]
Signed-off-by: Benno Lossin <lossin@kernel.org>
Cc: stable@vger.kernel.org # Needed in 6.18.y and later.
Link: https://patch.msgid.link/20260215132232.1549861-1-lossin@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Simplify the TEE implementor ID match by returning the boolean
expression directly instead of going through an if/else.

Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
Link: https://patch.msgid.link/20260126-optee-simplify-context-match-v1-3-d4104e526cb6@linaro.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

This converts some of the visually simpler cases that have been split
over multiple lines. I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.

Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script. I probably had made it a bit _too_ trivial.

So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.

The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Update documentation reference to reflect the file rename.
Monitor synthesis documentation was renamed in commit f40a7c060207
("Documentation/rv: Prepare monitor synthesis document for LTL inclusion")
from da_monitor_synthesis.rst to monitor_synthesis.rst.

Signed-off-by: Shubham Sharma <slopixelz@gmail.com>
Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
Link: https://lore.kernel.org/r/20251230075337.11993-1-slopixelz@gmail.com
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>

These callback functions take a generic `T` that is used in the body as
the generic argument in `Registration` and `ThreadedRegistration`. Those
types require `T: 'static`, but due to a compiler bug this requirement
isn't propagated to the function. Thus add the bound. This was caught in
the upstream Rust CI [1].

[ The three errors looked similar and will start appearing with Rust
1.95.0 (expected 2026-04-16). The first one was:

error[E0310]: the parameter type `T` may not live long enough
Error: --> rust/kernel/irq/request.rs:266:43
|
266 | let registration = unsafe { &*(ptr as *const Registration<T>) };
| ^^^^^^^^^^^^^^^^^^^^^^
| |
| the parameter type `T` must be valid for the static lifetime...
| ...so that the type `T` will meet its required lifetime bounds
|
help: consider adding an explicit lifetime bound
|
264 | unsafe extern "C" fn handle_irq_callback<T: Handler + 'static>(_irq: i32, ptr: *mut c_void) -> c_uint {
| +++++++++

- Miguel ]

Link: https://github.com/rust-lang/rust/pull/149389 [1]
Signed-off-by: Benno Lossin <lossin@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 29e16fcd67ee ("rust: irq: add &Device<Bound> argument to irq callbacks")
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/20260217222425.8755-1-cole@unwrap.rs/
Link: https://patch.msgid.link/20260214092740.3201946-1-lossin@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting
alarm") should not discard any errors from the preceding validations.

Prior to that commit, if the alarm feature was disabled, or the
set_alarm failed, a meaningful error code would be returned to the
caller for further action.

After, more often than not, the __rtc_read_time will cause a success
return code instead, misleading the caller.

An example of this is when timer_enqueue is called for a rtc-abx080x
device. Since that driver does not clear the alarm feature bit, but
instead relies on the set_alarm operation to return invalid, the discard
of the return code causes very different behaviour; i.e.
hwclock: select() to /dev/rtc0 to wait for clock tick timed out

Fixes: 795cda8338ea ("rtc: interface: Fix long-standing race when setting alarm")
Signed-off-by: Anthony Pighin (Nokia) <anthony.pighin@nokia.com>
Reviewed-by: Esben Haabendal <esben@geanix.com>
Tested-by: Nick Bowler <nbowler@draconx.ca>
Link: https://patch.msgid.link/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>