Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg00008.html.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen <[email protected]>
Signed-off-by: Conghui Chen <[email protected]>
Signed-off-by: Jie Deng <[email protected]>
---
Changes v10 -> v11
- Remove vi->adap.class = I2C_CLASS_DEPRECATED.
- Use #ifdef CONFIG_PM_SLEEP to replace the "__maybe_unused".
- Remove "struct mutex lock" in "struct virtio_i2c".
- Support zero-length request.
- Remove unnecessary logs.
- Remove vi->adap.timeout = HZ / 10, just use the default value.
- Use BIT(0) to define VIRTIO_I2C_FLAGS_FAIL_NEXT.
- Add the virtio_device index to adapter's naming mechanism.
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 265 ++++++++++++++++++++++++++++++++++++++++
include/uapi/linux/virtio_i2c.h | 41 +++++++
include/uapi/linux/virtio_ids.h | 1 +
5 files changed, 321 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
create mode 100644 include/uapi/linux/virtio_i2c.h
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 10acece..e47616a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ select VIRTIO
+ help
+ If you say yes to this option, support will be included for the virtio
+ I2C adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 69e9963..9843756 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -147,4 +147,7 @@ obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
obj-$(CONFIG_I2C_FSI) += i2c-fsi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 0000000..97dda54
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * The Virtio I2C Specification:
+ * https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
+ *
+ * Copyright (c) 2021 Intel Corporation. All rights reserved.
+ */
+
+#include <linux/acpi.h>
+#include <linux/completion.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/virtio.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+#include <linux/virtio_i2c.h>
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct virtqueue *vq;
+};
+
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
+ * @buf: the buffer into which data is read, or from which it's written
+ * @in_hdr: the IN header of the virtio I2C message
+ */
+struct virtio_i2c_req {
+ struct virtio_i2c_out_hdr out_hdr ____cacheline_aligned;
+ uint8_t *buf ____cacheline_aligned;
+ struct virtio_i2c_in_hdr in_hdr ____cacheline_aligned;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(&vi->completion);
+}
+
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr)
+{
+ struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
+ int i, outcnt, incnt, err = 0;
+
+ for (i = 0; i < nr; i++) {
+ /*
+ * Only 7-bit mode supported for this moment. For the address format,
+ * Please check the Virtio I2C Specification.
+ */
+ reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
+
+ if (i != nr - 1)
+ reqs[i].out_hdr.flags = cpu_to_le32(VIRTIO_I2C_FLAGS_FAIL_NEXT);
+
+ outcnt = incnt = 0;
+ sg_init_one(&out_hdr, &reqs[i].out_hdr, sizeof(reqs[i].out_hdr));
+ sgs[outcnt++] = &out_hdr;
+
+ reqs[i].buf = i2c_get_dma_safe_msg_buf(&msgs[i], 1);
+ if (!reqs[i].buf)
+ break;
+
+ sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
+
+ if (msgs[i].flags & I2C_M_RD)
+ sgs[outcnt + incnt++] = &msg_buf;
+ else
+ sgs[outcnt++] = &msg_buf;
+
+ sg_init_one(&in_hdr, &reqs[i].in_hdr, sizeof(reqs[i].in_hdr));
+ sgs[outcnt + incnt++] = &in_hdr;
+
+ err = virtqueue_add_sgs(vq, sgs, outcnt, incnt, &reqs[i], GFP_KERNEL);
+ if (err < 0) {
+ i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], false);
+ break;
+ }
+ }
+
+ return i;
+}
+
+static int virtio_i2c_complete_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr,
+ bool timeout)
+{
+ struct virtio_i2c_req *req;
+ bool failed = timeout;
+ unsigned int len;
+ int i, j = 0;
+
+ for (i = 0; i < nr; i++) {
+ /* Detach the ith request from the vq */
+ req = virtqueue_get_buf(vq, &len);
+
+ /*
+ * Condition (req && req == &reqs[i]) should always meet since
+ * we have total nr requests in the vq.
+ */
+ if (!failed && (WARN_ON(!(req && req == &reqs[i])) ||
+ (req->in_hdr.status != VIRTIO_I2C_MSG_OK)))
+ failed = true;
+
+ i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], !failed);
+ if (!failed)
+ ++j;
+ }
+
+ return (timeout ? -ETIMEDOUT : j);
+}
+
+static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+{
+ struct virtio_i2c *vi = i2c_get_adapdata(adap);
+ struct virtqueue *vq = vi->vq;
+ struct virtio_i2c_req *reqs;
+ unsigned long time_left;
+ int ret, nr;
+
+ reqs = kcalloc(num, sizeof(*reqs), GFP_KERNEL);
+ if (!reqs)
+ return -ENOMEM;
+
+ ret = virtio_i2c_send_reqs(vq, reqs, msgs, num);
+ if (ret == 0)
+ goto err_free;
+
+ nr = ret;
+ reinit_completion(&vi->completion);
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(&vi->completion, adap->timeout);
+ if (!time_left)
+ dev_err(&adap->dev, "virtio i2c backend timeout.\n");
+
+ ret = virtio_i2c_complete_reqs(vq, reqs, msgs, nr, !time_left);
+
+err_free:
+ kfree(reqs);
+ return ret;
+}
+
+static void virtio_i2c_del_vqs(struct virtio_device *vdev)
+{
+ vdev->config->reset(vdev);
+ vdev->config->del_vqs(vdev);
+}
+
+static int virtio_i2c_setup_vqs(struct virtio_i2c *vi)
+{
+ struct virtio_device *vdev = vi->vdev;
+
+ vi->vq = virtio_find_single_vq(vdev, virtio_i2c_msg_done, "msg");
+ return PTR_ERR_OR_ZERO(vi->vq);
+}
+
+static u32 virtio_i2c_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static struct i2c_algorithm virtio_algorithm = {
+ .master_xfer = virtio_i2c_xfer,
+ .functionality = virtio_i2c_func,
+};
+
+static int virtio_i2c_probe(struct virtio_device *vdev)
+{
+ struct device *pdev = vdev->dev.parent;
+ struct virtio_i2c *vi;
+ int ret;
+
+ vi = devm_kzalloc(&vdev->dev, sizeof(*vi), GFP_KERNEL);
+ if (!vi)
+ return -ENOMEM;
+
+ vdev->priv = vi;
+ vi->vdev = vdev;
+
+ init_completion(&vi->completion);
+
+ ret = virtio_i2c_setup_vqs(vi);
+ if (ret)
+ return ret;
+
+ vi->adap.owner = THIS_MODULE;
+ snprintf(vi->adap.name, sizeof(vi->adap.name),
+ "i2c_virtio at virtio bus %d", vdev->index);
+ vi->adap.algo = &virtio_algorithm;
+ vi->adap.dev.parent = &vdev->dev;
+ i2c_set_adapdata(&vi->adap, vi);
+
+ /* Setup ACPI node for controlled devices which will be probed through ACPI */
+ ACPI_COMPANION_SET(&vi->adap.dev, ACPI_COMPANION(pdev));
+
+ ret = i2c_add_adapter(&vi->adap);
+ if (ret)
+ virtio_i2c_del_vqs(vdev);
+
+ return ret;
+}
+
+static void virtio_i2c_remove(struct virtio_device *vdev)
+{
+ struct virtio_i2c *vi = vdev->priv;
+
+ i2c_del_adapter(&vi->adap);
+ virtio_i2c_del_vqs(vdev);
+}
+
+static struct virtio_device_id id_table[] = {
+ { VIRTIO_ID_I2C_ADAPTER, VIRTIO_DEV_ANY_ID },
+ {}
+};
+MODULE_DEVICE_TABLE(virtio, id_table);
+
+#ifdef CONFIG_PM_SLEEP
+static int virtio_i2c_freeze(struct virtio_device *vdev)
+{
+ virtio_i2c_del_vqs(vdev);
+ return 0;
+}
+
+static int virtio_i2c_restore(struct virtio_device *vdev)
+{
+ return virtio_i2c_setup_vqs(vdev->priv);
+}
+#endif
+
+static struct virtio_driver virtio_i2c_driver = {
+ .id_table = id_table,
+ .probe = virtio_i2c_probe,
+ .remove = virtio_i2c_remove,
+ .driver = {
+ .name = "i2c_virtio",
+ },
+#ifdef CONFIG_PM_SLEEP
+ .freeze = virtio_i2c_freeze,
+ .restore = virtio_i2c_restore,
+#endif
+};
+module_virtio_driver(virtio_i2c_driver);
+
+MODULE_AUTHOR("Jie Deng <[email protected]>");
+MODULE_AUTHOR("Conghui Chen <[email protected]>");
+MODULE_DESCRIPTION("Virtio i2c bus driver");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/virtio_i2c.h b/include/uapi/linux/virtio_i2c.h
new file mode 100644
index 0000000..3cc1609
--- /dev/null
+++ b/include/uapi/linux/virtio_i2c.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later WITH Linux-syscall-note */
+/*
+ * Definitions for virtio I2C Adpter
+ *
+ * Copyright (c) 2021 Intel Corporation. All rights reserved.
+ */
+
+#ifndef _UAPI_LINUX_VIRTIO_I2C_H
+#define _UAPI_LINUX_VIRTIO_I2C_H
+
+#include <linux/types.h>
+#include <linux/bits.h>
+
+/* The bit 0 of the @virtio_i2c_out_hdr.@flags, used to group the requests */
+#define VIRTIO_I2C_FLAGS_FAIL_NEXT BIT(0)
+
+/**
+ * struct virtio_i2c_out_hdr - the virtio I2C message OUT header
+ * @addr: the controlled device address
+ * @padding: used to pad to full dword
+ * @flags: used for feature extensibility
+ */
+struct virtio_i2c_out_hdr {
+ __le16 addr;
+ __le16 padding;
+ __le32 flags;
+};
+
+/**
+ * struct virtio_i2c_in_hdr - the virtio I2C message IN header
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_in_hdr {
+ __u8 status;
+};
+
+/* The final status written by the device */
+#define VIRTIO_I2C_MSG_OK 0
+#define VIRTIO_I2C_MSG_ERR 1
+
+#endif /* _UAPI_LINUX_VIRTIO_I2C_H */
diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index 4fe842c..3b5f05a 100644
--- a/include/uapi/linux/virtio_ids.h
+++ b/include/uapi/linux/virtio_ids.h
@@ -55,6 +55,7 @@
#define VIRTIO_ID_FS 26 /* virtio filesystem */
#define VIRTIO_ID_PMEM 27 /* virtio pmem */
#define VIRTIO_ID_MAC80211_HWSIM 29 /* virtio mac80211-hwsim */
+#define VIRTIO_ID_I2C_ADAPTER 34 /* virtio i2c adapter */
#define VIRTIO_ID_BT 40 /* virtio bluetooth */
#endif /* _LINUX_VIRTIO_IDS_H */
--
2.7.4
On 01-07-21, 11:24, Jie Deng wrote:
> Changes v10 -> v11
> - Remove vi->adap.class = I2C_CLASS_DEPRECATED.
> - Use #ifdef CONFIG_PM_SLEEP to replace the "__maybe_unused".
> - Remove "struct mutex lock" in "struct virtio_i2c".
> - Support zero-length request.
> - Remove unnecessary logs.
> - Remove vi->adap.timeout = HZ / 10, just use the default value.
> - Use BIT(0) to define VIRTIO_I2C_FLAGS_FAIL_NEXT.
> - Add the virtio_device index to adapter's naming mechanism.
Thanks Jie.
I hope you are going to send a fix for specification as well (for the
zero-length request) ?
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
> + int i, outcnt, incnt, err = 0;
> +
> + for (i = 0; i < nr; i++) {
> + /*
> + * Only 7-bit mode supported for this moment. For the address format,
> + * Please check the Virtio I2C Specification.
> + */
> + reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
> +
> + if (i != nr - 1)
> + reqs[i].out_hdr.flags = cpu_to_le32(VIRTIO_I2C_FLAGS_FAIL_NEXT);
> +
> + outcnt = incnt = 0;
> + sg_init_one(&out_hdr, &reqs[i].out_hdr, sizeof(reqs[i].out_hdr));
> + sgs[outcnt++] = &out_hdr;
> +
> + reqs[i].buf = i2c_get_dma_safe_msg_buf(&msgs[i], 1);
> + if (!reqs[i].buf)
> + break;
> +
> + sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
The len can be zero here for zero-length transfers.
> +
> + if (msgs[i].flags & I2C_M_RD)
> + sgs[outcnt + incnt++] = &msg_buf;
> + else
> + sgs[outcnt++] = &msg_buf;
> +
> + sg_init_one(&in_hdr, &reqs[i].in_hdr, sizeof(reqs[i].in_hdr));
> + sgs[outcnt + incnt++] = &in_hdr;
Why are we still sending the msg_buf if the length is 0? Sending the
buffer makes sense if you have some data to send, but otherwise it is
just an extra sg element, which isn't required to be sent.
> +
> + err = virtqueue_add_sgs(vq, sgs, outcnt, incnt, &reqs[i], GFP_KERNEL);
> + if (err < 0) {
> + i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], false);
> + break;
> + }
> + }
> +
> + return i;
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?
> +#ifdef CONFIG_PM_SLEEP
> +static int virtio_i2c_freeze(struct virtio_device *vdev)
> +{
> + virtio_i2c_del_vqs(vdev);
> + return 0;
> +}
> +
> +static int virtio_i2c_restore(struct virtio_device *vdev)
> +{
> + return virtio_i2c_setup_vqs(vdev->priv);
> +}
> +#endif
> +
> +static struct virtio_driver virtio_i2c_driver = {
> + .id_table = id_table,
> + .probe = virtio_i2c_probe,
> + .remove = virtio_i2c_remove,
> + .driver = {
> + .name = "i2c_virtio",
> + },
> +#ifdef CONFIG_PM_SLEEP
You could avoid this pair of ifdef by creating dummy versions of below
routines for !CONFIG_PM_SLEEP case. Up to you.
> + .freeze = virtio_i2c_freeze,
> + .restore = virtio_i2c_restore,
> +#endif
> +};
--
viresh
On 2021/7/1 12:04, Viresh Kumar wrote:
> On 01-07-21, 11:24, Jie Deng wrote:
>> Changes v10 -> v11
>> - Remove vi->adap.class = I2C_CLASS_DEPRECATED.
>> - Use #ifdef CONFIG_PM_SLEEP to replace the "__maybe_unused".
>> - Remove "struct mutex lock" in "struct virtio_i2c".
>> - Support zero-length request.
>> - Remove unnecessary logs.
>> - Remove vi->adap.timeout = HZ / 10, just use the default value.
>> - Use BIT(0) to define VIRTIO_I2C_FLAGS_FAIL_NEXT.
>> - Add the virtio_device index to adapter's naming mechanism.
> Thanks Jie.
>
> I hope you are going to send a fix for specification as well (for the
> zero-length request) ?
Yes. I will send that fix once this patch get merged.
>
>> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
>> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
>> + struct virtio_i2c_req *reqs,
>> + struct i2c_msg *msgs, int nr)
>> +{
>> + struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
>> + int i, outcnt, incnt, err = 0;
>> +
>> + for (i = 0; i < nr; i++) {
>> + /*
>> + * Only 7-bit mode supported for this moment. For the address format,
>> + * Please check the Virtio I2C Specification.
>> + */
>> + reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
>> +
>> + if (i != nr - 1)
>> + reqs[i].out_hdr.flags = cpu_to_le32(VIRTIO_I2C_FLAGS_FAIL_NEXT);
>> +
>> + outcnt = incnt = 0;
>> + sg_init_one(&out_hdr, &reqs[i].out_hdr, sizeof(reqs[i].out_hdr));
>> + sgs[outcnt++] = &out_hdr;
>> +
>> + reqs[i].buf = i2c_get_dma_safe_msg_buf(&msgs[i], 1);
>> + if (!reqs[i].buf)
>> + break;
>> +
>> + sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
> The len can be zero here for zero-length transfers.
>
>> +
>> + if (msgs[i].flags & I2C_M_RD)
>> + sgs[outcnt + incnt++] = &msg_buf;
>> + else
>> + sgs[outcnt++] = &msg_buf;
>> +
>> + sg_init_one(&in_hdr, &reqs[i].in_hdr, sizeof(reqs[i].in_hdr));
>> + sgs[outcnt + incnt++] = &in_hdr;
> Why are we still sending the msg_buf if the length is 0? Sending the
> buffer makes sense if you have some data to send, but otherwise it is
> just an extra sg element, which isn't required to be sent.
I think a fixed number of sgs will make things easier to develop backend.
If you prefer to parse the number of descriptors instead of using the
msg length to
distinguish the zero-length request from other requests, I'm OK to set a
limit.
if (!msgs[i].len) {
sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
if (msgs[i].flags & I2C_M_RD)
sgs[outcnt + incnt++] = &msg_buf;
else
sgs[outcnt++] = &msg_buf;
}
>
>> +#ifdef CONFIG_PM_SLEEP
>> +static int virtio_i2c_freeze(struct virtio_device *vdev)
>> +{
>> + virtio_i2c_del_vqs(vdev);
>> + return 0;
>> +}
>> +
>> +static int virtio_i2c_restore(struct virtio_device *vdev)
>> +{
>> + return virtio_i2c_setup_vqs(vdev->priv);
>> +}
>> +#endif
>> +
>> +static struct virtio_driver virtio_i2c_driver = {
>> + .id_table = id_table,
>> + .probe = virtio_i2c_probe,
>> + .remove = virtio_i2c_remove,
>> + .driver = {
>> + .name = "i2c_virtio",
>> + },
>> +#ifdef CONFIG_PM_SLEEP
> You could avoid this pair of ifdef by creating dummy versions of below
> routines for !CONFIG_PM_SLEEP case. Up to you.
Thank you. I'd like to keep the same.
On 01-07-21, 14:10, Jie Deng wrote:
> I think a fixed number of sgs will make things easier to develop backend.
Yeah, but it looks awkward to send a message buffer which isn't used
at all. From protocol's point of view, it just looks wrong/buggy.
The backend can just look at the number of elements received, they
can either be 2 (in case of zero-length) transfer, or 3 (for
read/write) and any other number is invalid.
> If you prefer to parse the number of descriptors instead of using the msg
> length to
>
> distinguish the zero-length request from other requests, I'm OK to set a
> limit.
My concern is more about the specification here first.
> if (!msgs[i].len) {
> ??? sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
>
> ??? if (msgs[i].flags & I2C_M_RD)
> ??? ??? sgs[outcnt + incnt++] = &msg_buf;
> ??? else
> ??? ??? sgs[outcnt++] = &msg_buf;
> }
> > > +#ifdef CONFIG_PM_SLEEP
> > You could avoid this pair of ifdef by creating dummy versions of below
> > routines for !CONFIG_PM_SLEEP case. Up to you.
>
>
> Thank you. I'd like to keep the same.
Sure.
--
viresh
Hi Jie,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on linux/master linus/master v5.13 next-20210630]
[cannot apply to vhost/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: x86_64-randconfig-r012-20210630 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project e7e71e9454ed76c1b3d8140170b5333c28bef1be)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# https://github.com/0day-ci/linux/commit/e8dedd2a8577148d7655d0affe35adf34efbbf15
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
git checkout e8dedd2a8577148d7655d0affe35adf34efbbf15
# save the attached .config to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>):
In file included from <built-in>:1:
>> ./usr/include/linux/virtio_i2c.h:12:10: fatal error: 'linux/bits.h' file not found
#include <linux/bits.h>
^~~~~~~~~~~~~~
1 error generated.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
Hi Jie,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on linux/master linus/master v5.13 next-20210630]
[cannot apply to vhost/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: i386-randconfig-c021-20210630 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/e8dedd2a8577148d7655d0affe35adf34efbbf15
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
git checkout e8dedd2a8577148d7655d0affe35adf34efbbf15
# save the attached .config to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>):
In file included from <command-line>:32:
>> ./usr/include/linux/virtio_i2c.h:12:10: fatal error: linux/bits.h: No such file or directory
12 | #include <linux/bits.h>
| ^~~~~~~~~~~~~~
compilation terminated.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
On Thu, Jul 01, 2021 at 11:24:46AM +0800, Jie Deng wrote:
> Add an I2C bus driver for virtio para-virtualization.
>
> The controller can be emulated by the backend driver in
> any device model software by following the virtio protocol.
>
> The device specification can be found on
> https://lists.oasis-open.org/archives/virtio-comment/202101/msg00008.html.
>
> By following the specification, people may implement different
> backend drivers to emulate different controllers according to
> their needs.
> - Use #ifdef CONFIG_PM_SLEEP to replace the "__maybe_unused".
Why is that?
--
With Best Regards,
Andy Shevchenko
> 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.
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.
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.
On 2021/7/1 18:45, Andy Shevchenko wrote:
> On Thu, Jul 01, 2021 at 11:24:46AM +0800, Jie Deng wrote:
>> Add an I2C bus driver for virtio para-virtualization.
>>
>> The controller can be emulated by the backend driver in
>> any device model software by following the virtio protocol.
>>
>> The device specification can be found on
>> https://lists.oasis-open.org/archives/virtio-comment/202101/msg00008.html.
>>
>> By following the specification, people may implement different
>> backend drivers to emulate different controllers according to
>> their needs.
>> - Use #ifdef CONFIG_PM_SLEEP to replace the "__maybe_unused".
> Why is that?
Please refer to https://lkml.org/lkml/2021/3/23/285.
On 2021/7/1 18:00, kernel test robot wrote:
> Hi Jie,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on wsa/i2c/for-next]
> [also build test ERROR on linux/master linus/master v5.13 next-20210630]
> [cannot apply to vhost/linux-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
> base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
> config: i386-randconfig-c021-20210630 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce (this is a W=1 build):
> # https://github.com/0day-ci/linux/commit/e8dedd2a8577148d7655d0affe35adf34efbbf15
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
> git checkout e8dedd2a8577148d7655d0affe35adf34efbbf15
> # save the attached .config to linux build tree
> mkdir build_dir
> make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <[email protected]>
>
> All errors (new ones prefixed by >>):
>
> In file included from <command-line>:32:
>>> ./usr/include/linux/virtio_i2c.h:12:10: fatal error: linux/bits.h: No such file or directory
> 12 | #include <linux/bits.h>
> | ^~~~~~~~~~~~~~
> compilation terminated.
I didn't see this error. Why did you say no such file? Anything wrong ?
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/tree/include/linux/bits.h
Thank you !
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/[email protected]
On 2021/7/1 14:18, Viresh Kumar wrote:
> On 01-07-21, 14:10, Jie Deng wrote:
>> I think a fixed number of sgs will make things easier to develop backend.
> Yeah, but it looks awkward to send a message buffer which isn't used
> at all. From protocol's point of view, it just looks wrong/buggy.
>
> The backend can just look at the number of elements received, they
> can either be 2 (in case of zero-length) transfer, or 3 (for
> read/write) and any other number is invalid.
>
OK. Let's add the following two lines to make sure that msg_buf is only
sent when the msgs len is not zero. And backend judges whether it is
a zero-length request by checking the number of elements received.
+ if (msgs[i].len) {
reqs[i].buf = i2c_get_dma_safe_msg_buf(&msgs[i], 1);
if (!reqs[i].buf)
break;
sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
if (msgs[i].flags & I2C_M_RD)
sgs[outcnt + incnt++] = &msg_buf;
else
sgs[outcnt++] = &msg_buf;
+}
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
On 02-07-21, 11:36, Jie Deng wrote:
> OK. Let's add the following two lines to make sure that msg_buf is only
> sent when the msgs len is not zero. And backend judges whether it is
> a zero-length request by checking the number of elements received.
>
> ?+ if (msgs[i].len) {
> ?????????? reqs[i].buf = i2c_get_dma_safe_msg_buf(&msgs[i], 1);
> ?????????? if (!reqs[i].buf)
> ?????????????????? break;
>
> ????????? sg_init_one(&msg_buf, reqs[i].buf, msgs[i].len);
>
> ????????? if (msgs[i].flags & I2C_M_RD)
> ????????????????? sgs[outcnt + incnt++] = &msg_buf;
> ????????? else
> ????????????????? sgs[outcnt++] = &msg_buf;
> +}
Perfect. Thanks.
--
viresh
> > > 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.
The client driver handles the case. I'd assume most will bail out of the
calling function and at some higher level it will be retried.
> > 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?
Yes.
On 7/2/21 11:12 AM, Jie Deng wrote:
>
> On 2021/7/1 18:00, kernel test robot wrote:
>> Hi Jie,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on wsa/i2c/for-next]
>> [also build test ERROR on linux/master linus/master v5.13 next-20210630]
>> [cannot apply to vhost/linux-next]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
>> i2c/for-next
>> config: i386-randconfig-c021-20210630 (attached as .config)
>> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>> reproduce (this is a W=1 build):
>> #
>> https://github.com/0day-ci/linux/commit/e8dedd2a8577148d7655d0affe35adf34efbbf15
>> git remote add linux-review https://github.com/0day-ci/linux
>> git fetch --no-tags linux-review
>> Jie-Deng/i2c-virtio-add-a-virtio-i2c-frontend-driver/20210701-112619
>> git checkout e8dedd2a8577148d7655d0affe35adf34efbbf15
>> # save the attached .config to linux build tree
>> mkdir build_dir
>> make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <[email protected]>
>>
>> All errors (new ones prefixed by >>):
>>
>> In file included from <command-line>:32:
>>>> ./usr/include/linux/virtio_i2c.h:12:10: fatal error: linux/bits.h:
>>>> No such file or directory
>> 12 | #include <linux/bits.h>
>> | ^~~~~~~~~~~~~~
>> compilation terminated.
>
>
> I didn't see this error. Why did you say no such file? Anything wrong ?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/tree/include/linux/bits.h
>
>
> Thank you !
Hi Jie,
The problem is reproducible, I guess it's due to bits.h not in
include/uapi/linux.
Best Regards,
Rong Chen
On 2021/7/2 12:55, Viresh Kumar wrote:
> 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.
>
This is not efficient. If adding the ith request to the queue fails, we
can still send
the requests before it. We don't need to know if it fails here (adding
to the queue)
or there (later in the host). The "master_xfer" just need to return
final number of
messages successfully processed.
On 02-07-21, 14:52, Jie Deng wrote:
> This is not efficient. If adding the ith request to the queue fails, we can
> still send
>
> the requests before it.
Not really. Normally the requests which are sent together by clients, are linked
together, like a state machine. So if the first one is sent, but not the second
one, then there is not going to be any meaningful result of that.
The i2c core doesn't club requests together from different clients in a single
i2c_transfer() call. So you must assume i2c_transfer(), irrespective of the
number of underlying messages in it, as atomic. If you fail, the client is going
to retry everything again or assume it failed completely.
> We don't need to know if it fails here (adding to
> the queue)
>
> or there (later in the host). The "master_xfer" just need to return final
> number of
>
> messages successfully processed.
No, that isn't going to help and it is rather inefficient, trying to send
transfer when we already know part of it failed.
--
viresh
> The i2c core doesn't club requests together from different clients in a single
> i2c_transfer() call. So you must assume i2c_transfer(), irrespective of the
> number of underlying messages in it, as atomic. If you fail, the client is going
> to retry everything again or assume it failed completely.
Ack.
On 2021/7/2 14:56, Viresh Kumar wrote:
> On 02-07-21, 14:52, Jie Deng wrote:
>> This is not efficient. If adding the ith request to the queue fails, we can
>> still send
>>
>> the requests before it.
> Not really. Normally the requests which are sent together by clients, are linked
> together, like a state machine. So if the first one is sent, but not the second
> one, then there is not going to be any meaningful result of that.
>
> The i2c core doesn't club requests together from different clients in a single
> i2c_transfer() call. So you must assume i2c_transfer(), irrespective of the
> number of underlying messages in it, as atomic. If you fail, the client is going
> to retry everything again or assume it failed completely.
Then what is the need to design this interface as "return the number of
messages successfully
processed, or a negative value on error". Just return success or fail is
enough.
Here, we didn't break the contract with the interface "master_xfer", so
if there is a problem then
the contract may be the problem.
On 02-07-21, 15:15, Jie Deng wrote:
> Then what is the need to design this interface as "return the number of
> messages successfully
> processed, or a negative value on error". Just return success or fail is
> enough.
Right, that isn't clear to me as well. And so I asked Wolfram this yesterday.
I think it is left for the clients handle this, i.e. what they want to do with
it if something fails in between.
> Here, we didn't break the contract with the interface "master_xfer", so if
> there is a problem then
> the contract may be the problem.
So in your case here, either you should return 0 or nr (the number of transfers
requested) and anything else can only be sent if the host reports partial
failures.
Also, since this driver is pretty much independent of everything else, and won't
break anything in the kernel, there is still a good chance of getting it merged
for 5.14-rc1/2.. So it would be better if you resend the next version as soon as
possible :)
--
viresh
On Fri, Jul 02, 2021 at 12:51:27PM +0530, Viresh Kumar wrote:
> On 02-07-21, 15:15, Jie Deng wrote:
> > Then what is the need to design this interface as "return the number of
> > messages successfully
> > processed, or a negative value on error". Just return success or fail is
> > enough.
Let me quote a comment from the I2C core which is there since 2008:
/* REVISIT the fault reporting model here is weak:
*
* - When we get an error after receiving N bytes from a slave,
* there is no way to report "N".
*
* - When we get a NAK after transmitting N bytes to a slave,
* there is no way to report "N" ... or to let the master
* continue executing the rest of this combined message, if
* that's the appropriate response.
*
* - When for example "num" is two and we successfully complete
* the first message but get an error part way through the
* second, it's unclear whether that should be reported as
* one (discarding status on the second message) or errno
* (discarding status on the first one).
*/
> for 5.14-rc1/2.. So it would be better if you resend the next version as soon as
> possible :)
I won't be around for the next two weeks after today.