> > 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. > 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.
Attachment:
signature.asc
Description: PGP signature
