From: Viresh Kumar <viresh.kumar@linaro.org> To: Wolfram Sang <wsa@kernel.org>, Jie Deng <jie.deng@intel.com>, linux-i2c@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, andriy.shevchenko@linux.intel.com, conghui.chen@intel.com, arnd@arndb.de, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, Sergey.Semin@baikalelectronics.ru, rppt@kernel.org, loic.poulain@linaro.org, tali.perry1@gmail.com, u.kleine-koenig@pengutronix.de, bjorn.andersson@linaro.org, yu1.wang@intel.com, shuo.a.liu@intel.com, stefanha@redhat.com, pbonzini@redhat.com Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Date: Fri, 23 Jul 2021 07:58:36 +0530 [thread overview] Message-ID: <20210723022836.ews7bshlwcsaktud@vireshk-i7> (raw) In-Reply-To: <YPmLoeLSPS1tfYUK@ninjato> Hi Wolfram, On 22-07-21, 17:15, Wolfram Sang wrote: > Nope, I think you misinterpreted that. SMBUS_QUICK will not send any > byte. After the address phase (with the RW bit as data), a STOP will > immediately follow. len = 0 will ensure that. > > msgbuf0[0] is set to 'command' because every mode except SMBUS_QUICK > will need that. So, it is convenient to always do it. For SMBUS_QUICK > it is superfluous but does not hurt. Yeah, I think I was confused by this stuff. > > If so, it would be difficult to implement this with the current i2c virtio > > specification, as the msg.len isn't really passed from guest to host, rather it > > is inferred using the length of the buffer itself. And so we can't really pass a > > buffer if length is 0. > > And you can't leave out the buffer and assume len = 0 then? Would need a spec update, which I am going to send. We would also need another update to spec to make the Quick thing working. Lemme do it separately and we merge the latest version of the driver for linux-next until then. I checked the code with i2cdetect -q and it worked fine, I was required to do some changes to the backend (and spec) to make it work. I will propose the changes to the spec first for the same. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: Wolfram Sang <wsa@kernel.org>, Jie Deng <jie.deng@intel.com>, linux-i2c@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, andriy.shevchenko@linux.intel.com, conghui.chen@intel.com, arnd@arndb.de, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, Sergey.Semin@baikalelectronics.ru, rppt@kernel.org, loic.poulain@linaro.org, tali.perry1@gmail.com, u.kleine-koenig@pengutronix.de, bjorn.andersson@linaro.org, yu1.wang@intel.com, shuo.a.liu@intel.com, stefanha@redhat.com, pbonzini@redhat.com Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver Date: Fri, 23 Jul 2021 07:58:36 +0530 [thread overview] Message-ID: <20210723022836.ews7bshlwcsaktud@vireshk-i7> (raw) In-Reply-To: <YPmLoeLSPS1tfYUK@ninjato> Hi Wolfram, On 22-07-21, 17:15, Wolfram Sang wrote: > Nope, I think you misinterpreted that. SMBUS_QUICK will not send any > byte. After the address phase (with the RW bit as data), a STOP will > immediately follow. len = 0 will ensure that. > > msgbuf0[0] is set to 'command' because every mode except SMBUS_QUICK > will need that. So, it is convenient to always do it. For SMBUS_QUICK > it is superfluous but does not hurt. Yeah, I think I was confused by this stuff. > > If so, it would be difficult to implement this with the current i2c virtio > > specification, as the msg.len isn't really passed from guest to host, rather it > > is inferred using the length of the buffer itself. And so we can't really pass a > > buffer if length is 0. > > And you can't leave out the buffer and assume len = 0 then? Would need a spec update, which I am going to send. We would also need another update to spec to make the Quick thing working. Lemme do it separately and we merge the latest version of the driver for linux-next until then. I checked the code with i2cdetect -q and it worked fine, I was required to do some changes to the backend (and spec) to make it work. I will propose the changes to the spec first for the same. -- viresh _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-07-23 2:28 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 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 [this message] 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=20210723022836.ews7bshlwcsaktud@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.