Hi Viresh, > If you look at i2c_smbus_xfer_emulated(), the command is always sent via > msgbuf0[0]. Even in the case of I2C_SMBUS_QUICK, where we set msg[0].len = 0, we > still send the buf. This is really confusing :( > > Do I understand correctly that we always need to send msg[0].buf even when > msg[0].len is 0 ? Nope, I think you misinterpreted that. SMBUS_QUICK will not send any byte. After the address phase (with the RW bit as data), a STOP will immediately follow. len = 0 will ensure that. msgbuf0[0] is set to 'command' because every mode except SMBUS_QUICK will need that. So, it is convenient to always do it. For SMBUS_QUICK it is superfluous but does not hurt. > If so, it would be difficult to implement this with the current i2c virtio > specification, as the msg.len isn't really passed from guest to host, rather it > is inferred using the length of the buffer itself. And so we can't really pass a > buffer if length is 0. And you can't leave out the buffer and assume len = 0 then? Otherwise, you can't do SMBUS_QUICK and we need to set a struct i2c_adapter_quirks with I2C_AQ_NO_ZERO_LEN. Speaking of adapter quirks, currently they are not exported to userspace. So, you can't inherit any quirks from the bus driver of the host. It is not too bad, I think. It would mean that the host driver will return -EOPNOTSUPP for transfers it cannot handle. Otherwise, if quirks were inherited, we could bail out sooner at guest level, but well... Does this help? Happy hacking, Wolfram
Attachment:
signature.asc
Description: PGP signature
