[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210629111630.badum3mtumcujbyk@vireshk-i7>
Date: Tue, 29 Jun 2021 16:46:30 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Wolfram Sang <wsa@...nel.org>, Jie Deng <jie.deng@...el.com>,
linux-i2c@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, mst@...hat.com, jasowang@...hat.com,
andriy.shevchenko@...ux.intel.com, conghui.chen@...el.com,
arnd@...db.de, kblaiech@...lanox.com,
jarkko.nikula@...ux.intel.com, Sergey.Semin@...kalelectronics.ru,
rppt@...nel.org, loic.poulain@...aro.org, tali.perry1@...il.com,
u.kleine-koenig@...gutronix.de, bjorn.andersson@...aro.org,
yu1.wang@...el.com, shuo.a.liu@...el.com, stefanha@...hat.com,
pbonzini@...hat.com
Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver
On 29-06-21, 13:11, Wolfram Sang wrote:
>
> > The case when ``length of \field{write_buf}''=0, and at the same time,
> > ``length of \field{read_buf}''=0 is called not-a-read-write request
> > and result for such a request is I2C device specific.
>
> Obviously, I don't know much about the specs and their wording. Still I
> wonder if we can't call it a zero length transfer?
Maybe that.
> This is allowed by
> the I2C standard and SMBus has even a proper name for it (SMBUS_QUICK).
> From my point of view, I would not say it is device specific because
> devices are expected to ACK such a message.
Actually we should skip the last line from my diff, i.e. completely
drop "and result for such a request is I2C device specific".
The device (host in virtio spec terminology) still needs to return
success/failure as it does for other requests. Nothing special here.
--
viresh
Powered by blists - more mailing lists