On Mon, Jun 15, 2020 at 07:07:42PM +0300, Andy Shevchenko wrote: > On Mon, Jun 15, 2020 at 7:06 PM Sultan Alsawaf <sultan@xxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 15, 2020 at 12:40:19PM +0300, Andy Shevchenko wrote: > > > On Sun, Jun 14, 2020 at 02:02:54PM -0700, Sultan Alsawaf wrote: > > > > From: Sultan Alsawaf <sultan@xxxxxxxxxxxxxxx> > > > > > > > > SMBus block reads can be broken because the read function will just skip > > > > over bytes it doesn't like until reaching a byte that conforms to the > > > > length restrictions for block reads. This is problematic when it isn't > > > > known if the incoming payload is indeed a conforming block read. > > > > > > > > According to the SMBus specification, block reads will only send the > > > > payload length in the first byte, so we can fix this by only considering > > > > the first byte in a sequence for block read length purposes. > > > > > > I'm wondering if this overlaps with [1]. AFAIU that one is also makes sure that > > > the length is not a garbage. > > > > > > [1]: https://lore.kernel.org/linux-i2c/20200613104109.2989-1-mans@xxxxxxxxx/T/#u > > > > No overlap. > > Thanks for clarifying. > > > That looks like a similar bug for a different driver. In my case, > > the adapter provides native SMBus support, so emulation is never used. This is > > clear to see by looking at i2c_transfer_buffer_flags(), which only uses the > > master_xfer functions provided by the adapter; it doesn't call the emulation > > path at all. > > But do we get an advantage if this can be done in the i2c core instead > (once for all)? We can't, because the adapter driver needs to know mid-transfer to look for the payload length in the first byte, and then alter the transfer size on-the-fly. That can't be done in the i2c core, sadly. The problem is that we don't know if a transfer is going to be a block read or not beforehand. And altering the transfer size mid-transfer is definitely a controller specific task. Sultan
