Not for the full duplex. As Paolo explained in those links.On 02-03-21, 10:21, Jie Deng wrote:On 2021/3/1 19:54, Viresh Kumar wrote: That's my original proposal. I used to mirror this interface with "struct i2c_msg". But the design philosophy of virtio TC is that VIRTIO devices are not specific to Linux so the specs design should avoid the limitations of the current Linux driver behavior.Right, I understand that.We had some discussion about this. You may check these links to learn the story. https://lists.oasis-open.org/archives/virtio-comment/202010/msg00016.html https://lists.oasis-open.org/archives/virtio-comment/202010/msg00033.html https://lists.oasis-open.org/archives/virtio-comment/202011/msg00025.htmlSo the thing is that we want to support full duplex mode, right ? How will that work protocol wise ? I mean how would we know if we are expecting both tx and rx buffers in a transfer ?
" This is when a write is followed by a read: the master starts off the transmission with a write, then sends a second START, then continues with a read from the same address. In theory there's no difference between one multi-segment transaction and many single-segment transactions _in a single-master scenario_. However, it is a plausible configuration to have multiple guests sharing an I2C host device as if they were multiple master.
So the spec should provide a way at least to support for transactions with 1 write and 1 read segment in one request to the same address.
"From the perspective of specification design, it hopes to provide more choices