On Tue Sep 9, 2025 at 7:55 PM CEST, Igor Korotin wrote:

On 8/27/2025 8:38 PM, Daniel Almeida wrote:

quoted

quoted

+#[pin_data]
+struct DriverModule {
+    #[pin]
+    _driver: kernel::driver::Registration<Ops<SampleDriver>>,
+    _reg: i2c::Registration,
+}

I was expecting this to be ARef of something, most likely I2cClient?

This is the Registration of an I2C device, just like auxiliary::Registration or
faux::Registration. There is no point in reference counting the registration
object.

You can't have an ARef<I2cClient> here either because you want to manage the
lifetime of the I2cClient to be registered in the system, i.e.
i2c_new_client_device() and i2c_unregister_device().

quoted

This is where my knowledge of i2c drivers start to fall short, but others will
probably chime in :)

You're right to mention this. This rust_driver_i2c is not the standard 
way of handling I2C devices.

It is indeed the normal way of handling this. This Registration object
represents the lifetime of calling i2c_new_client_device() e.g. from a platform
device probe (as Igor also mentions below) and calling i2c_unregister_device()
e.g. from platform device remove.

The ARef<I2cClient> can be obtained from the subsequent bus callback from the
I2C bus.

In fact, you could add a method to i2c::Registration to provide you with an
ARef<I2cClient> if that's ever needed.

But the i2c::Registration itself simply manages the lifetime for the I2C device
being registered in the system.

The idea was suggested by Danilo in the 
review of Patch v2: this driver merges an I2C driver sample with manual 
I2C device creation. The module creates a new I2cClient in its init 
function, and this new I2cClient is then probed by the SampleDriver.

In a normal driver it should be different. For example, let’s say 
there’s a platform device — the probe function for this platform device 
would create an I2cClient, and an appropriate I2C driver would then 
probe it.
Thanks for the review.

Best Regards
Igor