Re: [PATCH 0/5] rust: extend I2C functionality

Re: [PATCH 0/5] rust: extend I2C functionality

[Danilo Krummrich]

(Cc: Bartosz, Greg, Rafael, driver-core)

On Sat Jan 31, 2026 at 3:12 PM CET, Igor Korotin via B4 Relay wrote:
> This patch series extend the existing I2C functionality with:
> - Abstractions allowing to implement I2C algorithms used by I2C adapters;
> - Abstractions allowing to create and add new I2C adapters;
> - Safe wrappers upon I2C and SMbus transferring C API: read/write
>   bytes/words/byte arrays.
>
> The patch series contains additional new sample driver `rust_i2c_adapter`
> presenting the new functionality. 

The i2c_adapter code on the C side has some lifetime issues, Bartosz looks into
resolving.

My biggest concern is that struct i2c_adapter is a bus device implementation,
but does not use the reference count of the embedded struct device.

Instead, I2C bus drivers embedd the i2c_adapter in their driver specific
structure, which is typically freed in the I2C bus driver's remove() callback.

This violates struct device reference counts.

Until this is fixed, the Rust abstractions should probably work around this, to
subsequent painful rework.

> Patch series depend on 
> message-id: <20260107103511.570525-1-dakr@kernel.org>
>
> Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
> ---
> Igor Korotin (5):
>       rust: i2c: split client and adapter code into separate files
>       rust: bits: add define_flags macro
>       rust: i2c: Add I2C Adapter registration abstractions
>       rust: i2c: add I2C wrappers
>       samples: rust: add Rust I2C adapter registration sample
>
>  MAINTAINERS                      |   4 +-
>  include/linux/i2c.h              |   6 +
>  rust/helpers/helpers.c           |   1 +
>  rust/helpers/i2c.c               |  15 ++
>  rust/kernel/bits.rs              |  57 ++++++++
>  rust/kernel/i2c.rs               | 254 ++-------------------------------
>  rust/kernel/i2c/adapter.rs       | 200 ++++++++++++++++++++++++++
>  rust/kernel/i2c/algo.rs          | 300 +++++++++++++++++++++++++++++++++++++++
>  rust/kernel/i2c/client.rs        | 284 ++++++++++++++++++++++++++++++++++++
>  samples/rust/Kconfig             |  12 ++
>  samples/rust/Makefile            |   1 +
>  samples/rust/rust_driver_i2c.rs  |  10 +-
>  samples/rust/rust_i2c_adapter.rs | 170 ++++++++++++++++++++++
>  samples/rust/rust_i2c_client.rs  |  15 +-
>  14 files changed, 1069 insertions(+), 260 deletions(-)
> ---
> base-commit: a7c013f779530190d0c1e1aa5e7c8a61f0bd479e
> change-id: 20260131-i2c-adapter-d38d330c4c25
> prerequisite-message-id: <20260107103511.570525-1-dakr@kernel.org>
> prerequisite-patch-id: 6e4d28a06d842ddfc7db82f410532a35b8fe317d
> prerequisite-patch-id: 9739295d85b688257fca29be1e1217a05a69c9e7
> prerequisite-patch-id: 78eaed3746a40713f44f13508fcf43653b0a4528
> prerequisite-patch-id: 99f1881bc896896297a903affcfa4f62cab1a307
> prerequisite-patch-id: ea8baa9d648f1178d6f39d140b98bddf3c183f6f
> prerequisite-patch-id: f8a9e049d204bde04e80151a67dfff5ec2633e7a
>
> Best regards,
> -- 
> Igor Korotin <igor.korotin.linux@gmail.com>

Re: [PATCH 0/5] rust: extend I2C functionality

[Igor Korotin]

Hello Danilo

On 1/31/2026 2:26 PM, Danilo Krummrich wrote:
> (Cc: Bartosz, Greg, Rafael, driver-core)
> 
> On Sat Jan 31, 2026 at 3:12 PM CET, Igor Korotin via B4 Relay wrote:
>> This patch series extend the existing I2C functionality with:
>> - Abstractions allowing to implement I2C algorithms used by I2C adapters;
>> - Abstractions allowing to create and add new I2C adapters;
>> - Safe wrappers upon I2C and SMbus transferring C API: read/write
>>    bytes/words/byte arrays.
>>
>> The patch series contains additional new sample driver `rust_i2c_adapter`
>> presenting the new functionality.
> 
> The i2c_adapter code on the C side has some lifetime issues, Bartosz looks into
> resolving.
> 
> My biggest concern is that struct i2c_adapter is a bus device implementation,
> but does not use the reference count of the embedded struct device.
> 
> Instead, I2C bus drivers embedd the i2c_adapter in their driver specific
> structure, which is typically freed in the I2C bus driver's remove() callback.
> 
> This violates struct device reference counts.
> 
> Until this is fixed, the Rust abstractions should probably work around this, to
> subsequent painful rework.

