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

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

 




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





[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