Re: [RFC PATCH 1/3] rust: i2c: add SMBus byte transfer helpers
Bruce Robertson <[email protected]>
| Newsgroups | org.kernel.vger.linux-i2c,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Jul 11, 2026 at 11:34:11 +0100, Igor Korotin wrote: > I2cClient should implement the `Io` trait rather than adding standalone > SMBus methods like these -- this was already agreed on previously [1][2]. > > There's also an in-flight series doing exactly this rework right now: > Muchamad's "[RFC PATCH v4 1/3] i2c: rust: implement SMBus read > abstraction via kernel::io::Io for I2cClient". Thanks -- I hadn't seen the prior agreement or Muchamad's series (it ran on linux-iio, which I don't follow). The Io direction makes sense to me, especially given Danilo's point that it's what gets I2C the register!() framework. I'll drop this patch. No point in two competing implementations, and Muchamad's series is further along the agreed path. When the FallibleIoCapable discussion settles I'll rebase the SMB347 driver (patch 3/3) onto the Io-based accessors it provides. > Your smbus_update_bits() is exactly the kind of read-modify-write > that's affected Right -- and it may be useful as a test case. Unlike the AS5600, the SMB347 driver is write-capable: it does a config-unlock write and read-modify-write updates of charge-control fields, so it exercises exactly the try_write/try_update paths you identified as unsound if left routed through the infallible backend. I've offered it as an early consumer on that thread. The power_supply abstraction and the driver (patches 2/3 and 3/3) don't depend on the shape of the I2C accessors, so I'll continue revising those in the meantime. Bruce [1] https://lore.kernel.org/all/[email protected]/