Re: [PATCH] rust: i2c: remove TryFrom<&Device> implementation for &I2cClient

["Danilo Krummrich" <dakr@kernel.org>]

Igor,

On Wed Oct 21, 2026 at 2:44 PM CEST, Gary Guo wrote:
> On Wed Oct 21, 2026 at 1:32 PM BST, Igor Korotin wrote:
>> Hi all,
>>
>> Want to flag something before this lands -- I gave this an Acked-by
>> already, but while reviewing Muchamad's concurrent AS5600/IIO series
>> (Cc'd) I hit a real conflict with it.
>>
>> His IioDriver::read_raw is called by the generic IIO core, which only
>> ever hands the driver a generic &Device<Bound>
>
> That'd be a subsystem design issue.

Indeed, for class devices registered for a bus device there are two possible
options to get to the specific parent bus device:

  (1) Track it in the type system taking advantage of the AsBusDevice trait.

  (2) Let the driver store a reference to the specific bus device in its class
      device registration data (which is guaranteed to be shorter lived than the
      'bound lifetime).

The "upcast" was only ever needed for cases where we couldn't (easily) represent
the relationship through the type system (1); auxiliary bus was such an example.
But with the lifetime design this went away too.

> In the latest device driver lifecycle model design, class device must not mess
> around with parent bus device. It should use its own mechanism to carry around
> private data, which is initialized when creating the class device registration.
>
> The callback bridges should simply retrieve that registered data and hand it to
> the driver callback. The driver can decide to put whatever it needs there, and
> this include a `&Device<Bound>` of the bus device (hint -- you probably don't
> need it, it should just be a reference to whatever bus device resoruce the
> callback needs).

There's nothing wrong with a subsystem using AsBusDevice to keep track of the
specific parent bus device type and handing out references of it in callbacks,
but the lifetime design makes it largely unnecessary.

> The need for conversion is a strong indication that it's not aligned with the
> device driver lifetime design.

Indeed, but as mentioned above, this shouldn't even be necessary without it.