During a kexec restart, only the kernel is reloaded while devices
allocated in firmware persist, causing state mismatches between the
kernel and firmware.
Introduce PM_DEV_ALL_PERIPH node ID (0x18224FFFU) to release all
peripheral devices during kexec. On graceful restarts, this happens in
zynqmp_firmware_shutdown(). On crash kernel restarts, it happens in
zynqmp_firmware_probe() of the reloaded kernel.
Releasing all peripherals depends on firmware support for the
PM_DEV_ALL_PERIPH node ID. On firmware that does not implement it (the
feature check reports a version below PM_API_VERSION_3) the release is
skipped and a warning such as "Bulk device release is not supported by
firmware" is logged, e.g. on Versal NET firmware that predates this API.
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
Link: https://patch.msgid.link/20260729122522.3732875-3-jay.buddhabhatti@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Currently, during a kexec restart, only the kernel is reloaded, while
EL3-specific data remain unchanged. This leads to a mismatch between the
kernel state and secure firmware state like SGI number and shutdown scope
variable.
For example, the kernel registers an SGI number with EL3 firmware so that
secure firmware can notify the kernel of events via that SGI. EL3 stores
this SGI number in its internal state. After a kexec, the newly loaded
kernel re-registers and may request a different SGI number, but the stale
value programmed in EL3 remains, so event notifications are delivered on
the old SGI and are missed by the new kernel. The shutdown scope variable
has a similar stale state problem.
To resolve this, the TF_A_CLEAR_PM_STATE PM API is introduced to clear
EL3 PM subsystem state during kexec. On a graceful reboot, this API is
triggered by zynqmp_firmware_shutdown(), while in a crash kernel scenario,
it is invoked by zynqmp_firmware_probe() in the reloaded kernel.
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
Link: https://patch.msgid.link/20260729122522.3732875-2-jay.buddhabhatti@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
When do_fw_call() fails in __do_feature_check_call(), propagate the
actual errno from zynqmp_pm_ret_code() instead of always returning
-EOPNOTSUPP. This gives callers more precise error information. Existing
callers only test ret < 0 and are unchanged by this.
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
Link: https://patch.msgid.link/20260724095352.2890326-3-jay.buddhabhatti@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Currently, TF-A-specific APIs are validated using the firmware
PM_FEATURE_CHECK API, even though TF-A provides a dedicated mechanism
via PM_API_FEATURES API. Update the feature check logic for TF-A-specific
API calls to use PM_API_FEATURES. If this check fails, fall back to the
legacy PM_FEATURE_CHECK to support backward compatibility.
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
Link: https://patch.msgid.link/20260724095352.2890326-2-jay.buddhabhatti@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Just a single commit that fixes the i2c IRQ and MMIO ranges for the M3
SoC.
Signed-off-by: Sven Peter <sven@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS3vz815OHsEaWy0u9EEX0kKnUe6QUCanYCGgAKCRBEEX0kKnUe
6XCtAQCUJFZiqsus7g3hq7PpUyAmiEWfdOWrC5qnEqbhFiWdGAD+LWxX7b5bIq0M
es49MlApDpwzaFijCsz4KnNBsqjC1gk=
=CAwK
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmp5fEoACgkQmmx57+YA
GNlk4w/9HEYyM5nLoc5bMWNAdZDzfz8gTnxkSd7ZYhd4SWAdb1p0UlPk1rAyTS00
+piMiSOSZExH+8gq0+Gbr14Yj7GuXJ32etR+Kmreg+cRYf9TC1tu2DMFxt2IsADn
rObDHpkzNI3+9eMGQ50hLSo8vGDKmIeczSRy1MhCujYyjH1PLMMqXwZ8+20vWC/q
xL42k+MHHsYIBO6TuCx79uDfBBOG7yjjq55WXOGq+qTK28PP0fHXdOfo2Ds5Tp7o
NxhM5BTuwVutjGKcDj/nfRdU+kUDJVZZAXk7BoPZ14wk+7lAnqQpqM9d86dUKvHJ
meVm+ugtdMyPPeYCvMhDrC1dkXTgyRrkM1GMtXfR/ujR5yAgYQjJmHA2YRhwoLvg
dX142P8rdSEzexBxxSlxSRI2CtIqQp3oY9ew6XWu7PluNcVJi9jQpuxjoER7hTRZ
9MjusRYVoirm8h/jub9pZ4YlgCY37PjSslU6aQ5hkZgx9G1UND1hh4bDn/rnUT8m
fh96aoE7snbN259+ecYtylgOWSRKOeVn6FoeETCu74cDKNHH9C/WyjOU4c0earQn
CoOT1srhL506u3l4a1+b3CcCWB0XXuPxfQEaRnnj9kyrowNKXWKSEC5u1tEeupgN
0LJfNHbiBiyqveV3yPAysoaDm5uqV8EDL2Ymnfp9WGC2qYMAoXU=
=qGIT
-----END PGP SIGNATURE-----
Merge tag 'apple-soc-fixes-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into arm/fixes
Apple SoC fixes for 7.2
Just a single commit that fixes the i2c IRQ and MMIO ranges for the M3
SoC.
Signed-off-by: Sven Peter <sven@kernel.org>
* tag 'apple-soc-fixes-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux:
arm64: dts: apple: t8122: Fix I2C resources
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen,
valuelen) before checking if the entry pointer itself is within bounds.
If nameidx is crafted to point near the end of the buffer, these field
accesses can read out-of-bounds before the bounds check at
name_end > buf_end is performed.
Add explicit bounds checks for entry pointers before accessing their
fields. Use offsetof() to check that the start of the flexible array
member (nameval/name) is within bounds, which ensures all preceding
fields are safe to access.
Fixes: c84760659d ("xfs: check attribute leaf block structure")
Cc: <stable@vger.kernel.org> # v5.5
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Change the split_sectors check from !split_sectors to split_sectors <= 0
to make the error handling explicit. While bio_split_rw_at() cannot return
a negative error code for the current GC I/O path (GC I/O doesn't use
REQ_ATOMIC/REQ_NOWAIT flags and has proper alignment), making the check
explicit improves code clarity and makes the intent clear.
This also makes the code more robust for future maintenance if different
I/O patterns are introduced.
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_file_fsync() has a fallback flush for the case where the log force
was a no-op, for example fdatasync/O_DSYNC writes that do not require
metadata updates. The current fallback path is expressed in terms of the
main data device and explicitly excludes realtime inodes.
Realtime files with a separate realtime device are flushed before the log
force, because their data must reach stable storage before the log commit.
For the internal realtime device used by the zoned allocator, writes are
out-of-place and update inode and bmap metadata from I/O completion, so
the overwrite-without-metadata-update case does not apply in the same way.
Even so, the current fallback condition is inconsistent because it is
expressed as "non-realtime inode on the main data device" rather than in
terms of the inode's actual file data target.
Use xfs_inode_buftarg() to obtain the target that stores this file's
data, and issue the fallback flush when the log force did not flush
anything and the log target is the same as that file target.
This preserves existing behavior for regular files while making the
fallback logic consistent for files whose data target is selected by the
inode.
Fixes: bdc03eb5f9 ("xfs: allow internal RT devices for zoned mode")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
When __xfs_trans_commit() fails in xfs_trans_roll(), the NOFS context
is cleared but only restored in the success path. This leaves the
error path without nofs protection, causing a circular lock dependency
between xfs_nondir_ilock_class and fs_reclaim:
CPU0 CPU1
---- ----
lock(&xfs_nondir_ilock_class);
lock(fs_reclaim);
lock(&xfs_nondir_ilock_class);
lock(fs_reclaim);
Fix this by moving xfs_trans_set_context() before the error check so
that nofs context is always restored on the new transaction.
Reported-by: syzbot+59178abfeb0ea3f0ab20@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=59178abfeb0ea3f0ab20
Fixes: a1ca658d64 ("xfs: fix incorrect context handling in xfs_trans_roll")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Readahead currently always locks the buffer, which can cause contention
with actual users of the buffer. Add a fast path without taking any
locks if the buffer is uptodate and not stale.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
To prepare for buffer loookups that don't lock the buffer, move the
call to xfs_buf_find_lock from xfs_find_get_buf to its callers.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_buf_read_map is the only caller of xfs_buf_reverify that is left.
Merge it into that so that the comments can be moved closer to the
logic, and redundant asserts can be removed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
This keeps the I/O error handling contained at the end of the function
and removes the indentation for it. It also allows to reorder the
comments so that they are closer to the logic that they describe.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_buf_read_map calls xfs_buf_reverify to ensure the verifier has run
for a buffer before the data can be used when an earlier readahead read
the data before the buf_ops were assigned.
There is no point in doing this in xfs_buf_readahead_map for a buffer
already in memory as a later xfs_buf_read will do the same and can
actually propagate the error to the caller.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Prepare for limited lockless reading of flags by using WRITE_ONCE to
prevent the compiler from doing non-standard read-modify-write
operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Add helpers for the remaining buffer flags manipulation not done in the
core buffer cache code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Adding _XBF_LOGRECOVERY to every buffer write from log recovery is error
prone. Instead key off the behavior on log recovery being active with
indirecting that through a flag.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Both callers of ->verify_read already do this, so don't duplicate the
flag manipulation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_buf_get_map is currently reused to implement xfs_buf_read_map and
xfs_buf_readahead_map. This causes double accounting of buf_get stat
and leads to some ugly overload of the flags.
Split out a slightly lower-level xfs_find_get_buf helper and use that to
implement xfs_buf_get_map, xfs_buf_read_map and xfs_buf_readahead_map.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Consolidate the code to lock the buffer based on the passed in flags
into xfs_buf_get_map instead of having two different sites for buffer
lookup vs insertation. This requires initializing b_lock to unlocked on
allocation and doing an atomic for locking it for newly allocated buffers,
but greatly simplifies the logic.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
As of commit 497560b9ef ("xfs: switch (back) to a per-buftarg buffer
hash"), buffer lookups don't require the perag structure. Stop looking
it up in xfs_buf_get_map, and instead only find it when allocating a new
buffer.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
rcu_barrier() is a frequently used C function which is always safe to be
called.
Add a safe abstraction for rcu_barrier().
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Acked-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260805145949.938505-5-phasta@kernel.org
[ Formatted documentation. Sorted tags. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Implement ForeignOwnable for ARef<T>, making it possible for C code to
own an ARef<T>.
Since ARef represents shared ownership, BorrowedMut is &T rather than
&mut T, matching the semantics of the underlying reference-counted type.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260805145949.938505-4-phasta@kernel.org
[ Relaxed `'static` bound and added `#[inline]` as discussed. Added
the submitter's Signed-off-by tag. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add all of the remaining error codes from include/uapi/asm-generic/errno.h.
Previous updates to error.rs have been piecemeal -- adding single error
codes as needed. Instead, we can avoid future problems by adding all
the remaining error code in one swoop.
EDEADLOCK and EWOULDBLOCK are intentionally left out: they are just
deprecated compatibility aliases of EDEADLK and EAGAIN, kept around for
non-Linux/POSIX code, and have no use in new kernel code.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260805145949.938505-3-phasta@kernel.org
[ Formatted comments. Added the submitter's Signed-off-by tag. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Callers that go through `kernel::prelude` have `CStrExt` in scope, but
code inside the `kernel` crate imports explicitly and may not. Using
`warn_on!` from such a module fails to build on UML, which is the only
configuration where `warn_flags!` needs a C string pointer rather than an
inline asm bug entry:
error[E0599]: no method named `as_char_ptr` found for reference `&ffi::CStr` in the current scope
--> linux/rust/kernel/bug.rs:83:49
|
83 | $crate::c_str!(::core::file!()).as_char_ptr(),
| ^^^^^^^^^^^
|
::: linux/rust/kernel/time.rs:427:9
|
427 | warn_on!(self.nanos < 0);
| ------------------------ in this macro invocation
|
= help: items from traits can only be used if the trait is in scope
= note: this error originates in the macro `$crate::warn_flags` which comes from the expansion of the macro `warn_on` (in Nightly builds, run with -Z mac)
help: trait `CStrExt` which provides `as_char_ptr` is implemented but not in scope; perhaps you want to import it
--> linux/rust/kernel/time.rs:27:1
|
27 + use crate::str::CStrExt;
Call the method through its fully qualified path, which resolves
without any import at the expansion site.
Cc: stable@vger.kernel.org
Fixes: dff64b0727 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20260807112427.1039056-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Running `make rusttest` with `ARCH=` set to an architecture other than
the host's fails, e.g. `ARCH=arm64` on an x86_64 host:
error: invalid instruction mnemonic 'brk'
--> rust/kernel/bug.rs:63:17
|
63 | / concat!(
64 | | "/* {size} */",
65 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_warn_asm.rs")),
66 | | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_reachable_asm.rs")));
| |_______________________________________________________________________________________________________^
|
note: instantiated into assembly here
--> <inline asm>:1:115
|
1 | /* 8 */.pushsection __bug_table,"aw"; .align 2; 14470: .long 14471f - .;.short 2305;.align 2; .popsection; 14471:brk 0x800
| ^^^
The reason is that `rusttest` builds the `kernel` crate as a host
library: it passes the `CONFIG_*` cfgs of the configured architecture,
but not `--target`, so code generation happens for the
host. `warn_flags!` then selects the arch-specific inline asm arm
based on `CONFIG_*`, and the host assembler rejects it.
This does not happen with the current `master` because `warn_on!` has
no user inside the `kernel` crate itself yet, but it will as soon as
one is added.
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/all/CANiq72n4=fz=JNKY0Jdm8BnLa=RmHB2B7s0bO47YTJ7hygqBZg@mail.gmail.com/
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: stable@vger.kernel.org
Fixes: dff64b0727 ("rust: Add warn_on macro")
Link: https://patch.msgid.link/20260808022608.1125174-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Fix the following dead_code warning on some configurations in an
atomic development branch:
warning: constant `WARN_ON_FLAGS` is never used
--> linux/rust/kernel/bug.rs:126:19
|
126 | const WARN_ON_FLAGS: u32 = $crate:🐛:bugflag_taint($crate::bindings::TAINT_WARN);
| ^^^^^^^^^^^^^
|
::: linux/rust/kernel/sync/srcu.rs:106:12
|
106 | if crate::warn_on!(
| ____________-
107 | | // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
108 | | // and `srcu_readers_active()` only checks the active reader count.
109 | | unsafe { bindings::srcu_readers_active(ptr) }
110 | | ) {
| |_________- in this macro invocation
|
= note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
= note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info)
The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it
to warn_flags!. On configurations where warn_flags! does not reference
its flags argument (the LOONGARCH/ARM variant, which only calls
WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left
unused and triggers a dead_code warning.
warn_flags! is the macro that accepts (and here discards) the flags
argument, so make it responsible for the argument it drops.
Also rename `_COND_STR` to `COND_STR` and consume `$file` for consistency.
Fixes: dff64b0727 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260801024841.786664-1-tomo@flapping.org
[ Added newlines. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
When using the Rust GCC backend (i.e. `rustc_codegen_gcc`), GCC does not
inline enough these `Bounded::from_expr` calls:
/usr/bin/x86_64-linux-gnu-ld.bfd: rust/kernel.o: in function `<kernel::num::bounded::Bounded<u16, 2> as core::convert::From<kernel::bitfield::tests::Priority>>::from':
fake.c:(.text.unlikely+0x7be): undefined reference to `rust_build_error'
/usr/bin/x86_64-linux-gnu-ld.bfd: rust/kernel.o: in function `<kernel::num::bounded::Bounded<u64, 4> as core::convert::From<kernel::bitfield::tests::MemoryType>>::from':
fake.c:(.text.unlikely+0x90d): undefined reference to `rust_build_error'
Thus, similar to commit bc197e24a3 ("rust: num: bounded: Always inline
fits_within and from_expr"), mark them as `#[inline(always)]`.
[ Reworded to add the error and to follow our usual style and sent on
behalf of Antoni, who found this during his work to support Rust for
Linux with the GCC backend, i.e. with `rustc_codegen_gcc`. - Miguel ]
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Antoni Boucher <bouanto@zoho.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260807175012.142083-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The `Arc` documentation has a few mentions that do not follow the
surrounding style: a plain `Arc` without an intra-doc link and a
lower-case "arc".
Use intra-doc links for rustdoc references to `Arc` and spell internal
comments consistently as `Arc`, matching nearby docs.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1240
Signed-off-by: Harish C S <harish.cs.ss24@gmail.com>
Acked-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260711145033.39649-1-harish.cs.ss24@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
- Merge the `__pinned_init` and `__init` methods and make `Init` become a marker trait.
- Introduce public APIs `raw_init` and `raw_try_init` to prevent user from needing to invoke the internal `__pinned_init`/`__init` methods.
- Emit errors for duplicate `#[pin]` attributes.
- Link `Zeroable::zeroed` and `pin_init::zeroed` in documentation.
Other changes:
- Fix unwind safety issues.
- Clean up lint `allow` and `expect`s.
- Overhaul `#[cfg]` handling to pave the way for tuple struct and self referential structs.
- Mark many functions are `#[inline]` for better codegen with `-C opt-level=s` (CC_OPTIMIZE_FOR_SIZE).
-----BEGIN PGP SIGNATURE-----
iIcEABYKAC8WIQRIiwFmsgGbHdMqd+kPoQF7f9ATtgUCanMafBEcZ2FyeUBnYXJ5
Z3VvLm5ldAAKCRAPoQF7f9ATtlEGAQCNKDAMTM+DWL02l2jQu22HJ5XohUgiN7m4
VfIYjcPVxQD6A8n1Jyw7DmIF+hTBR6aAK+vH0iIqKKvWdVgvsNswKw0=
=LSdN
-----END PGP SIGNATURE-----
Merge tag 'pin-init-v7.3' of https://github.com/Rust-for-Linux/linux into rust-next
Pull pin-init updates from Gary Guo:
"User-visible changes:
- Merge the '__pinned_init' and '__init' methods and make 'Init'
a marker trait.
- Introduce public APIs 'raw_init' and 'raw_try_init' to prevent users
from needing to invoke the internal '__pinned_init'/'__init' methods.
- Emit errors for duplicate '#[pin]' attributes.
- Link 'Zeroable::zeroed' and 'pin_init::zeroed' in documentation.
Other changes:
- Fix unwind safety issues.
- Clean up lint 'allow' and 'expect's.
- Overhaul '#[cfg]' handling to pave the way for tuple structs and
self-referential structs.
- Mark many functions as '#[inline]' for better codegen with '-C
opt-level=s' ('CC_OPTIMIZE_FOR_SIZE')."
* tag 'pin-init-v7.3' of https://github.com/Rust-for-Linux/linux:
rust: pin-init: add `#[inline]` to small functions
rust: pin-init: remove `__pinned_init` method for `cfg(kernel)`
rust: treewide: replace `__pinned_init` with `raw_[try_]init`
rust: pin-init: add `raw_init` and `raw_try_init` and recommend over `__init`
rust: pin-init: merge `__pinned_init` and `__init`
rust: pin-init: examples: use `Wrapper::pin_init` instead of manual reimplementation
rust: pin-init: mark `pin_init::zeroed` and `Zeroable::zeroed` as `#[inline]`
rust: pin-init: docs: link `Zeroable::zeroed` and `pin_init::zeroed` in documentation
rust: pin-init: internal: rework how `#[pin_data]` handles cfg
rust: pin-init: make `[pin_]chain` unwind safe
rust: pin-init: make `[pin_]init_array_from_fn` unwind safe
rust: pin-init: internal: generate brace in macro for init code blocks
rust: pin-init: internal: remove `allow` and `expect`s that don't fire
rust: pin-init: remove redundant clippy expects in doc tests
rust: pin-init: examples: fix incorrect drop
rust: pin-init: internal: error on duplicate `#[pin]` attribute
elan-i2c-ids.h only needs struct acpi_device_id from the ACPI
device ID definitions. The MODULE_DEVICE_TABLE() user already includes
<linux/module.h>.
Include <linux/device-id/acpi.h> instead of the broader
<linux/mod_devicetable.h> header.
Assisted-by: Codex:GPT-5
Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
Link: https://patch.msgid.link/20260809142928.4031270-1-xialonglong2025@163.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Key slots are released through a kref and the existing release path
frees the AEAD transforms from an RCU callback. That is not safe for all
crypto implementations: crypto_free_aead can sleep, for example when an
async or hardware implementation has teardown work to complete.
Use queue_rcu_work for key-slot release. This keeps the RCU grace period
needed by lockless key-slot readers, but runs the actual crypto teardown
from workqueue context where sleeping is allowed. Once the rcu_work
callback runs, pre-existing RCU readers are gone, and the final kref put
already proves that no transform user remains, so the worker can release
the AEAD transforms and free the slot directly.
The previous patch drains ovpn_wq during module exit, so queued key-slot
teardown work cannot outlive module text.
Fixes: 8534731dbf ("ovpn: implement packet processing")
Signed-off-by: Ralf Lici <ralf@mandelbit.com>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
ovpn queues several work items whose callbacks execute module text.
These works currently run on the global system workqueues, so module
exit has no driver-owned drain point that guarantees the callbacks have
fully returned before the module text can be freed.
Object references protect the objects used by the callbacks, but they do
not prove that a workqueue function has returned. In particular, a
worker can drop the final reference that unblocks device teardown while
it is still executing ovpn code.
Add a module-owned workqueue and queue all ovpn work items on it. During
module exit, unregister rtnl and netlink first, flush the workqueue so
ordinary ovpn workers finish, run the final RCU barrier, and destroy the
workqueue last. This keeps the workqueue available for cleanup work
queued from RCU callbacks, while ensuring no ovpn work item can outlive
the module text.
The per-device delayed keepalive work remains explicitly disabled during
netdev teardown (disable_delayed_work_sync in ndo_uninit), since
flush_workqueue does not flush delayed work that is still only pending
on its timer.
Fixes: 3ecfd9349f ("ovpn: implement keepalive mechanism")
Fixes: 11851cbd60 ("ovpn: implement TCP transport")
Signed-off-by: Ralf Lici <ralf@mandelbit.com>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
- Fix use-after-free in eventfs_remove_rec()
The freeing of the eventfs_inode children used list_for_each_entry() where
the child is freed via srcu, but there's still a chance that it gets freed.
It should be using list_for_each_entry_safe().
- Fix eventfs_inode SRCU use of list in freeing
The iterator uses an SRCU protected list walk on the eventfs inodes. The
eventfs inode uses its "list" field in a union with the RCU list head.
When the inode gets added to the SRCU list it immediately corrupts the
list pointer and can cause an issue with the iterator. Move the RCU list
head to be shared with the children list head which allows the iterator to
check the parent inode if is freed before referencing the child. Have the
iterator check the parent "is_freed" field and break out if it is set.
Also add memory barriers to make sure the ordering is correct.
- Fix various RCU synchronization issues with direct_functions
Updates to direct_functions have some missing RCU protection and
synchronization. Restructure the code a bit to make sure updates to the
direct_functions are protected.
- Remove an unneeded comma from a scope_guard()
There's a spurious comma in a scope_guard(). Remove it.
- Fix race in per CPU buffer swap in the ring buffer
When a per CPU buffer swap happens, it must make sure that it doesn't
occur while a writer is active. Instead it returns an -EBUSY. But there's
a small race window when a writer moves from one sub-buffer to the next
that it resets the "committing" counter. If a swap happens at that moment,
the buffer used for the commit of an event will not match the buffer the
event is actually on. Instead of using the "committing" counter, use the
recursive detection counter that does not get reset when the writer
crosses sub-buffers.
- Fix off-by-one in ftrace_free_mem()
The function ftrace_free_mem() gets an "end_ptr" as a parameter that is
exclusive to the rang to be freed. But its value is used to search for the
records that expects an inclusive value. Subtract one from the parameter
to convert it to an inclusive range.
- Disable resizing of the ring buffer for persistent buffers
Resizing the persistent buffer has undefined behavior. Prevent it from
being resized.
- Disable changing ring buffer subbuf order when resizing is disabled
The ring buffer subbuffer order can not be changed during resizing. Use
that instead of just checking if the buffer is mapped as mapped buffers
also have resizing disabled.
- Initialize subbuf_order of reader pages when they are created
In rb_allocate_cpu_buffer() the bpage->order is not updated to the current
subbuf_order leaving it as zero. This value is used when the page is freed.
- Fix test_ringbuffer() to test for ERR_PTR before calling kthread_stop()
The rb_threads[] array is assigned the output of kthread_run_on_cpu()
which could return an ERR_PTR. At the end of the test, all threads in the
array are cleaned up by kthread_stop() passing in the value in the array
if it isn't zero. But if the array contains an ERR_PTR, kthread_stop()
will not be able to handle it properly.
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCanicmBQccm9zdGVkdEBn
b29kbWlzLm9yZwAKCRAp5XQQmuv6quonAP9HgM214Bt43edhuJb3oFy9fdS+sqYZ
RIJ9q90iMDUH0AEAk3650lu7u80YniD4INKNrz5QMM2EbIMaNqtqwkS8uwQ=
=tZwi
-----END PGP SIGNATURE-----
Merge tag 'trace-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Fix use-after-free in eventfs_remove_rec()
The freeing of the eventfs_inode children used list_for_each_entry()
where the child is freed via srcu, but there's still a chance that it
gets freed. It should be using list_for_each_entry_safe().
- Fix eventfs_inode SRCU use of list in freeing
The iterator uses an SRCU protected list walk on the eventfs inodes.
The eventfs inode uses its "list" field in a union with the RCU list
head. When the inode gets added to the SRCU list it immediately
corrupts the list pointer and can cause an issue with the iterator.
Move the RCU list head to be shared with the children list head which
allows the iterator to check the parent inode if is freed before
referencing the child. Have the iterator check the parent "is_freed"
field and break out if it is set. Also add memory barriers to make
sure the ordering is correct.
- Fix various RCU synchronization issues with direct_functions
Updates to direct_functions have some missing RCU protection and
synchronization. Restructure the code a bit to make sure updates to
the direct_functions are protected.
- Remove an unneeded comma from a scope_guard()
There's a spurious comma in a scope_guard(). Remove it.
- Fix race in per CPU buffer swap in the ring buffer
When a per CPU buffer swap happens, it must make sure that it doesn't
occur while a writer is active. Instead it returns an -EBUSY. But
there's a small race window when a writer moves from one sub-buffer
to the next that it resets the "committing" counter. If a swap
happens at that moment, the buffer used for the commit of an event
will not match the buffer the event is actually on. Instead of using
the "committing" counter, use the recursive detection counter that
does not get reset when the writer crosses sub-buffers.
- Fix off-by-one in ftrace_free_mem()
The function ftrace_free_mem() gets an "end_ptr" as a parameter that
is exclusive to the rang to be freed. But its value is used to search
for the records that expects an inclusive value. Subtract one from
the parameter to convert it to an inclusive range.
- Disable resizing of the ring buffer for persistent buffers
Resizing the persistent buffer has undefined behavior. Prevent it
from being resized.
- Disable changing ring buffer subbuf order when resizing is disabled
The ring buffer subbuffer order can not be changed during resizing.
Use that instead of just checking if the buffer is mapped as mapped
buffers also have resizing disabled.
- Initialize subbuf_order of reader pages when they are created
In rb_allocate_cpu_buffer() the bpage->order is not updated to the
current subbuf_order leaving it as zero. This value is used when the
page is freed.
- Fix test_ringbuffer() to test for ERR_PTR before calling
kthread_stop()
The rb_threads[] array is assigned the output of kthread_run_on_cpu()
which could return an ERR_PTR. At the end of the test, all threads in
the array are cleaned up by kthread_stop() passing in the value in
the array if it isn't zero. But if the array contains an ERR_PTR,
kthread_stop() will not be able to handle it properly.
* tag 'trace-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
ring-buffer: Fix crash passing ERR_PTR to kthread_stop()
ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()
ring-buffer: Prevent subbuf order change when resizing is disabled
ring-buffer: Prevent resizing of persistent ring buffer
ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()
ring-buffer: Use current_context for safe per-CPU buffer swap
ftrace: Drop extra comma in trace_buffered_event_enable
ftrace: Protect direct_functions in update_ftrace_direct_mod
ftrace: Protect direct_functions in update_ftrace_direct_del
ftrace: Protect direct_functions in ftrace_find_rec_direct
eventfs: Use children field for rcu head and add memory barriers
eventfs: Fix use-after-free in eventfs_remove_rec()
Add documentation for the KVM_PPC_GET_COMPAT_CAPS ioctl to the KVM API
documentation.
The ioctl exposes host processor compatibility modes supported for
nested KVM guests on PowerPC systems. The documentation covers error
code descriptions including E2BIG for forward compatibility,
KVM_PPC_COMPAT_CAPS_SIZE_VER0 as the minimum size floor, the rationale
for rejecting non-zero reserved fields to prevent ABI ambiguity, bit
numbering clarification for IBM MSB-0 convention, and KVM-specific
capability bit constants.
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-5-amachhiw@linux.ibm.com
Currently, when booting a compatibility-mode KVM guest (L1) on a PowerNV
hypervisor (L0), the guest runs with the expected processor
compatibility level. However, when booting a nested KVM guest (L2)
inside the L1, QEMU derives the CPU model from the raw host PVR and
attempts to run the nested guest at that level, instead of honoring the
compatibility mode of the L1.
Extend host CPU compatibility capability reporting to support nested
virtualization on PowerNV systems (PAPR nested API v1).
For nested API v2 (PowerVM), compatibility capabilities are served from
the cached nested_capabilities value (populated at module init via
kvmhv_nested_init() using the H_GUEST_GET_CAPABILITIES hcall). This
information is not available on PowerNV systems.
For nested API v1, derive the compatibility capabilities from the L1
guest by reading the "cpu-version" property from the device tree, which
reflects the effective (logical) processor compatibility level. Map this
value to the corresponding compatibility capability bitmap using
KVM-specific constants.
The mapping is cumulative: a system running at a given compatibility
level is assumed to also support older generations down the supported
chain. Note that unlike KVM on PowerVM (nested API v2), KVM on PowerNV
currently does not strictly enforce older generation compatibility modes
for nested guests - the reported capabilities reflect what the host CPU
can present, not what the hypervisor independently validates.
Introduce a helper kvmppc_map_compat_capabilities() to translate CPU
version values into KVM_PPC_COMPAT_CAP bits using a fallthrough switch,
and integrate it into kvmppc_get_compat_caps(). The implementation
applies masking to ensure only supported processor modes are exposed.
This allows userspace to query host CPU compatibility modes on both
KVM on PowerVM and on PowerNV platforms via the KVM_PPC_GET_COMPAT_CAPS
ioctl.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-4-amachhiw@linux.ibm.com
On POWER systems, the host CPU may run in a compatibility mode (e.g., a
Power11 processor operating in Power10 compatibility mode). In such
cases, the effective CPU level exposed to guests differs from the
physical processor generation.
When running nested KVM guests, QEMU derives the host CPU type using
mfpvr(), which reflects the physical processor version. This can result
in a mismatch between the CPU model selected by QEMU and the
compatibility mode enforced by the host, leading to guest boot failures.
For example, booting a nested guest on a Power11 LPAR configured in
Power10 compatibility mode fails with:
KVM-NESTEDv2: couldn't set guest wide elements
[..KVM reg dump..]
This occurs because QEMU selects a CPU model corresponding to the
physical processor (via mfpvr()), while the host operates in a lower
compatibility mode. As a result, KVM rejects the requested compatibility
level during guest initialization.
On pseries nestedv2 systems, add support for retrieving host CPU
compatibility capabilities for nested guests on PowerVM. The capability
bitmap reflects the processor modes negotiated between the Power
hypervisor (L0) and the host partition (L1) via the
H_GUEST_GET_CAPABILITIES hcall, but is retrieved from the cached
nested_capabilities value populated during module initialization,
avoiding repeated hypervisor calls. A WARN_ON_ONCE() flags the
unexpected case where nested_capabilities is zero on a nestedv2 system.
The implementation defines KVM-specific capability constants
(KVM_PPC_COMPAT_CAP_POWER9/10/11), masks unsupported bits, and exposes
the result through the KVM_PPC_GET_COMPAT_CAPS ioctl.
Hook the implementation into the Book3S HV kvmppc_ops so that it can be
invoked by the generic KVM ioctl handling code.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-3-amachhiw@linux.ibm.com
Introduce a new capability and ioctl to expose CPU compatibility modes
supported by the host processor for nested guests.
On IBM POWER systems, newer processor generations (N) can operate in
compatibility modes corresponding to earlier generations, like (N-1) and
(N-2). This is particularly relevant for nested virtualization, where
nested KVM guests may need to run with a specific processor compatibility
level.
Introduce KVM_CAP_PPC_COMPAT_CAPS capability and the corresponding
KVM_PPC_GET_COMPAT_CAPS vm ioctl. The ioctl returns a bitmap describing
the compatibility modes supported by the host in respective bit numbers,
allowing userspace (e.g., QEMU) to select an appropriate compatibility
level when configuring nested KVM guests.
The ioctl handling is added in kvm_arch_vm_ioctl() and retrieves host
CPU compatibility capabilities via a PowerPC-specific backend
implementation when available.
The struct kvm_ppc_compat_caps places the 'size' field first so it can
be read alone via get_user() before copy_struct_from_user() is called,
avoiding pointer arithmetic to locate the size field.
The ioctl is defined using _IO so the ioctl number remains stable even if
the struct grows in future versions. It uses copy_struct_from_user() and
copy_struct_to_user() to provide forward- and backward-compatible
extensibility: older userspace passing a smaller struct to a newer kernel
gets zero-padded trailing fields. Newer userspace passing a larger struct to
an older kernel (usize > ksize) succeeds if trailing bytes are zero (the
kernel reports back min(usize, ksize) as the filled size); if trailing bytes
are non-zero, the kernel writes back ksize into host_caps.size and returns
-E2BIG so userspace can retry with the correct size.
KVM_PPC_COMPAT_CAPS_SIZE_VER0 is defined as a frozen integer constant
(24) marking the size of the initial struct version, used as the
minimum floor for size field validation, similar to other versioned
struct interfaces in the kernel.
The 'flags' field is reserved for future use. The kernel rejects any
call where flags is non-zero with -EINVAL, preventing garbage values
from being baked into ABI permanently.
The ioctl returns appropriate error codes: E2BIG if usize exceeds
PAGE_SIZE, or if new userspace provides a larger struct with non-zero
trailing bytes (with ksize written back into host_caps.size for the
retry); EINVAL for an invalid size or non-zero reserved fields; EFAULT
for failed copy operations; and ENOTTY if the backend doesn't implement
get_compat_caps.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-2-amachhiw@linux.ibm.com
Replace devm_kasprintf() with dev_name() for the chip label. dev_name()
returns a stable pointer to the device name, so the separate allocation
and -ENOMEM check can be dropped.
Using dev_name() seems to be common for GPIO labels.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-9-rosenp@gmail.com
Shifting a 32-bit unsigned integer by 32 or more places is undefined
behavior in C. GPIO_MASK2 computes its shift amount as (gpio) * 2, and
for pins 16-31 in the OSRH/TSRH bank this yields shifts of 32-62.
While this happens to work on PowerPC because slw masks the shift count
to the low 5 bits, compilers performing value-range propagation may
assume the else branch is unreachable and optimize it away, or may
evaluate the shift as zero on other architectures via COMPILE_TEST.
Mask gpio to the 16-pin bank index so the shift stays within [0, 30].
The registers are banked (OSRL/TSRL for gpio 0-15, OSRH/TSRH for
gpio 16-31) with an identical 2-bit-per-pin layout from MSB to LSB,
so masking to the within-bank index preserves the intended behavior.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-8-rosenp@gmail.com
Replace PPC-specific clrbits32()/setbits32() with local helpers using
ioread32be()/iowrite32be() which are equivalent on PPC since commit
894fa235eb ("powerpc: inline iomap accessors").
Add COMPILE_TEST as a result to increase compile coverage.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-7-rosenp@gmail.com
Use gpio_generic_chip_init() to set up the PPC44x GPIO chip
instead of open-coding the basic get, set, locking and state handling.
Keep the PPC44x-specific direction callbacks because they still need to
program ODR and the OSR/TSR registers around the generic data and
direction registers.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-6-rosenp@gmail.com
Map the PPC44x GPIO register block through the platform device
resource instead of reparsing the firmware node directly.
The GPIO node now probes as a platform device, so use the
platform helper to keep resource handling aligned with the converted
driver model and to report mapping failures with the platform device
context.
Move ioremap up in order to avoid doing extra work in case of
-EPROBE_DEFER.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-5-rosenp@gmail.com
Replace the open-coded arch initcall registration with
module_platform_driver(). The initcall level changes from
arch_initcall to device_initcall, which is safe since the
driver no longer needs architecture-specific ordering.
Added MODULE info as a result, otherwise these warnings appear
ERROR: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ppc4xx.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-ppc4xx.o
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-4-rosenp@gmail.com
The kernel lost support for 4xx platforms and now only supports 44x.
Since this driver is being moved to drivers/gpio/ , take the opportunity
to modernize the name.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-3-rosenp@gmail.com
Move the ppc4xx gpio driver out of arch/powerpc/platforms/44x/ into
drivers/gpio/gpio-ppc44x.c. The driver has no architecture-specific
dependencies and follows the same pattern as other PowerPC GPIO
drivers already in drivers/gpio/ (e.g. gpio-mpc8xxx, gpio-mpc5200).
- Renamed Kconfig symbol from PPC4xx_GPIO to GPIO_PPC44X
- Updated ppc44x_defconfig and warp_defconfig to use the new symbol
- Marked the new option as tristate (was bool) since the driver
supports module build via module_platform_driver()
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-2-rosenp@gmail.com
