From: Viresh Kumar <viresh.kumar@linaro.org> To: "Wolfram Sang" <wsa@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>, "Jie Deng" <jie.deng@intel.com>, "Linux I2C" <linux-i2c@vger.kernel.org>, virtualization@lists.linux-foundation.org, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>, conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, "Sergey Semin" <Sergey.Semin@baikalelectronics.ru>, "Mike Rapoport" <rppt@kernel.org>, loic.poulain@linaro.org, "Tali Perry" <tali.perry1@gmail.com>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, yu1.wang@intel.com, shuo.a.liu@intel.com, "Stefan Hajnoczi" <stefanha@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com> Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Date: Tue, 29 Jun 2021 09:40:17 +0530 [thread overview] Message-ID: <20210629041017.dsvzldikvsaade37@vireshk-i7> (raw) In-Reply-To: <YNnjh3xxyaZZSo9N@ninjato> I will be replying here instead of replying to each and every msg :) On 28-06-21, 16:58, Wolfram Sang wrote: > > > You can fine Viresh's vhost-user implementation at > > https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.org/t/#m3b5044bad9769b170f505e63bd081eb27cef8db2 > > It looks OK so far; yet, it is not complete. But it might be bearable > in the end. While we are at it, this has been replaced by a Rust counterpart [1] (as that makes it hypervisor agnostic, which is the goal of my work here) and I need someone with I2C knowledge to help review it. It should be okay even if you don't understand Rust a lot, just review this file[2] which is where most of i2c specific stuff lies. > > As you say, it does get a bit clumsy, but I think there is also a good argument > > to be made that the clumsiness is based on the host Linux user interface > > more than the on the requirements of the physical interface, > > and that should not have to be reflected in the virtio specification. > > Makes sense to me. > > > Right, this one has come up before as well: the preliminary result > > was to assume that this probably won't be needed, but would be easy > > enough to add later if necessary. > > If adding support incrementally works for such an interface, this makes > sense as well. Yes, we don't support few of SMBUS transaction (the block ones) as you specified. > So, where are we? The virtio specification is already merged and here is the latest version [3]. > As I understand, this v10 does not support I2C transactions (or > I2C_RDWR as you said). I am not sure why you say I2C_RDWR isn't supported. The spec and Linux driver (+ my Rust/qemu backend), they all support I2C_RDWR as well as SMBUS. To clarify on an earlier point, every virtio transfer may contain one or more struct i2c_msg instances, all processed together (as expected). If you see virtio_i2c_send_reqs() in this patch, you will see that it converts a stream of i2c_req messages to their virtio counterparts and send them together, consider it a single transaction. > But you want to support all clients. So, this doesn't match, or? -- viresh [1] https://github.com/rust-vmm/vhost-device/pull/1 [2] https://github.com/rust-vmm/vhost-device/blob/5aa22c92faac84ab07b6b15a214513556e8b1d01/src/i2c/src/i2c.rs [3] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: "Wolfram Sang" <wsa@kernel.org>, "Arnd Bergmann" <arnd@arndb.de>, "Jie Deng" <jie.deng@intel.com>, "Linux I2C" <linux-i2c@vger.kernel.org>, virtualization@lists.linux-foundation.org, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>, conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, "Sergey Semin" <Sergey.Semin@baikalelectronics.ru>, "Mike Rapoport" <rppt@kernel.org>, loic.poulain@linaro.org, "Tali Perry" <tali.perry1@gmail.com>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, yu1.wang@intel.com, shuo.a.liu@intel.com, "Stefan Hajnoczi" <stefanha@redhat.com>, "Paolo Bonzini" <pbonzini@redhat.com> Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Date: Tue, 29 Jun 2021 09:40:17 +0530 [thread overview] Message-ID: <20210629041017.dsvzldikvsaade37@vireshk-i7> (raw) In-Reply-To: <YNnjh3xxyaZZSo9N@ninjato> I will be replying here instead of replying to each and every msg :) On 28-06-21, 16:58, Wolfram Sang wrote: > > > You can fine Viresh's vhost-user implementation at > > https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.org/t/#m3b5044bad9769b170f505e63bd081eb27cef8db2 > > It looks OK so far; yet, it is not complete. But it might be bearable > in the end. While we are at it, this has been replaced by a Rust counterpart [1] (as that makes it hypervisor agnostic, which is the goal of my work here) and I need someone with I2C knowledge to help review it. It should be okay even if you don't understand Rust a lot, just review this file[2] which is where most of i2c specific stuff lies. > > As you say, it does get a bit clumsy, but I think there is also a good argument > > to be made that the clumsiness is based on the host Linux user interface > > more than the on the requirements of the physical interface, > > and that should not have to be reflected in the virtio specification. > > Makes sense to me. > > > Right, this one has come up before as well: the preliminary result > > was to assume that this probably won't be needed, but would be easy > > enough to add later if necessary. > > If adding support incrementally works for such an interface, this makes > sense as well. Yes, we don't support few of SMBUS transaction (the block ones) as you specified. > So, where are we? The virtio specification is already merged and here is the latest version [3]. > As I understand, this v10 does not support I2C transactions (or > I2C_RDWR as you said). I am not sure why you say I2C_RDWR isn't supported. The spec and Linux driver (+ my Rust/qemu backend), they all support I2C_RDWR as well as SMBUS. To clarify on an earlier point, every virtio transfer may contain one or more struct i2c_msg instances, all processed together (as expected). If you see virtio_i2c_send_reqs() in this patch, you will see that it converts a stream of i2c_req messages to their virtio counterparts and send them together, consider it a single transaction. > But you want to support all clients. So, this doesn't match, or? -- viresh [1] https://github.com/rust-vmm/vhost-device/pull/1 [2] https://github.com/rust-vmm/vhost-device/blob/5aa22c92faac84ab07b6b15a214513556e8b1d01/src/i2c/src/i2c.rs [3] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-i2c.tex
next prev parent reply other threads:[~2021-06-29 4:10 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-23 14:19 [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Jie Deng 2021-03-23 14:19 ` Jie Deng 2021-03-23 7:27 ` Viresh Kumar 2021-03-23 8:33 ` Jie Deng 2021-03-23 8:33 ` Jie Deng 2021-03-23 8:37 ` Viresh Kumar 2021-03-23 9:27 ` Arnd Bergmann 2021-03-23 9:27 ` Arnd Bergmann 2021-03-24 1:17 ` Jie Deng 2021-03-24 1:17 ` Jie Deng 2021-03-24 4:00 ` Viresh Kumar 2021-04-15 6:45 ` Viresh Kumar 2021-04-15 6:56 ` Jie Deng 2021-04-15 6:56 ` Jie Deng 2021-04-15 7:15 ` Viresh Kumar 2021-04-15 7:21 ` Wolfram Sang 2021-04-15 7:24 ` Viresh Kumar 2021-04-15 7:28 ` Wolfram Sang 2021-04-15 7:37 ` Viresh Kumar 2021-04-15 8:15 ` Jie Deng 2021-04-15 8:15 ` Jie Deng 2021-04-15 8:18 ` Wolfram Sang 2021-04-15 8:20 ` Jie Deng 2021-04-15 8:20 ` Jie Deng 2021-05-27 6:49 ` Jie Deng 2021-05-27 6:49 ` Jie Deng 2021-05-12 1:37 ` Jie Deng 2021-05-12 1:37 ` Jie Deng 2021-03-23 9:01 ` Viresh Kumar 2021-03-23 9:38 ` Viresh Kumar 2021-03-24 0:53 ` Jie Deng 2021-03-24 0:53 ` Jie Deng 2021-03-24 3:52 ` Viresh Kumar 2021-03-24 4:00 ` Jie Deng 2021-03-24 4:00 ` Jie Deng 2021-03-24 4:02 ` Viresh Kumar 2021-03-24 4:20 ` Viresh Kumar 2021-03-24 6:05 ` Jie Deng 2021-03-24 6:05 ` Jie Deng 2021-03-24 6:09 ` Viresh Kumar 2021-03-24 6:41 ` Jie Deng 2021-03-24 6:41 ` Jie Deng 2021-03-24 6:44 ` Viresh Kumar 2021-04-14 2:07 ` Jie Deng 2021-04-14 2:07 ` Jie Deng 2021-04-14 3:52 ` Viresh Kumar 2021-04-15 6:25 ` Jie Deng 2021-04-15 6:25 ` Jie Deng 2021-04-15 3:51 ` Jason Wang 2021-04-15 3:51 ` Jason Wang 2021-04-15 6:17 ` Jie Deng 2021-04-15 6:17 ` Jie Deng 2021-06-28 8:39 ` Wolfram Sang 2021-06-28 9:01 ` Arnd Bergmann 2021-06-28 9:01 ` Arnd Bergmann 2021-06-28 9:25 ` Wolfram Sang 2021-06-28 9:51 ` Arnd Bergmann 2021-06-28 9:51 ` Arnd Bergmann 2021-06-28 10:13 ` Wolfram Sang 2021-06-28 11:50 ` Arnd Bergmann 2021-06-28 11:50 ` Arnd Bergmann 2021-06-28 14:58 ` Wolfram Sang 2021-06-29 3:04 ` Jie Deng 2021-06-29 3:04 ` Jie Deng 2021-06-29 8:30 ` Wolfram Sang 2021-06-29 9:13 ` Viresh Kumar 2021-06-29 9:13 ` Viresh Kumar 2021-06-29 9:36 ` Wolfram Sang 2021-06-29 4:10 ` Viresh Kumar [this message] 2021-06-29 4:10 ` Viresh Kumar 2021-06-29 8:27 ` Wolfram Sang 2021-06-29 8:52 ` Viresh Kumar 2021-06-29 8:52 ` Viresh Kumar 2021-06-29 9:07 ` Wolfram Sang 2021-06-30 14:38 ` Wolfram Sang 2021-06-30 15:09 ` Viresh Kumar 2021-06-30 15:09 ` Viresh Kumar 2021-06-29 3:03 ` Jie Deng 2021-06-29 3:03 ` Jie Deng 2021-06-29 10:07 ` Wolfram Sang 2021-06-29 10:16 ` Viresh Kumar 2021-06-29 10:16 ` Viresh Kumar 2021-06-29 10:23 ` Wolfram Sang 2021-06-29 10:30 ` Viresh Kumar 2021-06-29 10:30 ` Viresh Kumar 2021-06-29 10:42 ` Wolfram Sang 2021-06-29 10:43 ` Wolfram Sang 2021-06-29 10:56 ` Viresh Kumar 2021-06-29 10:56 ` Viresh Kumar 2021-06-29 11:11 ` Wolfram Sang 2021-06-29 11:16 ` Viresh Kumar 2021-06-29 11:16 ` Viresh Kumar 2021-06-29 11:48 ` Wolfram Sang 2021-07-05 12:18 ` Viresh Kumar 2021-07-05 12:18 ` Viresh Kumar 2021-07-06 1:50 ` Jie Deng 2021-07-06 1:50 ` Jie Deng 2021-07-22 15:15 ` Wolfram Sang 2021-07-23 2:28 ` Viresh Kumar 2021-07-23 2:28 ` Viresh Kumar 2021-07-23 5:28 ` Viresh Kumar 2021-07-23 5:28 ` Viresh Kumar 2021-06-30 6:45 ` Jie Deng 2021-06-30 6:45 ` Jie Deng 2021-06-30 7:32 ` Wolfram Sang 2021-06-30 7:51 ` Jie Deng 2021-06-30 7:51 ` Jie Deng 2021-06-30 7:55 ` Arnd Bergmann 2021-06-30 7:55 ` Arnd Bergmann 2021-06-30 8:04 ` Wolfram Sang 2021-06-30 8:07 ` Andy Shevchenko 2021-06-30 8:07 ` Andy Shevchenko 2021-06-30 8:29 ` Arnd Bergmann 2021-06-30 8:29 ` Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210629041017.dsvzldikvsaade37@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=Sergey.Semin@baikalelectronics.ru \ --cc=andriy.shevchenko@linux.intel.com \ --cc=arnd@arndb.de \ --cc=bjorn.andersson@linaro.org \ --cc=conghui.chen@intel.com \ --cc=jarkko.nikula@linux.intel.com \ --cc=jasowang@redhat.com \ --cc=jie.deng@intel.com \ --cc=kblaiech@mellanox.com \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=loic.poulain@linaro.org \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=rppt@kernel.org \ --cc=shuo.a.liu@intel.com \ --cc=stefanha@redhat.com \ --cc=tali.perry1@gmail.com \ --cc=u.kleine-koenig@pengutronix.de \ --cc=virtualization@lists.linux-foundation.org \ --cc=wsa@kernel.org \ --cc=yu1.wang@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.