> On Aug 3, 2020, at 1:38 AM, Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> 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. >
