On 25-03-21, 17:16, Arnd Bergmann wrote:
On Wed, Mar 24, 2021 at 8:33 AM Viresh Kumar viresh.kumar@linaro.org wrote:
+static uint8_t vi2c_xfer(VuDev *dev, struct i2c_msg *msg) +{
- VuI2c *i2c = container_of(dev, VuI2c, dev.parent);
- struct i2c_rdwr_ioctl_data data;
- VI2cAdapter *adapter;
- adapter = vi2c_find_adapter(i2c, msg->addr);
- if (!adapter) {
g_printerr("Failed to find adapter for address: %x\n", msg->addr);return VIRTIO_I2C_MSG_ERR;- }
- data.nmsgs = 1;
- data.msgs = msg;
- if (ioctl(adapter->fd, I2C_RDWR, &data) < 0) {
g_printerr("Failed to transfer data to address %x : %d\n", msg->addr, errno);return VIRTIO_I2C_MSG_ERR;- }
As you found during testing, this doesn't work for host kernels that only implement the SMBUS protocol. Since most i2c clients only need simple register read/write operations, I think you should at least handle the common ones (and one two byte read/write) here to make it more useful.
I am thinking if that is what we really want to support, then shouldn't the i2c virtio spec be updated first to support SMBUS type transfers as well?
+static void vi2c_handle_ctrl(VuDev *dev, int qidx) +{
- VuVirtq *vq = vu_get_queue(dev, qidx);
- struct i2c_msg msg;
- struct virtio_i2c_out_hdr *out_hdr;
- struct virtio_i2c_in_hdr *in_hdr;
- bool fail_next = false;
- size_t len, in_hdr_len;
- for (;;) {
VuVirtqElement *elem;elem = vu_queue_pop(dev, vq, sizeof(VuVirtqElement));if (!elem) {break;}g_debug("%s: got queue (in %d, out %d)", __func__, elem->in_num,elem->out_num);/* Validate size of out header */if (elem->out_sg[0].iov_len != sizeof(*out_hdr)) {g_warning("%s: Invalid out hdr %zu : %zu\n", __func__,elem->out_sg[0].iov_len, sizeof(*out_hdr));continue;}out_hdr = elem->out_sg[0].iov_base;/* Bit 0 is reserved in virtio spec */msg.addr = out_hdr->addr >> 1;/* Read Operation */if (elem->out_num == 1 && elem->in_num == 2) {len = elem->in_sg[0].iov_len;if (!len) {g_warning("%s: Read buffer length can't be zero\n", __func__);continue;}It looks like you are not handling endianness conversion here. As far as I can tell, the protocol requires little-endian data, but the code might run on a big-endian CPU.
Jie Deng also pointed out the type differences, but actually handling them correctly is more important that describing them the right way.
Right, I missed that.