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

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

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
include/linux/cpu.h between commit 2987557f52b9 ("driver-core/cpu: Expose
hotpluggability to the rest of the kernel") from the tip tree and commit
8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck' sysdev_class to a
regular subsystem") from the driver-core tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/cpu.h
index 305c263,fc3da0d..0000000
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@@ -26,16 -26,15 +26,16 @@@ struct cpu 
  };
  
  extern int register_cpu(struct cpu *cpu, int num);
- extern struct sys_device *get_cpu_sysdev(unsigned cpu);
+ extern struct device *get_cpu_device(unsigned cpu);
 +extern bool cpu_is_hotpluggable(unsigned cpu);
  
- extern int cpu_add_sysdev_attr(struct sysdev_attribute *attr);
- extern void cpu_remove_sysdev_attr(struct sysdev_attribute *attr);
+ extern int cpu_add_dev_attr(struct device_attribute *attr);
+ extern void cpu_remove_dev_attr(struct device_attribute *attr);
  
- extern int cpu_add_sysdev_attr_group(struct attribute_group *attrs);
- extern void cpu_remove_sysdev_attr_group(struct attribute_group *attrs);
+ extern int cpu_add_dev_attr_group(struct attribute_group *attrs);
+ extern void cpu_remove_dev_attr_group(struct attribute_group *attrs);
  
- extern int sched_create_sysfs_power_savings_entries(struct sysdev_class *cls);
+ extern int sched_create_sysfs_power_savings_entries(struct device *dev);
  
  #ifdef CONFIG_HOTPLUG_CPU
  extern void unregister_cpu(struct cpu *cpu);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Greg KH]

