Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 2 Jul 2021 10:25:12 +0530
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, arnd@arndb.de,
        jasowang@redhat.com, andriy.shevchenko@linux.intel.com,
        yu1.wang@intel.com, shuo.a.liu@intel.com, conghui.chen@intel.com,
        stefanha@redhat.com
Subject: Re: [PATCH v11] i2c: virtio: add a virtio i2c frontend driver
Message-ID: <20210702045512.u4dvbapoc5a2a4jb@vireshk-i7>
References: <510c876952efa693339ab0d6cc78ba7be9ef6897.1625104206.git.jie.deng@intel.com>
 <20210701040436.p7kega6rzeqz5tlm@vireshk-i7>
 <YN4WeJCepCrpylOD@kunai>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YN4WeJCepCrpylOD@kunai>
User-Agent: NeoMutt/20180716-391-311a52
Precedence: bulk

On 01-07-21, 21:24, Wolfram Sang wrote:
> 
> > I just noticed this now, but this function even tries to send data
> > partially, which isn't right. If the caller (i2c device's driver)
> > calls this for 5 struct i2c_msg instances, then all 5 need to get
> > through or none.. where as we try to send as many as possible here.
> > 
> > This looks broken to me. Rather return an error value here on success,
> > or make it complete failure.
> > 
> > Though to be fair I see i2c-core also returns number of messages
> > processed from i2c_transfer().
> > 
> > Wolfram, what's expected here ? Shouldn't all message transfer or
> > none?
> 
> Well, on a physical bus, it can simply happen that after message 3 of 5,
> the bus is stalled, so we need to bail out.

Right, and in that case the transfer will have any meaning left? I believe it
needs to be fully retried as the requests may have been dependent on each other.

> Again, I am missing details of a virtqueue, but I'd think it is
> different. If adding to the queue fails, then it probably make sense to
> drop the whole transfer.

Exactly my point.

> Of course, it can later happen on the physical bus of the host, though,
> that the bus is stalled after message 3 of 5, and I2C_RDWR will bail
> out.

Basically we fail as soon as we know something is not right, correct?

-- 
viresh