just to clarify what is currently implemented on the Rust side.

The Rust I2cAdapter is required to be bound to a parent Device<Bound>. 
The implementation keeps a reference to the embedded struct device 
inside struct i2c_adapter for the entire lifetime of the Rust adapter, 
so its lifetime is tied to the device model.

I am not entirely sure which specific lifetime or refcounting scenario 
you are referring to. If you have a concrete case in mind where this 
would still be problematic, could you please point it out?

Cheers
Igor

Re: [PATCH 0/5] rust: extend I2C functionality

[Danilo Krummrich]

On Sun Feb 8, 2026 at 1:34 PM CET, Igor Korotin wrote:
> Hello Danilo
>
> On 1/31/2026 2:26 PM, Danilo Krummrich wrote:
>> (Cc: Bartosz, Greg, Rafael, driver-core)
>> 
>> On Sat Jan 31, 2026 at 3:12 PM CET, Igor Korotin via B4 Relay wrote:
>>> This patch series extend the existing I2C functionality with:
>>> - Abstractions allowing to implement I2C algorithms used by I2C adapters;
>>> - Abstractions allowing to create and add new I2C adapters;
>>> - Safe wrappers upon I2C and SMbus transferring C API: read/write
>>>    bytes/words/byte arrays.
>>>
>>> The patch series contains additional new sample driver `rust_i2c_adapter`
>>> presenting the new functionality.
>> 
>> The i2c_adapter code on the C side has some lifetime issues, Bartosz looks into
>> resolving.
>> 
>> My biggest concern is that struct i2c_adapter is a bus device implementation,
>> but does not use the reference count of the embedded struct device.
>> 
>> Instead, I2C bus drivers embedd the i2c_adapter in their driver specific
>> structure, which is typically freed in the I2C bus driver's remove() callback.
>> 
>> This violates struct device reference counts.
>> 
>> Until this is fixed, the Rust abstractions should probably work around this, to
>> subsequent painful rework.
>
> just to clarify what is currently implemented on the Rust side.
>
> The Rust I2cAdapter is required to be bound to a parent Device<Bound>. 
> The implementation keeps a reference to the embedded struct device 
> inside struct i2c_adapter for the entire lifetime of the Rust adapter, 
> so its lifetime is tied to the device model.
>
> I am not entirely sure which specific lifetime or refcounting scenario 
> you are referring to. If you have a concrete case in mind where this 
> would still be problematic, could you please point it out?

The implementation on the C side does not consider the reference count of the
embedded struct device, which is not correct.

Re: [PATCH 0/5] rust: extend I2C functionality

[Bartosz Golaszewski]

On Sat, 31 Jan 2026 15:26:22 +0100, Danilo Krummrich <dakr@kernel.org> said:
> (Cc: Bartosz, Greg, Rafael, driver-core)
>
> On Sat Jan 31, 2026 at 3:12 PM CET, Igor Korotin via B4 Relay wrote:
>> This patch series extend the existing I2C functionality with:
>> - Abstractions allowing to implement I2C algorithms used by I2C adapters;
>> - Abstractions allowing to create and add new I2C adapters;
>> - Safe wrappers upon I2C and SMbus transferring C API: read/write
>>   bytes/words/byte arrays.
>>
>> The patch series contains additional new sample driver `rust_i2c_adapter`
>> presenting the new functionality.
>
> The i2c_adapter code on the C side has some lifetime issues, Bartosz looks into
> resolving.
>
> My biggest concern is that struct i2c_adapter is a bus device implementation,
> but does not use the reference count of the embedded struct device.
>
> Instead, I2C bus drivers embedd the i2c_adapter in their driver specific
> structure, which is typically freed in the I2C bus driver's remove() callback.
>

Correct.

> This violates struct device reference counts.
>

What's currently done in order to not crash is: we wait forever until all users
release their references[1].

> Until this is fixed, the Rust abstractions should probably work around this, to
> subsequent painful rework.
>

The rework of the C part will be long an painful already. I estimated the work
will take at least a year. More info here[2].

Bart

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/i2c-core-base.c#n1814
[2] https://lore.kernel.org/all/aWYYZEPX-_1GfQtL@ninjato/