On 01-07-21, 21:24, Wolfram Sang wrote: > > > I just noticed this now, but this function even tries to send data > > partially, which isn't right. If the caller (i2c device's driver) > > calls this for 5 struct i2c_msg instances, then all 5 need to get > > through or none.. where as we try to send as many as possible here. > > > > This looks broken to me. Rather return an error value here on success, > > or make it complete failure. > > > > Though to be fair I see i2c-core also returns number of messages > > processed from i2c_transfer(). > > > > Wolfram, what's expected here ? Shouldn't all message transfer or > > none? > > Well, on a physical bus, it can simply happen that after message 3 of 5, > the bus is stalled, so we need to bail out. Right, and in that case the transfer will have any meaning left? I believe it needs to be fully retried as the requests may have been dependent on each other. > Again, I am missing details of a virtqueue, but I'd think it is > different. If adding to the queue fails, then it probably make sense to > drop the whole transfer. Exactly my point. > Of course, it can later happen on the physical bus of the host, though, > that the bus is stalled after message 3 of 5, and I2C_RDWR will bail > out. Basically we fail as soon as we know something is not right, correct? -- viresh
