linux-next: manual merge of the rust tree with the driver-core tree

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/miscdevice.rs

between commit:

  0d8a7c7bf47a ("rust: miscdevice: access file in fops")

from the driver-core tree and commit:

  27c7518e7f1c ("rust: finish using custom FFI integer types")
  1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/miscdevice.rs
index ebc82e7dfc80,8f88891fb1d2..000000000000
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@@ -10,11 -10,9 +10,12 @@@
  
  use crate::{
      bindings,
 +    device::Device,
      error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
+     ffi::{c_int, c_long, c_uint, c_ulong},
 +    fs::File,
      prelude::*,
 +    seq_file::SeqFile,
      str::CStr,
      types::{ForeignOwnable, Opaque},
  };
@@@ -274,12 -225,7 +270,12 @@@ unsafe extern "C" fn fops_ioctl<T: Misc
      // SAFETY: Ioctl calls can borrow the private data of the file.
      let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
  
 -    match T::ioctl(device, cmd, arg) {
 +    // SAFETY:
 +    // * The file is valid for the duration of this call.
 +    // * There is no active fdget_pos region on the file on this thread.
 +    let file = unsafe { File::from_raw_file(file) };
 +
-     match T::ioctl(device, file, cmd, arg as usize) {
++    match T::ioctl(device, file, cmd, arg) {
          Ok(ret) => ret as c_long,
          Err(err) => err.to_errno() as c_long,
      }
@@@ -299,12 -245,7 +295,12 @@@ unsafe extern "C" fn fops_compat_ioctl<
      // SAFETY: Ioctl calls can borrow the private data of the file.
      let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
  
 -    match T::compat_ioctl(device, cmd, arg) {
 +    // SAFETY:
 +    // * The file is valid for the duration of this call.
 +    // * There is no active fdget_pos region on the file on this thread.
 +    let file = unsafe { File::from_raw_file(file) };
 +
-     match T::compat_ioctl(device, file, cmd, arg as usize) {
++    match T::compat_ioctl(device, file, cmd, arg) {
          Ok(ret) => ret as c_long,
          Err(err) => err.to_errno() as c_long,
      }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Greg KH]

On Tue, Dec 17, 2024 at 02:09:39PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rust tree got a conflict in:
> 
>   rust/kernel/miscdevice.rs
> 
> between commit:
> 
>   0d8a7c7bf47a ("rust: miscdevice: access file in fops")
> 
> from the driver-core tree and commit:
> 
>   27c7518e7f1c ("rust: finish using custom FFI integer types")
>   1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`")
> 
> from the rust tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc rust/kernel/miscdevice.rs
> index ebc82e7dfc80,8f88891fb1d2..000000000000
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@@ -10,11 -10,9 +10,12 @@@
>   
>   use crate::{
>       bindings,
>  +    device::Device,
>       error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
> +     ffi::{c_int, c_long, c_uint, c_ulong},
>  +    fs::File,
>       prelude::*,
>  +    seq_file::SeqFile,
>       str::CStr,
>       types::{ForeignOwnable, Opaque},
>   };
> @@@ -274,12 -225,7 +270,12 @@@ unsafe extern "C" fn fops_ioctl<T: Misc
>       // SAFETY: Ioctl calls can borrow the private data of the file.
>       let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>   
>  -    match T::ioctl(device, cmd, arg) {
>  +    // SAFETY:
>  +    // * The file is valid for the duration of this call.
>  +    // * There is no active fdget_pos region on the file on this thread.
>  +    let file = unsafe { File::from_raw_file(file) };
>  +
> -     match T::ioctl(device, file, cmd, arg as usize) {
> ++    match T::ioctl(device, file, cmd, arg) {
>           Ok(ret) => ret as c_long,
>           Err(err) => err.to_errno() as c_long,
>       }
> @@@ -299,12 -245,7 +295,12 @@@ unsafe extern "C" fn fops_compat_ioctl<
>       // SAFETY: Ioctl calls can borrow the private data of the file.
>       let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>   
>  -    match T::compat_ioctl(device, cmd, arg) {
>  +    // SAFETY:
>  +    // * The file is valid for the duration of this call.
>  +    // * There is no active fdget_pos region on the file on this thread.
>  +    let file = unsafe { File::from_raw_file(file) };
>  +
> -     match T::compat_ioctl(device, file, cmd, arg as usize) {
> ++    match T::compat_ioctl(device, file, cmd, arg) {
>           Ok(ret) => ret as c_long,
>           Err(err) => err.to_errno() as c_long,
>       }


Looks good to me, thansk!

greg k-h

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Tue, Dec 17, 2024 at 4:10 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Sorry, I missed to reply earlier, but this looked good to me too.

Thanks!

Cheers,
Miguel

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/miscdevice.rs

between commits:

  0d8a7c7bf47a ("rust: miscdevice: access file in fops")
  5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
  bf2aa7df2687 ("miscdevice: rust: use build_error! macro instead of function")

from the driver-core tree and commits:

  27c7518e7f1c ("rust: finish using custom FFI integer types")
  1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`")
  15f2f9313a39 ("rust: use the `build_error!` macro, not the hidden function")
  4401565fe92b ("rust: add `build_error!` to the prelude")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/miscdevice.rs
index dfb363630c70,9e1b9c0fae9d..000000000000
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@@ -10,11 -10,9 +10,12 @@@
  
  use crate::{
      bindings,
 +    device::Device,
      error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
+     ffi::{c_int, c_long, c_uint, c_ulong},
 +    fs::File,
      prelude::*,
 +    seq_file::SeqFile,
      str::CStr,
      types::{ForeignOwnable, Opaque},
  };
@@@ -151,17 -132,8 +147,17 @@@ pub trait MiscDevice: Sized 
          _cmd: u32,
          _arg: usize,
      ) -> Result<isize> {
-         kernel::build_error!(VTABLE_DEFAULT_ERROR)
+         build_error!(VTABLE_DEFAULT_ERROR)
      }
 +
 +    /// Show info for this fd.
 +    fn show_fdinfo(
 +        _device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
 +        _m: &SeqFile,
 +        _file: &File,
 +    ) {
-         kernel::build_error!(VTABLE_DEFAULT_ERROR)
++        build_error!(VTABLE_DEFAULT_ERROR)
 +    }
  }
  
  const fn create_vtable<T: MiscDevice>() -> &'static bindings::file_operations {
@@@ -274,12 -225,7 +270,12 @@@ unsafe extern "C" fn fops_ioctl<T: Misc
      // SAFETY: Ioctl calls can borrow the private data of the file.
      let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
  
 -    match T::ioctl(device, cmd, arg) {
 +    // SAFETY:
 +    // * The file is valid for the duration of this call.
 +    // * There is no active fdget_pos region on the file on this thread.
 +    let file = unsafe { File::from_raw_file(file) };
 +
-     match T::ioctl(device, file, cmd, arg as usize) {
++    match T::ioctl(device, file, cmd, arg) {
          Ok(ret) => ret as c_long,
          Err(err) => err.to_errno() as c_long,
      }
@@@ -299,12 -245,7 +295,12 @@@ unsafe extern "C" fn fops_compat_ioctl<
      // SAFETY: Ioctl calls can borrow the private data of the file.
      let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
  
 -    match T::compat_ioctl(device, cmd, arg) {
 +    // SAFETY:
 +    // * The file is valid for the duration of this call.
 +    // * There is no active fdget_pos region on the file on this thread.
 +    let file = unsafe { File::from_raw_file(file) };
 +
-     match T::compat_ioctl(device, file, cmd, arg as usize) {
++    match T::compat_ioctl(device, file, cmd, arg) {
          Ok(ret) => ret as c_long,
          Err(err) => err.to_errno() as c_long,
      }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Mon, Jan 13, 2025 at 5:12 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (see below) and can carry the fix as necessary. This

Looks good, thanks!

Cheers,
Miguel

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/lib.rs

between commit:

  9b90864bb42b ("rust: implement `IdArray`, `IdTable` and `RawDeviceId`")

from the driver-core tree and commit:

  47cb6bf7860c ("rust: use derive(CoercePointee) on rustc >= 1.84.0")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/lib.rs
index b11fa08de3c0,545d1170ee63..000000000000
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@@ -13,16 -13,12 +13,17 @@@
  
  #![no_std]
  #![feature(arbitrary_self_types)]
- #![feature(coerce_unsized)]
- #![feature(dispatch_from_dyn)]
+ #![cfg_attr(CONFIG_RUSTC_HAS_COERCE_POINTEE, feature(derive_coerce_pointee))]
+ #![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(coerce_unsized))]
+ #![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(dispatch_from_dyn))]
+ #![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(unsize))]
  #![feature(inline_const)]
  #![feature(lint_reasons)]
- #![feature(unsize)]
 +// Stable in Rust 1.83
 +#![feature(const_maybe_uninit_as_mut_ptr)]
 +#![feature(const_mut_refs)]
 +#![feature(const_ptr_write)]
 +#![feature(const_refs_to_cell)]
  
  // Ensure conditional compilation based on the kernel configuration works;
  // otherwise we may silently break things like initcall handling.
@@@ -37,12 -33,10 +38,13 @@@ pub use ffi
  pub mod alloc;
  #[cfg(CONFIG_BLOCK)]
  pub mod block;
- mod build_assert;
+ #[doc(hidden)]
+ pub mod build_assert;
  pub mod cred;
  pub mod device;
 +pub mod device_id;
 +pub mod devres;
 +pub mod driver;
  pub mod error;
  #[cfg(CONFIG_RUST_FW_LOADER_ABSTRACTIONS)]
  pub mod firmware;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4048 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/miscdevice.rs

between commit:

  88441d5c6d17 ("rust: miscdevice: access the `struct miscdevice` from fops->open()")

from the driver-core tree and commit:

  14686571a914 ("rust: kernel: change `ForeignOwnable` pointer to mut")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/miscdevice.rs
index dfb363630c70,b3a6cc50b240..000000000000
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@@ -10,11 -10,9 +10,12 @@@
  
  use crate::{
      bindings,
 +    device::Device,
      error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
+     ffi::{c_int, c_long, c_uint, c_ulong},
 +    fs::File,
      prelude::*,
 +    seq_file::SeqFile,
      str::CStr,
      types::{ForeignOwnable, Opaque},
  };
@@@ -151,17 -132,8 +147,17 @@@ pub trait MiscDevice: Sized 
          _cmd: u32,
          _arg: usize,
      ) -> Result<isize> {
-         kernel::build_error!(VTABLE_DEFAULT_ERROR)
+         build_error!(VTABLE_DEFAULT_ERROR)
      }
 +
 +    /// Show info for this fd.
 +    fn show_fdinfo(
 +        _device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
 +        _m: &SeqFile,
 +        _file: &File,
 +    ) {
-         kernel::build_error!(VTABLE_DEFAULT_ERROR)
++        build_error!(VTABLE_DEFAULT_ERROR)
 +    }
  }
  
  const fn create_vtable<T: MiscDevice>() -> &'static bindings::file_operations {
@@@ -230,12 -188,8 +226,12 @@@ unsafe extern "C" fn fops_open<T: MiscD
          Err(err) => return err.to_errno(),
      };
  
 -    // SAFETY: The open call of a file owns the private data.
 -    unsafe { (*file).private_data = ptr.into_foreign() };
 +    // This overwrites the private data with the value specified by the user, changing the type of
 +    // this file's private data. All future accesses to the private data is performed by other
 +    // fops_* methods in this file, which all correctly cast the private data to the new type.
 +    //
 +    // SAFETY: The open call of a file can access the private data.
-     unsafe { (*raw_file).private_data = ptr.into_foreign().cast_mut() };
++    unsafe { (*raw_file).private_data = ptr.into_foreign() };
  
      0
  }
@@@ -274,12 -225,7 +270,12 @@@ unsafe extern "C" fn fops_ioctl<T: Misc
      // SAFETY: Ioctl calls can borrow the private data of the file.
      let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
  
 -    match T::ioctl(device, cmd, arg) {
 +    // SAFETY:
 +    // * The file is valid for the duration of this call.
 +    // * There is no active fdget_pos region on the file on this thread.
 +    let file = unsafe { File::from_raw_file(file) };
 +
-     match T::ioctl(device, file, cmd, arg as usize) {
++    match T::ioctl(device, file, cmd, arg) {
          Ok(ret) => ret as c_long,
          Err(err) => err.to_errno() as c_long,
      }
@@@ -299,12 -245,7 +295,12 @@@ unsafe extern "C" fn fops_compat_ioctl<
      // SAFETY: Ioctl calls can borrow the private data of the file.
      let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
  
 -    match T::compat_ioctl(device, cmd, arg) {
 +    // SAFETY:
 +    // * The file is valid for the duration of this call.
 +    // * There is no active fdget_pos region on the file on this thread.
 +    let file = unsafe { File::from_raw_file(file) };
 +
-     match T::compat_ioctl(device, file, cmd, arg as usize) {
++    match T::compat_ioctl(device, file, cmd, arg) {
          Ok(ret) => ret as c_long,
          Err(err) => err.to_errno() as c_long,
      }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Tue, Jan 14, 2025 at 5:37 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
>   rust/kernel/lib.rs
>
> between commit:
>
>   9b90864bb42b ("rust: implement `IdArray`, `IdTable` and `RawDeviceId`")
>
> from the driver-core tree and commit:
>
>   47cb6bf7860c ("rust: use derive(CoercePointee) on rustc >= 1.84.0")
>
> from the rust tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This

Looks good to me, thanks!

Cheers,
Miguel

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Tue, Jan 14, 2025 at 5:46 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
>   rust/kernel/miscdevice.rs
>
> between commit:
>
>   88441d5c6d17 ("rust: miscdevice: access the `struct miscdevice` from fops->open()")
>
> from the driver-core tree and commit:
>
>   14686571a914 ("rust: kernel: change `ForeignOwnable` pointer to mut")
>
> from the rust tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This

Looks good to me as well, thanks!

Cheers,
Miguel

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

Hi all,

On Tue, 14 Jan 2025 15:37:33 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the rust tree got a conflict in:
> 
>   rust/kernel/lib.rs
> 
> between commit:
> 
>   9b90864bb42b ("rust: implement `IdArray`, `IdTable` and `RawDeviceId`")
> 
> from the driver-core tree and commit:
> 
>   47cb6bf7860c ("rust: use derive(CoercePointee) on rustc >= 1.84.0")
> 
> from the rust tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> 
> diff --cc rust/kernel/lib.rs
> index b11fa08de3c0,545d1170ee63..000000000000
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@@ -13,16 -13,12 +13,17 @@@
>   
>   #![no_std]
>   #![feature(arbitrary_self_types)]
> - #![feature(coerce_unsized)]
> - #![feature(dispatch_from_dyn)]
> + #![cfg_attr(CONFIG_RUSTC_HAS_COERCE_POINTEE, feature(derive_coerce_pointee))]
> + #![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(coerce_unsized))]
> + #![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(dispatch_from_dyn))]
> + #![cfg_attr(not(CONFIG_RUSTC_HAS_COERCE_POINTEE), feature(unsize))]
>   #![feature(inline_const)]
>   #![feature(lint_reasons)]
> - #![feature(unsize)]
>  +// Stable in Rust 1.83
>  +#![feature(const_maybe_uninit_as_mut_ptr)]
>  +#![feature(const_mut_refs)]
>  +#![feature(const_ptr_write)]
>  +#![feature(const_refs_to_cell)]
>   
>   // Ensure conditional compilation based on the kernel configuration works;
>   // otherwise we may silently break things like initcall handling.
> @@@ -37,12 -33,10 +38,13 @@@ pub use ffi
>   pub mod alloc;
>   #[cfg(CONFIG_BLOCK)]
>   pub mod block;
> - mod build_assert;
> + #[doc(hidden)]
> + pub mod build_assert;
>   pub mod cred;
>   pub mod device;
>  +pub mod device_id;
>  +pub mod devres;
>  +pub mod driver;
>   pub mod error;
>   #[cfg(CONFIG_RUST_FW_LOADER_ABSTRACTIONS)]
>   pub mod firmware;

This is now a conflict bewteen the driver-core tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4415 bytes --]

Hi all,

On Tue, 14 Jan 2025 15:46:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the rust tree got a conflict in:
> 
>   rust/kernel/miscdevice.rs
> 
> between commit:
> 
>   88441d5c6d17 ("rust: miscdevice: access the `struct miscdevice` from fops->open()")
> 
> from the driver-core tree and commit:
> 
>   14686571a914 ("rust: kernel: change `ForeignOwnable` pointer to mut")
> 
> from the rust tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc rust/kernel/miscdevice.rs
> index dfb363630c70,b3a6cc50b240..000000000000
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@@ -10,11 -10,9 +10,12 @@@
>   
>   use crate::{
>       bindings,
>  +    device::Device,
>       error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
> +     ffi::{c_int, c_long, c_uint, c_ulong},
>  +    fs::File,
>       prelude::*,
>  +    seq_file::SeqFile,
>       str::CStr,
>       types::{ForeignOwnable, Opaque},
>   };
> @@@ -151,17 -132,8 +147,17 @@@ pub trait MiscDevice: Sized 
>           _cmd: u32,
>           _arg: usize,
>       ) -> Result<isize> {
> -         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> +         build_error!(VTABLE_DEFAULT_ERROR)
>       }
>  +
>  +    /// Show info for this fd.
>  +    fn show_fdinfo(
>  +        _device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
>  +        _m: &SeqFile,
>  +        _file: &File,
>  +    ) {
> -         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> ++        build_error!(VTABLE_DEFAULT_ERROR)
>  +    }
>   }
>   
>   const fn create_vtable<T: MiscDevice>() -> &'static bindings::file_operations {
> @@@ -230,12 -188,8 +226,12 @@@ unsafe extern "C" fn fops_open<T: MiscD
>           Err(err) => return err.to_errno(),
>       };
>   
>  -    // SAFETY: The open call of a file owns the private data.
>  -    unsafe { (*file).private_data = ptr.into_foreign() };
>  +    // This overwrites the private data with the value specified by the user, changing the type of
>  +    // this file's private data. All future accesses to the private data is performed by other
>  +    // fops_* methods in this file, which all correctly cast the private data to the new type.
>  +    //
>  +    // SAFETY: The open call of a file can access the private data.
> -     unsafe { (*raw_file).private_data = ptr.into_foreign().cast_mut() };
> ++    unsafe { (*raw_file).private_data = ptr.into_foreign() };
>   
>       0
>   }
> @@@ -274,12 -225,7 +270,12 @@@ unsafe extern "C" fn fops_ioctl<T: Misc
>       // SAFETY: Ioctl calls can borrow the private data of the file.
>       let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>   
>  -    match T::ioctl(device, cmd, arg) {
>  +    // SAFETY:
>  +    // * The file is valid for the duration of this call.
>  +    // * There is no active fdget_pos region on the file on this thread.
>  +    let file = unsafe { File::from_raw_file(file) };
>  +
> -     match T::ioctl(device, file, cmd, arg as usize) {
> ++    match T::ioctl(device, file, cmd, arg) {
>           Ok(ret) => ret as c_long,
>           Err(err) => err.to_errno() as c_long,
>       }
> @@@ -299,12 -245,7 +295,12 @@@ unsafe extern "C" fn fops_compat_ioctl<
>       // SAFETY: Ioctl calls can borrow the private data of the file.
>       let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>   
>  -    match T::compat_ioctl(device, cmd, arg) {
>  +    // SAFETY:
>  +    // * The file is valid for the duration of this call.
>  +    // * There is no active fdget_pos region on the file on this thread.
>  +    let file = unsafe { File::from_raw_file(file) };
>  +
> -     match T::compat_ioctl(device, file, cmd, arg as usize) {
> ++    match T::compat_ioctl(device, file, cmd, arg) {
>           Ok(ret) => ret as c_long,
>           Err(err) => err.to_errno() as c_long,
>       }

This is now a conflict between the driver-core tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]

Hi all,

On Mon, 13 Jan 2025 15:12:36 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
> 
>   rust/kernel/miscdevice.rs
> 
> between commits:
> 
>   0d8a7c7bf47a ("rust: miscdevice: access file in fops")
>   5bcc8bfe841b ("rust: miscdevice: add fops->show_fdinfo() hook")
>   bf2aa7df2687 ("miscdevice: rust: use build_error! macro instead of function")
> 
> from the driver-core tree and commits:
> 
>   27c7518e7f1c ("rust: finish using custom FFI integer types")
>   1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`")
>   15f2f9313a39 ("rust: use the `build_error!` macro, not the hidden function")
>   4401565fe92b ("rust: add `build_error!` to the prelude")
> 
> from the rust tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc rust/kernel/miscdevice.rs
> index dfb363630c70,9e1b9c0fae9d..000000000000
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@@ -10,11 -10,9 +10,12 @@@
>   
>   use crate::{
>       bindings,
>  +    device::Device,
>       error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
> +     ffi::{c_int, c_long, c_uint, c_ulong},
>  +    fs::File,
>       prelude::*,
>  +    seq_file::SeqFile,
>       str::CStr,
>       types::{ForeignOwnable, Opaque},
>   };
> @@@ -151,17 -132,8 +147,17 @@@ pub trait MiscDevice: Sized 
>           _cmd: u32,
>           _arg: usize,
>       ) -> Result<isize> {
> -         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> +         build_error!(VTABLE_DEFAULT_ERROR)
>       }
>  +
>  +    /// Show info for this fd.
>  +    fn show_fdinfo(
>  +        _device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
>  +        _m: &SeqFile,
>  +        _file: &File,
>  +    ) {
> -         kernel::build_error!(VTABLE_DEFAULT_ERROR)
> ++        build_error!(VTABLE_DEFAULT_ERROR)
>  +    }
>   }
>   
>   const fn create_vtable<T: MiscDevice>() -> &'static bindings::file_operations {
> @@@ -274,12 -225,7 +270,12 @@@ unsafe extern "C" fn fops_ioctl<T: Misc
>       // SAFETY: Ioctl calls can borrow the private data of the file.
>       let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>   
>  -    match T::ioctl(device, cmd, arg) {
>  +    // SAFETY:
>  +    // * The file is valid for the duration of this call.
>  +    // * There is no active fdget_pos region on the file on this thread.
>  +    let file = unsafe { File::from_raw_file(file) };
>  +
> -     match T::ioctl(device, file, cmd, arg as usize) {
> ++    match T::ioctl(device, file, cmd, arg) {
>           Ok(ret) => ret as c_long,
>           Err(err) => err.to_errno() as c_long,
>       }
> @@@ -299,12 -245,7 +295,12 @@@ unsafe extern "C" fn fops_compat_ioctl<
>       // SAFETY: Ioctl calls can borrow the private data of the file.
>       let device = unsafe { <T::Ptr as ForeignOwnable>::borrow(private) };
>   
>  -    match T::compat_ioctl(device, cmd, arg) {
>  +    // SAFETY:
>  +    // * The file is valid for the duration of this call.
>  +    // * There is no active fdget_pos region on the file on this thread.
>  +    let file = unsafe { File::from_raw_file(file) };
>  +
> -     match T::compat_ioctl(device, file, cmd, arg as usize) {
> ++    match T::compat_ioctl(device, file, cmd, arg) {
>           Ok(ret) => ret as c_long,
>           Err(err) => err.to_errno() as c_long,
>       }

This is now a conflict between the driver-core tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a semantic conflict in:

  samples/rust/rust_dma.rs

between commit:

  7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")

from the driver-core tree and commit:

  9901addae63b ("samples: rust: add Rust dma test sample driver")

from the rust tree.

I fixed it up (I applied the following supplied resolution, thanks Danilo)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 21 Mar 2025 18:21:27 +1100
Subject: [PATCH] fix up for "samples: rust: add Rust dma test sample driver"

interacting with commit

  7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")

from the driver-core tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 samples/rust/rust_dma.rs | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/samples/rust/rust_dma.rs b/samples/rust/rust_dma.rs
index 908acd34b8db..874c2c964afa 100644
--- a/samples/rust/rust_dma.rs
+++ b/samples/rust/rust_dma.rs
@@ -4,10 +4,10 @@
 //!
 //! To make this driver probe, QEMU must be run with `-device pci-testdev`.
 
-use kernel::{bindings, dma::CoherentAllocation, pci, prelude::*};
+use kernel::{bindings, device::Core, dma::CoherentAllocation, pci, prelude::*, types::ARef};
 
 struct DmaSampleDriver {
-    pdev: pci::Device,
+    pdev: ARef<pci::Device>,
     ca: CoherentAllocation<MyStruct>,
 }
 
@@ -48,7 +48,7 @@ impl pci::Driver for DmaSampleDriver {
     type IdInfo = ();
     const ID_TABLE: pci::IdTable<Self::IdInfo> = &PCI_TABLE;
 
-    fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
+    fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
         dev_info!(pdev.as_ref(), "Probe DMA test driver.\n");
 
         let ca: CoherentAllocation<MyStruct> =
@@ -64,7 +64,7 @@ fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>
 
         let drvdata = KBox::new(
             Self {
-                pdev: pdev.clone(),
+                pdev: pdev.into(),
                 ca,
             },
             GFP_KERNEL,
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Fri, Mar 21, 2025 at 8:56 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a semantic conflict in:
>
>   samples/rust/rust_dma.rs
>
> between commit:
>
>   7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
>
> from the driver-core tree and commit:
>
>   9901addae63b ("samples: rust: add Rust dma test sample driver")
>
> from the rust tree.
>
> I fixed it up (I applied the following supplied resolution, thanks Danilo)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Looks like it worked from my test builds, thanks!

Cheers,
Miguel

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

Hi all,

On Fri, 21 Mar 2025 18:56:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a semantic conflict in:
> 
>   samples/rust/rust_dma.rs
> 
> between commit:
> 
>   7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
> 
> from the driver-core tree and commit:
> 
>   9901addae63b ("samples: rust: add Rust dma test sample driver")
> 
> from the rust tree.
> 
> I fixed it up (I applied the following supplied resolution, thanks Danilo)
> and can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 21 Mar 2025 18:21:27 +1100
> Subject: [PATCH] fix up for "samples: rust: add Rust dma test sample driver"
> 
> interacting with commit
> 
>   7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
> 
> from the driver-core tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  samples/rust/rust_dma.rs | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/samples/rust/rust_dma.rs b/samples/rust/rust_dma.rs
> index 908acd34b8db..874c2c964afa 100644
> --- a/samples/rust/rust_dma.rs
> +++ b/samples/rust/rust_dma.rs
> @@ -4,10 +4,10 @@
>  //!
>  //! To make this driver probe, QEMU must be run with `-device pci-testdev`.
>  
> -use kernel::{bindings, dma::CoherentAllocation, pci, prelude::*};
> +use kernel::{bindings, device::Core, dma::CoherentAllocation, pci, prelude::*, types::ARef};
>  
>  struct DmaSampleDriver {
> -    pdev: pci::Device,
> +    pdev: ARef<pci::Device>,
>      ca: CoherentAllocation<MyStruct>,
>  }
>  
> @@ -48,7 +48,7 @@ impl pci::Driver for DmaSampleDriver {
>      type IdInfo = ();
>      const ID_TABLE: pci::IdTable<Self::IdInfo> = &PCI_TABLE;
>  
> -    fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
> +    fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
>          dev_info!(pdev.as_ref(), "Probe DMA test driver.\n");
>  
>          let ca: CoherentAllocation<MyStruct> =
> @@ -64,7 +64,7 @@ fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>
>  
>          let drvdata = KBox::new(
>              Self {
> -                pdev: pdev.clone(),
> +                pdev: pdev.into(),
>                  ca,
>              },
>              GFP_KERNEL,
> -- 
> 2.45.2

This is now a conflict between the driver-core tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Greg KH]

On Tue, Apr 01, 2025 at 02:21:59PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 21 Mar 2025 18:56:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the rust tree got a semantic conflict in:
> > 
> >   samples/rust/rust_dma.rs
> > 
> > between commit:
> > 
> >   7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
> > 
> > from the driver-core tree and commit:
> > 
> >   9901addae63b ("samples: rust: add Rust dma test sample driver")
> > 
> > from the rust tree.
> > 
> > I fixed it up (I applied the following supplied resolution, thanks Danilo)
> > and can carry the fix as necessary. This is now fixed as far as linux-next
> > is concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging.  You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 21 Mar 2025 18:21:27 +1100
> > Subject: [PATCH] fix up for "samples: rust: add Rust dma test sample driver"
> > 
> > interacting with commit
> > 
> >   7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
> > 
> > from the driver-core tree.
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  samples/rust/rust_dma.rs | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/samples/rust/rust_dma.rs b/samples/rust/rust_dma.rs
> > index 908acd34b8db..874c2c964afa 100644
> > --- a/samples/rust/rust_dma.rs
> > +++ b/samples/rust/rust_dma.rs
> > @@ -4,10 +4,10 @@
> >  //!
> >  //! To make this driver probe, QEMU must be run with `-device pci-testdev`.
> >  
> > -use kernel::{bindings, dma::CoherentAllocation, pci, prelude::*};
> > +use kernel::{bindings, device::Core, dma::CoherentAllocation, pci, prelude::*, types::ARef};
> >  
> >  struct DmaSampleDriver {
> > -    pdev: pci::Device,
> > +    pdev: ARef<pci::Device>,
> >      ca: CoherentAllocation<MyStruct>,
> >  }
> >  
> > @@ -48,7 +48,7 @@ impl pci::Driver for DmaSampleDriver {
> >      type IdInfo = ();
> >      const ID_TABLE: pci::IdTable<Self::IdInfo> = &PCI_TABLE;
> >  
> > -    fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
> > +    fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>> {
> >          dev_info!(pdev.as_ref(), "Probe DMA test driver.\n");
> >  
> >          let ca: CoherentAllocation<MyStruct> =
> > @@ -64,7 +64,7 @@ fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> Result<Pin<KBox<Self>>
> >  
> >          let drvdata = KBox::new(
> >              Self {
> > -                pdev: pdev.clone(),
> > +                pdev: pdev.into(),
> >                  ca,
> >              },
> >              GFP_KERNEL,
> > -- 
> > 2.45.2
> 
> This is now a conflict between the driver-core tree and Linus' tree.

Thanks, I've sent the pull request to Linus right after the rust one,
and warned him about this conflict.

greg k-h

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/devres.rs

between commits:

  0dab138d0f4c ("rust: devres: require T: Send for Devres")
  ce7c22b2e1fb ("rust: revocable: support fallible PinInit types")
  46ae8fd7386a ("rust: devres: replace Devres::new_foreign_owned()")
  f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")

from the driver-core tree and commits:

  fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")
  23773bd8da71 ("rust: enable `clippy::as_ptr_cast_mut` lint")
  5e30550558b1 ("rust: enable `clippy::as_underscore` lint")
  b6985083be1d ("rust: Use consistent "# Examples" heading style in rustdoc")

from the rust tree.

Maybe not all the above commits are involved ...

I used the former version (since it changed things so much) and then
added the changes from the latter by hand where I could.  I ended up
with the below diff compared to te HEAD before the merge.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --git a/rust/kernel/devres.rs b/rust/kernel/devres.rs
index 7c5c5de8bcb6..f900433f5296 100644
--- a/rust/kernel/devres.rs
+++ b/rust/kernel/devres.rs
@@ -49,7 +49,7 @@ struct Inner<T: Send> {
 /// [`Devres`] users should make sure to simply free the corresponding backing resource in `T`'s
 /// [`Drop`] implementation.
 ///
-/// # Example
+/// # Examples
 ///
 /// ```no_run
 /// # use kernel::{bindings, c_str, device::{Bound, Device}, devres::Devres, io::{Io, IoRaw}};
@@ -66,19 +66,19 @@ struct Inner<T: Send> {
 ///     unsafe fn new(paddr: usize) -> Result<Self>{
 ///         // SAFETY: By the safety requirements of this function [`paddr`, `paddr` + `SIZE`) is
 ///         // valid for `ioremap`.
-///         let addr = unsafe { bindings::ioremap(paddr as _, SIZE as _) };
+///         let addr = unsafe { bindings::ioremap(paddr as bindings::phys_addr_t, SIZE) };
 ///         if addr.is_null() {
 ///             return Err(ENOMEM);
 ///         }
 ///
-///         Ok(IoMem(IoRaw::new(addr as _, SIZE)?))
+///         Ok(IoMem(IoRaw::new(addr as usize, SIZE)?))
 ///     }
 /// }
 ///
 /// impl<const SIZE: usize> Drop for IoMem<SIZE> {
 ///     fn drop(&mut self) {
 ///         // SAFETY: `self.0.addr()` is guaranteed to be properly mapped by `Self::new`.
-///         unsafe { bindings::iounmap(self.0.addr() as _); };
+///         unsafe { bindings::iounmap(self.0.addr() as *mut c_void); };
 ///     }
 /// }
 ///
@@ -214,7 +214,7 @@ fn remove_action(&self) -> bool {
     /// An error is returned if `dev` does not match the same [`Device`] this [`Devres`] instance
     /// has been created with.
     ///
-    /// # Example
+    /// # Examples
     ///
     /// ```no_run
     /// # #![cfg(CONFIG_PCI)]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Tue, Jul 1, 2025 at 9:46 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Maybe not all the above commits are involved ...
>
> I used the former version (since it changed things so much) and then
> added the changes from the latter by hand where I could.  I ended up
> with the below diff compared to te HEAD before the merge.

Sounds reasonable -- I did a quick merge of just rust-next into
driver-core and I saw a few conflicts, yeah.

The diff seems OK, but I can take a better look when the tag is out.

Thanks!

Cheers,
Miguel

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/pci.rs

between commit:

  4231712c8e98 ("rust: pci: use generic device drvdata accessors")

from the driver-core tree and commit:

  fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")

from the rust tree.

I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/platform.rs

between commit:

  f0a68a912c67 ("rust: platform: use generic device drvdata accessors")

from the driver-core tree and commit:

  fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")

from the rust tree.

I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Tamir Duberstein]

On Fri, Jul 11, 2025 at 4:04 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the rust tree got a conflict in:
>
>   rust/kernel/platform.rs
>
> between commit:
>
>   f0a68a912c67 ("rust: platform: use generic device drvdata accessors")
>
> from the driver-core tree and commit:
>
>   fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")
>
> from the rust tree.
>
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

The former version looks correct as it removed the line modified by
the latter version.

Thank you Stephen.

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Fri, Jul 11, 2025 at 9:59 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got a conflict in:
>
>   rust/kernel/pci.rs
>
> between commit:
>
>   4231712c8e98 ("rust: pci: use generic device drvdata accessors")
>
> from the driver-core tree and commit:
>
>   fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")
>
> from the rust tree.
>
> I fixed it up (I used the former version) and can carry the fix as

Same as Tamir mentioned for the other one (`platform`): the former
removes the line modified by the latter.

So it looks good -- thanks!

Cheers,
Miguel

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/pci.rs

between commit:

  4231712c8e98 ("rust: pci: use generic device drvdata accessors")

from the driver-core tree and commits:

  fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")
  12717ebeffcf ("rust: types: add FOREIGN_ALIGN to ForeignOwnable")

from the rust tree.

I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/platform.rs

between commit:

  f0a68a912c67 ("rust: platform: use generic device drvdata accessors")

from the driver-core tree and commits:

  fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")
  12717ebeffcf ("rust: types: add FOREIGN_ALIGN to ForeignOwnable")

from the rust tree.

I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

Hi all,

Today's linux-next merge of the rust tree got conflicts in:

  rust/kernel/device_id.rs
  rust/kernel/devres.rs

between commits:

  8d84b32075fb ("rust: device_id: split out index support into a separate trait")
  f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")

from the driver-core tree and various commits from the rust tree.

I fixed it up (see below - basically took the former version of
devres.rs and I suspect I have not got device_id.rs right) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/device_id.rs
index 8ed2c946144c,3dc72ca8cfc2..000000000000
--- a/rust/kernel/device_id.rs
+++ b/rust/kernel/device_id.rs
@@@ -94,16 -77,14 +94,16 @@@ impl<T: RawDeviceId, U, const N: usize
              // SAFETY: by the safety requirement of `RawDeviceId`, we're guaranteed that `T` is
              // layout-wise compatible with `RawType`.
              raw_ids[i] = unsafe { core::mem::transmute_copy(&ids[i].0) };
 -            // SAFETY: by the safety requirement of `RawDeviceId`, this would be effectively
 -            // `raw_ids[i].driver_data = i;`.
 -            unsafe {
 -                raw_ids[i]
 -                    .as_mut_ptr()
 -                    .byte_add(T::DRIVER_DATA_OFFSET)
 -                    .cast::<usize>()
 -                    .write(i);
 +            if let Some(data_offset) = data_offset {
 +                // SAFETY: by the safety requirement of this function, this would be effectively
 +                // `raw_ids[i].driver_data = i;`.
 +                unsafe {
 +                    raw_ids[i]
 +                        .as_mut_ptr()
-                         .byte_offset(data_offset as _)
++                        .byte_add(T::DRIVER_DATA_OFFSET)
 +                        .cast::<usize>()
 +                        .write(i);
 +                }
              }
  
              // SAFETY: this is effectively a move: `infos[i] = ids[i].1`. We make a copy here but
diff --cc rust/kernel/devres.rs
index 152a89b78943,d0e6c6e162c2..000000000000
--- a/rust/kernel/devres.rs
+++ b/rust/kernel/devres.rs
@@@ -49,10 -44,10 +49,10 @@@ struct Inner<T: Send> 
  /// [`Devres`] users should make sure to simply free the corresponding backing resource in `T`'s
  /// [`Drop`] implementation.
  ///
- /// # Example
+ /// # Examples
  ///
  /// ```no_run
 -/// # use kernel::{bindings, c_str, device::{Bound, Device}, devres::Devres, io::{Io, IoRaw}};
 +/// # use kernel::{bindings, device::{Bound, Device}, devres::Devres, io::{Io, IoRaw}};
  /// # use core::ops::Deref;
  ///
  /// // See also [`pci::Bar`] for a real example.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/device_id.rs

between commit:

  8d84b32075fb ("rust: device_id: split out index support into a separate trait")

from the driver-core tree and commit:

  5e30550558b1 ("rust: enable `clippy::as_underscore` lint")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/device_id.rs
index 8ed2c946144c,3dc72ca8cfc2..000000000000
--- a/rust/kernel/device_id.rs
+++ b/rust/kernel/device_id.rs
@@@ -94,16 -77,14 +94,16 @@@ impl<T: RawDeviceId, U, const N: usize
              // SAFETY: by the safety requirement of `RawDeviceId`, we're guaranteed that `T` is
              // layout-wise compatible with `RawType`.
              raw_ids[i] = unsafe { core::mem::transmute_copy(&ids[i].0) };
 -            // SAFETY: by the safety requirement of `RawDeviceId`, this would be effectively
 -            // `raw_ids[i].driver_data = i;`.
 -            unsafe {
 -                raw_ids[i]
 -                    .as_mut_ptr()
 -                    .byte_add(T::DRIVER_DATA_OFFSET)
 -                    .cast::<usize>()
 -                    .write(i);
 +            if let Some(data_offset) = data_offset {
 +                // SAFETY: by the safety requirement of this function, this would be effectively
 +                // `raw_ids[i].driver_data = i;`.
 +                unsafe {
 +                    raw_ids[i]
 +                        .as_mut_ptr()
-                         .byte_offset(data_offset as _)
++                        .byte_add(data_offset)
 +                        .cast::<usize>()
 +                        .write(i);
 +                }
              }
  
              // SAFETY: this is effectively a move: `infos[i] = ids[i].1`. We make a copy here but

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Hi all,


On Fri, 18 Jul 2025 20:26:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the rust tree got conflicts in:
> 
>   rust/kernel/device_id.rs
>   rust/kernel/devres.rs
> 
> between commits:
> 
>   8d84b32075fb ("rust: device_id: split out index support into a separate trait")
>   f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")
> 
> from the driver-core tree and various commits from the rust tree.

Ignore this, I am redoing the merge ...
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/devres.rs

between commit:

  f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")

from the driver-core tree and commits:

  fcad9bbf9e1a ("rust: enable `clippy::ptr_as_ptr` lint")
  23773bd8da71 ("rust: enable `clippy::as_ptr_cast_mut` lint")

from the rust tree.

I fixed it up (I basically took the former version) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Danilo Krummrich]

On Fri, Jul 18, 2025 at 08:46:53PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the rust tree got a conflict in:
> 
>   rust/kernel/device_id.rs
> 
> between commit:
> 
>   8d84b32075fb ("rust: device_id: split out index support into a separate trait")
> 
> from the driver-core tree and commit:
> 
>   5e30550558b1 ("rust: enable `clippy::as_underscore` lint")
> 
> from the rust tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks, the diff looks good!

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc rust/kernel/device_id.rs
> index 8ed2c946144c,3dc72ca8cfc2..000000000000
> --- a/rust/kernel/device_id.rs
> +++ b/rust/kernel/device_id.rs
> @@@ -94,16 -77,14 +94,16 @@@ impl<T: RawDeviceId, U, const N: usize
>               // SAFETY: by the safety requirement of `RawDeviceId`, we're guaranteed that `T` is
>               // layout-wise compatible with `RawType`.
>               raw_ids[i] = unsafe { core::mem::transmute_copy(&ids[i].0) };
>  -            // SAFETY: by the safety requirement of `RawDeviceId`, this would be effectively
>  -            // `raw_ids[i].driver_data = i;`.
>  -            unsafe {
>  -                raw_ids[i]
>  -                    .as_mut_ptr()
>  -                    .byte_add(T::DRIVER_DATA_OFFSET)
>  -                    .cast::<usize>()
>  -                    .write(i);
>  +            if let Some(data_offset) = data_offset {
>  +                // SAFETY: by the safety requirement of this function, this would be effectively
>  +                // `raw_ids[i].driver_data = i;`.
>  +                unsafe {
>  +                    raw_ids[i]
>  +                        .as_mut_ptr()
> -                         .byte_offset(data_offset as _)
> ++                        .byte_add(data_offset)
>  +                        .cast::<usize>()
>  +                        .write(i);
>  +                }
>               }
>   
>               // SAFETY: this is effectively a move: `infos[i] = ids[i].1`. We make a copy here but

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  drivers/cpufreq/rcpufreq_dt.rs

between commit:

  d3393e845038 ("rust: device: Move property_present() to FwNode")

from the driver-core tree and commit:

  f411b7eddde8 ("rust: kernel: remove `fmt!`, fix clippy::uninlined-format-args")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/cpufreq/rcpufreq_dt.rs
index 9ad85fe6fd05,4608d2286fa1..000000000000
--- a/drivers/cpufreq/rcpufreq_dt.rs
+++ b/drivers/cpufreq/rcpufreq_dt.rs
@@@ -19,9 -18,8 +18,9 @@@ use kernel::
  
  /// Finds exact supply name from the OF node.
  fn find_supply_name_exact(dev: &Device, name: &str) -> Option<CString> {
-     let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
+     let prop_name = CString::try_from_fmt(fmt!("{name}-supply")).ok()?;
 -    dev.property_present(&prop_name)
 +    dev.fwnode()?
 +        .property_present(&prop_name)
          .then(|| CString::try_from_fmt(fmt!("{name}")).ok())
          .flatten()
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Mon, Jul 21, 2025 at 6:25 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (see below) and can carry the fix as necessary. This

Looks good, thanks!

Cheers,
Miguel

linux-next: manual merge of the rust tree with the driver-core tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 9559 bytes --]

Hi all,

Today's linux-next merge of the rust tree got a conflict in:

  rust/kernel/types.rs

between commit:

  64888dfdfac7 ("rust: implement `Wrapper<T>` for `Opaque<T>`")

from the driver-core tree and commits:

  8802e1684378 ("rust: types: add Opaque::cast_from")
  07dad44aa9a9 ("rust: kernel: move ARef and AlwaysRefCounted to sync::aref")

from the rust tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/types.rs
index 3958a5f44d56,ec82a163cb0e..000000000000
--- a/rust/kernel/types.rs
+++ b/rust/kernel/types.rs
@@@ -5,12 -6,13 +6,13 @@@ use crate::ffi::c_void
  use core::{
      cell::UnsafeCell,
      marker::{PhantomData, PhantomPinned},
-     mem::{ManuallyDrop, MaybeUninit},
+     mem::MaybeUninit,
      ops::{Deref, DerefMut},
-     ptr::NonNull,
  };
 -use pin_init::{PinInit, Zeroable};
 +use pin_init::{PinInit, Wrapper, Zeroable};
  
+ pub use crate::sync::aref::{ARef, AlwaysRefCounted};
+ 
  /// Used to transfer ownership to and from foreign (non-Rust) languages.
  ///
  /// Ownership is transferred from Rust to a foreign language by calling [`Self::into_foreign`] and
@@@ -399,191 -411,16 +400,29 @@@ impl<T> Opaque<T> 
      ///
      /// This function is useful to get access to the value without creating intermediate
      /// references.
-     pub const fn raw_get(this: *const Self) -> *mut T {
+     pub const fn cast_into(this: *const Self) -> *mut T {
          UnsafeCell::raw_get(this.cast::<UnsafeCell<MaybeUninit<T>>>()).cast::<T>()
      }
+ 
+     /// The opposite operation of [`Opaque::cast_into`].
+     pub const fn cast_from(this: *const T) -> *const Self {
+         this.cast()
+     }
  }
  
 +impl<T> Wrapper<T> for Opaque<T> {
 +    /// Create an opaque pin-initializer from the given pin-initializer.
 +    fn pin_init<E>(slot: impl PinInit<T, E>) -> impl PinInit<Self, E> {
 +        Self::try_ffi_init(|ptr: *mut T| {
 +            // SAFETY:
 +            //   - `ptr` is a valid pointer to uninitialized memory,
 +            //   - `slot` is not accessed on error,
 +            //   - `slot` is pinned in memory.
 +            unsafe { PinInit::<T, E>::__pinned_init(slot, ptr) }
 +        })
 +    }
 +}
 +
- /// Types that are _always_ reference counted.
- ///
- /// It allows such types to define their own custom ref increment and decrement functions.
- /// Additionally, it allows users to convert from a shared reference `&T` to an owned reference
- /// [`ARef<T>`].
- ///
- /// This is usually implemented by wrappers to existing structures on the C side of the code. For
- /// Rust code, the recommendation is to use [`Arc`](crate::sync::Arc) to create reference-counted
- /// instances of a type.
- ///
- /// # Safety
- ///
- /// Implementers must ensure that increments to the reference count keep the object alive in memory
- /// at least until matching decrements are performed.
- ///
- /// Implementers must also ensure that all instances are reference-counted. (Otherwise they
- /// won't be able to honour the requirement that [`AlwaysRefCounted::inc_ref`] keep the object
- /// alive.)
- pub unsafe trait AlwaysRefCounted {
-     /// Increments the reference count on the object.
-     fn inc_ref(&self);
- 
-     /// Decrements the reference count on the object.
-     ///
-     /// Frees the object when the count reaches zero.
-     ///
-     /// # Safety
-     ///
-     /// Callers must ensure that there was a previous matching increment to the reference count,
-     /// and that the object is no longer used after its reference count is decremented (as it may
-     /// result in the object being freed), unless the caller owns another increment on the refcount
-     /// (e.g., it calls [`AlwaysRefCounted::inc_ref`] twice, then calls
-     /// [`AlwaysRefCounted::dec_ref`] once).
-     unsafe fn dec_ref(obj: NonNull<Self>);
- }
- 
- /// An owned reference to an always-reference-counted object.
- ///
- /// The object's reference count is automatically decremented when an instance of [`ARef`] is
- /// dropped. It is also automatically incremented when a new instance is created via
- /// [`ARef::clone`].
- ///
- /// # Invariants
- ///
- /// The pointer stored in `ptr` is non-null and valid for the lifetime of the [`ARef`] instance. In
- /// particular, the [`ARef`] instance owns an increment on the underlying object's reference count.
- pub struct ARef<T: AlwaysRefCounted> {
-     ptr: NonNull<T>,
-     _p: PhantomData<T>,
- }
- 
- // SAFETY: It is safe to send `ARef<T>` to another thread when the underlying `T` is `Sync` because
- // it effectively means sharing `&T` (which is safe because `T` is `Sync`); additionally, it needs
- // `T` to be `Send` because any thread that has an `ARef<T>` may ultimately access `T` using a
- // mutable reference, for example, when the reference count reaches zero and `T` is dropped.
- unsafe impl<T: AlwaysRefCounted + Sync + Send> Send for ARef<T> {}
- 
- // SAFETY: It is safe to send `&ARef<T>` to another thread when the underlying `T` is `Sync`
- // because it effectively means sharing `&T` (which is safe because `T` is `Sync`); additionally,
- // it needs `T` to be `Send` because any thread that has a `&ARef<T>` may clone it and get an
- // `ARef<T>` on that thread, so the thread may ultimately access `T` using a mutable reference, for
- // example, when the reference count reaches zero and `T` is dropped.
- unsafe impl<T: AlwaysRefCounted + Sync + Send> Sync for ARef<T> {}
- 
- impl<T: AlwaysRefCounted> ARef<T> {
-     /// Creates a new instance of [`ARef`].
-     ///
-     /// It takes over an increment of the reference count on the underlying object.
-     ///
-     /// # Safety
-     ///
-     /// Callers must ensure that the reference count was incremented at least once, and that they
-     /// are properly relinquishing one increment. That is, if there is only one increment, callers
-     /// must not use the underlying object anymore -- it is only safe to do so via the newly
-     /// created [`ARef`].
-     pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
-         // INVARIANT: The safety requirements guarantee that the new instance now owns the
-         // increment on the refcount.
-         Self {
-             ptr,
-             _p: PhantomData,
-         }
-     }
- 
-     /// Consumes the `ARef`, returning a raw pointer.
-     ///
-     /// This function does not change the refcount. After calling this function, the caller is
-     /// responsible for the refcount previously managed by the `ARef`.
-     ///
-     /// # Examples
-     ///
-     /// ```
-     /// use core::ptr::NonNull;
-     /// use kernel::types::{ARef, AlwaysRefCounted};
-     ///
-     /// struct Empty {}
-     ///
-     /// # // SAFETY: TODO.
-     /// unsafe impl AlwaysRefCounted for Empty {
-     ///     fn inc_ref(&self) {}
-     ///     unsafe fn dec_ref(_obj: NonNull<Self>) {}
-     /// }
-     ///
-     /// let mut data = Empty {};
-     /// let ptr = NonNull::<Empty>::new(&mut data).unwrap();
-     /// # // SAFETY: TODO.
-     /// let data_ref: ARef<Empty> = unsafe { ARef::from_raw(ptr) };
-     /// let raw_ptr: NonNull<Empty> = ARef::into_raw(data_ref);
-     ///
-     /// assert_eq!(ptr, raw_ptr);
-     /// ```
-     pub fn into_raw(me: Self) -> NonNull<T> {
-         ManuallyDrop::new(me).ptr
-     }
- }
- 
- impl<T: AlwaysRefCounted> Clone for ARef<T> {
-     fn clone(&self) -> Self {
-         self.inc_ref();
-         // SAFETY: We just incremented the refcount above.
-         unsafe { Self::from_raw(self.ptr) }
-     }
- }
- 
- impl<T: AlwaysRefCounted> Deref for ARef<T> {
-     type Target = T;
- 
-     fn deref(&self) -> &Self::Target {
-         // SAFETY: The type invariants guarantee that the object is valid.
-         unsafe { self.ptr.as_ref() }
-     }
- }
- 
- impl<T: AlwaysRefCounted> From<&T> for ARef<T> {
-     fn from(b: &T) -> Self {
-         b.inc_ref();
-         // SAFETY: We just incremented the refcount above.
-         unsafe { Self::from_raw(NonNull::from(b)) }
-     }
- }
- 
- impl<T: AlwaysRefCounted> Drop for ARef<T> {
-     fn drop(&mut self) {
-         // SAFETY: The type invariants guarantee that the `ARef` owns the reference we're about to
-         // decrement.
-         unsafe { T::dec_ref(self.ptr) };
-     }
- }
- 
- /// A sum type that always holds either a value of type `L` or `R`.
- ///
- /// # Examples
- ///
- /// ```
- /// use kernel::types::Either;
- ///
- /// let left_value: Either<i32, &str> = Either::Left(7);
- /// let right_value: Either<i32, &str> = Either::Right("right value");
- /// ```
- pub enum Either<L, R> {
-     /// Constructs an instance of [`Either`] containing a value of type `L`.
-     Left(L),
- 
-     /// Constructs an instance of [`Either`] containing a value of type `R`.
-     Right(R),
- }
- 
  /// Zero-sized type to mark types not [`Send`].
  ///
  /// Add this type as a field to your struct if your type should not be sent to a different task.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the rust tree with the driver-core tree

[Miguel Ojeda]

On Wed, Jul 23, 2025 at 3:26 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (see below) and can carry the fix as necessary. This

Looks good to me, thanks!

(I am still checking/testing the others)

Cheers,
Miguel