Re: [PATCH i2c-tools] i2ctransfer: add support for I2C_M_RECV_LEN

Daniel Stodden
2020-08-03T20:25:22Z

> On Aug 3, 2020, at 1:38 AM, Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
>
>
>>> I have just checked existing I2C_M_RECV_LEN handling. Quite some drivers
>>> do it wrong. And there is no consistency in what they return. Lots of
>>> things to fix there...
>>
>> Would be curious about what variants are there.
>
> 1) some do it correctly
> 2) some hardcode the new length as recv_len + 1 (or recv_len + 2
> if they think about PEC). But they don't do extra_bytes + recv_len
> 3) some don't touch msg->len at all
> 4) some also remove the flag I2C_M_RECV_LEN while processing
> 5) one driver always sets length to I2C_SMBUS_MAX_BLOCK_LEN no matter
> what the device responds
>
> ...maybe more, but I gave up.

Yaah. Right. I think I see how this comes together.

If the driver author only looks at __i2_transfer => master_xfer invocations
as employed by i2c_smbus_xfer_emulated, and PEC isn’t used either, then that
code path let’s you get away with pretty much any msgs[i].len you come up with.

The smbus block reads are only looking at msgs[i].block[0] in that case.

Daniel

>> Note that msgs[i].len isn’t updated, you only get <extra_bytes> of data back,
>> so the difference would be severe: msgs[i].len is what guides copy_to_user().
>
> I think you can clearly see what was actually tested and what was coded
> after the specs without proper testing (or maybe just kernel-space
> testing?). This is why I hope my slave-testunit helps a little by
> providing a device to test against.
>