From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933250AbcETIbe (ORCPT <rfc822;w@1wt.eu>);
	Fri, 20 May 2016 04:31:34 -0400
Received: from smtp.codeaurora.org ([198.145.29.96]:36615 "EHLO
	smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932749AbcETIb0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 20 May 2016 04:31:26 -0400
From: "Sricharan" <sricharan@codeaurora.org>
To: "'Naveen Kaje'" <nkaje@codeaurora.org>, <wsa@the-dreams.de>,
        <linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <linux-arm-msm@vger.kernel.org>, <rruigrok@codeaurora.org>,
        <timur@codeaurora.org>, <cov@codeaurora.org>,
        <austinwc@codeaurora.org>, <linux-arm-kernel@lists.infradead.org>,
        "'Sricharan'" <sricharan@codeaurora.org>
References: <1463006736-24652-1-git-send-email-nkaje@codeaurora.org> <1463006736-24652-2-git-send-email-nkaje@codeaurora.org> <000d01d1b0d3$d70e1f30$852a5d90$@codeaurora.org> <757c18e2-562a-9f43-0fb6-ab3e7ac3af88@codeaurora.org>
In-Reply-To: <757c18e2-562a-9f43-0fb6-ab3e7ac3af88@codeaurora.org>
Subject: RE: [PATCH v2 2/2] i2c: qup: support SMBus block read
Date: Fri, 20 May 2016 14:01:17 +0530
Message-ID: <000501d1b271$fef3bc90$fcdb35b0$@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJXjp6iV28stO1fxYldGk+6MmpGgAMLzzquAnExifkA5jjypJ6CrACw
Content-Language: en-us
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

<snip..>
>>> @@ -1128,6 +1173,22 @@ static int qup_i2c_read_one_v2(struct
>>> qup_i2c_dev *qup, struct i2c_msg *msg)
>>>   			goto err;
>>>
>>>   		qup->blk.pos++;
>>> +
>>> +		/* Handle SMBus block read length */
>>> +		if (qup_i2c_check_msg_len(msg) && (msg->len == 1)) {
>>> +			if (msg->buf[0] > I2C_SMBUS_BLOCK_MAX) {
>>> +				ret = -EPROTO;
>>> +				goto err;
>>> +			}
>>> +			msg->len += msg->buf[0];
>>> +			qup->pos = 0;
>>> +			qup_i2c_set_read_mode_v2(qup, msg->len);
>>> +			qup_i2c_issue_xfer_v2(qup, msg);
>>> +			ret = qup_i2c_wait_for_complete(qup, msg);
>>> +			if (ret)
>>> +				goto err;
>> 		Is the issue_xfer_v2 needed inside this here ?
>No, qup_i2c_issue_xfer_v2 is needed so that we read rest of the data
>that is indicated by the length we read earlier.

So qup_i2c_issue_xfer_v2 writes the tags and there is one already in the loop above this
 check. So if you just do qup_i2c_set_read_mode_v2 and qup_i2c_set_blk_data inside this
 check, will not be enough ?

Regards,
 Sricharan