[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YNsImlDN19zXRDO1@ninjato>
Date: Tue, 29 Jun 2021 13:48:42 +0200
From: Wolfram Sang <wsa@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: 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
> > 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.
I'd prefer it.
> > 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".
Sounds good.
> The device (host in virtio spec terminology) still needs to return
> success/failure as it does for other requests. Nothing special here.
Ack.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists