Received: by 10.223.185.116 with SMTP id b49csp3629844wrg; Mon, 19 Feb 2018 03:25:13 -0800 (PST) X-Google-Smtp-Source: AH8x227FZMy0xQAU01mBWKGHVqGsHVi8vO/bpUvxFiX7fJpHb26Nq/p0PLxEnOg+oHY436hrkVFt X-Received: by 10.99.56.77 with SMTP id h13mr12242142pgn.1.1519039513617; Mon, 19 Feb 2018 03:25:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519039513; cv=none; d=google.com; s=arc-20160816; b=wqxTMceygQ8S/Jx8CLOFo5TxhtnPNy5Xtm6xKwSMc4t8i8sHuVKdNmP7EBYrbwvYnz ZhFWrn/rn7c/rpQdmgYIoISLtq+fLARverF/yRUfe3lm3ucsnIN79/prwGM+R2m4FHfH B3U5PJoTJ1no9UFV7MXvLP0yrXmqVn1sxIEgnTLJDUxSiiT6T+izErAjtL+hFs1TQaXn nMPqL3oywtnQJimJnMcnSduBz8cnVVtuwYBucqPoVdx9xTg7GrG1+ZG2i4Jy6CaPwgFf jPXbp5rk2uu0Tpv1VVgiPXYGZJnvQCVwYZj5s0032AMK+zxGpuDuzLMDTmsTf18eyxEf 6RyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=gfwSsZ9nx6AcXYaU4Y2fBOaQ52QW39zAavLd7/YMWg0=; b=l1/DRYib5CJcmMiQu+DL606Ss16Nezgxz37FS567R4eXhXbTOPPZsmc4brHV1cJr5R hz4LHuQOfgyFMGtVJ/Z90/dv0/vNa3mezGLVNSgbdeCAZWwcbMO4yFssNs1dgclsq5zU jnYgiglmi4s7ZjlYzOJ3BT9VwD+nXVqPW2gfJOCqM2YKX+4+5tp9FuwHOVgiQOauHSU8 m6Cqo1wjRe5vHEm5BwVDV5OXcWdfOa4xJ0/1moRivRtxS3Kb+lxJlKJjTmZQVshD6Y2k eHfQabhl3fG74bIPjIPVvw42BHdzYuM0nX4hRT7Z60U7JdNrE2PwwttyiWmWe+cwjc/b 96yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=bNqyCZt1; dkim=pass header.i=@codeaurora.org header.s=default header.b=Zw3aPX30; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n10si7589053pfk.254.2018.02.19.03.24.59; Mon, 19 Feb 2018 03:25:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=bNqyCZt1; dkim=pass header.i=@codeaurora.org header.s=default header.b=Zw3aPX30; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752781AbeBSLYF (ORCPT + 99 others); Mon, 19 Feb 2018 06:24:05 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:42996 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752594AbeBSLYC (ORCPT ); Mon, 19 Feb 2018 06:24:02 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 00D1B60A66; Mon, 19 Feb 2018 11:24:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1519039442; bh=+MtgBr72wPGNyTO1pqJunHKMQXnPeM/DKnMr81VrQI4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bNqyCZt1Z1lX0lPHOQL5owQWm13vE+NGY8sfjaEL6xlLBbfW+xEPqt+PhLiKNoEJs Zs5qJxxCQdmVrEtp/NHfnMf50Gu6NZ4EB1CoZNY5tfsP9lYcURxfGMpuuMC+Q82SpY yi54z9LUj/4u7mDViS2vZYC1lMBSAhNtyVxlmsiM= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 4B9F160227; Mon, 19 Feb 2018 11:24:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1519039441; bh=+MtgBr72wPGNyTO1pqJunHKMQXnPeM/DKnMr81VrQI4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Zw3aPX30EPG6zYZham692OkZKm+3+288VS1ToumnMwfib/hYMArsaQefbK7E/o6G+ gYzOHWqaqqgqHilXVpXXGtFRaKQQkJdJD4waCG0NGwJF3ICkgzKoOyk8AZCJae+XgY ly+j87+6epnAFgqC/6L78XJhE/gCH6ZKDttPhxS8= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 19 Feb 2018 16:54:01 +0530 From: Abhishek Sahu To: Sricharan R Cc: Andy Gross , Wolfram Sang , David Brown , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len In-Reply-To: <246915f4-5351-c1b5-761b-45d88e4a3845@codeaurora.org> References: <1517644697-30806-1-git-send-email-absahu@codeaurora.org> <1517644697-30806-10-git-send-email-absahu@codeaurora.org> <246915f4-5351-c1b5-761b-45d88e4a3845@codeaurora.org> Message-ID: X-Sender: absahu@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-16 10:51, Sricharan R wrote: > Hi Abhishek, > > On 2/3/2018 1:28 PM, Abhishek Sahu wrote: >> The BAM mode requires buffer for start tag data and tx, rx SG >> list. Currently, this is being taken for maximum transfer length >> (65K). But an I2C transfer can have multiple messages and each >> message can be of this maximum length so the buffer overflow will >> happen in this case. Since increasing buffer length won’t be >> feasible since an I2C transfer can contain any number of messages >> so this patch does following changes to make i2c transfers working >> for multiple messages case. >> >> 1. Calculate the required buffers for 2 maximum length messages >> (65K * 2). >> 2. Split the descriptor formation and descriptor scheduling. >> The idea is to fit as many messages in one DMA transfers for 65K >> threshold value (max_xfer_sg_len). Whenever the sg_cnt is >> crossing this, then schedule the BAM transfer and subsequent >> transfer will again start from zero. >> +static void qup_i2c_bam_clear_tag_buffers(struct qup_i2c_dev *qup) >> +{ >> + qup->btx.sg_cnt = 0; >> + qup->brx.sg_cnt = 0; >> + qup->tag_buf_pos = 0; >> +} >> + >> static int qup_i2c_bam_xfer(struct i2c_adapter *adap, struct i2c_msg >> *msg, >> int num) >> { >> struct qup_i2c_dev *qup = i2c_get_adapdata(adap); >> int ret = 0; >> + int idx = 0; >> >> enable_irq(qup->irq); >> ret = qup_i2c_req_dma(qup); >> @@ -905,9 +916,34 @@ static int qup_i2c_bam_xfer(struct i2c_adapter >> *adap, struct i2c_msg *msg, >> goto out; >> >> writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL); >> + qup_i2c_bam_clear_tag_buffers(qup); >> + >> + for (idx = 0; idx < num; idx++) { >> + qup->msg = msg + idx; >> + qup->is_last = idx == (num - 1); >> + >> + ret = qup_i2c_bam_make_desc(qup, qup->msg); >> + if (ret) >> + break; >> + >> + /* >> + * Make DMA descriptor and schedule the BAM transfer if its >> + * already crossed the maximum length. Since the memory for all >> + * tags buffers have been taken for 2 maximum possible >> + * transfers length so it will never cross the buffer actual >> + * length. >> + */ >> + if (qup->btx.sg_cnt > qup->max_xfer_sg_len || >> + qup->brx.sg_cnt > qup->max_xfer_sg_len || >> + qup->is_last) { >> + ret = qup_i2c_bam_schedule_desc(qup); >> + if (ret) >> + break; >> + >> + qup_i2c_bam_clear_tag_buffers(qup); >> + } >> + } >> > > hmm, is this because of only stress tests or was there any device > which > was using i2c for multiple messages exceeding 64k bytes ? Its mainly part of stress test but we have test slave devices which supports the multiple messages exceeding 64k bytes. Also, in I2C EEPROM we can send the multiple messages exceeding 64k bytes. It will roll over to starting address after its capacity. > > Infact we are trying to club two separate messages together across > 64k > boundaries. Not sure if its really correct. So either we club all > messages > fully or club only up to the length that would cover the whole > message < 64K > and send the remaining whole messages in next transfer. > The QUP DMA can be used for any transfer length. It supports greater than 64k also in one go. Only restriction is descriptors memory. clubing all messages won't be feasible since there is no restriction on the number of messages due to which we can't determine the required descriptors size. whole message < 64K will require more code changes since we need to calculate the number of required descriptors in advance. Again in descriptor formation, the number of required descriptors will be calculated and filled. To make the code less complicated, I have taken the memory for 128K xfer length which will make the current code working without any major code changes. Thanks, Abhishek