summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2026-01-16Merge tag 'v6.19-rc5' into drm-rust-nextDanilo Krummrich
We need the drm-rust fixes from -rc5 in here for nova-core to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: redefine `bindings::compat_ptr_ioctl` in RustAlice Ryhl
There is currently an inconsistency between C and Rust, which is that when Rust requires cfg(CONFIG_COMPAT) on compat_ioctl when using the compat_ptr_ioctl symbol because '#define compat_ptr_ioctl NULL' does not get translated to anything by bindgen. But it's not *just* a matter of translating the '#define' into Rust when CONFIG_COMPAT=n. This is because when CONFIG_COMPAT=y, the type of compat_ptr_ioctl is a non-nullable function pointer, and to seamlessly use it regardless of the config, we need a nullable function pointer. I think it's important to do something about this; I've seen the mistake of accidentally forgetting '#[cfg(CONFIG_COMPAT)]' when compat_ptr_ioctl is used multiple times now. This explicitly declares 'bindings::compat_ptr_ioctl' as an Option that is always defined but might be None. This matches C, but isn't ideal: it modifies the bindings crate. But I'm not sure if there's a better way to do it. If we just redefine in kernel/, then people may still use the one in bindings::, since that is where you would normally find it. I am open to suggestions. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260105-redefine-compat_ptr_ioctl-v1-1-25edb3d91acc@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.19-rc6). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-16rust: driver: drop device private data post unbindDanilo Krummrich
Currently, the driver's device private data is allocated and initialized from driver core code called from bus abstractions after the driver's probe() callback returned the corresponding initializer. Similarly, the driver's device private data is dropped within the remove() callback of bus abstractions after calling the remove() callback of the corresponding driver. However, commit 6f61a2637abe ("rust: device: introduce Device::drvdata()") introduced an accessor for the driver's device private data for a Device<Bound>, i.e. a device that is currently bound to a driver. Obviously, this is in conflict with dropping the driver's device private data in remove(), since a device can not be considered to be fully unbound after remove() has finished: We also have to consider registrations guarded by devres - such as IRQ or class device registrations - which are torn down after remove() in devres_release_all(). Thus, it can happen that, for instance, a class device or IRQ callback still calls Device::drvdata(), which then runs concurrently to remove() (which sets dev->driver_data to NULL and drops the driver's device private data), before devres_release_all() started to tear down the corresponding registration. This is because devres guarded registrations can, as expected, access the corresponding Device<Bound> that defines their scope. In C it simply is the driver's responsibility to ensure that its device private data is freed after e.g. an IRQ registration is unregistered. Typically, C drivers achieve this by allocating their device private data with e.g. devm_kzalloc() before doing anything else, i.e. before e.g. registering an IRQ with devm_request_threaded_irq(), relying on the reverse order cleanup of devres. Technically, we could do something similar in Rust. However, the resulting code would be pretty messy: In Rust we have to differentiate between allocated but uninitialized memory and initialized memory in the type system. Thus, we would need to somehow keep track of whether the driver's device private data object has been initialized (i.e. probe() was successful and returned a valid initializer for this memory) and conditionally call the destructor of the corresponding object when it is freed. This is because we'd need to allocate and register the memory of the driver's device private data *before* it is initialized by the initializer returned by the driver's probe() callback, because the driver could already register devres guarded registrations within probe() outside of the driver's device private data initializer. Luckily there is a much simpler solution: Instead of dropping the driver's device private data at the end of remove(), we just drop it after the device has been fully unbound, i.e. after all devres callbacks have been processed. For this, we introduce a new post_unbind() callback private to the driver-core, i.e. the callback is neither exposed to drivers, nor to bus abstractions. This way, the driver-core code can simply continue to conditionally allocate the memory for the driver's device private data when the driver's initializer is returned from probe() - no change needed - and drop it when the driver-core code receives the post_unbind() callback. Closes: https://lore.kernel.org/all/DEZMS6Y4A7XE.XE7EUBT5SJFJ@kernel.org/ Fixes: 6f61a2637abe ("rust: device: introduce Device::drvdata()") Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-7-dakr@kernel.org [ Remove #ifdef CONFIG_RUST, rename post_unbind() to post_unbind_rust(). - Danilo] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: add DriverData type to the DriverLayout traitDanilo Krummrich
Add an associated type DriverData to the DriverLayout trait indicating the type of the driver's device private data. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-6-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: add DEVICE_DRIVER_OFFSET to the DriverLayout traitDanilo Krummrich
Add an associated const DEVICE_DRIVER_OFFSET to the DriverLayout trait indicating the offset of the embedded struct device_driver within Self::DriverType, i.e. the specific driver structs, such as struct pci_driver or struct platform_driver. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-5-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-16rust: driver: introduce a DriverLayout traitDanilo Krummrich
The DriverLayout trait describes the layout of a specific driver structure, such as `struct pci_driver` or `struct platform_driver`. In a first step, this replaces the associated type RegType of the RegistrationOps with the DriverLayout::DriverType associated type. Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-4-dakr@kernel.org [ Rename driver::Driver to driver::DriverLayout, as it represents the layout of a driver structure rather than the driver structure itself. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-15rust: xarray: add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Tamir Duberstein <tamird@gmail.com> Link: https://lore.kernel.org/r/20260105-define-rust-helper-v2-27-51da5f454a67@google.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-01-15rust: configfs: replace `kernel::c_str!` with C-StringsTamir Duberstein
C-String literals were added in Rust 1.77. Replace instances of `kernel::c_str!` with C-String literals where possible. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20251222-cstr-configfs-v1-1-cc1665c51c43@gmail.com Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2026-01-15rust: auxiliary: add Driver::unbind() callbackDanilo Krummrich
Add missing unbind() callback to auxiliary::Driver, since it will be needed by drivers eventually (e.g. the Nova DRM driver). Acked-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260107103511.570525-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-15rust: i2c: do not drop device private data on shutdown()Danilo Krummrich
We must not drop the device private data on shutdown(); none of the registrations attached to devres that might access the device private data are released before shutdown() is called. Hence, freeing the device private data on shutdown() can cause UAF bugs. Fixes: 57c5bd9aee94 ("rust: i2c: add basic I2C device and driver abstractions") Acked-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260107103511.570525-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-14rust: irq: always inline functions using build_assert with argumentsAlexandre Courbot
`build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Cc: stable@vger.kernel.org Fixes: 746680ec6696 ("rust: irq: add flags module") Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20251208-io-build-assert-v3-6-98aded02c1ea@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-14rust: io: always inline functions using build_assert with argumentsAlexandre Courbot
`build_assert` relies on the compiler to optimize out its error path. Functions using it with its arguments must thus always be inlined, otherwise the error path of `build_assert` might not be optimized out, triggering a build error. Cc: stable@vger.kernel.org Fixes: ce30d94e6855 ("rust: add `io::{Io, IoRaw}` base types") Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Link: https://patch.msgid.link/20251208-io-build-assert-v3-2-98aded02c1ea@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-14rust: macros: ignore example with module parametersFUJITA Tomonori
`ModuleParamAccess` uses `SetOnce`, which depends on the helper functions so the `macros` crate example under `rusttest` fails to build: ---- rust/macros/lib.rs - module (line 62) stdout ---- error: linking with `cc` failed: exit status: 1 | = note: "cc" "-m64" ... = note: some arguments are omitted. use `--verbose` to show all linker arguments = note: rust-lld: error: undefined symbol: rust_helper_atomic_try_cmpxchg_relaxed >>> referenced by kernel.ecd446ce39a5fcbb-cgu.3 >>> kernel.kernel.ecd446ce39a5fcbb-cgu.3.rcgu.o:(kernel::sync::set_once::SetOnce$LT$T$GT$::populate::h8b02644e30bd70bc) in archive ./rust/test/libkernel.rlib rust-lld: error: undefined symbol: rust_helper_atomic_set_release >>> referenced by kernel.ecd446ce39a5fcbb-cgu.3 >>> kernel.kernel.ecd446ce39a5fcbb-cgu.3.rcgu.o:(kernel::sync::set_once::SetOnce$LT$T$GT$::populate::h8b02644e30bd70bc) in archive ./rust/test/libkernel.rlib collect2: error: ld returned 1 exit status Thus ignore that example to fix the error. [ Only the first one is needed (the other example does not use parameters), so we can keep it enabled. Thus I removed that second deletion (and reworded a bit). We may want to do something better here later on; on the other hand, we should get KUnit tests for `macros` too eventually, so we may end up removing or repurposing that target anyway, so it is not a big deal. - Miguel ] Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://lore.kernel.org/rust-for-linux/CANiq72mEYacdZmHKvpbahJzO_X_qqYyiSiSTYaWEQZAfp6sbxg@mail.gmail.com/ Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Fixes: 0b24f9740f26 ("rust: module: update the module macro with module parameter support") Link: https://patch.msgid.link/20251210.082603.290476643413141778.fujita.tomonori@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-01-13rust: bitops: fix missing _find_* functions on 32-bit ARMAlice Ryhl
On 32-bit ARM, you may encounter linker errors such as this one: ld.lld: error: undefined symbol: _find_next_zero_bit >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0 >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0 >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a This error occurs because even though the functions are declared by include/linux/find.h, the definition is #ifdef'd out on 32-bit ARM. This is because arch/arm/include/asm/bitops.h contains: #define find_first_zero_bit(p,sz) _find_first_zero_bit_le(p,sz) #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off) #define find_first_bit(p,sz) _find_first_bit_le(p,sz) #define find_next_bit(p,sz,off) _find_next_bit_le(p,sz,off) And the underscore-prefixed function is conditional on #ifndef of the non-underscore-prefixed name, but the declaration in find.h is *not* conditional on that #ifndef. To fix the linker error, we ensure that the symbols in question exist when compiling Rust code. We do this by defining them in rust/helpers/ whenever the normal definition is #ifndef'd out. Note that these helpers are somewhat unusual in that they do not have the rust_helper_ prefix that most helpers have. Adding the rust_helper_ prefix does not compile, as 'bindings::_find_next_zero_bit()' will result in a call to a symbol called _find_next_zero_bit as defined by include/linux/find.h rather than a symbol with the rust_helper_ prefix. This is because when a symbol is present in both include/ and rust/helpers/, the one from include/ wins under the assumption that the current configuration is one where that helper is unnecessary. This heuristic fails for _find_next_zero_bit() because the header file always declares it even if the symbol does not exist. The functions still use the __rust_helper annotation. This lets the wrapper function be inlined into Rust code even if full kernel LTO is not used once the patch series for that feature lands. Yury: arches are free to implement they own find_bit() functions. Most rely on generic implementation, but arm32 and m86k - not; so they require custom handling. Alice confirmed it fixes the build for both. Cc: stable@vger.kernel.org Fixes: 6cf93a9ed39e ("rust: add bindings for bitops.h") Reported-by: Andreas Hindborg <a.hindborg@kernel.org> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/561677301 Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2026-01-13regulator: Add TPS65185Mark Brown
Merge series from Andreas Kemnade <andreas@kemnade.info>: Add a driver for the TPS65185 regulator which provides the comparatively high voltages needed for electronic paper displays. Datasheet for the TPS65185 is at https://www.ti.com/lit/gpn/tps65185 To simplify things, include the hwmon part directly which is only one temperature sensor and there are no other functions besides regulators in this chip.
2026-01-13rust: platform: fix remove_callback invariant commentAlok Tiwari
Correct copy-paste errors where remove_callback safety invariants incorrectly referenced probe_callback(). Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260110115159.2313116-1-alok.a.tiwari@oracle.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-13rust: auxiliary: fix remove_callback invariant commentAlok Tiwari
Correct copy-paste errors where remove_callback safety invariants incorrectly referenced probe_callback(). Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260110114817.2312828-1-alok.a.tiwari@oracle.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-12Merge tag 'v6.19-rc5' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-12regulator: core: allow regulator_register() withMark Brown
Merge series from André Draszik <andre.draszik@linaro.org>: With these attached patches it becomes possible again to support hardware designs with multiple PMICs where individual rails of each act as required supplies for rails of the other (due to the latter being e.g. always-on), and vice-versa. Google Pixel 6 and 6 Pro (oriole and raven) are examples of such designs. Rather than returning -EPORBE_DEFER in regulator_register() when set_machine_constraints() fails with -EPROBE_DEFER (due to missing required supplies), we still allow rail registration and try to reresolve supplies each time a new rail gets registered. This is implemented using a bus (regulator bus), which allows the core to reresolve supplies for regulators that still need them whenever new regulators (i.e. devices) are added. Using a bus also solves existing problems around late resolution of supplies as mentioned in the commit message introducing that bus. The series starts with a few bug fixes and the last two commits implement the changes mentioned above, but do depend on the bug fixes.
2026-01-12Merge 6.19-rc5 into char-misc-nextGreg Kroah-Hartman
We need the char/misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-10Merge tag 'driver-core-6.19-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Fix swapped example values for the `family` and `machine` attributes in the sysfs SoC bus ABI documentation - Fix Rust build and intra-doc issues when optional subsystems (CONFIG_PCI, CONFIG_AUXILIARY_BUS, CONFIG_PRINTK) are disabled - Fix typos and incorrect safety comments in Rust PCI, DMA, and device ID documentation * tag 'driver-core-6.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: rust: device: Remove explicit import of CStrExt rust: pci: fix typos in Bar struct's comments rust: device: fix broken intra-doc links rust: dma: fix broken intra-doc links rust: driver: fix broken intra-doc links to example driver types rust: device_id: replace incorrect word in safety documentation rust: dma: remove incorrect safety documentation docs: ABI: sysfs-devices-soc: Fix swapped sample values
2026-01-10rust: sync: Inline various lock related methodsAlice Ryhl
While debugging a different issue [1], the following relocation was noticed in the rust_binder.ko file: R_AARCH64_CALL26 _RNvXNtNtNtCsdfZWD8DztAw_6kernel4sync4lock8spinlockNtB2_15SpinLockBackendNtB4_7Backend6unlock This relocation (and a similar one for lock) occurred many times throughout the module. That is not really useful because all this function does is call spin_unlock(), so what we actually want here is that a call to spin_unlock() dirctly is generated in favor of this wrapper method. Thus, mark these methods inline. [boqun: Reword the commit message a bit] Link: https://lore.kernel.org/p/20251111-binder-fix-list-remove-v1-0-8ed14a0da63d@google.com Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251218-inline-lock-unlock-v2-1-fbadac8bd61b@google.com
2026-01-09rust: helpers: Move #define __rust_helper out of atomic.cAlice Ryhl
In order to support inline helpers [1], we need to have __rust_helper defined for all helper files. Current we are lucky that atomic.c is the first file in helpers.c, but this is fragile. Thus, move it to helpers.c. [boqun: Reword the commit message and apply file hash changes] Link: https://lore.kernel.org/r/20260105-define-rust-helper-v2-0-51da5f454a67@google.com [1] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260107-move-rust_helper-define-v1-1-4109d58ef275@google.com
2026-01-09rust: wait: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-25-51da5f454a67@google.com
2026-01-09rust: time: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-22-51da5f454a67@google.com
2026-01-09rust: task: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-21-51da5f454a67@google.com
2026-01-09rust: sync: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-20-51da5f454a67@google.com
2026-01-09rust: refcount: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-17-51da5f454a67@google.com
2026-01-09rust: rcu: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Joel Fernandes (NVIDIA) <joel@joelfernandes.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-16-51da5f454a67@google.com
2026-01-09rust: processor: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-13-51da5f454a67@google.com
2026-01-09rust: cpu: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-6-51da5f454a67@google.com
2026-01-09rust: completion: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-5-51da5f454a67@google.com
2026-01-09rust: blk: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-2-51da5f454a67@google.com
2026-01-09rust: barrier: Add __rust_helper to helpersAlice Ryhl
This is needed to inline these helpers into Rust code. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260105-define-rust-helper-v2-1-51da5f454a67@google.com
2026-01-09rust: list: Switch to kernel::sync atomic primitivesFUJITA Tomonori
Convert uses of `AtomicBool` to `Atomic<bool>`. Note that the compare_exchange migration simplifies to `try_cmpxchg()`, since `try_cmpxchg()` provides relaxed ordering on failure, making the explicit failure ordering unnecessary. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251230093718.1852322-3-fujita.tomonori@gmail.com
2026-01-09rust: sync: atomic: Add atomic bool testsFUJITA Tomonori
Add tests for Atomic<bool> operations. Atomic<bool> does not fit into the existing u8/16/32/64 tests so introduce a dedicated test for it. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260101034922.2020334-3-fujita.tomonori@gmail.com
2026-01-09rust: sync: atomic: Add atomic bool support via i8 representationFUJITA Tomonori
Add `bool` support, `Atomic<bool>` by using `i8` as its underlying representation. Rust specifies that `bool` has size 1 and alignment 1 [1], so it matches `i8` on layout; keep `static_assert!()` checks to enforce this assumption at build time. [boqun: Remove the unnecessary impl AtomicImpl for bool] Link: https://doc.rust-lang.org/reference/types/boolean.html [1] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20260101034922.2020334-2-fujita.tomonori@gmail.com
2026-01-09rust: sync: atomic: Add i8/i16 xchg and cmpxchg supportFUJITA Tomonori
Add atomic xchg and cmpxchg operation support for i8 and i16 types with tests. Note that since the current implementation of Atomic::<{i8,i16}>::{load,store}() is READ_ONCE()/WRITE_ONCE()-based. The atomicity between load/store and xchg/cmpxchg is only guaranteed if the architecture has native RmW support, hence i8/i16 is currently AtomicImpl only when CONFIG_ARCH_SUPPORTS_ATOMIC_RWM=y. [boqun: Make i8/i16 AtomicImpl only when CONFIG_ARCH_SUPPORTS_ATOMIC_RWM=y] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251228120546.1602275-4-fujita.tomonori@gmail.com
2026-01-09rust: sync: atomic: Add store_release/load_acquire testsFUJITA Tomonori
Add minimum store_release/load_acquire tests. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251211113826.1299077-5-fujita.tomonori@gmail.com
2026-01-09rust: sync: atomic: Add i8/i16 load and store supportFUJITA Tomonori
Add atomic operation support for i8 and i16 types using volatile read/write and smp_load_acquire/smp_store_release helpers. [boqun: Adjust [1] to avoid introduction of impl_atomic_only_load_and_store_ops!() in the middle] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://lore.kernel.org/all/20251228120546.1602275-1-fujita.tomonori@gmail.com/ [1] Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251211113826.1299077-4-fujita.tomonori@gmail.com
2026-01-09rust: sync: atomic: Prepare AtomicOps macros for i8/i16 supportFUJITA Tomonori
Rework the internal AtomicOps macro plumbing to generate per-type implementations from a mapping list. Capture the trait definition once and reuse it for both declaration and per-type impl expansion to reduce duplication and keep future extensions simple. This is a preparatory refactor for enabling i8/i16 atomics cleanly. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251228120546.1602275-2-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg_relaxed helpersFUJITA Tomonori
Add i8/i16 atomic try_cmpxchg_relaxed helpers that call try_cmpxchg_relaxed() macro implementing atomic try_cmpxchg_relaxed using architecture-specific instructions. [boqun: Use try_cmpxchg_relaxed() instead of raw_try_cmpxchg_relaxed()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-5-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg_release helpersFUJITA Tomonori
Add i8/i16 atomic try_cmpxchg_release helpers that call try_cmpxchg_release() macro implementing atomic try_cmpxchg_release using architecture-specific instructions. [boqun: Use try_cmpxchg_release() instead of raw_try_cmpxchg_release()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-4-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg_acquire helpersFUJITA Tomonori
Add i8/i16 atomic try_cmpxchg_acquire helpers that call try_cmpxchg_acquire() macro implementing atomic try_cmpxchg_acquire using architecture-specific instructions. [boqun: Use try_cmpxchg_acquire() instead of raw_try_cmpxchg_acquire()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-3-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic try_cmpxchg helpersFUJITA Tomonori
Add i8/i16 atomic try_cmpxchg helpers that call try_cmpxchg() macro implementing atomic try_cmpxchg using architecture-specific instructions. [boqun: Add comments explaining CONFIG_ARCH_SUPPORTS_ATOMIC_RMW and use try_cmpxchg() instead of raw_try_cmpxchg()] Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251227115951.1424458-2-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg_relaxed helpersFUJITA Tomonori
Add i8/i16 atomic xchg_relaxed helpers that call xchg_relaxed() macro implementing atomic xchg_relaxed using architecture-specific instructions. [boqun: Use xchg_relaxed() instead of raw_xchg_relaxed()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-5-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg_release helpersFUJITA Tomonori
Add i8/i16 atomic xchg_release helpers that call xchg_release() macro implementing atomic xchg_release using architecture-specific instructions. [boqun: Use xchg_release() instead of raw_xchg_release()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-4-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg_acquire helpersFUJITA Tomonori
Add i8/i16 atomic xchg_acquire helpers that call xchg_acquire() macro implementing atomic xchg_acquire using architecture-specific instructions. [boqun: Use xchg_acquire() instead of raw_xchg_acquire()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-3-fujita.tomonori@gmail.com
2026-01-09rust: helpers: Add i8/i16 atomic xchg helpersFUJITA Tomonori
Add i8/i16 atomic xchg helpers that call xchg() macro implementing atomic xchg using architecture-specific instructions. [boqun: Use xchg() instead of raw_xchg()] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251223062140.938325-2-fujita.tomonori@gmail.com