Update call sites in `i2c.rs` to import `ARef` and
`AlwaysRefCounted` from `sync::aref` instead of `types`.

This aligns with the ongoing effort to move `ARef` and
`AlwaysRefCounted` to sync.

Suggested-by: Benno Lossin <lossin@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1173
Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
Acked-by: Igor Korotin <igor.korotin.linux@gmail.com>
---
v1 -> v2:

Used the direct module name instead of including the path again,
re-worded the commit title to rust: i2c: and
carry-forwarded the Acked-by tag.

Link of v1: https://lore.kernel.org/all/20251123092438.182251-6-shankari.ak0208@gmail.com/

---
 rust/kernel/i2c.rs | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs
index 491e6cc25cf4..9f5f18792916 100644
--- a/rust/kernel/i2c.rs
+++ b/rust/kernel/i2c.rs
@@ -16,10 +16,8 @@
     error::*,
     of,
     prelude::*,
-    types::{
-        AlwaysRefCounted,
-        Opaque, //
-    }, //
+    sync::aref::AlwaysRefCounted,
+    types::Opaque, //
 };
 
 use core::{
@@ -31,7 +29,7 @@
     }, //
 };
 
-use kernel::types::ARef;
+use kernel::sync::aref::ARef;
 
 /// An I2C device id table.
 #[repr(transparent)]
@@ -407,7 +405,7 @@ pub fn get(index: i32) -> Result<ARef<Self>> {
 kernel::impl_device_context_into_aref!(I2cAdapter);
 
 // SAFETY: Instances of `I2cAdapter` are always reference-counted.
-unsafe impl crate::types::AlwaysRefCounted for I2cAdapter {
+unsafe impl AlwaysRefCounted for I2cAdapter {
     fn inc_ref(&self) {
         // SAFETY: The existence of a shared reference guarantees that the refcount is non-zero.
         unsafe { bindings::i2c_get_adapter(self.index()) };

-- 
2.34.1

On 1/2/2026 8:27 PM, Shankari Anand wrote:
> Update call sites in `i2c.rs` to import `ARef` and
> `AlwaysRefCounted` from `sync::aref` instead of `types`.
> 
> This aligns with the ongoing effort to move `ARef` and
> `AlwaysRefCounted` to sync.
> 
> Suggested-by: Benno Lossin <lossin@kernel.org>
> Link: https://github.com/Rust-for-Linux/linux/issues/1173
> Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com>
> ---
> v1 -> v2:
> 
> Used the direct module name instead of including the path again,
> re-worded the commit title to rust: i2c: and
> carry-forwarded the Acked-by tag.
> 
> Link of v1: https://lore.kernel.org/all/20251123092438.182251-6-shankari.ak0208@gmail.com/
> 
> ---
>   rust/kernel/i2c.rs | 10 ++++------
>   1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/rust/kernel/i2c.rs b/rust/kernel/i2c.rs
> index 491e6cc25cf4..9f5f18792916 100644
> --- a/rust/kernel/i2c.rs
> +++ b/rust/kernel/i2c.rs
> @@ -16,10 +16,8 @@
>       error::*,
>       of,
>       prelude::*,
> -    types::{
> -        AlwaysRefCounted,
> -        Opaque, //
> -    }, //
> +    sync::aref::AlwaysRefCounted,
> +    types::Opaque, //
>   };
>   
>   use core::{
> @@ -31,7 +29,7 @@
>       }, //
>   };
>   
> -use kernel::types::ARef;
> +use kernel::sync::aref::ARef;
>   
>   /// An I2C device id table.
>   #[repr(transparent)]
> @@ -407,7 +405,7 @@ pub fn get(index: i32) -> Result<ARef<Self>> {
>   kernel::impl_device_context_into_aref!(I2cAdapter);
>   
>   // SAFETY: Instances of `I2cAdapter` are always reference-counted.
> -unsafe impl crate::types::AlwaysRefCounted for I2cAdapter {
> +unsafe impl AlwaysRefCounted for I2cAdapter {
>       fn inc_ref(&self) {
>           // SAFETY: The existence of a shared reference guarantees that the refcount is non-zero.
>           unsafe { bindings::i2c_get_adapter(self.index()) };
> 

Acked-by: Igor Korotin <igor.korotin.linux@gmail.com>

Since I still don’t yet have a public kernel tree, I’d appreciate it if 
someone could pick this up through their tree.

Thanks
Igor

(Cc: Wolfram)

On Sat Jan 3, 2026 at 7:45 PM CET, Igor Korotin wrote:
> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com>
>
> Since I still don’t yet have a public kernel tree, I’d appreciate it if 
> someone could pick this up through their tree.

Since I've taken the initial I2C code through the driver-core tree I can pick
those patches up as well.

However, maybe it's something for Wolfram to just take through his tree?

Please let me know what you prefer.

- Danilo

Hello Danilo

On 1/3/2026 8:18 PM, Danilo Krummrich wrote:
> (Cc: Wolfram)
> 
> On Sat Jan 3, 2026 at 7:45 PM CET, Igor Korotin wrote:
>> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com>
>>
>> Since I still don’t yet have a public kernel tree, I’d appreciate it if
>> someone could pick this up through their tree.
> 
> Since I've taken the initial I2C code through the driver-core tree I can pick
> those patches up as well.
> 
> However, maybe it's something for Wolfram to just take through his tree?

I see this change more as a Rust infrastructure change rather than 
something I2C-specific.

If it is not a burden for you, I would appreciate it if you could take 
it through your tree.

Thanks,
Igor

On Sun, Jan 4, 2026 at 12:31 AM Igor Korotin
<igor.korotin.linux@gmail.com> wrote:
>
> I see this change more as a Rust infrastructure change rather than
> something I2C-specific.
>
> If it is not a burden for you, I would appreciate it if you could take
> it through your tree.

This could even go through the Rust tree since it is a general
cleanup, but I imagine Danilo wanted to see what Wolfram thinks first,
since it is the "parent" subsystem.

I.e. in general, even for cleanup patches like this the subsystems
decide (e.g. others in this series went through their subsystems) and
generally pick the patches unless there is a practical reason not to.

Cheers,
Miguel

On Sun Jan 4, 2026 at 12:58 PM CET, Miguel Ojeda wrote:
> On Sun, Jan 4, 2026 at 12:31 AM Igor Korotin
> <igor.korotin.linux@gmail.com> wrote:
>>
>> I see this change more as a Rust infrastructure change rather than
>> something I2C-specific.
>>
>> If it is not a burden for you, I would appreciate it if you could take
>> it through your tree.
>
> This could even go through the Rust tree since it is a general
> cleanup, but I imagine Danilo wanted to see what Wolfram thinks first,
> since it is the "parent" subsystem.

Yes, that was the intention. I think it is a good thing if the C and Rust parts
of subsystems are handled closely. I think making even trivial patches flow
through the corresponding trees can help with that. :)

On Sun, Jan 4, 2026 at 1:09 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Yes, that was the intention. I think it is a good thing if the C and Rust parts
> of subsystems are handled closely. I think making even trivial patches flow
> through the corresponding trees can help with that. :)

Indeed!

It makes things easier and is meant to be the default modulo
exceptional cases (most subsystems already handle patches like this,
which is great).

Cheers,
Miguel