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