Message-Id: <DDTFXY5VJCS2.1ZB9EPNLDTPAC@kernel.org>
Date: Mon, 27 Oct 2025 23:00:25 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Igor Korotin" <igor.korotin.linux@...il.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
 <alex.gaynor@...il.com>, "Wolfram Sang" <wsa+renesas@...g-engineering.com>,
 "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice
 Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, "Viresh Kumar"
 <viresh.kumar@...aro.org>, "Asahi Lina" <lina+kernel@...hilina.net>,
 "Wedson Almeida Filho" <wedsonaf@...il.com>, "Alex Hung"
 <alex.hung@....com>, "Tamir Duberstein" <tamird@...il.com>, "Xiangfei Ding"
 <dingxiangfei2009@...il.com>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH v6 2/3] rust: i2c: Add basic I2C driver abstractions

On Mon Oct 27, 2025 at 9:27 PM CET, Igor Korotin wrote:
> On 10/26/2025 7:20 PM, Danilo Krummrich wrote:
>> This is an API that should be used by drivers operating complicated devices
>> (DRM, NET, etc.) where there is no point in keeping an i2c::Registration alive
>> after the driver that registered the I2C client has been unbound itself.
>> 
>> For instance, a GPU driver may call this in probe() to register an I2C device
>> for some redriver, repeater, multiplexer, etc. So, it makes no sense to allow a
>> corresponding i2c::Registration to still exist beyond the GPU driver being unbound.
>> 
>> Hence, besides not really being necessary for safety reasons, it still seems
>> reasonable to enforce this for semantic reasons.
>
> I might be misunderstanding your point, but as I see it, Devres cannot 
> apply here
> because we can't bind it to i2c_adapter.

Yes, you do misunderstand.

I'm not saying to use the I2C adapter device for this, that makes no sense. In
fact, it wouldn't even work, because the underlying device can not be guaranteed
to be in a bound state.

> There's no guarantee that driver
> owns it. Registration can't be bound to i2c_client, cause it's kind of 
> chicken and egg situation.

I'm also not saying to use the the I2C client, which indeed makes even less
sense (and wouldn't work for the same reason mentioned above).

Think of the bigger picture, i.e. where is i2c:Registration::new() called from?

It's called from other drivers (e.g. DRM drivers [1] or network drivers [2])
that are bound to some bus device themselves, e.g. a platform device or a PCI
device.

This is the device that we can give to i2c:Registration::new() and use for the
internal call to devres.

With that we ensure that the i2c:Registration will be dropped, when the driver
that originally called i2c:Registration::new() is unbound; it makes no sense to
allow a driver to keep an i2c:Registration alive when it is unbound.

In fact, quite some C drivers are already doing exactly this by hand. For
instance, see [3]. Four lines after [3], raa215300_rtc_unregister_device() is
registered with devm_add_action_or_reset(), which calls i2c_unregister_device().

Having that said, I'm a bit curious now: What is your use-case for
i2c:Registration?

[1] https://elixir.bootlin.com/linux/v6.17.5/source/drivers/gpu/drm/xe/xe_i2c.c#L72
[2] https://elixir.bootlin.com/linux/v6.17.5/source/drivers/net/ethernet/intel/igb/igb_hwmon.c#L201
[3] https://elixir.bootlin.com/linux/v6.17.5/source/drivers/regulator/raa215300.c#L160

Powered by blists - more mailing lists