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

[Gary Guo]

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.

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).

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

Best,
Gary

> -- it has no way to know
> the device is I2C specifically. To do SMBus I/O there, the driver needs
> to recover &I2cClient<Bound> from that generic reference, which is
> exactly what this TryFrom did.
>
> I checked whether storing a handle from probe() instead avoids the need
> -- it doesn't. AlwaysRefCounted is only implemented for I2cClient
> (Normal context), not I2cClient<Bound>, so there's nothing you can hold
> onto from probe() that still proves "currently bound" later. And there's
> no way to get back from Normal to Bound (Deref only goes the other
> way). As_raw() on both Device and I2cClient is private to kernel::i2c,
> so a driver can't reimplement the conversion itself either.
>
> So removing this outright leaves no path for any bus-agnostic subsystem
> callback (IIO being the concrete case, but this'll recur for SPI, HID,
> etc.) to ever recover a bus-specific handle after probe. Danilo, you
> mentioned a fix tying the lifetimes together properly
> (impl<'a, Ctx> TryFrom<&'a Device<Ctx>> for &'a I2cClient<Ctx>) as an
> alternative to removal -- given this, I think that's the right call
> instead of deleting it. It closes the actual soundness hole (output
> lifetime no longer independent of input) without removing the only way
> generic callbacks can get back to a specific bus type.
>
> I haven't pushed Nicolás's patch to rust-i2c-next yet -- holding off
> until this is settled.
>
> Cheers
> Igor