On Wed, Dec 28, 2011 at 03:57:07PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> include/linux/cpu.h between commit 2987557f52b9 ("driver-core/cpu: Expose
> hotpluggability to the rest of the kernel") from the tip tree and commit
> 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck' sysdev_class to a
> regular subsystem") from the driver-core tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary

Looks fine, thanks.

greg k-h

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

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
lib/Makefile between commit e6459606b04e ("lib: Add early cpio decoder")
from the tip tree and commit 610141ee651c ("lib: kobject_uevent is no
longer dependant on CONFIG_HOTPLUG") from the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc lib/Makefile
index e91b9df,66787b9..0000000
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -12,7 -12,7 +12,7 @@@ lib-y := ctype.o string.o vsprintf.o cm
  	 idr.o int_sqrt.o extable.o \
  	 sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
  	 proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
- 	 is_single_threaded.o plist.o decompress.o earlycpio.o
 -	 is_single_threaded.o plist.o decompress.o kobject_uevent.o
++	 is_single_threaded.o plist.o decompress.o earlycpio.o kobject_uevent.o
  
  lib-$(CONFIG_MMU) += ioremap.o
  lib-$(CONFIG_SMP) += cpumask.o

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Greg KH]

On Thu, Nov 29, 2012 at 03:24:11PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> lib/Makefile between commit e6459606b04e ("lib: Add early cpio decoder")
> from the tip tree and commit 610141ee651c ("lib: kobject_uevent is no
> longer dependant on CONFIG_HOTPLUG") from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks.

greg k-h

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

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
kernel/rtmutex-tester.c between commit 8184004ed7a0
("locking/rtmutex/tester: Set correct permissions on sysfs files") from
the tip tree and commit 928c0c1571b0 ("rtmutex-tester: fix mode of sysfs
files") from the driver-core tree.

Both patches do the same thing - I used the tip version and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Greg KH]

On Thu, Apr 11, 2013 at 03:30:23PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> kernel/rtmutex-tester.c between commit 8184004ed7a0
> ("locking/rtmutex/tester: Set correct permissions on sysfs files") from
> the tip tree and commit 928c0c1571b0 ("rtmutex-tester: fix mode of sysfs
> files") from the driver-core tree.
> 
> Both patches do the same thing - I used the tip version and can carry the
> fix as necessary (no action is required).

Thanks for the heads up.

greg k-h

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

[Mark Brown]

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

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in arch/x86/Kconfig between commit b4df597ae51f ("audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL") from the tip tree and commit 2b9c1f03278 ("x86: align x86 arch with generic CPU modalias handling") from the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

diff --cc arch/x86/Kconfig
index 81f8485bb6b7,7fab7e0b1a72..000000000000
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -127,7 -127,7 +127,8 @@@ config X8
        select HAVE_DEBUG_STACKOVERFLOW
        select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
        select HAVE_CC_STACKPROTECTOR
 +      select HAVE_ARCH_AUDITSYSCALL
+       select GENERIC_CPU_AUTOPROBE
  
  config INSTRUCTION_DECODER
        def_bool y

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
lib/Kconfig.debug between commit e704f93af5a0 ("kernel: time: Add
udelay_test module to validate udelay") from the tip tree and commit
0a8adf584759 ("test: add firmware_class loader test") from the
driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc lib/Kconfig.debug
index 7cc4e8aff5df,213cd9f7e957..000000000000
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@@ -1659,15 -1649,19 +1659,28 @@@ config TEST_BP
  
  	  If unsure, say N.
  
+ config TEST_FIRMWARE
+ 	tristate "Test firmware loading via userspace interface"
+ 	default n
+ 	depends on FW_LOADER
+ 	help
+ 	  This builds the "test_firmware" module that creates a userspace
+ 	  interface for testing firmware loading. This can be used to
+ 	  control the triggering of firmware loading without needing an
+ 	  actual firmware-using device. The contents can be rechecked by
+ 	  userspace.
+ 
+ 	  If unsure, say N.
+ 
 +config TEST_UDELAY
 +	tristate "udelay test driver"
 +	default n
 +	help
 +	  This builds the "udelay_test" module that helps to make sure
 +	  that udelay() is working properly.
 +
 +	  If unsure, say N.
 +
  source "samples/Kconfig"
  
  source "lib/Kconfig.kgdb"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Greg KH]

On Thu, Jul 31, 2014 at 05:07:35PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> lib/Kconfig.debug between commit e704f93af5a0 ("kernel: time: Add
> udelay_test module to validate udelay") from the tip tree and commit
> 0a8adf584759 ("test: add firmware_class loader test") from the
> driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks.

greg k-h

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

[Kees Cook]

On Thu, Jul 31, 2014 at 8:20 PM, Greg KH <greg@kroah.com> wrote:
> On Thu, Jul 31, 2014 at 05:07:35PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the driver-core tree got a conflict in
>> lib/Kconfig.debug between commit e704f93af5a0 ("kernel: time: Add
>> udelay_test module to validate udelay") from the tip tree and commit
>> 0a8adf584759 ("test: add firmware_class loader test") from the
>> driver-core tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Looks good, thanks.

For keeping things regularized, could this module instead be named
"test_udelay", to match the rest of most of the test modules?
(Starting with "test_".)

-Kees

-- 
Kees Cook
Chrome OS Security

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

[Greg KH]

On Fri, Aug 01, 2014 at 07:38:26PM -0400, Kees Cook wrote:
> On Thu, Jul 31, 2014 at 8:20 PM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Jul 31, 2014 at 05:07:35PM +1000, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the driver-core tree got a conflict in
> >> lib/Kconfig.debug between commit e704f93af5a0 ("kernel: time: Add
> >> udelay_test module to validate udelay") from the tip tree and commit
> >> 0a8adf584759 ("test: add firmware_class loader test") from the
> >> driver-core tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary (no action
> >> is required).
> >
> > Looks good, thanks.
> 
> For keeping things regularized, could this module instead be named
> "test_udelay", to match the rest of most of the test modules?
> (Starting with "test_".)

Makes sense, want to send a patch to rename it?

thanks,

greg k-h

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

[John Stultz]

On Fri, Aug 1, 2014 at 4:38 PM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jul 31, 2014 at 8:20 PM, Greg KH <greg@kroah.com> wrote:
>> On Thu, Jul 31, 2014 at 05:07:35PM +1000, Stephen Rothwell wrote:
>>> Hi Greg,
>>>
>>> Today's linux-next merge of the driver-core tree got a conflict in
>>> lib/Kconfig.debug between commit e704f93af5a0 ("kernel: time: Add
>>> udelay_test module to validate udelay") from the tip tree and commit
>>> 0a8adf584759 ("test: add firmware_class loader test") from the
>>> driver-core tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>> is required).
>>
>> Looks good, thanks.
>
> For keeping things regularized, could this module instead be named
> "test_udelay", to match the rest of most of the test modules?
> (Starting with "test_".)

Sure. I'll spin up a patch to change it and will submit here shortly.

thanks
-john

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

[Stephen Rothwell]

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

Hi all,

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

  rust/kernel/debugfs/traits.rs

between commit:

  f74cf399e02e ("rust: debugfs: Replace the usage of Rust native atomics")

from the tip tree and commits:

  9c804d9cf2db ("rust: debugfs: support for binary large objects")
  a9fca8a7b2c5 ("rust: debugfs: support blobs from smart pointers")

from the driver-core tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc rust/kernel/debugfs/traits.rs
index 92054fed2136,82441ac8adaa..000000000000
--- a/rust/kernel/debugfs/traits.rs
+++ b/rust/kernel/debugfs/traits.rs
@@@ -3,12 -3,20 +3,17 @@@
  
  //! Traits for rendering or updating values exported to DebugFS.
  
+ use crate::alloc::Allocator;
+ use crate::fs::file;
  use crate::prelude::*;
+ use crate::sync::Arc;
 +use crate::sync::atomic::{Atomic, AtomicBasicOps, AtomicType, Relaxed};
  use crate::sync::Mutex;
- use crate::uaccess::UserSliceReader;
+ use crate::transmute::{AsBytes, FromBytes};
+ use crate::uaccess::{UserSliceReader, UserSliceWriter};
  use core::fmt::{self, Debug, Formatter};
+ use core::ops::{Deref, DerefMut};
  use core::str::FromStr;
 -use core::sync::atomic::{
 -    AtomicI16, AtomicI32, AtomicI64, AtomicI8, AtomicIsize, AtomicU16, AtomicU32, AtomicU64,
 -    AtomicU8, AtomicUsize, Ordering,
 -};
  
  /// A trait for types that can be written into a string.
  ///
@@@ -63,21 -175,164 +172,148 @@@ impl<T: FromStr + Unpin> Reader for Mut
      }
  }
  
 +impl<T: AtomicType + FromStr> Reader for Atomic<T>
 +where
 +    T::Repr: AtomicBasicOps,
 +{
 +    fn read_from_slice(&self, reader: &mut UserSliceReader) -> Result {
 +        let mut buf = [0u8; 21]; // Enough for a 64-bit number.
 +        if reader.len() > buf.len() {
 +            return Err(EINVAL);
 +        }
 +        let n = reader.len();
 +        reader.read_slice(&mut buf[..n])?;
 +
 +        let s = core::str::from_utf8(&buf[..n]).map_err(|_| EINVAL)?;
 +        let val = s.trim().parse::<T>().map_err(|_| EINVAL)?;
 +        self.store(val, Relaxed);
 +        Ok(())
 +    }
 +}
++
+ /// Trait for types that can be constructed from a binary representation.
+ ///
+ /// See also [`BinaryReader`] for interior mutability.
+ pub trait BinaryReaderMut {
+     /// Reads the binary form of `self` from `reader`.
+     ///
+     /// Same as [`BinaryReader::read_from_slice`], but takes a mutable reference.
+     ///
+     /// `offset` is the requested offset into the binary representation of `self`.
+     ///
+     /// On success, returns the number of bytes read from `reader`.
+     fn read_from_slice_mut(
+         &mut self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize>;
+ }
+ 
+ // Base implementation for any `T: AsBytes + FromBytes`.
+ impl<T: AsBytes + FromBytes> BinaryReaderMut for T {
+     fn read_from_slice_mut(
+         &mut self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         reader.read_slice_file(self.as_bytes_mut(), offset)
+     }
+ }
+ 
+ // Delegate for `Box<T, A>`: Support a `Box<T, A>` with an outer lock.
+ impl<T: ?Sized + BinaryReaderMut, A: Allocator> BinaryReaderMut for Box<T, A> {
+     fn read_from_slice_mut(
+         &mut self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         self.deref_mut().read_from_slice_mut(reader, offset)
+     }
+ }
+ 
+ // Delegate for `Vec<T, A>`: Support a `Vec<T, A>` with an outer lock.
+ impl<T, A> BinaryReaderMut for Vec<T, A>
+ where
+     T: AsBytes + FromBytes,
+     A: Allocator,
+ {
+     fn read_from_slice_mut(
+         &mut self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         let slice = self.as_mut_slice();
+ 
+         // SAFETY: `T: AsBytes + FromBytes` allows us to treat `&mut [T]` as `&mut [u8]`.
+         let buffer = unsafe {
+             core::slice::from_raw_parts_mut(
+                 slice.as_mut_ptr().cast(),
+                 core::mem::size_of_val(slice),
+             )
+         };
+ 
+         reader.read_slice_file(buffer, offset)
+     }
+ }
+ 
+ /// Trait for types that can be constructed from a binary representation.
+ ///
+ /// See also [`BinaryReaderMut`] for the mutable version.
+ pub trait BinaryReader {
+     /// Reads the binary form of `self` from `reader`.
+     ///
+     /// `offset` is the requested offset into the binary representation of `self`.
+     ///
+     /// On success, returns the number of bytes read from `reader`.
+     fn read_from_slice(
+         &self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize>;
+ }
+ 
+ // Delegate for `Mutex<T>`: Support a `T` with an outer `Mutex`.
+ impl<T: BinaryReaderMut + Unpin> BinaryReader for Mutex<T> {
+     fn read_from_slice(
+         &self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         let mut this = self.lock();
+ 
+         this.read_from_slice_mut(reader, offset)
+     }
+ }
+ 
+ // Delegate for `Box<T, A>`: Support a `Box<T, A>` with an inner lock.
+ impl<T: ?Sized + BinaryReader, A: Allocator> BinaryReader for Box<T, A> {
+     fn read_from_slice(
+         &self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         self.deref().read_from_slice(reader, offset)
+     }
+ }
+ 
+ // Delegate for `Pin<Box<T, A>>`: Support a `Pin<Box<T, A>>` with an inner lock.
+ impl<T: ?Sized + BinaryReader, A: Allocator> BinaryReader for Pin<Box<T, A>> {
+     fn read_from_slice(
+         &self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         self.deref().read_from_slice(reader, offset)
+     }
+ }
+ 
+ // Delegate for `Arc<T>`: Support an `Arc<T>` with an inner lock.
+ impl<T: ?Sized + BinaryReader> BinaryReader for Arc<T> {
+     fn read_from_slice(
+         &self,
+         reader: &mut UserSliceReader,
+         offset: &mut file::Offset,
+     ) -> Result<usize> {
+         self.deref().read_from_slice(reader, offset)
+     }
+ }
 -
 -macro_rules! impl_reader_for_atomic {
 -    ($(($atomic_type:ty, $int_type:ty)),*) => {
 -        $(
 -            impl Reader for $atomic_type {
 -                fn read_from_slice(&self, reader: &mut UserSliceReader) -> Result {
 -                    let mut buf = [0u8; 21]; // Enough for a 64-bit number.
 -                    if reader.len() > buf.len() {
 -                        return Err(EINVAL);
 -                    }
 -                    let n = reader.len();
 -                    reader.read_slice(&mut buf[..n])?;
 -
 -                    let s = core::str::from_utf8(&buf[..n]).map_err(|_| EINVAL)?;
 -                    let val = s.trim().parse::<$int_type>().map_err(|_| EINVAL)?;
 -                    self.store(val, Ordering::Relaxed);
 -                    Ok(())
 -                }
 -            }
 -        )*
 -    };
 -}
 -
 -impl_reader_for_atomic!(
 -    (AtomicI16, i16),
 -    (AtomicI32, i32),
 -    (AtomicI64, i64),
 -    (AtomicI8, i8),
 -    (AtomicIsize, isize),
 -    (AtomicU16, u16),
 -    (AtomicU32, u32),
 -    (AtomicU64, u64),
 -    (AtomicU8, u8),
 -    (AtomicUsize, usize)
 -);

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

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

[Stephen Rothwell]

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

Hi all,

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

  samples/rust/rust_debugfs.rs
  samples/rust/rust_debugfs_scoped.rs

between commit:

  f74cf399e02e ("rust: debugfs: Replace the usage of Rust native atomics")

from the tip tree and commits:

  0242623384c7 ("rust: driver: let probe() return impl PinInit<Self, Error>")
  52af0c37964b ("samples: rust: debugfs: add example for blobs")
  f656279afde1 ("samples: rust: debugfs_scoped: add example for blobs")

from the driver-core tree.

I fixed it up (I think - 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 samples/rust/rust_debugfs.rs
index 711faa07bece,c45b568d951b..000000000000
--- a/samples/rust/rust_debugfs.rs
+++ b/samples/rust/rust_debugfs.rs
@@@ -36,8 -38,9 +36,9 @@@ use kernel::c_str
  use kernel::debugfs::{Dir, File};
  use kernel::new_mutex;
  use kernel::prelude::*;
+ use kernel::sizes::*;
 +use kernel::sync::atomic::{Atomic, Relaxed};
  use kernel::sync::Mutex;
 -
  use kernel::{acpi, device::Core, of, platform, str::CString, types::ARef};
  
  kernel::module_platform_driver! {
@@@ -57,9 -60,13 +58,13 @@@ struct RustDebugFs 
      #[pin]
      _compatible: File<CString>,
      #[pin]
 -    counter: File<AtomicUsize>,
 +    counter: File<Atomic<usize>>,
      #[pin]
      inner: File<Mutex<Inner>>,
+     #[pin]
+     array_blob: File<Mutex<[u8; 4]>>,
+     #[pin]
+     vector_blob: File<Mutex<KVec<u8>>>,
  }
  
  #[derive(Debug)]
@@@ -104,16 -111,17 +109,17 @@@ impl platform::Driver for RustDebugFs 
      fn probe(
          pdev: &platform::Device<Core>,
          _info: Option<&Self::IdInfo>,
-     ) -> Result<Pin<KBox<Self>>> {
-         let result = KBox::try_pin_init(RustDebugFs::new(pdev), GFP_KERNEL)?;
-         // We can still mutate fields through the files which are atomic or mutexed:
-         result.counter.store(91, Relaxed);
-         {
-             let mut guard = result.inner.lock();
-             guard.x = guard.y;
-             guard.y = 42;
-         }
-         Ok(result)
+     ) -> impl PinInit<Self, Error> {
+         RustDebugFs::new(pdev).pin_chain(|this| {
 -            this.counter.store(91, Ordering::Relaxed);
++            this.counter.store(91, Relaxed);
+             {
+                 let mut guard = this.inner.lock();
+                 guard.x = guard.y;
+                 guard.y = 42;
+             }
+ 
+             Ok(())
+         })
      }
  }
  
diff --cc samples/rust/rust_debugfs_scoped.rs
index 9f0ec5f24cda,c80312cf168d..000000000000
--- a/samples/rust/rust_debugfs_scoped.rs
+++ b/samples/rust/rust_debugfs_scoped.rs
@@@ -6,9 -6,10 +6,10 @@@
  //! `Scope::dir` to create a variety of files without the need to separately
  //! track them all.
  
 -use core::sync::atomic::AtomicUsize;
  use kernel::debugfs::{Dir, Scope};
  use kernel::prelude::*;
+ use kernel::sizes::*;
 +use kernel::sync::atomic::Atomic;
  use kernel::sync::Mutex;
  use kernel::{c_str, new_mutex, str::CString};
  
@@@ -109,7 -114,8 +114,8 @@@ impl ModuleData 
  
  struct DeviceData {
      name: CString,
 -    nums: KVec<AtomicUsize>,
 +    nums: KVec<Atomic<usize>>,
+     blob: Pin<KBox<Mutex<[u8; SZ_4K]>>>,
  }
  
  fn init_control(base_dir: &Dir, dyn_dirs: Dir) -> impl PinInit<Scope<ModuleData>> + '_ {

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

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

[Boqun Feng]

On Mon, Nov 17, 2025 at 04:21:54PM +1100, Stephen Rothwell wrote:
> Hi all,
> 

Hi Stephen,

> Today's linux-next merge of the driver-core tree got a conflict in:
> 
>   rust/kernel/debugfs/traits.rs
> 
> between commit:
> 
>   f74cf399e02e ("rust: debugfs: Replace the usage of Rust native atomics")
> 
> from the tip tree and commits:
> 
>   9c804d9cf2db ("rust: debugfs: support for binary large objects")
>   a9fca8a7b2c5 ("rust: debugfs: support blobs from smart pointers")
> 
> from the driver-core tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary. This
> complex conflicts.

Thank you for reporting this, the fix looks good to me and I also did a
rust doc test on next-20251117, and confirm it works. Thank you!

> conflicts should be mentioned to your upstream maintainer when your tree
> is now fixed as far as linux-next is concerned, but any non trivial
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> 

Greg and Peter, any concern about this conflict? It's not very trivial,
but I believe it's not too much work to resolve then (just removing the
Atomic* usage and use the LKMM atomic).

Regards,
Boqun

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc rust/kernel/debugfs/traits.rs
> index 92054fed2136,82441ac8adaa..000000000000
> --- a/rust/kernel/debugfs/traits.rs
> +++ b/rust/kernel/debugfs/traits.rs
> @@@ -3,12 -3,20 +3,17 @@@
>   
>   //! Traits for rendering or updating values exported to DebugFS.
>   
> + use crate::alloc::Allocator;
> + use crate::fs::file;
>   use crate::prelude::*;
> + use crate::sync::Arc;
>  +use crate::sync::atomic::{Atomic, AtomicBasicOps, AtomicType, Relaxed};
>   use crate::sync::Mutex;
> - use crate::uaccess::UserSliceReader;
> + use crate::transmute::{AsBytes, FromBytes};
> + use crate::uaccess::{UserSliceReader, UserSliceWriter};
>   use core::fmt::{self, Debug, Formatter};
> + use core::ops::{Deref, DerefMut};
>   use core::str::FromStr;
>  -use core::sync::atomic::{
>  -    AtomicI16, AtomicI32, AtomicI64, AtomicI8, AtomicIsize, AtomicU16, AtomicU32, AtomicU64,
>  -    AtomicU8, AtomicUsize, Ordering,
>  -};
>   
>   /// A trait for types that can be written into a string.
>   ///
> @@@ -63,21 -175,164 +172,148 @@@ impl<T: FromStr + Unpin> Reader for Mut
>       }
>   }
>   
>  +impl<T: AtomicType + FromStr> Reader for Atomic<T>
>  +where
>  +    T::Repr: AtomicBasicOps,
>  +{
>  +    fn read_from_slice(&self, reader: &mut UserSliceReader) -> Result {
>  +        let mut buf = [0u8; 21]; // Enough for a 64-bit number.
>  +        if reader.len() > buf.len() {
>  +            return Err(EINVAL);
>  +        }
>  +        let n = reader.len();
>  +        reader.read_slice(&mut buf[..n])?;
>  +
>  +        let s = core::str::from_utf8(&buf[..n]).map_err(|_| EINVAL)?;
>  +        let val = s.trim().parse::<T>().map_err(|_| EINVAL)?;
>  +        self.store(val, Relaxed);
>  +        Ok(())
>  +    }
>  +}
> ++
> + /// Trait for types that can be constructed from a binary representation.
> + ///
> + /// See also [`BinaryReader`] for interior mutability.
> + pub trait BinaryReaderMut {
> +     /// Reads the binary form of `self` from `reader`.
> +     ///
> +     /// Same as [`BinaryReader::read_from_slice`], but takes a mutable reference.
> +     ///
> +     /// `offset` is the requested offset into the binary representation of `self`.
> +     ///
> +     /// On success, returns the number of bytes read from `reader`.
> +     fn read_from_slice_mut(
> +         &mut self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize>;
> + }
> + 
> + // Base implementation for any `T: AsBytes + FromBytes`.
> + impl<T: AsBytes + FromBytes> BinaryReaderMut for T {
> +     fn read_from_slice_mut(
> +         &mut self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         reader.read_slice_file(self.as_bytes_mut(), offset)
> +     }
> + }
> + 
> + // Delegate for `Box<T, A>`: Support a `Box<T, A>` with an outer lock.
> + impl<T: ?Sized + BinaryReaderMut, A: Allocator> BinaryReaderMut for Box<T, A> {
> +     fn read_from_slice_mut(
> +         &mut self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         self.deref_mut().read_from_slice_mut(reader, offset)
> +     }
> + }
> + 
> + // Delegate for `Vec<T, A>`: Support a `Vec<T, A>` with an outer lock.
> + impl<T, A> BinaryReaderMut for Vec<T, A>
> + where
> +     T: AsBytes + FromBytes,
> +     A: Allocator,
> + {
> +     fn read_from_slice_mut(
> +         &mut self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         let slice = self.as_mut_slice();
> + 
> +         // SAFETY: `T: AsBytes + FromBytes` allows us to treat `&mut [T]` as `&mut [u8]`.
> +         let buffer = unsafe {
> +             core::slice::from_raw_parts_mut(
> +                 slice.as_mut_ptr().cast(),
> +                 core::mem::size_of_val(slice),
> +             )
> +         };
> + 
> +         reader.read_slice_file(buffer, offset)
> +     }
> + }
> + 
> + /// Trait for types that can be constructed from a binary representation.
> + ///
> + /// See also [`BinaryReaderMut`] for the mutable version.
> + pub trait BinaryReader {
> +     /// Reads the binary form of `self` from `reader`.
> +     ///
> +     /// `offset` is the requested offset into the binary representation of `self`.
> +     ///
> +     /// On success, returns the number of bytes read from `reader`.
> +     fn read_from_slice(
> +         &self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize>;
> + }
> + 
> + // Delegate for `Mutex<T>`: Support a `T` with an outer `Mutex`.
> + impl<T: BinaryReaderMut + Unpin> BinaryReader for Mutex<T> {
> +     fn read_from_slice(
> +         &self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         let mut this = self.lock();
> + 
> +         this.read_from_slice_mut(reader, offset)
> +     }
> + }
> + 
> + // Delegate for `Box<T, A>`: Support a `Box<T, A>` with an inner lock.
> + impl<T: ?Sized + BinaryReader, A: Allocator> BinaryReader for Box<T, A> {
> +     fn read_from_slice(
> +         &self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         self.deref().read_from_slice(reader, offset)
> +     }
> + }
> + 
> + // Delegate for `Pin<Box<T, A>>`: Support a `Pin<Box<T, A>>` with an inner lock.
> + impl<T: ?Sized + BinaryReader, A: Allocator> BinaryReader for Pin<Box<T, A>> {
> +     fn read_from_slice(
> +         &self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         self.deref().read_from_slice(reader, offset)
> +     }
> + }
> + 
> + // Delegate for `Arc<T>`: Support an `Arc<T>` with an inner lock.
> + impl<T: ?Sized + BinaryReader> BinaryReader for Arc<T> {
> +     fn read_from_slice(
> +         &self,
> +         reader: &mut UserSliceReader,
> +         offset: &mut file::Offset,
> +     ) -> Result<usize> {
> +         self.deref().read_from_slice(reader, offset)
> +     }
> + }
>  -
>  -macro_rules! impl_reader_for_atomic {
>  -    ($(($atomic_type:ty, $int_type:ty)),*) => {
>  -        $(
>  -            impl Reader for $atomic_type {
>  -                fn read_from_slice(&self, reader: &mut UserSliceReader) -> Result {
>  -                    let mut buf = [0u8; 21]; // Enough for a 64-bit number.
>  -                    if reader.len() > buf.len() {
>  -                        return Err(EINVAL);
>  -                    }
>  -                    let n = reader.len();
>  -                    reader.read_slice(&mut buf[..n])?;
>  -
>  -                    let s = core::str::from_utf8(&buf[..n]).map_err(|_| EINVAL)?;
>  -                    let val = s.trim().parse::<$int_type>().map_err(|_| EINVAL)?;
>  -                    self.store(val, Ordering::Relaxed);
>  -                    Ok(())
>  -                }
>  -            }
>  -        )*
>  -    };
>  -}
>  -
>  -impl_reader_for_atomic!(
>  -    (AtomicI16, i16),
>  -    (AtomicI32, i32),
>  -    (AtomicI64, i64),
>  -    (AtomicI8, i8),
>  -    (AtomicIsize, isize),
>  -    (AtomicU16, u16),
>  -    (AtomicU32, u32),
>  -    (AtomicU64, u64),
>  -    (AtomicU8, u8),
>  -    (AtomicUsize, usize)
>  -);

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

[Boqun Feng]

On Mon, Nov 17, 2025 at 04:30:33PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the driver-core tree got conflicts in:
> 
>   samples/rust/rust_debugfs.rs
>   samples/rust/rust_debugfs_scoped.rs
> 
> between commit:
> 
>   f74cf399e02e ("rust: debugfs: Replace the usage of Rust native atomics")
> 
> from the tip tree and commits:
> 
>   0242623384c7 ("rust: driver: let probe() return impl PinInit<Self, Error>")
>   52af0c37964b ("samples: rust: debugfs: add example for blobs")
>   f656279afde1 ("samples: rust: debugfs_scoped: add example for blobs")
> 
> from the driver-core tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

Again, this fix looks good to me. Thanks!

Regards,
Boqun

> 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 samples/rust/rust_debugfs.rs
> index 711faa07bece,c45b568d951b..000000000000
> --- a/samples/rust/rust_debugfs.rs
> +++ b/samples/rust/rust_debugfs.rs
> @@@ -36,8 -38,9 +36,9 @@@ use kernel::c_str
>   use kernel::debugfs::{Dir, File};
>   use kernel::new_mutex;
>   use kernel::prelude::*;
> + use kernel::sizes::*;
>  +use kernel::sync::atomic::{Atomic, Relaxed};
>   use kernel::sync::Mutex;
>  -
>   use kernel::{acpi, device::Core, of, platform, str::CString, types::ARef};
>   
>   kernel::module_platform_driver! {
> @@@ -57,9 -60,13 +58,13 @@@ struct RustDebugFs 
>       #[pin]
>       _compatible: File<CString>,
>       #[pin]
>  -    counter: File<AtomicUsize>,
>  +    counter: File<Atomic<usize>>,
>       #[pin]
>       inner: File<Mutex<Inner>>,
> +     #[pin]
> +     array_blob: File<Mutex<[u8; 4]>>,
> +     #[pin]
> +     vector_blob: File<Mutex<KVec<u8>>>,
>   }
>   
>   #[derive(Debug)]
> @@@ -104,16 -111,17 +109,17 @@@ impl platform::Driver for RustDebugFs 
>       fn probe(
>           pdev: &platform::Device<Core>,
>           _info: Option<&Self::IdInfo>,
> -     ) -> Result<Pin<KBox<Self>>> {
> -         let result = KBox::try_pin_init(RustDebugFs::new(pdev), GFP_KERNEL)?;
> -         // We can still mutate fields through the files which are atomic or mutexed:
> -         result.counter.store(91, Relaxed);
> -         {
> -             let mut guard = result.inner.lock();
> -             guard.x = guard.y;
> -             guard.y = 42;
> -         }
> -         Ok(result)
> +     ) -> impl PinInit<Self, Error> {
> +         RustDebugFs::new(pdev).pin_chain(|this| {
>  -            this.counter.store(91, Ordering::Relaxed);
> ++            this.counter.store(91, Relaxed);
> +             {
> +                 let mut guard = this.inner.lock();
> +                 guard.x = guard.y;
> +                 guard.y = 42;
> +             }
> + 
> +             Ok(())
> +         })
>       }
>   }
>   
> diff --cc samples/rust/rust_debugfs_scoped.rs
> index 9f0ec5f24cda,c80312cf168d..000000000000
> --- a/samples/rust/rust_debugfs_scoped.rs
> +++ b/samples/rust/rust_debugfs_scoped.rs
> @@@ -6,9 -6,10 +6,10 @@@
>   //! `Scope::dir` to create a variety of files without the need to separately
>   //! track them all.
>   
>  -use core::sync::atomic::AtomicUsize;
>   use kernel::debugfs::{Dir, Scope};
>   use kernel::prelude::*;
> + use kernel::sizes::*;
>  +use kernel::sync::atomic::Atomic;
>   use kernel::sync::Mutex;
>   use kernel::{c_str, new_mutex, str::CString};
>   
> @@@ -109,7 -114,8 +114,8 @@@ impl ModuleData 
>   
>   struct DeviceData {
>       name: CString,
>  -    nums: KVec<AtomicUsize>,
>  +    nums: KVec<Atomic<usize>>,
> +     blob: Pin<KBox<Mutex<[u8; SZ_4K]>>>,
>   }
>   
>   fn init_control(base_dir: &Dir, dyn_dirs: Dir) -> impl PinInit<Scope<ModuleData>> + '_ {