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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux