[i2c] [patch 2.6.23-rc5] i2c_msg kerneldoc

[Jean Delvare]

Hi David,

On 9/10/2007, "David Brownell" <david-b at pacbell.net> wrote:
>> > 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!

If and only if you encode the length in a single byte. Which is what
SMBus block transactions do, but I2C doesn't have such a limitation. So
is your suggestion only about SMBus-level transactions (i.e. about
i2c_smbus_data, not i2c_msg)?

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

This might be my lack of experience speaking, but I am not convinced.
Given how explicit the 32-byte limit is in the SMBus specification, I
perfectly understand why SMBus support was designed the way it was.

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

Fine with me. Care to send a patch?

--
Jean Delvare