Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/14 下午4:37, Jie Deng wrote:
On 2020/10/13 16:00, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left =
wait_for_completion_timeout(>completion, adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x
timeout.\n", i, msgs[i].addr);
+ break;
+ }
You don't set error number here. Is this intended?
And using a timeout here is not good, and if the request is
finished just after the timeout, in the next xfer you may hit the
following check.
It's better to use either interrupt here.
Could you check the I2C drivers in the kernel ? The
"wait_for_completion_timeout" mechanism
is commonly used by I2C bus drivers in their
i2c_algorithm.master_xfer.
There's a major difference between virtio-i2c and other drivers. In
the case of virtio, the device could be a software device emulated
by a remote process. This means the timeout might not be rare.
I don't see how timeout is properly handled in this patch (e.g did
you notice that you don't set any error when timeout? or is this
intended?)
The backend software may operate the physical device. The timeout
depends on how the backend is designed.
Here if the timeout happens, it will return the actual number of
messages successfully processed to the I2C core.
Let the I2C core decides how to do next.
So let's consider the following case:
1) driver:virtio_i2c_add_msg(msgA)
2) driver:timeout, and return to I2C core
3) driver:virtio_i2c_add_msg(msgB)
4) device: complete msgA
5) driver: virtqueue_get_buf() returns msgA, since the token is
always vi->vmsg, the driver may think msgB has been completed.
If this case does happen, it is exactly a case that the condition
"((!vmsg) || (vmsg != >vmsg))" are met.
I may miss something, but you always use vi->vmsg as token so vmsg is
equal to >vmsg here
Currently, the timeout value is hard-coded in the driver. Generally
speaking, timeout rarely happens.
Well, it's better to no have such assumption consider the device could
be a emulated one.
It can also be designed as a device configuration if needed.
In any case, the timeout should be handled correctly regardless of its
frequency.
Thanks.
Thanks.
+
+ vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq,
);
+ /* vmsg should point to the same address with >vmsg */
+ if ((!vmsg) || (vmsg != >vmsg)) {
+ dev_err(>dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, msgs[i].addr);
+ break;
+ }
So I think we can remove this check. Consider only one descriptor
will be used at most, unless there's a bug in the device (and no
other driver to the similar check), we should not hit this.
Btw, as I replied in the previous version, the device should be
cacpable of dealing of a batch of requests through the virtqueue,
otherwise it's meaningless to use a queue here.
We should not assume there is no bug in the device. I don't think
we can remove this check if we want our code to be robust.
Can you tell when at which case you may hit !vmsg or vmsg != vi->vmsg?
Normally, it won't hit here. But the API "virtqueue_get_buf" tells me
"It *may *return NULL or the "data" token handed to virtqueue_add_*()."
Note that we had the following check already in
virtqueue_get_buf_ctx(), so the the virtio core had already have the
ability to figure out the wrong head.
if (unlikely(id >= vq->packed.vring.num)) {
BAD_RING(vq, "id %u out of range\n", id);
return NULL;
}
if (unlikely(!vq->packed.desc_state[id].data)) {
BAD_RING(vq, "id %u is not a head!\n", id);
return NULL;
}
And when it returns a NULL, it's not necessarily an error of the
device, it might just require more time to finish the processing.
That's why we just returned the actual number of messages successfully
processed in this case,
and let the I2C core to try one more time.
Actually we have no idea if this is a device error or not. Try one
more time can also fail if it is a backend error.
Of course, there is another option. We can return error for timeout,
no matter what reason.
Thanks.
From the perspective of a caller, I just don't care when it happens.
To make the code robust, what I care about is what I should do if
this is not our case
since the doc says it*may *happen.
If you insist on removing this check, I will remove "vmsg !=
vi->vmsg" and keep the check for !vmsg.
As Dan reported in v2, we should at least check here for NULL.
Thanks.
As I said, currently, we are using the virtqueue to send the msg
one by one to the backend. The mechanism is described in the spec.
Which part of the spec describes such "one by one" mechanism? If
there is one, I'd happily give a NACK since it doesn't require a
queue to work which is conflict with the concept of the virtqueue.
What's the concept of the virtqueue ? Why do you want to restrict
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/13 16:00, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n",
i, msgs[i].addr);
+ break;
+ }
You don't set error number here. Is this intended?
And using a timeout here is not good, and if the request is
finished just after the timeout, in the next xfer you may hit the
following check.
It's better to use either interrupt here.
Could you check the I2C drivers in the kernel ? The
"wait_for_completion_timeout" mechanism
is commonly used by I2C bus drivers in their
i2c_algorithm.master_xfer.
There's a major difference between virtio-i2c and other drivers. In
the case of virtio, the device could be a software device emulated
by a remote process. This means the timeout might not be rare.
I don't see how timeout is properly handled in this patch (e.g did
you notice that you don't set any error when timeout? or is this
intended?)
The backend software may operate the physical device. The timeout
depends on how the backend is designed.
Here if the timeout happens, it will return the actual number of
messages successfully processed to the I2C core.
Let the I2C core decides how to do next.
So let's consider the following case:
1) driver:virtio_i2c_add_msg(msgA)
2) driver:timeout, and return to I2C core
3) driver:virtio_i2c_add_msg(msgB)
4) device: complete msgA
5) driver: virtqueue_get_buf() returns msgA, since the token is always
vi->vmsg, the driver may think msgB has been completed.
If this case does happen, it is exactly a case that the condition
"((!vmsg) || (vmsg != >vmsg))" are met.
Currently, the timeout value is hard-coded in the driver. Generally
speaking, timeout rarely happens.
It can also be designed as a device configuration if needed.
Thanks.
Thanks.
+
+ vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq,
);
+ /* vmsg should point to the same address with >vmsg */
+ if ((!vmsg) || (vmsg != >vmsg)) {
+ dev_err(>dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, msgs[i].addr);
+ break;
+ }
So I think we can remove this check. Consider only one descriptor
will be used at most, unless there's a bug in the device (and no
other driver to the similar check), we should not hit this.
Btw, as I replied in the previous version, the device should be
cacpable of dealing of a batch of requests through the virtqueue,
otherwise it's meaningless to use a queue here.
We should not assume there is no bug in the device. I don't think
we can remove this check if we want our code to be robust.
Can you tell when at which case you may hit !vmsg or vmsg != vi->vmsg?
Normally, it won't hit here. But the API "virtqueue_get_buf" tells me
"It *may *return NULL or the "data" token handed to virtqueue_add_*()."
Note that we had the following check already in
virtqueue_get_buf_ctx(), so the the virtio core had already have the
ability to figure out the wrong head.
if (unlikely(id >= vq->packed.vring.num)) {
BAD_RING(vq, "id %u out of range\n", id);
return NULL;
}
if (unlikely(!vq->packed.desc_state[id].data)) {
BAD_RING(vq, "id %u is not a head!\n", id);
return NULL;
}
And when it returns a NULL, it's not necessarily an error of the
device, it might just require more time to finish the processing.
That's why we just returned the actual number of messages successfully
processed in this case,
and let the I2C core to try one more time.
Actually we have no idea if this is a device error or not. Try one more
time can also fail if it is a backend error.
Of course, there is another option. We can return error for timeout, no
matter what reason.
Thanks.
From the perspective of a caller, I just don't care when it happens.
To make the code robust, what I care about is what I should do if
this is not our case
since the doc says it*may *happen.
If you insist on removing this check, I will remove "vmsg !=
vi->vmsg" and keep the check for !vmsg.
As Dan reported in v2, we should at least check here for NULL.
Thanks.
As I said, currently, we are using the virtqueue to send the msg
one by one to the backend. The mechanism is described in the spec.
Which part of the spec describes such "one by one" mechanism? If
there is one, I'd happily give a NACK since it doesn't require a
queue to work which is conflict with the concept of the virtqueue.
What's the concept of the virtqueue ? Why do you want to restrict
how users use virtqueue ?
So I think there's some misunderstanding here. The point is not to
restrict how to use virtqueue.
What I meant is:
- we should not invent a device with a virtqueue that can only accept
one buffer at a time
- I don't see any mechanism like "one by one" described in the spec,
so it's ok but
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/13 下午3:16, Jie Deng wrote:
On 2020/10/12 11:43, Jason Wang wrote:
On 2020/10/12 上午10:45, Jie Deng wrote:
On 2020/10/10 11:14, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n",
i, msgs[i].addr);
+ break;
+ }
You don't set error number here. Is this intended?
And using a timeout here is not good, and if the request is
finished just after the timeout, in the next xfer you may hit the
following check.
It's better to use either interrupt here.
Could you check the I2C drivers in the kernel ? The
"wait_for_completion_timeout" mechanism
is commonly used by I2C bus drivers in their i2c_algorithm.master_xfer.
There's a major difference between virtio-i2c and other drivers. In
the case of virtio, the device could be a software device emulated by
a remote process. This means the timeout might not be rare.
I don't see how timeout is properly handled in this patch (e.g did
you notice that you don't set any error when timeout? or is this
intended?)
The backend software may operate the physical device. The timeout
depends on how the backend is designed.
Here if the timeout happens, it will return the actual number of
messages successfully processed to the I2C core.
Let the I2C core decides how to do next.
So let's consider the following case:
1) driver:virtio_i2c_add_msg(msgA)
2) driver:timeout, and return to I2C core
3) driver:virtio_i2c_add_msg(msgB)
4) device: complete msgA
5) driver: virtqueue_get_buf() returns msgA, since the token is always
vi->vmsg, the driver may think msgB has been completed.
Thanks.
+
+ vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq, );
+ /* vmsg should point to the same address with >vmsg */
+ if ((!vmsg) || (vmsg != >vmsg)) {
+ dev_err(>dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, msgs[i].addr);
+ break;
+ }
So I think we can remove this check. Consider only one descriptor
will be used at most, unless there's a bug in the device (and no
other driver to the similar check), we should not hit this.
Btw, as I replied in the previous version, the device should be
cacpable of dealing of a batch of requests through the virtqueue,
otherwise it's meaningless to use a queue here.
We should not assume there is no bug in the device. I don't think we
can remove this check if we want our code to be robust.
Can you tell when at which case you may hit !vmsg or vmsg != vi->vmsg?
Normally, it won't hit here. But the API "virtqueue_get_buf" tells me
"It *may *return NULL or the "data" token handed to virtqueue_add_*()."
Note that we had the following check already in virtqueue_get_buf_ctx(),
so the the virtio core had already have the ability to figure out the
wrong head.
if (unlikely(id >= vq->packed.vring.num)) {
BAD_RING(vq, "id %u out of range\n", id);
return NULL;
}
if (unlikely(!vq->packed.desc_state[id].data)) {
BAD_RING(vq, "id %u is not a head!\n", id);
return NULL;
}
And when it returns a NULL, it's not necessarily an error of the device,
it might just require more time to finish the processing.
From the perspective of a caller, I just don't care when it happens.
To make the code robust, what I care about is what I should do if this
is not our case
since the doc says it*may *happen.
If you insist on removing this check, I will remove "vmsg != vi->vmsg"
and keep the check for !vmsg.
As Dan reported in v2, we should at least check here for NULL.
Thanks.
As I said, currently, we are using the virtqueue to send the msg one
by one to the backend. The mechanism is described in the spec.
Which part of the spec describes such "one by one" mechanism? If
there is one, I'd happily give a NACK since it doesn't require a
queue to work which is conflict with the concept of the virtqueue.
What's the concept of the virtqueue ? Why do you want to restrict how
users use virtqueue ?
So I think there's some misunderstanding here. The point is not to
restrict how to use virtqueue.
What I meant is:
- we should not invent a device with a virtqueue that can only accept
one buffer at a time
- I don't see any mechanism like "one by one" described in the spec, so
it's ok but if it'd happen to have, I will NACK
It's like you provide a water glass to user. The user can fill a full
glass of water and drinks once or
fill half a glass of water and drink twice. It is a user behavior and
should not be restricted by
the glass provider.
That's my point as well, we should not describe the "once" behavior in
the spec.
Thanks.
Thanks.
+
+
+#ifndef _UAPI_LINUX_VIRTIO_I2C_H
+#define _UAPI_LINUX_VIRTIO_I2C_H
+
+#include
+#include
+#include
+
+/**
+ * struct virtio_i2c_hdr - the
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/12 11:43, Jason Wang wrote:
On 2020/10/12 上午10:45, Jie Deng wrote:
On 2020/10/10 11:14, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n",
i, msgs[i].addr);
+ break;
+ }
You don't set error number here. Is this intended?
And using a timeout here is not good, and if the request is finished
just after the timeout, in the next xfer you may hit the following
check.
It's better to use either interrupt here.
Could you check the I2C drivers in the kernel ? The
"wait_for_completion_timeout" mechanism
is commonly used by I2C bus drivers in their i2c_algorithm.master_xfer.
There's a major difference between virtio-i2c and other drivers. In
the case of virtio, the device could be a software device emulated by
a remote process. This means the timeout might not be rare.
I don't see how timeout is properly handled in this patch (e.g did you
notice that you don't set any error when timeout? or is this intended?)
The backend software may operate the physical device. The timeout
depends on how the backend is designed.
Here if the timeout happens, it will return the actual number of
messages successfully processed to the I2C core.
Let the I2C core decides how to do next.
Thanks.
+
+ vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq, );
+ /* vmsg should point to the same address with >vmsg */
+ if ((!vmsg) || (vmsg != >vmsg)) {
+ dev_err(>dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, msgs[i].addr);
+ break;
+ }
So I think we can remove this check. Consider only one descriptor
will be used at most, unless there's a bug in the device (and no
other driver to the similar check), we should not hit this.
Btw, as I replied in the previous version, the device should be
cacpable of dealing of a batch of requests through the virtqueue,
otherwise it's meaningless to use a queue here.
We should not assume there is no bug in the device. I don't think we
can remove this check if we want our code to be robust.
Can you tell when at which case you may hit !vmsg or vmsg != vi->vmsg?
Normally, it won't hit here. But the API "virtqueue_get_buf" tells me
"It *may *return NULL or the "data" token handed to virtqueue_add_*()."
From the perspective of a caller, I just don't care when it happens.
To make the code robust, what I care about is what I should do if this
is not our case
since the doc says it*may *happen.
If you insist on removing this check, I will remove "vmsg != vi->vmsg"
and keep the check for !vmsg.
As Dan reported in v2, we should at least check here for NULL.
Thanks.
As I said, currently, we are using the virtqueue to send the msg one
by one to the backend. The mechanism is described in the spec.
Which part of the spec describes such "one by one" mechanism? If there
is one, I'd happily give a NACK since it doesn't require a queue to
work which is conflict with the concept of the virtqueue.
What's the concept of the virtqueue ? Why do you want to restrict how
users use virtqueue ?
It's like you provide a water glass to user. The user can fill a full
glass of water and drinks once or
fill half a glass of water and drink twice. It is a user behavior and
should not be restricted by
the glass provider.
Thanks.
Thanks.
+
+
+#ifndef _UAPI_LINUX_VIRTIO_I2C_H
+#define _UAPI_LINUX_VIRTIO_I2C_H
+
+#include
+#include
+#include
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __le16 addr;
+ __le16 flags;
+ __le16 len;
+};
I'm afraid this is not complete. E.g the status is missed.
I suspect what virtio-scsi use is better. Which split the in from
the out instead of reusing the same buffer. And it can ease the uAPI
header export.
Thanks
I think following definition in uAPI for the status is enough.
There is no need to provide a "u8" status in the structure.
/* The final status written by the device */
#define VIRTIO_I2C_MSG_OK 0
#define VIRTIO_I2C_MSG_ERR 1
You can see an example in virtio_blk.
In the spec:
struct virtio_blk_req {
le32 type;
le32 reserved;
le64 sector;
u8 data[];
u8 status;
};
In virtio_blk.h, there is only following definitions.
#define VIRTIO_BLK_S_OK 0
#define VIRTIO_BLK_S_IOERR 1
#define VIRTIO_BLK_S_UNSUPP 2
virtio-blk is a bad example, it's just too late to fix. For any new
introduced uAPI it should be a complete one.
Thanks
I checked a relatively new device "virtio_fs".
I found following definition in spec but not in uAPI also.
struct virtio_fs_req {
// Device -readable part
struct fuse_in_header in;
u8 datain[];
// Device -writable part
struct
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/12 上午10:45, Jie Deng wrote:
On 2020/10/10 11:14, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n", i,
msgs[i].addr);
+ break;
+ }
You don't set error number here. Is this intended?
And using a timeout here is not good, and if the request is finished
just after the timeout, in the next xfer you may hit the following
check.
It's better to use either interrupt here.
Could you check the I2C drivers in the kernel ? The
"wait_for_completion_timeout" mechanism
is commonly used by I2C bus drivers in their i2c_algorithm.master_xfer.
There's a major difference between virtio-i2c and other drivers. In the
case of virtio, the device could be a software device emulated by a
remote process. This means the timeout might not be rare.
I don't see how timeout is properly handled in this patch (e.g did you
notice that you don't set any error when timeout? or is this intended?)
+
+ vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq, );
+ /* vmsg should point to the same address with >vmsg */
+ if ((!vmsg) || (vmsg != >vmsg)) {
+ dev_err(>dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, msgs[i].addr);
+ break;
+ }
So I think we can remove this check. Consider only one descriptor
will be used at most, unless there's a bug in the device (and no
other driver to the similar check), we should not hit this.
Btw, as I replied in the previous version, the device should be
cacpable of dealing of a batch of requests through the virtqueue,
otherwise it's meaningless to use a queue here.
We should not assume there is no bug in the device. I don't think we
can remove this check if we want our code to be robust.
Can you tell when at which case you may hit !vmsg or vmsg != vi->vmsg?
As I said, currently, we are using the virtqueue to send the msg one
by one to the backend. The mechanism is described in the spec.
Which part of the spec describes such "one by one" mechanism? If there
is one, I'd happily give a NACK since it doesn't require a queue to work
which is conflict with the concept of the virtqueue.
Thanks.
+
+
+#ifndef _UAPI_LINUX_VIRTIO_I2C_H
+#define _UAPI_LINUX_VIRTIO_I2C_H
+
+#include
+#include
+#include
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __le16 addr;
+ __le16 flags;
+ __le16 len;
+};
I'm afraid this is not complete. E.g the status is missed.
I suspect what virtio-scsi use is better. Which split the in from the
out instead of reusing the same buffer. And it can ease the uAPI
header export.
Thanks
I think following definition in uAPI for the status is enough.
There is no need to provide a "u8" status in the structure.
/* The final status written by the device */
#define VIRTIO_I2C_MSG_OK 0
#define VIRTIO_I2C_MSG_ERR 1
You can see an example in virtio_blk.
In the spec:
struct virtio_blk_req {
le32 type;
le32 reserved;
le64 sector;
u8 data[];
u8 status;
};
In virtio_blk.h, there is only following definitions.
#define VIRTIO_BLK_S_OK 0
#define VIRTIO_BLK_S_IOERR 1
#define VIRTIO_BLK_S_UNSUPP 2
virtio-blk is a bad example, it's just too late to fix. For any new
introduced uAPI it should be a complete one.
Thanks
Thanks.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/8 22:01, Wolfram Sang wrote: Hi, some super high level questions: different controllers according to their needs. A backend example can be found in the device model of the open source project ACRN. For more information, please refer to https://projectacrn.org. Could you provide a link directly to the backend, please? Sure. Here is the link. https://raw.githubusercontent.com/projectacrn/acrn-hypervisor/master/devicemodel/hw/pci/virtio/virtio_i2c.c The device ID request: https://github.com/oasis-tcs/virtio-spec/issues/85 Shall we wait for this to be approved? Or will it get only approved once the driver here is upstream? That's what I want to know also. So hi Michael, what's the upstream flow for this patch ? Thanks. + 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. That means stuff like "limiting which devices on a given bus can be accessed" will be handled by the backends, or? What kind of testing has been done with this on which setup? Thanks and happy hacking, Wolfram Yes, you can configure what devices can be seen by the guest. This provides a way to flexibly organize and manage I2C slave devices from the guest. We tested it on Intel APL MRB. There are some docs for you reference. https://projectacrn.github.io/latest/developer-guides/hld/virtio-i2c.html?highlight=i2c Regards. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/10/10 11:14, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n", i,
msgs[i].addr);
+ break;
+ }
You don't set error number here. Is this intended?
And using a timeout here is not good, and if the request is finished
just after the timeout, in the next xfer you may hit the following check.
It's better to use either interrupt here.
Could you check the I2C drivers in the kernel ? The
"wait_for_completion_timeout" mechanism
is commonly used by I2C bus drivers in their i2c_algorithm.master_xfer.
+
+ vmsg = (struct virtio_i2c_msg *)virtqueue_get_buf(vq, );
+ /* vmsg should point to the same address with >vmsg */
+ if ((!vmsg) || (vmsg != >vmsg)) {
+ dev_err(>dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, msgs[i].addr);
+ break;
+ }
So I think we can remove this check. Consider only one descriptor will
be used at most, unless there's a bug in the device (and no other
driver to the similar check), we should not hit this.
Btw, as I replied in the previous version, the device should be
cacpable of dealing of a batch of requests through the virtqueue,
otherwise it's meaningless to use a queue here.
We should not assume there is no bug in the device. I don't think we can
remove this check if we want our code to be robust.
As I said, currently, we are using the virtqueue to send the msg one by
one to the backend. The mechanism is described in the spec.
Thanks.
+
+
+#ifndef _UAPI_LINUX_VIRTIO_I2C_H
+#define _UAPI_LINUX_VIRTIO_I2C_H
+
+#include
+#include
+#include
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __le16 addr;
+ __le16 flags;
+ __le16 len;
+};
I'm afraid this is not complete. E.g the status is missed.
I suspect what virtio-scsi use is better. Which split the in from the
out instead of reusing the same buffer. And it can ease the uAPI
header export.
Thanks
I think following definition in uAPI for the status is enough.
There is no need to provide a "u8" status in the structure.
/* The final status written by the device */
#define VIRTIO_I2C_MSG_OK 0
#define VIRTIO_I2C_MSG_ERR 1
You can see an example in virtio_blk.
In the spec:
struct virtio_blk_req {
le32 type;
le32 reserved;
le64 sector;
u8 data[];
u8 status;
};
In virtio_blk.h, there is only following definitions.
#define VIRTIO_BLK_S_OK 0
#define VIRTIO_BLK_S_IOERR 1
#define VIRTIO_BLK_S_UNSUPP 2
Thanks.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/22 上午10:58, 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.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the I2C msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed-by: Shuo Liu
Reviewed-by: Andy Shevchenko
---
The device ID request:
https://github.com/oasis-tcs/virtio-spec/issues/85
The specification:
https://lists.oasis-open.org/archives/virtio-comment/202009/msg00021.html
Changes in v3:
- Move the interface into uAPI according to Jason.
- Fix issues reported by Dan Carpenter.
- Fix typo reported by Randy.
Changes in v2:
- Addressed comments received from Michael, Andy and Jason.
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 256
include/uapi/linux/virtio_i2c.h | 31 +
include/uapi/linux/virtio_ids.h | 1 +
5 files changed, 302 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 293e7a0..f2f6543 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"
+ depends on 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 19aff0e..821acfa 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI)+= i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..48fd780
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * struct virtio_i2c_msg - the virtio I2C message structure
+ * @hdr: the virtio I2C message header
+ * @buf: virtio I2C message data buffer
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_msg {
+ struct virtio_i2c_hdr hdr;
+ u8 *buf;
+ u8 status;
+};
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @vmsg: the virtio I2C message for communication
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct virtio_i2c_msg vmsg;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(>completion);
+}
+
+static int virtio_i2c_add_msg(struct virtqueue *vq,
+ struct virtio_i2c_msg *vmsg,
+ struct i2c_msg *msg)
+{
+ struct scatterlist *sgs[3], hdr, bout, bin, status;
+ int outcnt = 0, incnt = 0;
+
+ if (!msg->len)
+ return -EINVAL;
+
+ vmsg->hdr.addr = cpu_to_le16(msg->addr);
+ vmsg->hdr.flags =
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/22 19:23, Andy Shevchenko wrote:
+ if ((!vmsg) || (vmsg != >vmsg)) {
This is a bit difficult to read (esp. taking into account the above comment)
besides the fact of redundant parentheses. Why not simply:
if (!(vmsg && vmsg == >vmsg)) {
?
Thanks Andy. It looks better.
--
2.7.4
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/22 19:23, Andy Shevchenko wrote:
+ if ((!vmsg) || (vmsg != >vmsg)) {
This is a bit difficult to read (esp. taking into account the above comment)
besides the fact of redundant parentheses. Why not simply:
if (!(vmsg && vmsg == >vmsg)) {
?
Thanks Andy. It looks better.
--
2.7.4
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] i2c: virtio: add a virtio i2c frontend driver
On Tue, Sep 22, 2020 at 10:58:43AM +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.
>
> This driver communicates with the backend driver through a
> virtio I2C message structure which includes following parts:
>
> - Header: i2c_msg addr, flags, len.
> - Data buffer: the pointer to the I2C msg data.
> - Status: the processing result from the backend.
>
> People may implement different backend drivers to emulate
> different controllers according to their needs. A backend
> example can be found in the device model of the open source
> project ACRN. For more information, please refer to
> https://projectacrn.org.
>
> The virtio device ID 34 is used for this I2C adpter since IDs
> before 34 have been reserved by other virtio devices.
>
> Co-developed-by: Conghui Chen
> Signed-off-by: Conghui Chen
> Signed-off-by: Jie Deng
> Reviewed-by: Shuo Liu
> Reviewed-by: Andy Shevchenko
> ---
> The device ID request:
> https://github.com/oasis-tcs/virtio-spec/issues/85
>
> The specification:
>
> https://lists.oasis-open.org/archives/virtio-comment/202009/msg00021.html
>
> Changes in v3:
> - Move the interface into uAPI according to Jason.
> - Fix issues reported by Dan Carpenter.
> - Fix typo reported by Randy.
>
> Changes in v2:
> - Addressed comments received from Michael, Andy and Jason.
>
> drivers/i2c/busses/Kconfig | 11 ++
> drivers/i2c/busses/Makefile | 3 +
> drivers/i2c/busses/i2c-virtio.c | 256
>
> include/uapi/linux/virtio_i2c.h | 31 +
> include/uapi/linux/virtio_ids.h | 1 +
> 5 files changed, 302 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 293e7a0..f2f6543 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"
> + depends on 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 19aff0e..821acfa 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -6,6 +6,9 @@
> # ACPI drivers
> obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
>
> +# VIRTIO I2C host controller driver
> +obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
> +
> # PC SMBus host controller drivers
> obj-$(CONFIG_I2C_ALI1535)+= i2c-ali1535.o
> obj-$(CONFIG_I2C_ALI1563)+= i2c-ali1563.o
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> new file mode 100644
> index 000..48fd780
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-virtio.c
> @@ -0,0 +1,256 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Virtio I2C Bus Driver
> + *
> + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +/**
> + * struct virtio_i2c_msg - the virtio I2C message structure
> + * @hdr: the virtio I2C message header
> + * @buf: virtio I2C message data buffer
> + * @status: the processing result from the backend
> + */
> +struct virtio_i2c_msg {
> + struct virtio_i2c_hdr hdr;
> + u8 *buf;
> + u8 status;
> +};
> +
> +/**
> + * struct virtio_i2c - virtio I2C data
> + * @vdev: virtio device for this controller
> + * @completion: completion of virtio I2C message
> + * @vmsg: the virtio I2C message for communication
> + * @adap: I2C adapter for this controller
> + * @i2c_lock: lock for virtqueue processing
> + * @vq: the virtio virtqueue for communication
> + */
> +struct virtio_i2c {
> + struct virtio_device *vdev;
> + struct completion completion;
> + struct virtio_i2c_msg vmsg;
> + struct i2c_adapter adap;
> + struct mutex i2c_lock;
> + struct virtqueue *vq;
> +};
> +
> +static void virtio_i2c_msg_done(struct virtqueue *vq)
> +{
> + struct virtio_i2c *vi = vq->vdev->priv;
> +
> + complete(>completion);
> +}
> +
> +static int virtio_i2c_add_msg(struct virtqueue *vq,
> + struct virtio_i2c_msg *vmsg,
> + struct
[PATCH v3] i2c: virtio: add a virtio i2c frontend driver
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.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the I2C msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed-by: Shuo Liu
Reviewed-by: Andy Shevchenko
---
The device ID request:
https://github.com/oasis-tcs/virtio-spec/issues/85
The specification:
https://lists.oasis-open.org/archives/virtio-comment/202009/msg00021.html
Changes in v3:
- Move the interface into uAPI according to Jason.
- Fix issues reported by Dan Carpenter.
- Fix typo reported by Randy.
Changes in v2:
- Addressed comments received from Michael, Andy and Jason.
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 256
include/uapi/linux/virtio_i2c.h | 31 +
include/uapi/linux/virtio_ids.h | 1 +
5 files changed, 302 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 293e7a0..f2f6543 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"
+ depends on 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 19aff0e..821acfa 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..48fd780
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * struct virtio_i2c_msg - the virtio I2C message structure
+ * @hdr: the virtio I2C message header
+ * @buf: virtio I2C message data buffer
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_msg {
+ struct virtio_i2c_hdr hdr;
+ u8 *buf;
+ u8 status;
+};
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @vmsg: the virtio I2C message for communication
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct virtio_i2c_msg vmsg;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(>completion);
+}
+
+static int virtio_i2c_add_msg(struct virtqueue *vq,
+ struct virtio_i2c_msg *vmsg,
+ struct i2c_msg *msg)
+{
+ struct scatterlist *sgs[3], hdr, bout, bin, status;
+ int outcnt = 0, incnt = 0;
+
+ if (!msg->len)
+ return -EINVAL;
+
+ vmsg->hdr.addr = cpu_to_le16(msg->addr);
+ vmsg->hdr.flags = cpu_to_le16(msg->flags);
+ vmsg->hdr.len = cpu_to_le16(msg->len);
