From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Subject: Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC Date: Tue, 17 Jun 2014 22:07:13 -0700 Message-ID: References: <1402954800-28215-1-git-send-email-dianders@chromium.org> <1402954800-28215-11-git-send-email-dianders@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Doug Anderson Cc: Lee Jones , Andrew Bresticker , Stephen Warren , Olof Johansson , Sonny Rao , linux-samsung-soc , Javier Martinez Canillas , Bill Richardson , Wolfram Sang , Mark Brown , Samuel Ortiz , Vincent Palatin , "linux-i2c@vger.kernel.org" , lk List-Id: linux-i2c@vger.kernel.org Hi Doug, On 17 June 2014 21:54, Doug Anderson wrote: > Simon, > > On Tue, Jun 17, 2014 at 8:46 PM, Simon Glass wrote: >> Hi, >> >> On 16 June 2014 14:40, Doug Anderson wrote: >>> From: Bill Richardson >>> >>> When communicating with the EC, the cmd_xfer() function should return the >>> number of bytes it received from the EC, or negative on error. >> >> This is just for the I2C tunnel feature, right? If so, I think this >> should be mentioned here. It seems to be affecting ec_i2c_xfer(), not >> cmd_xfer(). > > No, the tunnel feature is implemented just fine without this (and is > already landed and working). It looks like the (not yet upstreamed) > ec_i2c_limited_xfer for spring returns this new value directly but I'm > not convinced that's technicall correct. > > Bill can correct me if I'm wrong, but I think this is primarily > interesting once we add in cros_ec_dev (the userspace API) which needs > this info. Until that happens this patch doesn't hurt and just > returns some extra info. Agreed. Reviewed-by: Simon Glass Regards, Simon