Re: [RFC PATCH v4 1/3] i2c: rust: implement SMBus read abstraction via kernel::io::Io for I2cClient
Muchamad Coirul Anwar <[email protected]>
| Newsgroups | org.kernel.vger.linux-i2c,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAO26r3Ttyfqhs3_jWDFym7FpswqFW4-UA8p1pQBcuWzDGGzstg@mail.gmail.com> |
On Sat, 11 Jul 2026 at 17:05, Igor Korotin <[email protected]> wrote: > This driver only calls try_read8()/try_read16(), so AS5600 itself isn't > affected in practice. But the abstraction being introduced here would be > unsound the moment any write-capable consumer reaches for it -- and I > don't think patching try_write8/try_update one at a time is the right > fix, since it just leaves the same trap for whichever method nobody's > gotten around to overriding yet. > > Danilo -- since using Io for I2C was originally your suggestion, I'd like > your read on this before we go further: IoCapable::io_read/io_write are > infallible by signature, which holds for MMIO/PCI-config (bounds-checked > implies success) but doesn't hold for a bus transaction -- I2C can > genuinely fail per-transfer regardless of address validity. Given that, > is Io/IoCapable the right abstraction for I2cClient to implement at all, > or does I2C need its own fallible-native interface rather than overriding > pieces of this one? Agreed. I will rework on top of Danilo's FallibleIoCapable approach in v5. I checked rust-next and neither FallibleIoCapable nor io_projection v6 has landed yet. Danilo, should I wait for io_projection to land first before rebasing, or should I carry FallibleIoCapable as a preparatory patch in my series? Thanks for the detailed review. Coirul