[i2c] [patch 2.6.23-rc5] i2c_msg kerneldoc

[David Brownell]

> > Ideally we'd have both TX and RX block paths able to take buffers of
> > any size physically possible with the encoding (1-255), and to report
> > just how many bytes were transferred.  Like most I/O interfaces ...
>
> What makes you think that 255 is the maximum size?

The length is encoded in a single byte, hence 0-255 works at the
encoding level.  That's what!

In such cases it's usual to work from the encoding out, making
infrastructure work sanely with any values that can be encoded.
(Some developers surely will do so!  The PMBus folk are one example
here, but that's true with most wire protocol specs.)  Any policy
driven limitations should be left up to higher level code.


> > By the way, did you consider how this affects I2C_RDWR from userspace?
>
> No, and I do not really care. I2C_M_RECV_LEN is meant for SMBus block
> reads, and SMBus block reads should be done from userspace using
> I2C_SMBUS, not I2C_RDWR.

In that case it's probably best to reject calls with I2C_M_RECV_LEN,
since otherwise getting the buffer length negotiations right will be
kind of error prone ... maybe even oopsable.

- Dave