[{"id":1780541,"web_url":"http://patchwork.ozlabs.org/comment/1780541/","msgid":"<20171005120125.nnhomwg2e2twbaqm@ninjato>","list_archive_url":null,"date":"2017-10-05T12:01:25","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":22495,"url":"http://patchwork.ozlabs.org/api/people/22495/","name":"Wolfram Sang","email":"wsa@the-dreams.de"},"content":"On Sat, Sep 16, 2017 at 01:02:52PM +1000, Andrew Worsley wrote:\n> The i2c interrupt handler was not checking against the length of\n> supplied buffer so if the hardware supplied more data than requested in\n> the i2c transfer it happily copies it right past the end of the buffer!\n> \n> Signed-off-by: Andrew Worsley \n\nThank you for the bug report. I don't know the hardware in detail, but I\nam a bit confused...\n\n> ---\n> \n> This bug reliably caused a stack corruption when the hardware provided more data than\n> asked for in the i2c request. The hardware (a tpm) very occasionally appends a burst of\n> 0xff to the end of the data requested and the i2c interrupt handler mindlessly copies all\n> the data right past the end of the buffer and in my case across the stack. :-(\n\n... because you as the master should have control over how many bytes\nyou want to have. If you are done, send NAK+STOP and the message is\nover. Is it really the device (which one is it BTW?)? Or is the FIFO\nhandling of the master driver buggy?\n\nMichal, Sören?\n\n> \n> With this patch the transfer now terminates with an -EIO but with out voilating the\n> buffer boundaries. I would prefer to just make the transfer succeed while not retrieving\n> additional bytes but I wasn't able to find an easy way to do this. As this is definitely a\n> fault that causes a kernel oops I just wanted to get a fix out there for others to avoid\n> the problem as it has taken me a few weeks to chase down this oops. If someone has a\n> better or nicer fix I would appreciate it or a pointer to how to do this.\n> \n> Thanks\n> \n> Andrew\n> drivers/i2c/busses/i2c-cadence.c | 7 +++++++\n> 1 file changed, 7 insertions(+)\n> \n> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c\n> index b13605718291..c1f61ca6843e 100644\n> --- a/drivers/i2c/busses/i2c-cadence.c\n> +++ b/drivers/i2c/busses/i2c-cadence.c\n> @@ -234,6 +234,7 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)\n> \tif (id->p_recv_buf &&\n> \t ((isr_status & CDNS_I2C_IXR_COMP) ||\n> \t (isr_status & CDNS_I2C_IXR_DATA))) {\n> +\t\tunsigned char *p = id->p_recv_buf;\n> \t\t/* Read data if receive data valid is set */\n> \t\twhile (cdns_i2c_readreg(CDNS_I2C_SR_OFFSET) &\n> \t\t CDNS_I2C_SR_RXDV) {\n> @@ -246,6 +247,12 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)\n> \t\t\t !id->bus_hold_flag)\n> \t\t\t\tcdns_i2c_clear_bus_hold(id);\n> \n> +\t\t\tif (id->recv_count == 0) {\n> +\t\t\t\tpr_notice(\"%s: i2c receive buffer filled : %u aborting transfer %p - %p\\n\",\n> +\t\t\t\t\t__func__, (id->p_recv_buf - p));\n> +\t\t\t\tbreak;\n> +\t\t\t}\n> +\n> \t\t\t*(id->p_recv_buf)++ =\n> \t\t\t\tcdns_i2c_readreg(CDNS_I2C_DATA_OFFSET);\n> \t\t\tid->recv_count--;\n> -- \n> 2.11.0\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y7BFP4wlDz9sPt\n\tfor ;\n\tThu, 5 Oct 2017 23:01:29 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751418AbdJEMB2 (ORCPT );\n\tThu, 5 Oct 2017 08:01:28 -0400","from sauhun.de ([88.99.104.3]:39148 \"EHLO pokefinder.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751295AbdJEMB2 (ORCPT );\n\tThu, 5 Oct 2017 08:01:28 -0400","from localhost (p54B33366.dip0.t-ipconnect.de [84.179.51.102])\n\tby pokefinder.org (Postfix) with ESMTPSA id B7E2B2C379F;\n\tThu, 5 Oct 2017 14:01:26 +0200 (CEST)"],"Date":"Thu, 5 Oct 2017 14:01:25 +0200","From":"Wolfram Sang ","To":"Andrew Worsley , michal.simek@xilinx.com,\n\tsoren.brinkmann@xilinx.com","Cc":"linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","Message-ID":"<20171005120125.nnhomwg2e2twbaqm@ninjato>","References":"<20170916030252.10680-1-amworsley@gmail.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"zklvukmqjq6mzyph\"","Content-Disposition":"inline","In-Reply-To":"<20170916030252.10680-1-amworsley@gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1782019,"web_url":"http://patchwork.ozlabs.org/comment/1782019/","msgid":"","list_archive_url":null,"date":"2017-10-07T05:32:29","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":68717,"url":"http://patchwork.ozlabs.org/api/people/68717/","name":"Andrew Worsley","email":"amworsley@gmail.com"},"content":"> Thank you for the bug report. I don't know the hardware in detail, but I\n> am a bit confused...\n>\n>> ---\n>> This bug reliably caused a stack corruption when the hardware provided more data than\n>> asked for in the i2c request. The hardware (a tpm) very occasionally appends a burst of\n>> 0xff to the end of the data requested and the i2c interrupt handler mindlessly copies all\n>> the data right past the end of the buffer and in my case across the stack. :-(\n>\n> ... because you as the master should have control over how many bytes\n> you want to have. If you are done, send NAK+STOP and the message is\n> over. Is it really the device (which one is it BTW?)? Or is the FIFO\n> handling of the master driver buggy?\n>\n> Michal, Sören?\n\nJust a quick comment - as I don't have time at the moment to look\ndeeply into the driver at the moment.\n\nI was just looking at Ch 20 of the TRM on the i2c under Read Transfer\nand it says step 4 write the number of requested bytes to the Transfer\nSize Register.\n\nBut in the code it talks about a work around for large receive operation.\n\nLooking at the change log: commit 9fae82e1acda\n\nExplains for transfers > 252 bytes that\n\n \"the transfer size register has to be maintained at a value >= 1\n\nSo my guess is the code is trying to keep this transfer size non-zero\nand so just keeps pulling more bytes our of the slave i2c device. I\nfind it is hard to follow the complex code though.\n\nMy buggy condition was a transfer of 128 bytes so it is not hit this\ncondition except in that the slave supplies way more bytes than was in\nthe original i2c_transfer request.\n\nAndrew","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"l5wL7Pt/\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y8FWk5CQ4z9t5w\n\tfor ;\n\tSat, 7 Oct 2017 16:32:34 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750765AbdJGFcc (ORCPT );\n\tSat, 7 Oct 2017 01:32:32 -0400","from mail-ua0-f176.google.com ([209.85.217.176]:45271 \"EHLO\n\tmail-ua0-f176.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750713AbdJGFcb (ORCPT\n\t); Sat, 7 Oct 2017 01:32:31 -0400","by mail-ua0-f176.google.com with SMTP id l40so12182565uah.2\n\tfor ; Fri, 06 Oct 2017 22:32:30 -0700 (PDT)","by 10.176.72.233 with HTTP; Fri, 6 Oct 2017 22:32:29 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=mLjEnUBwP52y0DWDQvcFTO9QnBFs/uZAwzFQtf1++CM=;\n\tb=l5wL7Pt/L8jt3Qt3UFmF+hpgRFuy+n7tmx8GYXhfc+ifjM7f82GnrwBryujg1OxjBm\n\tEdb2KO5rJfWPCiWqOhvyAa+5n92alzI2X5TjNkvbHBQe3oqzCPg0qJcWegkoc7Bfvxwq\n\tiHXHnDoH7YheCv1Kk16iZC9wR8ST0xQmfszgrSdqlegfZG21gwP/o5zS09YpBX2VNQT2\n\tJdSbfrB6AIrTplOUZcGNX0W2JKnehoKgyT2Qk20WolHzTKOy2K0OKK75P+TlXtve5uDM\n\tpMNYB506z+CSaXlo2ytR2AMvPf9Ek9iF6soEKbyhNlNFxmkt7Jx6Hd6y4NSC2fqvZIJ1\n\tNf8Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=mLjEnUBwP52y0DWDQvcFTO9QnBFs/uZAwzFQtf1++CM=;\n\tb=o4GyOPfpBJxgG1sLp/feqemTkmMHDqSrN5X+e/ZJGCPddEsS+R6hRHWVSbzzo623Bc\n\tURYl79LXTvVmdOESin36hHE7AN0YgDOWprRJbvbnrndV6qrLo7yhc9xjX4QZl9cg0toL\n\t7pG7tAd7v/gtCC6Ns3k5cwzutqC5WfnZVAbmcGUczPWM3s/tEtHdQbh1ABCva3qSladE\n\tMAzgbrqDTxlYZjNkS7qVXy0r0qUFS2QDr6cPGCkMSywwN2+ioK5lZaRrh+kKaz99Tq9j\n\tGg2Sy3nKToLYDAykmhSNxEZNWSLebvyMkcTyqBQP8+JisIlD75YSo1PpFfrRU/utzSWf\n\tYMcA==","X-Gm-Message-State":"AMCzsaUBwnHkXDBCc+ugmRoILKYVyWFR1U+gVkqulpHlnz1NaoqoLQ6n\n\tijGjMRoEg+w9hNzQD9iet3Aj25R6FzWo2Ccw4ic=","X-Google-Smtp-Source":"AOwi7QBmWl6EZIYwoHbrcdd9W0X7D4Z8v2miLqe4tx7JUVXuB01LcQpBZfpDKhBYIzG3GjTNESIeww/mjVWTbztPaL0=","X-Received":"by 10.176.3.132 with SMTP id 4mr1839081uau.152.1507354350461;\n\tFri, 06 Oct 2017 22:32:30 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171005120125.nnhomwg2e2twbaqm@ninjato>","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>","From":"Andrew Worsley ","Date":"Sat, 7 Oct 2017 16:32:29 +1100","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Wolfram Sang ","Cc":"Michal Simek ,\n\tSoren Brinkmann ,\n\tlinux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1786546,"web_url":"http://patchwork.ozlabs.org/comment/1786546/","msgid":"<20171013184646.cy5gmpwrxbacje3m@ninjato>","list_archive_url":null,"date":"2017-10-13T18:46:46","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":22495,"url":"http://patchwork.ozlabs.org/api/people/22495/","name":"Wolfram Sang","email":"wsa@the-dreams.de"},"content":"On Sat, Oct 07, 2017 at 04:32:29PM +1100, Andrew Worsley wrote:\n> > Thank you for the bug report. I don't know the hardware in detail, but I\n> > am a bit confused...\n> >\n> >> ---\n> >> This bug reliably caused a stack corruption when the hardware provided more data than\n> >> asked for in the i2c request. The hardware (a tpm) very occasionally appends a burst of\n> >> 0xff to the end of the data requested and the i2c interrupt handler mindlessly copies all\n> >> the data right past the end of the buffer and in my case across the stack. :-(\n> >\n> > ... because you as the master should have control over how many bytes\n> > you want to have. If you are done, send NAK+STOP and the message is\n> > over. Is it really the device (which one is it BTW?)? Or is the FIFO\n> > handling of the master driver buggy?\n> >\n> > Michal, Sören?\n> \n> Just a quick comment - as I don't have time at the moment to look\n> deeply into the driver at the moment.\n> \n> I was just looking at Ch 20 of the TRM on the i2c under Read Transfer\n> and it says step 4 write the number of requested bytes to the Transfer\n> Size Register.\n> \n> But in the code it talks about a work around for large receive operation.\n> \n> Looking at the change log: commit 9fae82e1acda\n> \n> Explains for transfers > 252 bytes that\n> \n> \"the transfer size register has to be maintained at a value >= 1\n> \n> So my guess is the code is trying to keep this transfer size non-zero\n> and so just keeps pulling more bytes our of the slave i2c device. I\n> find it is hard to follow the complex code though.\n> \n> My buggy condition was a transfer of 128 bytes so it is not hit this\n> condition except in that the slave supplies way more bytes than was in\n> the original i2c_transfer request.\n\nSo, let's add Harini Katakam to CC who implemented this. But I'd be\nhappy for anyone from Xilinx to respond...\n\n> \n> Andrew","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yDGsP6yFmz9s5L\n\tfor ;\n\tSat, 14 Oct 2017 05:46:49 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751279AbdJMSqs (ORCPT );\n\tFri, 13 Oct 2017 14:46:48 -0400","from sauhun.de ([88.99.104.3]:41558 \"EHLO pokefinder.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751138AbdJMSqr (ORCPT );\n\tFri, 13 Oct 2017 14:46:47 -0400","from localhost (p54B33E27.dip0.t-ipconnect.de [84.179.62.39])\n\tby pokefinder.org (Postfix) with ESMTPSA id 81A862C30C6;\n\tFri, 13 Oct 2017 20:46:46 +0200 (CEST)"],"Date":"Fri, 13 Oct 2017 20:46:46 +0200","From":"Wolfram Sang ","To":"Andrew Worsley , Harini Katakam ","Cc":"Michal Simek ,\n\tSoren Brinkmann ,\n\tlinux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","Message-ID":"<20171013184646.cy5gmpwrxbacje3m@ninjato>","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"6f4hrvueqn5pdfmm\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1787141,"web_url":"http://patchwork.ozlabs.org/comment/1787141/","msgid":"","list_archive_url":null,"date":"2017-10-16T05:49:28","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":18585,"url":"http://patchwork.ozlabs.org/api/people/18585/","name":"Michal Simek","email":"michal.simek@xilinx.com"},"content":"Hi Wolfram,\n\nOn 13.10.2017 20:46, Wolfram Sang wrote:\n> On Sat, Oct 07, 2017 at 04:32:29PM +1100, Andrew Worsley wrote:\n>>> Thank you for the bug report. I don't know the hardware in detail, but I\n>>> am a bit confused...\n>>>\n>>>> ---\n>>>> This bug reliably caused a stack corruption when the hardware provided more data than\n>>>> asked for in the i2c request. The hardware (a tpm) very occasionally appends a burst of\n>>>> 0xff to the end of the data requested and the i2c interrupt handler mindlessly copies all\n>>>> the data right past the end of the buffer and in my case across the stack. :-(\n>>>\n>>> ... because you as the master should have control over how many bytes\n>>> you want to have. If you are done, send NAK+STOP and the message is\n>>> over. Is it really the device (which one is it BTW?)? Or is the FIFO\n>>> handling of the master driver buggy?\n>>>\n>>> Michal, Sören?\n>>\n>> Just a quick comment - as I don't have time at the moment to look\n>> deeply into the driver at the moment.\n>>\n>> I was just looking at Ch 20 of the TRM on the i2c under Read Transfer\n>> and it says step 4 write the number of requested bytes to the Transfer\n>> Size Register.\n>>\n>> But in the code it talks about a work around for large receive operation.\n>>\n>> Looking at the change log: commit 9fae82e1acda\n>>\n>> Explains for transfers > 252 bytes that\n>>\n>> \"the transfer size register has to be maintained at a value >= 1\n>>\n>> So my guess is the code is trying to keep this transfer size non-zero\n>> and so just keeps pulling more bytes our of the slave i2c device. I\n>> find it is hard to follow the complex code though.\n>>\n>> My buggy condition was a transfer of 128 bytes so it is not hit this\n>> condition except in that the slave supplies way more bytes than was in\n>> the original i2c_transfer request.\n> \n> So, let's add Harini Katakam to CC who implemented this. But I'd be\n> happy for anyone from Xilinx to respond...\n\nIt is still in my inbox to look at more details or ask my colleague to\nlook at it. I simply didn't have a time to do it.\n\nThanks,\nMichal","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=xilinx.onmicrosoft.com\n\theader.i=@xilinx.onmicrosoft.com header.b=\"kg0NSgmW\"; \n\tdkim-atps=neutral","spf=pass (sender IP is 149.199.60.83)\n\tsmtp.mailfrom=xilinx.com; the-dreams.de;\n\tdkim=none (message not signed)\n\theader.d=none;the-dreams.de; dmarc=bestguesspass action=none\n\theader.from=xilinx.com;"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yFnTJ3Fz5z9t2c\n\tfor ;\n\tMon, 16 Oct 2017 16:49:40 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751870AbdJPFtj (ORCPT );\n\tMon, 16 Oct 2017 01:49:39 -0400","from mail-sn1nam02on0078.outbound.protection.outlook.com\n\t([104.47.36.78]:65056\n\t\"EHLO NAM02-SN1-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S1750826AbdJPFti (ORCPT );\n\tMon, 16 Oct 2017 01:49:38 -0400","from BY2PR02CA0002.namprd02.prod.outlook.com (10.163.44.140) by\n\tCY4PR02MB3384.namprd02.prod.outlook.com (10.165.89.155) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.77.7; Mon, 16 Oct 2017 05:49:36 +0000","from SN1NAM02FT025.eop-nam02.prod.protection.outlook.com\n\t(2a01:111:f400:7e44::209) by BY2PR02CA0002.outlook.office365.com\n\t(2a01:111:e400:5261::12) with Microsoft SMTP Server (version=TLS1_2, \n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.77.7 via\n\tFrontend Transport; Mon, 16 Oct 2017 05:49:35 +0000","from xsj-pvapsmtpgw01 (149.199.60.83) by\n\tSN1NAM02FT025.mail.protection.outlook.com (10.152.72.87) with\n\tMicrosoft SMTP Server (version=TLS1_0,\n\tcipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.77.10\n\tvia Frontend Transport; Mon, 16 Oct 2017 05:49:35 +0000","from unknown-38-66.xilinx.com ([149.199.38.66] helo=xsj-pvapsmtp01)\n\tby xsj-pvapsmtpgw01 with esmtp (Exim 4.63)\n\t(envelope-from )\n\tid 1e3yHO-0000bG-F4; Sun, 15 Oct 2017 22:49:34 -0700","from [127.0.0.1] (helo=localhost)\n\tby xsj-pvapsmtp01 with smtp (Exim 4.63)\n\t(envelope-from )\n\tid 1e3yHO-0003ng-9p; Sun, 15 Oct 2017 22:49:34 -0700","from xsj-pvapsmtp01 (mailhub.xilinx.com [149.199.38.66])\n\tby xsj-smtp-dlp1.xlnx.xilinx.com (8.13.8/8.13.1) with ESMTP id\n\tv9G5nVwQ022179; Sun, 15 Oct 2017 22:49:31 -0700","from [172.30.17.111] by xsj-pvapsmtp01 with esmtp (Exim 4.63)\n\t(envelope-from )\n\tid 1e3yHL-0003mT-6s; Sun, 15 Oct 2017 22:49:31 -0700"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=xilinx.onmicrosoft.com; s=selector1-xilinx-com;\n\th=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=L0dG+PZ6Qvm1Fmnb0m2xyBfunmRK8TnWQ61mjk6dzUg=;\n\tb=kg0NSgmWPsL3MO+dF016X0fzRnqN8ieBxdP527sMatTCa86frZr5lS1Z3Dwxk9o0YXhCdHKtHSkpYK6PYqJ8Acv8ZgHf2CkzJRH1o4H+V9GMcupqxmfwsM6CnkynBdAEc+kJm6e3y17ZQmmRVWo9wJ8FrdW/onbyhbqpLRXjgdg=","Received-SPF":"Pass (protection.outlook.com: domain of xilinx.com designates\n\t149.199.60.83 as permitted sender)\n\treceiver=protection.outlook.com; \n\tclient-ip=149.199.60.83; helo=xsj-pvapsmtpgw01;","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Wolfram Sang , Andrew Worsley ,\n\tHarini Katakam ","CC":"Michal Simek ,\n\tSoren Brinkmann ,\n\t, ","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>","From":"Michal Simek ","Message-ID":"","Date":"Mon, 16 Oct 2017 07:49:28 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<20171013184646.cy5gmpwrxbacje3m@ninjato>","Content-Type":"text/plain; charset=\"utf-8\"","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-RCIS-Action":"ALLOW","X-TM-AS-Product-Ver":"IMSS-7.1.0.1224-8.1.0.1062-23396.006","X-TM-AS-User-Approved-Sender":"Yes;Yes","X-EOPAttributedMessage":"0","X-MS-Office365-Filtering-HT":"Tenant","X-Forefront-Antispam-Report":"CIP:149.199.60.83; IPV:NLI; CTRY:US; EFV:NLI;\n\tSFV:NSPM;\n\tSFS:(10009020)(6009001)(39860400002)(376002)(346002)(2980300002)(438002)(189002)(24454002)(199003)(54534003)(106466001)(93886005)(4326008)(39060400002)(63266004)(54906003)(110136005)(23676002)(50986999)(2950100002)(33646002)(83506001)(65956001)(65806001)(2870700001)(345774005)(2906002)(6246003)(77096006)(106002)(47776003)(478600001)(6666003)(36756003)(9786002)(31686004)(6636002)(64126003)(189998001)(31696002)(36386004)(86362001)(356003)(229853002)(50466002)(53546010)(81166006)(58126008)(305945005)(5660300001)(65826007)(81156014)(54356999)(76176999)(8676002)(8936002)(316002)(107986001);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR02MB3384;\n\tH:xsj-pvapsmtpgw01; FPR:; SPF:Pass;\n\tPTR:unknown-60-83.xilinx.com; MX:1; A:1; LANG:en; ","X-Microsoft-Exchange-Diagnostics":["1; SN1NAM02FT025;\n\t1:Q2m3TS7owj5qG3fWqa6F1oSOk7qtPlOSvZzxt5wwYdIsF/lUrXos7SIEhGEKbb/UFlWM99yZP54qoasdVg5QXrim9pyaMZZn2AmsHjbCzYM0B2hmWN9yoXxtDZkDTi11","1; CY4PR02MB3384;\n\t3:1Xsb7Jplp/KIJckJa39CKaf9cwEPq6N6O9uc86VGbI5jWVz5enT135chi3yYe5ZYiJ15wliPajmfabfKvpuIOSvy6GXny1qBzARPCz3yc8TxF9LRRNOWQ98AineMrXp20LgMsOUa+o95EEQ8ZUr7a0CQN5hM5+59Qegmn8Bh7BNYz13JH25anyuIatZrbMkUgkv4MhlUwL/ox2bnLsJkOPpI6nReNIV6GYt2wib7cArbxusyNEycjkuP13jPQnV7aKaC3AvT6/A3fAlyZiclofJ1+tcizXnG2ZUqCJ6zaCGZh0ATWu9er33OWTknEnuCxxc1Pg3X7CKF/EulPi8ArCW6WSu/u79I2pqy0YI0lJE=;\n\t25:u2Qs/iMDWwHkmTnIpIH/HC+4N1c97dXZkql6H1eLUcfpYKcVl0xORKcROcjZAnochiPnFLTfS2igj4BwD6KJilz+yS/0sFWFFVchc1r6MgGgWq9lrJaUbYsUoCBWvZD+Mz/4hc3kstvt9jAexsvgqiRqvlaWU6EUS1s78pUme5FcIsnKezlrRPSOweqWWFdn7MK46uGYefi3/kNRHliB8t0Zgd8KmJGRRDdLxrQ4PiAkzBNC548UrqWlaFMJ0Mfw23YHz9KAFaKnqJhnw745ZSExr9ODssyn16pKk1V7qv+sOAjMbsx+SQMtOIRlEBe+wkDePaBCoUCKJbZI+xmBFw==","1; CY4PR02MB3384;\n\t31:E1vSqAbeRhAbyRagwoKIoRxJfzaW44lWtPDtWcwXoylcWwQpb47Qun6VtbwIlAzPF8BunPMPnSTFQxeTZhFlRIGZAWRzybK1m6J7MVkB8+C3TUkBVQ9nwmbgww57IO7D4XbLvndfXLoMQT3MKKXBPnapywOqHBg9OBBK/MNRJQL97OnhLyxb/oLUVQH1OV/xlNt8ZEaAP6g/wl/7HG4TTTGZbQAVXLsPb97bX5pk9yw=;\n\t20:s5F+VHu/THdTNnhTh3mS8312d6ueedCI1ehG46kvLxHV/Ac0f09lNwWT+JaYtq66aWsyALsBqRAdVoZwEXq/uiS304CNPf8q0g096qaZdXXs+hDvHItSF8UKVpCPJTepRH7p2X4t/XjHXa7scipMQwD/lYQ62UQVobGZsDRUmWVdlbQKiarR+bqT2VtvHAQE1k4VDGLo386pC8xfd+w6RTYEm++W9sS8rJI+Q0ZfPVUF22UL0yJ0FU/8tRIQj8++jgqTjMh6RvVSpu5hmn32LwUC70c19e2TyHBr9SKAw51ZcTb6xZJbNgrXr/677NC+LX6AK81dPcJ9uSJUPhCJ0a4MCzacLyf12Bi+88ILobwbOfSRUwjesiCpcMdZhAsWJQ2/ZnJN7/NfdYuyPWzyt4DoFAK0aK+k1Vtp6dmO5/6LgddKfLsO5rMjRHZiXZFxETyfo7+8stZlpOeDa7S7coPjMsy+BZhO6eEdg332sPeVXF9wW9Z1pNks4z+XxZ9z","1; CY4PR02MB3384;\n\t4:Sj7sgRFYqrHiCvmZPAOZU6Urj4/eE7WFDdYcUUOy4hAaFF7A4HDFzRXiWSCPSEKn8r9B6JDchJernFdr7OGUlsGhAnPp67VWhnDfI/IBGLVEBrukIKNK45NSZWLvv2m+xJdnXUI6LGAXcpTVoPESKef+6gR9D4cMbY3mUfgFht9VTnpxgaN1+LpMEHe9GbZ1Mb9WLfYQ80s87Af3ZOVEkIABlxnHZL3lJhNoLMDgrWQJCKtoXEHUfx3x0iE4l3e9","=?utf-8?q?1=3BCY4PR02MB3384=3B23=3ANc6U?=\n\t=?utf-8?q?ul9NdjUQzoo/7Ubym0XZkJt8Pbz7K7GtI24crS9yoZZ4a+rRylirMrgX?=\n\t=?utf-8?q?3G/lybezjB9q5YmgeJt3hjEslyDrFSbxExyQ1V5oDbBdqaBHqKv2aXE/?=\n\t=?utf-8?q?GJsm3mi0EmlZFCiI/umNk+hsn5VSMXeHNBdtuLgOhW/nr929irYdjRO8?=\n\t=?utf-8?q?y4QD9ccJ1cCGKEajhC4dTGHHO8mqQtT33WxAcsspyad4rGaAgJldB5wi?=\n\t=?utf-8?q?6xZ8yqpcwLWYFtQG1LRwV5PIZteWXySkO/b29xiGKcmU/bLZKHKFC3fx?=\n\t=?utf-8?q?3MRqKzyILnGFE6Nj6KzF8rn5jjM9aK4DxjDUgq4lCfgc4doTuPRmYmvj?=\n\t=?utf-8?q?ch0wMf5VF5N2DiRlT+JVmkGMbe6kKGu0lg5rxMHtIhoKIHZ3QYuFCA23?=\n\t=?utf-8?q?SPOLn3vyTti9d1982DqmfFftj0Xh06WyhUw2pynk4ebu6O3+Uj6tuTZ4?=\n\t=?utf-8?q?S+3smJxWNb+PBVq1dzi0VPzuwttbLZd1gLHXwPSBbZ5PQelDGX6ZkSXr?=\n\t=?utf-8?q?51k5zQAcaRh6lJuQKGFoi2IawrrKdPkwz7RzegQjD8hxyZZi7r5c7Urf?=\n\t=?utf-8?q?2KrG2HGTNcBp2Z0XJINmtnwJsJp1+UkZFNW7n/qQ/Zzq8v4vawdTEEep?=\n\t=?utf-8?q?5hfeM7/h4zcTk/32KlWPgM5SfYOHrHFN+TxELS3f/tf1TdREg1pXSCpT?=\n\t=?utf-8?q?NKUl/HllmO5VpnaWKVy0WbWNuJ37ZtSTQodRlALrniTy9jyfVIRDtokS?=\n\t=?utf-8?q?cO7D2SLUCUgkiXVOsDTLcwF5SGBNEQ+/rUdVvUoamJ3TljRPJ7LwIhC4?=\n\t=?utf-8?q?LVwH83kFOIorF+byBk6LO9fV0AeGBc3/KjlHi/pR3YUdgrsa+HzJs5vP?=\n\t=?utf-8?q?FxEgtm4DIJsnmYQ9pcv9dXAK1E2X3YyAV+SFKG+c4KWMyqbt+sy7NUUX?=\n\t=?utf-8?q?Enm6ILgAsXc8zyVlNzTpWnncHpZ9Z8chfFjFK1mvdPqwBJDbkLMNB+0I?=\n\t=?utf-8?q?3JVKNUUcsSqWRYrnaQCYLxOJGrP8vMd+JXye+/MqMN1NecaH60hWEwTG?=\n\t=?utf-8?q?T7ks+wpcVaZR3jw5tQB8HV+uZcuEfoPhT6TTx2SMhyYjiNOIIn+qtJJS?=\n\t=?utf-8?q?MEp7hUTfH6bJ8rTXVUxcK5qKC1RntWQW69UZ49WvVSoVagkDBWKO84hw?=\n\t=?utf-8?q?jXFFgSClqHc+6QPDkNdjl1QXFW2UecCUjgLeJKrW8g/crMzPf7cswgBL?=\n\t=?utf-8?q?Q7sB1NyRMPaxO3d1ol9/ma2B4T2+As/bFURFAFa9jPOrkZD5BvYOVH0G?=\n\t=?utf-8?q?1kddCD1wYV5VcrPjKuXy92qOuZ/tzJcAXz3vbyzC8E0Z53wN11rMBQ6T?=\n\t=?utf-8?q?JtLKldYkBXZQZC7ylDuoQhw5j+VkKuoycReaDwaiNuIv6WiMWySYWiIW?=\n\t=?utf-8?q?WHvsrBvW1u1gn5tQCw=3D=3D?=","1; CY4PR02MB3384;\n\t6:wF7W7n8N84AqgSQUZDFsJnF7XuKPPafuS9nRwEydJhRtzMU8orxVIfhmWxAmg1bd6SYKpi2fnpOD4fkdnLi6Vn4cSWhtoBZxLTF2Z2JqEvmgtzNPuTqSZV8X8cIbUreNRvzJ4sL6KL+VvFVNI6nRDPXf5qTcsCSuWleVclNgrGU1JAyaKS1v2r+AGwrrvvdoSyBlw5nzJTe8TSQqjjbHLTIsv2Ltk8O2/QPbxJwkEgZNm6G7hndCPvQVJrsE8ZjdpyOQmHu3H02I81QuR78s/1O7Mx5xLYXBoz+mbWleCIo/gWZaWJXQ/NR+Qm2DAVj8rzNftGnlVuxArFiNEWhcgQ==;\n\t5:Y9a6IbNVnAf6zbnGZA7/PO5m5E04E+onw03j2C1nFofoWSj2h2PnAHs8aL/dXKsWUaaGmCXzRGgi4ZRHdB3T7SZ5C683p5xeDPkVa9S3E9hw5ahq8tF75PmHhcp0rpUtsYGdtOT17b2H2CYGu4amhw==;\n\t24:PEV8b03QryRGNycIzu0DJfwWQnWX0WvrHROLLl4CNU19zl+bPjalIDIfQeaBXbk2fsLB79fT9mHwwFjXdwXdRm87tsw7Kz8fZtto3hw2xGo=;\n\t7:yHteYUVoKonpcioYwpdl69QZmV7PZGSq7Kp+GDyAv3QhTJlfqNSEM3YxsfmuwKfOldQP4zkXR6mY319pqPpx5T4Uxd4wWY25tfPb4RG8/eQw9PXMRZLtMpR1gT1hChOnA/b9MuAD5ApakcpKnI/Bjf7XN0009E3NsyZSUDSYbMbAiJZvpe7e4o/trr3QUgRJlXr59r2EGPIV6nRZXspY1QS1tzA19lsnB422W2+u0zQ="],"X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"0d672398-09e5-4c3b-a2f5-08d51459ae57","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(2017030254152)(8251501002)(2017052603199)(201703131423075)(201703031133081)(201702281549075);\n\tSRVR:CY4PR02MB3384; ","X-MS-TrafficTypeDiagnostic":"CY4PR02MB3384:","X-Exchange-Antispam-Report-Test":"UriScan:;","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93004095)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:CY4PR02MB3384; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:CY4PR02MB3384; ","X-Forefront-PRVS":"0462918D61","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"xilinx.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"16 Oct 2017 05:49:35.0229\n\t(UTC)","X-MS-Exchange-CrossTenant-Id":"657af505-d5df-48d0-8300-c31994686c5c","X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp":"TenantId=657af505-d5df-48d0-8300-c31994686c5c;\n\tIp=[149.199.60.83]; Helo=[xsj-pvapsmtpgw01]","X-MS-Exchange-CrossTenant-FromEntityHeader":"HybridOnPrem","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"CY4PR02MB3384","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1787142,"web_url":"http://patchwork.ozlabs.org/comment/1787142/","msgid":"","list_archive_url":null,"date":"2017-10-16T05:55:18","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":62785,"url":"http://patchwork.ozlabs.org/api/people/62785/","name":"Harini Katakam","email":"harinikatakamlinux@gmail.com"},"content":"Hi Andrew,\n\nOn Sat, Oct 14, 2017 at 12:16 AM, Wolfram Sang wrote:\n> On Sat, Oct 07, 2017 at 04:32:29PM +1100, Andrew Worsley wrote:\n>> > Thank you for the bug report. I don't know the hardware in detail, but I\n>> > am a bit confused...\n>> >\n>> >> ---\n>> >> This bug reliably caused a stack corruption when the hardware provided more data than\n>> >> asked for in the i2c request. The hardware (a tpm) very occasionally appends a burst of\n>> >> 0xff to the end of the data requested and the i2c interrupt handler mindlessly copies all\n>> >> the data right past the end of the buffer and in my case across the stack. :-(\n>> >\n>> > ... because you as the master should have control over how many bytes\n>> > you want to have. If you are done, send NAK+STOP and the message is\n>> > over. Is it really the device (which one is it BTW?)? Or is the FIFO\n>> > handling of the master driver buggy?\n>> >\n>> > Michal, Sören?\n>>\n>> Just a quick comment - as I don't have time at the moment to look\n>> deeply into the driver at the moment.\n>>\n>> I was just looking at Ch 20 of the TRM on the i2c under Read Transfer\n>> and it says step 4 write the number of requested bytes to the Transfer\n>> Size Register.\n>>\n>> But in the code it talks about a work around for large receive operation.\n>>\n>> Looking at the change log: commit 9fae82e1acda\n>>\n>> Explains for transfers > 252 bytes that\n>>\n>> \"the transfer size register has to be maintained at a value >= 1\n>>\n>> So my guess is the code is trying to keep this transfer size non-zero\n>> and so just keeps pulling more bytes our of the slave i2c device. I\n>> find it is hard to follow the complex code though.\n>>\n>> My buggy condition was a transfer of 128 bytes so it is not hit this\n>> condition except in that the slave supplies way more bytes than was in\n>> the original i2c_transfer request.\n>\n> So, let's add Harini Katakam to CC who implemented this. But I'd be\n> happy for anyone from Xilinx to respond...\n\nThe workaround you are referring to is implemented under\n\"if (cdns_is_holdquirk(id, hold_quirk)) {\"\nand should not apply to your case of 128 byte transfer at all.\n\nThe specific place you have problem is under the loop\nwhere RX data valid is being checked and ideally, that\nbuffer should never be written with more data than requested -\nbecause no. of bytes requested is written to transfer size register,\nthe same is the amount the controller (master) fetches and\nRX data valid remains set only for that duration.\n\nAre you using Zynq?\nI'm not working on this anymore but we could take a look at\nyour error if we are able to reproduce it.\nCould you please provide more details of your application and\nsetup?\n\nRegards,\nHarini","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"YsEJpfdI\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yFnbs3VfBz9t2c\n\tfor ;\n\tMon, 16 Oct 2017 16:55:21 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751730AbdJPFzU (ORCPT );\n\tMon, 16 Oct 2017 01:55:20 -0400","from mail-qk0-f174.google.com ([209.85.220.174]:48500 \"EHLO\n\tmail-qk0-f174.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750821AbdJPFzT (ORCPT\n\t); Mon, 16 Oct 2017 01:55:19 -0400","by mail-qk0-f174.google.com with SMTP id d67so11501832qkg.5\n\tfor ; Sun, 15 Oct 2017 22:55:19 -0700 (PDT)","by 10.200.11.71 with HTTP; Sun, 15 Oct 2017 22:55:18 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=0CMvJEYlP9a6BSIpYbaK+ChASsqUrnFaLuM0MtuQ6iE=;\n\tb=YsEJpfdIVUMmwSl2dIh67m5xZQXHE7I5v0ifJ+kpT+p0zpXmtUCXsMN4uvk2LWGQEP\n\tc97PFjBTLix0Spq2lF+2ay+ZudQi2m1ZERkZezWGTPFyklwLAVLEgl5vKxUtYz6WkYJd\n\tIwaSzdE4SNEOLUQxoo2c9ClmP1cCuKMMgwc7TFLuscaAAZZqzPm9yAs4wMGsbaGKXKn2\n\tHFf8iCRRkRbeqkoWCOZ1xChzuoSjFwVhoNi0Gl7Opr0h9WssEdR6AvwIydgXFXabUSc1\n\tRWYMXszew/PQIE++NP7Lehy9A4ecuzAO4iHjLX11fxh2XriSC+ixLJSb8YYvVs3X6pn3\n\tw8lQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=0CMvJEYlP9a6BSIpYbaK+ChASsqUrnFaLuM0MtuQ6iE=;\n\tb=NNry5JmWjbJ8tHLXITNcOzNOY+vyr56jJrE6FxygWK8h6df4PZvlGkCnn1cY7ZGo3F\n\tYP4FD/ahXCdRZjLQmjSEq7Q+YQs20zUhoZzVKacwrPM9mS8fAar6myBm9aQeqf+PL1e8\n\tDtzCUbpdxf+mG2AQxN3vl0Sv8iaiTy5M6S7pgmmr+oASSEAiM9IaNqEFp51mvfMGCXTT\n\tL33pvS/2hTCJ0BFxNlj3U3lFxUjkBU1HOD09EZNBAc4BgALsUqDvWZiesogZHop4qDxg\n\tTGqtfTKPSHqVqfo9l1Pl2B0y9Q44y72nfV8CmYxSUr4EtELAgIDKjSk5rH6opx7bkv0h\n\tPeZw==","X-Gm-Message-State":"AMCzsaXxTE7nefOgYBmDZ96A9cT8R0aaOe6YM1aAZ+nnhJx3IorWCA+O\n\to4iGZEmtkTlkzvbRLLCOjTmsZ3JBKDXN+kKSZ94=","X-Google-Smtp-Source":"AOwi7QAdV/N6xGLxzdTEm1DtTx6xuLocDTuHDxMC5zoo8Tv8cznLLGnADfQkM03D8Zd1VhbfwRDEsBCT0TOJ0hLkmwU=","X-Received":"by 10.233.223.2 with SMTP id t2mr11599961qkf.331.1508133318968; \n\tSun, 15 Oct 2017 22:55:18 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20171013184646.cy5gmpwrxbacje3m@ninjato>","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>","From":"Harini Katakam ","Date":"Mon, 16 Oct 2017 11:25:18 +0530","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Wolfram Sang ","Cc":"Andrew Worsley ,\n\tMichal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1787270,"web_url":"http://patchwork.ozlabs.org/comment/1787270/","msgid":"","list_archive_url":null,"date":"2017-10-16T09:18:37","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":68717,"url":"http://patchwork.ozlabs.org/api/people/68717/","name":"Andrew Worsley","email":"amworsley@gmail.com"},"content":"Thanks I think I know understand how this transfer register is set up.\nI will add some diagnostic printk's to track down exactly how it is\nfailing and get back to you.\n\n Yes it is zynq. The test case is large (128 byte) transfers from a\ntpm to fill an rng driver. I just pull large amounts of data via dd.\n\nIt may depend on the i2c slave being willing to just respond to\nrequests that read arbitrary amounts of data. In this case the TPM\nappeared to generate FF when requested for more data than was in the\nTPM_RANDOM request.\n\n\n\nOn 16 October 2017 at 16:55, Harini Katakam\n wrote:\n> Hi Andrew,\n>\n> On Sat, Oct 14, 2017 at 12:16 AM, Wolfram Sang wrote:\n.....\n>>\n>> So, let's add Harini Katakam to CC who implemented this. But I'd be\n>> happy for anyone from Xilinx to respond...\n>\n> The workaround you are referring to is implemented under\n> \"if (cdns_is_holdquirk(id, hold_quirk)) {\"\n> and should not apply to your case of 128 byte transfer at all.\n\nAh I can see the logic now. If the transfer is small (< 250 or so\nbytes) it will just write it into the transfer register. Yes my\ntransfers are only 128 + some TPM related headers ( not big I expect).\n....\n\n\n>\n> The specific place you have problem is under the loop\n> where RX data valid is being checked and ideally, that\n> buffer should never be written with more data than requested -\n> because no. of bytes requested is written to transfer size register,\n> the same is the amount the controller (master) fetches and\n> RX data valid remains set only for that duration.\n\nIf the transfer register was set with the\n>\n> Are you using Zynq?\n> I'm not working on this anymore but we could take a look at\n> your error if we are able to reproduce it.\n> Could you please provide more details of your application and\n> setup?\n>\n> Regards,\n> Harini\n\nYes - I will get back to you with more details and further debugging\naround exactly how it is failing.\n\nAssuming it is not obvious how to fix it - perhaps I can try setting\nthe transfer register to zero when it hits the end of the transfer?\n(if recv_count == 0).\n\nThanks very much Harini - that was just the pointer I needed to\nfollow the code.\n\nAndrew","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"Xhhi+b3q\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yFt6W4Pdjz9sPk\n\tfor ;\n\tMon, 16 Oct 2017 20:18:43 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751802AbdJPJSl (ORCPT );\n\tMon, 16 Oct 2017 05:18:41 -0400","from mail-vk0-f52.google.com ([209.85.213.52]:53992 \"EHLO\n\tmail-vk0-f52.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751501AbdJPJSi (ORCPT\n\t); Mon, 16 Oct 2017 05:18:38 -0400","by mail-vk0-f52.google.com with SMTP id c76so7181553vkd.10\n\tfor ; Mon, 16 Oct 2017 02:18:38 -0700 (PDT)","by 10.176.72.233 with HTTP; Mon, 16 Oct 2017 02:18:37 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=2yiBEk09GZFy4g+4Evd2fpS+SoYMAVJqajT7mmKl4C4=;\n\tb=Xhhi+b3qDCpuqyfE7uQHpTe2QKAIBOnyXTIQ6jf0Nm99wBW2qvffgrmgLVMyovuff6\n\tXFWt9ZYLGARqr4Ccn2W40FqyynLDzYSv1yQqSp/TKXqOu7WiSNzJzhtNYDrOVXSvV9jr\n\tA2OQ+vHP+LT9QbqpJ0jQdiX9HJZ7I8Mm/rpanm2GSoTX9flvVtPaWbkgemVKdZKocRvm\n\tmnhIdvzfw2v/oy3k12w7NbZ0H9lpsLsz3utihmf1pzyuzHjLW8HJWnJorysoG3rqAhIj\n\tXEXDvlZoXjb9kKdvxY0bRqKS9q1fa9KNFd1dCCrWMGNj8FFeX8ZnE9wZ1JPHw8+WjlyC\n\tsaTA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=2yiBEk09GZFy4g+4Evd2fpS+SoYMAVJqajT7mmKl4C4=;\n\tb=bYjHDDeGzqC7XGSv0MGo+KlVQm15mrkDi0VkIEqPgp1zGo1HfuVh2xGhVY3WhntZ1r\n\tzpVOa8hLDdg2HF/A61RCRveC+f7S7KDbVAWn8GUvo3zHGheMK7YeoAcfH356Y2O4Jslt\n\tWLrht2iLhyGoHo4IbTHb1Iox2QAb2VFH4RhsqExO0ICDlgiLRJQzvPpZ9xSzhZDmvYe6\n\tsPE5TUBIbcK/6rCz/0RHvrBpqyUMm5M704PWkVzHRATXL2mX23Sh+XPcro2yOMTOXXfv\n\t7JsJb9SluZ4UIp92OdK7W9rEdmKJ0ur8dYRhSnuAHEEi5Tm7KD6KLOYcThLmjurKgbvr\n\tBIYg==","X-Gm-Message-State":"AMCzsaX9JW1NYim+aeydHK+t1Wi7KLUuwkJmosbLaP+BcPD8bUj3oiC1\n\tsnKt9cW/Idb0KhrsKC6slVdufx6YVm0Pg6Gfoj4=","X-Google-Smtp-Source":"AOwi7QAAq6VbtlkdP+EBSmiGvBvuAyHZYMkgmcm0bijAQoiAF70RvMrLLcXQRUZQaf/j7lcmTR3ttvL7VILsXQjxBws=","X-Received":"by 10.31.195.195 with SMTP id t186mr6973935vkf.198.1508145517838;\n\tMon, 16 Oct 2017 02:18:37 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t","From":"Andrew Worsley ","Date":"Mon, 16 Oct 2017 20:18:37 +1100","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Harini Katakam ","Cc":"Wolfram Sang , Michal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1787325,"web_url":"http://patchwork.ozlabs.org/comment/1787325/","msgid":"","list_archive_url":null,"date":"2017-10-16T10:38:30","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":62785,"url":"http://patchwork.ozlabs.org/api/people/62785/","name":"Harini Katakam","email":"harinikatakamlinux@gmail.com"},"content":"Hi Andrew,\n\nOn Mon, Oct 16, 2017 at 2:48 PM, Andrew Worsley wrote:\n> Thanks I think I know understand how this transfer register is set up.\n> I will add some diagnostic printk's to track down exactly how it is\n> failing and get back to you.\n>\n> Yes it is zynq. The test case is large (128 byte) transfers from a\n> tpm to fill an rng driver. I just pull large amounts of data via dd.\n>\n> It may depend on the i2c slave being willing to just respond to\n> requests that read arbitrary amounts of data. In this case the TPM\n> appeared to generate FF when requested for more data than was in the\n> TPM_RANDOM request.\n>\n>\n>\n> On 16 October 2017 at 16:55, Harini Katakam\n> wrote:\n>> Hi Andrew,\n>>\n>> On Sat, Oct 14, 2017 at 12:16 AM, Wolfram Sang wrote:\n> .....\n>>>\n>>> So, let's add Harini Katakam to CC who implemented this. But I'd be\n>>> happy for anyone from Xilinx to respond...\n>>\n>> The workaround you are referring to is implemented under\n>> \"if (cdns_is_holdquirk(id, hold_quirk)) {\"\n>> and should not apply to your case of 128 byte transfer at all.\n>\n> Ah I can see the logic now. If the transfer is small (< 250 or so\n> bytes) it will just write it into the transfer register. Yes my\n> transfers are only 128 + some TPM related headers ( not big I expect).\n> ....\n>\n>\n>>\n>> The specific place you have problem is under the loop\n>> where RX data valid is being checked and ideally, that\n>> buffer should never be written with more data than requested -\n>> because no. of bytes requested is written to transfer size register,\n>> the same is the amount the controller (master) fetches and\n>> RX data valid remains set only for that duration.\n>\n> If the transfer register was set with the\n\nYes, this is assuming the transfer size register was not set inittially\nor later with more byted than required.\n\n>>\n>> Are you using Zynq?\n>> I'm not working on this anymore but we could take a look at\n>> your error if we are able to reproduce it.\n>> Could you please provide more details of your application and\n>> setup?\n>>\n>> Regards,\n>> Harini\n>\n> Yes - I will get back to you with more details and further debugging\n> around exactly how it is failing.\n>\n> Assuming it is not obvious how to fix it - perhaps I can try setting\n> the transfer register to zero when it hits the end of the transfer?\n> (if recv_count == 0).\n\nYes, that can be done as a workaround but ideally, the transfer\nsize register should have decremented to zero by this point.\n\n>\n> Thanks very much Harini - that was just the pointer I needed to\n> follow the code.\n\nThanks for the information - please let me know what you find.\n\nRegards,\nHarini","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"AtYGE9fK\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yFvtd6MnSz9s7h\n\tfor ;\n\tMon, 16 Oct 2017 21:38:33 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751410AbdJPKic (ORCPT );\n\tMon, 16 Oct 2017 06:38:32 -0400","from mail-qt0-f178.google.com ([209.85.216.178]:44482 \"EHLO\n\tmail-qt0-f178.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750914AbdJPKib (ORCPT\n\t); Mon, 16 Oct 2017 06:38:31 -0400","by mail-qt0-f178.google.com with SMTP id 8so30582555qtv.1\n\tfor ; Mon, 16 Oct 2017 03:38:31 -0700 (PDT)","by 10.200.11.71 with HTTP; Mon, 16 Oct 2017 03:38:30 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=16DMZFZsTQsNIZLb8lG8ARsSPqCGr+A4n6xYUy3j8hg=;\n\tb=AtYGE9fKElTZatPduY5R4ZckVqraAJzrRNS3V1uS5qRMv4aaoGn14YH2D7zw0S0g3O\n\tgTh6lYe5WmUxCE9pHpat9yQKhiQyr7c6yJsJHkgkOPbTQCMQs8VFY1tSfsCB6wawdt1T\n\tXYvsGfSaa+iKRrjK/FazMci84T+mKEB+Mn1f2lFSrmmJoIkNrCgC5k3wizrpywdEIjp4\n\tX7SfyP0Byypd0cDDN3gIsEFr2iYYU0EREm3NNUfIsajWhpzZKdvbTgoAarMYLPXiGDvI\n\twTNEo3FtP5R/s1+QF3JGSV2IkomoK6okM1WooYisTOgGu3aFeimrVbh6JoOuwQjCQ3Ok\n\tiViA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=16DMZFZsTQsNIZLb8lG8ARsSPqCGr+A4n6xYUy3j8hg=;\n\tb=HXDBrFC/eWYf3sedT7KjANZG6pF90AL1q12gwoahRtZThMdaskvOTHVH+VI2Y8jIlp\n\tBs9P+oTsm0vovSgPJ+AUXRUtcln0WpDUyvO2jDyVr+89KDn5ZvK0EYldkPW4ELHHuXZH\n\tizByD4CiEv+9tQ0MtbAzMmF9NZv1degTHSzT4giasznic8jxVZfiqINTN3aFisMUlAXp\n\tG+EE+owlemcMv5x+ZPs0qGQatSslyGC0OUkfouTXRYD15bxyHVZYiRj48zzKFXFZgxqK\n\tnQmmTB+5fn3OkYOWiv9rkJ5f6EakMcw8HjWQMNp7cKM8s9muN1xNAIiqgho2tnal2zNj\n\tdNtQ==","X-Gm-Message-State":"AMCzsaUI6zc8kizgL+I2Sa0felz342RlkN8KiOuKzJw5F54k+vCbNpHY\n\tU6Rc/MTQ1VYWuLvVaPSMQoDQXlbyt5pLPDu9wDA=","X-Google-Smtp-Source":"AOwi7QCTQBjDoVWNlTW7eOJUvkTQjQ89JHF9ubDeXgk29JZq/seNhc/HI+akhqtB4UrjasyMLjvNmYYptEA4SKOQjgk=","X-Received":"by 10.200.53.89 with SMTP id z25mr14028727qtb.58.1508150310646; \n\tMon, 16 Oct 2017 03:38:30 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t","From":"Harini Katakam ","Date":"Mon, 16 Oct 2017 16:08:30 +0530","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Andrew Worsley ","Cc":"Wolfram Sang , Michal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ,\n\tHarini Katakam ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1789300,"web_url":"http://patchwork.ozlabs.org/comment/1789300/","msgid":"","list_archive_url":null,"date":"2017-10-18T09:41:26","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":68717,"url":"http://patchwork.ozlabs.org/api/people/68717/","name":"Andrew Worsley","email":"amworsley@gmail.com"},"content":"On 16 October 2017 at 21:38, Harini Katakam\n wrote:\n> Hi Andrew,\n\nHi Harini, I did manage to reproduce the issue and got some more info\non the bug some more\n- but I don't really understanding the cause.\n\n> On Mon, Oct 16, 2017 at 2:48 PM, Andrew Worsley wrote:\n>> Thanks I think I know understand how this transfer register is set up.\n>> I will add some diagnostic printk's to track down exactly how it is\n>> failing and get back to you.\n\n\nIt appears to be working fine and then just fails with the transfer\nsize register value set to 242.\nAlways the value 240 or 242 in the transfer register.\n\n>>\n>> Yes it is zynq. The test case is large (128 byte) transfers from a\n>> tpm to fill an rng driver. I just pull large amounts of data via dd.\n>>\n\nI have a lot of data so I will summarise it and I can post more\ndetails on what people want to know.\n\nI added printk's on each i2c operation and each write to the transfer\nsize register.\nWhen the overrun is hit it prints out most of the registers, about\nhalf the time the overflow bit is set.\n\nHere is my last output which has the most diagnostics:\n...\n[ 15.607821] zs2 kernel: cdns_i2c_process_msg: Rd len=142 #8\n[ 15.607826] zs2 kernel: cdns_i2c_mrecv:cdns_i2c_writereg(142,\nCDNS_I2C_XFER_SIZE_OFFSET)\n #6\n[ 15.611343] zs2 kernel: cdns_i2c_process_msg: Wr len=14 #8\n[ 15.611777] zs2 kernel: cdns_i2c_process_msg: Rd len=35 #8\n[ 15.611781] zs2 kernel: cdns_i2c_mrecv:cdns_i2c_writereg(35,\nCDNS_I2C_XFER_SIZE_OFFSET)\n#6\n[ 15.611836] zs2 kernel: cdns_i2c_master_reset:cdns_i2c_writereg(0,\nCDNS_I2C_XFER_SIZE_OF\nFSET) #4\n[ 15.612847] zs2 kernel: cdns_i2c_process_msg: Rd len=35 #8\n[ 15.612850] zs2 kernel: cdns_i2c_mrecv:cdns_i2c_writereg(35,\nCDNS_I2C_XFER_SIZE_OFFSET)\n#6\n[ 15.612911] zs2 kernel: cdns_i2c_master_reset:cdns_i2c_writereg(0,\nCDNS_I2C_XFER_SIZE_OF\nFSET) #4\n[ 15.613924] zs2 kernel: cdns_i2c_process_msg: Rd len=35 #8\n[ 15.613928] zs2 kernel: cdns_i2c_mrecv:cdns_i2c_writereg(35,\nCDNS_I2C_XFER_SIZE_OFFSET)\n#6\n[ 15.614836] zs2 kernel: tpm_transmit: after req_complete_val status=0x1\n[ 15.614846] zs2 kernel: cdns_i2c_process_msg: Rd len=142 #8\n[ 15.614851] zs2 kernel: cdns_i2c_mrecv:cdns_i2c_writereg(142,\nCDNS_I2C_XFER_SIZE_OFFSET)\n #6\n[ 15.626087] zs2 kernel: cdns_i2c_isr: buffer overrunning !!!-\ntransfer-size=242 ctrl=0xc0f status=0x120 int-status=0x0\n[ 15.626091] zs2 kernel: cdns_i2c_isr:Aborting transfer...\n....\n\nI tried to handle situation by setting the transfer register to zero\nand breaking out of the loop which is copying bytes out of the FIFO.\nAt no time are any of the transfers bigger than 142 bytes or so as\nshown above. So the driver always sets the transfer register to the\nfull size.\n\nThe only writes to the transfer register are 0, 1, 35 and 142. I\nnever see an overly large write to the transfer register.\n\n>>> Could you please provide more details of your application and\n>>> setup?\n>>>\n>>> Regards,\n>>> Harini\n>>\n\nI originally discovered the flaw with two of the last i2c-cadence\ndriver fixes not present\n\n Initialize-configuration-before-prob\n fix-ctrl-addr-reg-write-order\n\n and a fair amount of debug in the TPM driver - then the bug hit\nnearly every run.\nWith these two i2c fixes in it occured only once per 4-5 runs.\n\nPerhaps this information gives some one a path to investigate further?\nI can't really see how this transfer size register can get confused -\nespecially always with 240 or 242 = 255-13\nPerhaps the transfer register rolls over from zero or something?\nOr Perhaps I am just looking for magic numbers?\n\n\n>>\n>> Assuming it is not obvious how to fix it - perhaps I can try setting\n>> the transfer register to zero when it hits the end of the transfer?\n>> (if recv_count == 0).\n>\n> Yes, that can be done as a workaround but ideally, the transfer\n> size register should have decremented to zero by this point.\n\nSetting the transfer size to zero and then doing a break on an error\nis ok but causes the transfer to fail still.\nNow thinking about it perhaps I should have done a continue - so the\nloop would terminate more naturally.\n\n>>\n>> Thanks very much Harini - that was just the pointer I needed to\n>> follow the code.\n>\n> Thanks for the information - please let me know what you find.\n>\n> Regards,\n>\n\nLet me know if you have any other suggestions for me to try. my tpm\ndriver changes are not in main line so it's hard for anyone else to do\nexactly that test case.\nI can't get back to this till next week so I won't be able to try this\ntill then.\nMy thoughts are to remove the TPM debugging code to confirm that no\nother changes are needed to reproduce this issue.\nBut I can't see how anything can overwrite the transfer register.\n\n> Harini\n\nI attach a patch of the changes to the i2c driver showing my debug in\nthis driver.\nAs I said I am happy to send more verbose bug output - I have about 36\nodd runs with 9 occurences of the bug.\nOnce it happen twice in the one run\n\nI include the crashing line from the runs where the bug occured (I\nadded more diagnostics as the runs progressed):\n% grep overrunning i2c-tpm-run*\ni2c-tpm-run12-bad-rev-ecbd28b9.txt:[ 8.543441] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=242\ni2c-tpm-run13-bad-rev-ecbd28b9.txt:[ 16.193018] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=242\ni2c-tpm-run18-bad-rev-ecbd28b9.txt:[ 26.065783] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=240 ctrl=0xc0f\nstatus=0xa0 int-status=0x0\ni2c-tpm-run18-bad-rev-ecbd28b9.txt:[ 30.272113] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=240 ctrl=0xc0f\nstatus=0xa0 int-status=0x0\ni2c-tpm-run21-bad-rev-ecbd28b9.txt:[ 20.162880] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=240 ctrl=0xc0f\nstatus=0xa0=>Overflow<= int-status=0x0\ni2c-tpm-run24-bad-rev-ecbd28b9.txt:[ 15.191316] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=242 ctrl=0xc0f\nstatus=0x120 int-status=0x0\ni2c-tpm-run26-bad-rev-ecbd28b9.txt:[ 18.370014] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=240 ctrl=0xc0f\nstatus=0xa0=>Overflow<= int-status=0x0\ni2c-tpm-run30-bad-rev-ecbd28b9.txt:[ 20.177092] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=242 ctrl=0xc0f\nstatus=0x120 int-status=0x0\ni2c-tpm-run36-bad-rev-ecbd28b9.txt:[ 15.626087] zs2 kernel:\ncdns_i2c_isr: buffer overrunning !!!- transfer-size=242 ctrl=0xc0f\nstatus=0x120 int-status=0x0\n\nI attach the diff of the changes to the i2c-cadence driver file\n\nSuggestions appreciated.\n\nAndrew\ndiff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c\nindex 75d80161931f..a6103c303b08 100644\n--- a/drivers/i2c/busses/i2c-cadence.c\n+++ b/drivers/i2c/busses/i2c-cadence.c\n@@ -246,6 +246,20 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)\n \t\t\t !id->bus_hold_flag)\n \t\t\t\tcdns_i2c_clear_bus_hold(id);\n \n+ if (id->recv_count == 0)\n+ {\n+ unsigned int st = cdns_i2c_readreg(CDNS_I2C_SR_OFFSET);\n+ pr_notice(\"%s: buffer overrunning !!!- transfer-size=%d ctrl=%#x status=%#x%s int-status=%#x\\n\",\n+ __func__,\n+ cdns_i2c_readreg(CDNS_I2C_XFER_SIZE_OFFSET),\n+ cdns_i2c_readreg(CDNS_I2C_CR_OFFSET),\n+ st, st & BIT(7) ? \"=>Overflow<=\" : \"\",\n+ cdns_i2c_readreg(CDNS_I2C_ISR_OFFSET)\n+ );\n+ pr_notice(\"%s:Aborting transfer...\\n\", __func__);\n+ cdns_i2c_writereg(0, CDNS_I2C_XFER_SIZE_OFFSET);\n+ break;\n+ }\n \t\t\t*(id->p_recv_buf)++ =\n \t\t\t\tcdns_i2c_readreg(CDNS_I2C_DATA_OFFSET);\n \t\t\tid->recv_count--;\n@@ -274,11 +288,15 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)\n \t\t\t */\n \t\t\tif (((int)(id->recv_count) - CDNS_I2C_FIFO_DEPTH) >\n \t\t\t CDNS_I2C_TRANSFER_SIZE) {\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #1\\n\",\n+ __func__, CDNS_I2C_TRANSFER_SIZE);\n \t\t\t\tcdns_i2c_writereg(CDNS_I2C_TRANSFER_SIZE,\n \t\t\t\t\t\t CDNS_I2C_XFER_SIZE_OFFSET);\n \t\t\t\tid->curr_recv_count = CDNS_I2C_TRANSFER_SIZE +\n \t\t\t\t\t\t CDNS_I2C_FIFO_DEPTH;\n \t\t\t} else {\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #2\\n\",\n+ __func__, id->recv_count - CDNS_I2C_FIFO_DEPTH);\n \t\t\t\tcdns_i2c_writereg(id->recv_count -\n \t\t\t\t\t\t CDNS_I2C_FIFO_DEPTH,\n \t\t\t\t\t\t CDNS_I2C_XFER_SIZE_OFFSET);\n@@ -292,10 +310,14 @@ static irqreturn_t cdns_i2c_isr(int irq, void *ptr)\n \t\t\t\t\t\tCDNS_I2C_ADDR_OFFSET);\n \n \t\t\tif (id->recv_count > CDNS_I2C_TRANSFER_SIZE) {\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #3\\n\",\n+ __func__, CDNS_I2C_TRANSFER_SIZE);\n \t\t\t\tcdns_i2c_writereg(CDNS_I2C_TRANSFER_SIZE,\n \t\t\t\t\t\tCDNS_I2C_XFER_SIZE_OFFSET);\n \t\t\t\tid->curr_recv_count = CDNS_I2C_TRANSFER_SIZE;\n \t\t\t} else {\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #4\\n\",\n+ __func__, id->recv_count);\n \t\t\t\tcdns_i2c_writereg(id->recv_count,\n \t\t\t\t\t\tCDNS_I2C_XFER_SIZE_OFFSET);\n \t\t\t\tid->curr_recv_count = id->recv_count;\n@@ -398,10 +420,14 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)\n \t * it is more. Enable the interrupts.\n \t */\n \tif (id->recv_count > CDNS_I2C_TRANSFER_SIZE) {\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #5\\n\",\n+ __func__, CDNS_I2C_XFER_SIZE_OFFSET);\n \t\tcdns_i2c_writereg(CDNS_I2C_TRANSFER_SIZE,\n \t\t\t\t CDNS_I2C_XFER_SIZE_OFFSET);\n \t\tid->curr_recv_count = CDNS_I2C_TRANSFER_SIZE;\n \t} else {\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #6\\n\",\n+ __func__, id->recv_count);\n \t\tcdns_i2c_writereg(id->recv_count, CDNS_I2C_XFER_SIZE_OFFSET);\n \t}\n \n@@ -499,6 +525,8 @@ static void cdns_i2c_master_reset(struct i2c_adapter *adap)\n \tregval |= CDNS_I2C_CR_CLR_FIFO;\n \tcdns_i2c_writereg(regval, CDNS_I2C_CR_OFFSET);\n \t/* Update the transfercount register to zero */\n+ pr_info(\"%s:cdns_i2c_writereg(%d, CDNS_I2C_XFER_SIZE_OFFSET) #4\\n\",\n+ __func__, 0);\n \tcdns_i2c_writereg(0, CDNS_I2C_XFER_SIZE_OFFSET);\n \t/* Clear the interupt status register */\n \tregval = cdns_i2c_readreg(CDNS_I2C_ISR_OFFSET);\n@@ -530,6 +558,7 @@ static int cdns_i2c_process_msg(struct cdns_i2c *id, struct i2c_msg *msg,\n \t\t\t\t\tCDNS_I2C_CR_OFFSET);\n \t}\n \n+ pr_info(\"%s: %s len=%d #8\\n\", __func__, msg->flags & I2C_M_RD ? \"Rd\" : \"Wr\", msg->len);\n \t/* Check for the R/W flag on each msg */\n \tif (msg->flags & I2C_M_RD)\n \t\tcdns_i2c_mrecv(id);\n@@ -629,6 +658,7 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,\n \t\t\t\tgoto out;\n \t\t\t}\n \t\t\tret = -EIO;\n+\t\t\tpr_info(\"%s: id->err_status=%#x\\n\", __func__, id->err_status);\n \t\t\tgoto out;\n \t\t}\n \t}","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"KxR8x0LO\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yH6Wv4Z5rz9t3B\n\tfor ;\n\tWed, 18 Oct 2017 20:41:31 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S934153AbdJRJla (ORCPT );\n\tWed, 18 Oct 2017 05:41:30 -0400","from mail-ua0-f169.google.com ([209.85.217.169]:52026 \"EHLO\n\tmail-ua0-f169.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S933078AbdJRJl2 (ORCPT\n\t); Wed, 18 Oct 2017 05:41:28 -0400","by mail-ua0-f169.google.com with SMTP id 47so3098483uas.8\n\tfor ; Wed, 18 Oct 2017 02:41:28 -0700 (PDT)","by 10.176.72.233 with HTTP; Wed, 18 Oct 2017 02:41:26 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=rJx1rUfnwu7TuRO6pWSLaDZUeWuQM1wf0kVaupFjDY8=;\n\tb=KxR8x0LOdReZ9k9I/rmzMsNq+OPVFRLkaWImPhSgA/WxJZKhgpHZXUn/FyYFZ6b1Uf\n\t3FTN10dwJT68rJ/+W9PXADjmQ5P5X3AODOQQGhOamav6eFuHl5uOFVy+y6XbR0FrPS+b\n\t/9w0tnfKzR+wvpae/6hPaUjFD0ZEND7DYeSBOzwyGkc9wGMocm07IHf05yiki6eUlqHc\n\t7kOgfYoTAidlQ3DTOI2Ya+KOBYkzCX2cycOejANYQ1V3HpYBTj0E/2qxaDXUAIbwGIt1\n\tH5BdMmihAX0FKMnjFpIwcDHReP1zb7sTTMWY+j3aKyTJH7plBWR0cJSTUpYxd3Cz4Mgn\n\tRulA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=rJx1rUfnwu7TuRO6pWSLaDZUeWuQM1wf0kVaupFjDY8=;\n\tb=KK0blBs4edV7jZxLUfZJEPb5ww57S5gV9MqsEr7cU2eKflbEBulmJC49h9k+Qk5xiF\n\tvBuSfAdmqCW5nZXEMNBbw3YgJ9Q/h3FDRNXRTLFkliAEjjHWPWtjaamBCsSbSbf/lX3b\n\tI5aMsGGYjMZgRyvpZUtODt6uJiH96jq7k8+ooig0OfvH2dn4kFgq8j8eVdy2hEqOsQcH\n\tmbIdyimGCkquPaJoFh0IxFONdKbByh3ZJLigx/VIVbtppfLyLigUlUvtNlpAs16mWjmS\n\ts2uiZJb7eGyFta8CiSsZ2uSUld+ORCPXFI5NqFLDagDgxNgY+PaHJA+Lm+S0M4JAMMYH\n\toSnw==","X-Gm-Message-State":"AMCzsaUeRxtZPlWohQVl//Bv8qpRkfpcOC6lfXhNFnqInWFXhjhmzMcU\n\tEtdhHmjeEkqNqUeoONUuRF7r6Vp6a5wFveoqKJ8=","X-Google-Smtp-Source":"AOwi7QBOUGoJsoL9PIcElV+sGF4cRkSLjNcHAS0MygccuvOkjrDgC4R6LgjX22phOba7+iZKH5Viq46iieXaU7AnytU=","X-Received":"by 10.176.21.35 with SMTP id o32mr12188035uae.177.1508319687465; \n\tWed, 18 Oct 2017 02:41:27 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t\n\t","From":"Andrew Worsley ","Date":"Wed, 18 Oct 2017 20:41:26 +1100","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Harini Katakam ","Cc":"Wolfram Sang , Michal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ,\n\tHarini Katakam ","Content-Type":"multipart/mixed; boundary=\"001a11428a542dfe98055bcf0b77\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1791106,"web_url":"http://patchwork.ozlabs.org/comment/1791106/","msgid":"","list_archive_url":null,"date":"2017-10-20T05:04:44","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":62785,"url":"http://patchwork.ozlabs.org/api/people/62785/","name":"Harini Katakam","email":"harinikatakamlinux@gmail.com"},"content":"Hi Andrew,\n\nOn Wed, Oct 18, 2017 at 3:11 PM, Andrew Worsley wrote:\n\n> Perhaps this information gives some one a path to investigate further?\n> I can't really see how this transfer size register can get confused -\n> especially always with 240 or 242 = 255-13\n> Perhaps the transfer register rolls over from zero or something?\n> Or Perhaps I am just looking for magic numbers?\n\nThanks for the debug Andrew..\nWe do have one known issue for Zynq:\nhttps://www.xilinx.com/support/answers/61664.html\nThe patch for >252 byte transfers was a workaround to this.\nIn short, the I2C master generates invalid clocks and\nstarts reading extra bytes (0xFFs) when the transfer size register\nreaches zero and the hold bit is set (as is the case with >252 transfers).\nThe transfer size register does roll over to 255 in this case.\nBut in case of 242 bytes or all the other values (13, 142) written\nto transfer size register, I don't see this errata coming into picture.\n\n\n\n> I attach a patch of the changes to the i2c driver showing my debug in\n> this driver.\n> As I said I am happy to send more verbose bug output - I have about 36\n> odd runs with 9 occurences of the bug.\n> Once it happen twice in the one run\n>\n> I include the crashing line from the runs where the bug occured (I\n> added more diagnostics as the runs progressed):\n\nI'll check with out HW team as well and check your flow to\nsee if we can reproduce it; will also check if the existing errata\nhas larger scope.\nI'll let you know if we require further assistance with debug\nnext week.\n\nRegards,\nHarini","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"oHXQQhcg\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yJDHf4RWXz9tY0\n\tfor ;\n\tFri, 20 Oct 2017 16:04:46 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750773AbdJTFEq (ORCPT );\n\tFri, 20 Oct 2017 01:04:46 -0400","from mail-qt0-f178.google.com ([209.85.216.178]:52246 \"EHLO\n\tmail-qt0-f178.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750752AbdJTFEp (ORCPT\n\t); Fri, 20 Oct 2017 01:04:45 -0400","by mail-qt0-f178.google.com with SMTP id 31so17133888qtz.9\n\tfor ; Thu, 19 Oct 2017 22:04:45 -0700 (PDT)","by 10.200.11.71 with HTTP; Thu, 19 Oct 2017 22:04:44 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=OHcEP8BE5jxiC8zSGe22jnHXOnNwMHJulIHz2Xga40E=;\n\tb=oHXQQhcg8QmTcJEqLLXBSf04WnMXt7wtEORa7iyo7BwbJDH3giZpb4K2aStXPBpgdf\n\tDf8SD+UTfyrSmduWKij1kZyWUk1qEH789yBcdBtpRsEMTJLsTVi+lleOjUMakzuwnv0v\n\tAbC53lHkRrSAAzkQ9xqSwcUmlYQyY62tw7I0WM+nS8xB3jcH93DaGCunj9YM5jUyqGEx\n\t0OgkVn8iQm4Iix/eJh6daivDDmMZPY0vh9c+0WJS5H5ecqlSBak6wYz/YVGYutbDZrPX\n\tKAvStqnUaptGo4y6w3Sm1Cdq6NLFXqAYlGeL/gtYxVu7LEOqZrnncOyTR+N/6tKwWGvl\n\tIcIA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=OHcEP8BE5jxiC8zSGe22jnHXOnNwMHJulIHz2Xga40E=;\n\tb=lIcLD/LCFQQecioi6YpTXDxCpZyd0/+aMBkryOgsypfZ8D/qrdJOAWIuRdwBBx7fbB\n\tVMYialhOdUO5kPFMn0tEBSRMH2E16kTSVyBR+pqpZP9NhmIoWC2Dcdb41FM2N/BWpvAw\n\t/3eqbyy1P116RtZHFEojDi9BTs0IKl672TmafKt78mIdoBtUhCxAtiyoMwMDQit7K+5M\n\tWeHHZrgFDtGfp5mBUEd5nnyCKsWBn4yUDNUnzqQCW0PH+OFcgRwPq8hLEK70btSpdB+o\n\t+MzE6Q/RPG1M4tq8eCOtItTtrD35Qke69pytalJ7UiPjPt0BStJisCCdRz9Rukij4BFc\n\tv17w==","X-Gm-Message-State":"AMCzsaVVnGYh4d3VH3SZXfmqEP2Z9pe35zq08rn1lJHr3UCrEgBhQBuB\n\tpnygrW4TCVMuPpafGHJklGp8WbVlPFTG/7q5Ils=","X-Google-Smtp-Source":"ABhQp+TQEBaYWbB4N1mqg8n9ma9j1UYdSlYsT4/qbCTk/h/ugAV0902T24ltBSJN8dQsKbbQXlMDYv1orQvgyW67Rtg=","X-Received":"by 10.237.62.45 with SMTP id l42mr5628034qtf.46.1508475884738;\n\tThu, 19 Oct 2017 22:04:44 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t\n\t\n\t","From":"Harini Katakam ","Date":"Fri, 20 Oct 2017 10:34:44 +0530","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Andrew Worsley ","Cc":"Wolfram Sang , Michal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1817587,"web_url":"http://patchwork.ozlabs.org/comment/1817587/","msgid":"<20171207104915.fdqkj35ga2yxeg3n@ninjato>","list_archive_url":null,"date":"2017-12-07T10:49:15","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":22495,"url":"http://patchwork.ozlabs.org/api/people/22495/","name":"Wolfram Sang","email":"wsa@the-dreams.de"},"content":"> > I attach a patch of the changes to the i2c driver showing my debug in\n> > this driver.\n> > As I said I am happy to send more verbose bug output - I have about 36\n> > odd runs with 9 occurences of the bug.\n> > Once it happen twice in the one run\n> >\n> > I include the crashing line from the runs where the bug occured (I\n> > added more diagnostics as the runs progressed):\n> \n> I'll check with out HW team as well and check your flow to\n> see if we can reproduce it; will also check if the existing errata\n> has larger scope.\n> I'll let you know if we require further assistance with debug\n> next week.\n\nAny news here?","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yssg26k7Bz9sMN\n\tfor ;\n\tThu, 7 Dec 2017 21:49:18 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752312AbdLGKtR (ORCPT );\n\tThu, 7 Dec 2017 05:49:17 -0500","from sauhun.de ([88.99.104.3]:55615 \"EHLO pokefinder.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750913AbdLGKtR (ORCPT );\n\tThu, 7 Dec 2017 05:49:17 -0500","from localhost (unknown [145.253.130.2])\n\tby pokefinder.org (Postfix) with ESMTPSA id E25452C3356;\n\tThu, 7 Dec 2017 11:49:15 +0100 (CET)"],"Date":"Thu, 7 Dec 2017 11:49:15 +0100","From":"Wolfram Sang ","To":"Harini Katakam ","Cc":"Andrew Worsley ,\n\tMichal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","Message-ID":"<20171207104915.fdqkj35ga2yxeg3n@ninjato>","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t\n\t\n\t\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"4twrd6hgxtjb2646\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1817717,"web_url":"http://patchwork.ozlabs.org/comment/1817717/","msgid":"","list_archive_url":null,"date":"2017-12-07T13:30:40","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":62785,"url":"http://patchwork.ozlabs.org/api/people/62785/","name":"Harini Katakam","email":"harinikatakamlinux@gmail.com"},"content":"Hi Wolfram and Andrew,\n\nOn Thu, Dec 7, 2017 at 4:19 PM, Wolfram Sang wrote:\n>\n>> > I attach a patch of the changes to the i2c driver showing my debug in\n>> > this driver.\n>> > As I said I am happy to send more verbose bug output - I have about 36\n>> > odd runs with 9 occurences of the bug.\n>> > Once it happen twice in the one run\n>> >\n>> > I include the crashing line from the runs where the bug occured (I\n>> > added more diagnostics as the runs progressed):\n>>\n>> I'll check with out HW team as well and check your flow to\n>> see if we can reproduce it; will also check if the existing errata\n>> has larger scope.\n>> I'll let you know if we require further assistance with debug\n>> next week.\n>\n> Any news here?\n\nSorry for the delay.\nI've checked the known errata and confirmed that it wont\naffect this use case. And we haven't been able to hit this\nissue on our HW (with eeprom slave devices).\nI will add my colleague looking into this further to debug.\n\nRegards,\nHarini","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"Y3Bra8qu\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3ysxFK3kK4z9s4s\n\tfor ;\n\tFri, 8 Dec 2017 00:30:45 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753311AbdLGNan (ORCPT );\n\tThu, 7 Dec 2017 08:30:43 -0500","from mail-qt0-f182.google.com ([209.85.216.182]:43230 \"EHLO\n\tmail-qt0-f182.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753108AbdLGNal (ORCPT\n\t); Thu, 7 Dec 2017 08:30:41 -0500","by mail-qt0-f182.google.com with SMTP id w10so17412343qtb.10\n\tfor ; Thu, 07 Dec 2017 05:30:41 -0800 (PST)","by 10.200.53.229 with HTTP; Thu, 7 Dec 2017 05:30:40 -0800 (PST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=3aXcuLnzoJf6NoLHrPGyMczsmLWkFvwh2N6iotvTjaI=;\n\tb=Y3Bra8quD71OuirVmKQ12dZZZ1TikBrczdP0Fmx6Gvak8FoZTEcaljuMSXLLMDifpJ\n\ti+iD6+4sURerYrYk/76i8HRVxVlhKbis0hBD0qBhxroJMlXaqL/GLBBaYwZOyo03wTFr\n\tPfyK3zgaR0mtdT7SGeQW2HFiPmE10nJZHQAfTBcD7sM1Tu8B8y0TnVqmcD5poyjmkPD4\n\tP7sLM1onpLsXPysVeiDk3OPhmTo3dFnYs/y8YA58UtkGSAlJFoBNo7R3EtZ/e+632XEI\n\tHLQNkABQ0W33cowthvlLJx7fHj2fIPkeXPs1lnaN+TtzqjGxVlpYcutCL3ECH3dX7WtW\n\tJgdA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=3aXcuLnzoJf6NoLHrPGyMczsmLWkFvwh2N6iotvTjaI=;\n\tb=at6peWD715zhLCYodfR7InaCyW2O3YoifeWAvEl78uXE3HNbvMSPxVpmhIOU+nN27Q\n\tEBKg+vjBmFKCL71irWbhJZcJZGcIWcX8oX7z45SoZfywwIav0djNgRjR0tfEqqLrpYOW\n\tARo/oD3Tdb81ppgjm/XOYlSF7MC54WlMSA1//Es9y+T4X3kIlV5Ub5d/tVXX0D2EenZG\n\tkkN+rMziE5xxfXH5FCoZGOirb4dD/fqjgFQJetFeKm+EGg8DztrKc0T8jX/QejKQhTgn\n\tPLjJOHaLdx0vBtArTJ+Y04JNuGEPo4scL0aHQdON9BKBIPiXPswNHRWwztD8K6m6wELg\n\tUucQ==","X-Gm-Message-State":"AKGB3mILgUidRALnCl8FPDabrWDnpVrU5hJqQuk2tka7h58DyseK1aC1\n\toaxp6XJJtlt9AqDVADIA6n3egVZbFB7IMiBsc4w=","X-Google-Smtp-Source":"AGs4zMbeS8H7UZWCOHAh99Jj65FqYa4xKIOVtxUULYfqOOO0LXpZ6wHxS5Un+abJUBoi8IR9whxyb0v+acfTgOJ0Wo8=","X-Received":"by 10.200.43.16 with SMTP id 16mr10156148qtu.44.1512653441067;\n\tThu, 07 Dec 2017 05:30:41 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<20171207104915.fdqkj35ga2yxeg3n@ninjato>","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t\n\t\n\t\n\t\n\t<20171207104915.fdqkj35ga2yxeg3n@ninjato>","From":"Harini Katakam ","Date":"Thu, 7 Dec 2017 19:00:40 +0530","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Wolfram Sang ","Cc":"Andrew Worsley ,\n\tMichal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1841374,"web_url":"http://patchwork.ozlabs.org/comment/1841374/","msgid":"","list_archive_url":null,"date":"2018-01-18T02:20:45","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":68717,"url":"http://patchwork.ozlabs.org/api/people/68717/","name":"Andrew Worsley","email":"amworsley@gmail.com"},"content":"On 8 December 2017 at 09:15, Andrew Worsley wrote:\n> Thanks. I regularly see the warning my patch prints out on boot up as then\n> there is a big pull of random data from the TPM.\n\n Just an update on this bug - I did a i2c capture with pulseview on\na boot that included this issue.\n\n> On 8 Dec 2017 12:30 am, \"Harini Katakam\" \n> wrote:\n>>\n>> Hi Wolfram and Andrew,\n>>\n>> On Thu, Dec 7, 2017 at 4:19 PM, Wolfram Sang wrote:\n>> >\n>> >> > I attach a patch of the changes to the i2c driver showing my debug in\n>> >> > this driver.\n>> >> > As I said I am happy to send more verbose bug output - I have about\n>> >> > 36\n>> >> > odd runs with 9 occurences of the bug.\n>> >> > Once it happen twice in the one run\n>> >> >\n>> >> > I include the crashing line from the runs where the bug occured (I\n>> >> > added more diagnostics as the runs progressed):\n>> >>\n>> >> I'll check with out HW team as well and check your flow to\n>> >> see if we can reproduce it; will also check if the existing errata\n>> >> has larger scope.\n>> >> I'll let you know if we require further assistance with debug\n>> >> next week.\n>> >\n>> > Any news here?\n>>\n>> Sorry for the delay.\n>> I've checked the known errata and confirmed that it wont\n>> affect this use case. And we haven't been able to hit this\n>> issue on our HW (with eeprom slave devices).\n>> I will add my colleague looking into this further to debug.\n>>\n>> Regards,\n>> Harini\n\nI suspect a well behaved i2c slave may never show the issue. But the\ni2c cadence doesn't handle bad slaves safely\nso I suggest that length check is needed to avoid buffer kernel\ncrashes due to mis-behaving i2c hardware.\n\nI got a board that this issue was *very* bad to the point that the\nTPM_RANDOM requests repeatedly returned the same data and so were\nfailing the sanity tests. So I captured the i2c transactions using\npulseview and very bad behaviour from the TPM. The problem disappears\nat 100KHz and very reliably occurs at 400k on this individual board so\nI believe this TPM is failing to keep up with the i2c clock and\nscrewying everything up.\n\nWhat I am concerned about is that the i2c-cadence driver is almost\nalways carrying on and returning data with out errors.\n\nIn particular I see repeated starts and long periods where the data\nline is held low and NO Bus Arbitration or Time out errors. In\nparticular I can get repeated TPM_RANDOM requests to the TPM returning\nthe exact same data until another i2c operation to a different chip\n(RTC) which works fine at this 400kHz.\n\nSo to summarize most (all?) other boards work at this 400kHz speed so\nI definitely have a marginal TPM chip on this board. But why doesn't\nthe i2c-cadence HW pick up these faults? The i2c transactions decoded\nby pulseview show a\na real mess but i2c-cadence is bravely pulling data out of it.\n\nI will attempt to append a few images of i2c traces - to illustrate\nthe mess that happens but that the i2c cadence hardware is very rarely\nreporting any problems - but returns invalid data. In about 15+ boots\nI got one Bus arbitration.\n\nAfter looking at the i2c traces it is not surprising that the cadence\ni2c hardware can become confused and return way more\ndata than was requested. As the buffer overrun can cause a crash in a\ndifferent routine (after the i2c driver has finished) I think it is\nprudent to keep some sort of check on the data size returned.\n\nAndrew\n\nread-overview image is the large TPM read I suspect where things go\nwrong showing lots of i2c bursts on one transactions with the\nclock+data held low between them and actually ends with the data held\nlow. It is not fixed until *much* later way past the end of that\nimage.\n\nThe read-start image is the very start of this long transaction\nshowing the read to TPM at address 0x29 - but the pulseview decode is\ncorrectly reporting repeated starts although it looks like the master\nisn't detecting it - there are many many occurrences of these sorts of\nproblems","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"e79VtobT\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3zMSNy4l1fz9t0m\n\tfor ;\n\tThu, 18 Jan 2018 13:20:50 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753282AbeARCUt (ORCPT );\n\tWed, 17 Jan 2018 21:20:49 -0500","from mail-ua0-f182.google.com ([209.85.217.182]:41798 \"EHLO\n\tmail-ua0-f182.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752746AbeARCUs (ORCPT\n\t); Wed, 17 Jan 2018 21:20:48 -0500","by mail-ua0-f182.google.com with SMTP id x10so14606898ual.8\n\tfor ; Wed, 17 Jan 2018 18:20:47 -0800 (PST)","by 10.176.94.172 with HTTP; Wed, 17 Jan 2018 18:20:45 -0800 (PST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=QqTbsUGd9HVFLHS1629TgasGgPFy7SUwkTN1TM+av0g=;\n\tb=e79VtobTPyV8BmxAPsG+br+oSro3gXm+lzNN5hJaLav4g8LmVTOQjxubJ+RH+dRyxp\n\ta/2vt0hM4XgEPJhNMVyuXZDEy59Y3XDbrhEbsz/GaPM35+xFrH0vR6DdvIRihs6T7e77\n\t6DYeGjDkmH0ieueXzqWMQ+FBrA+aeRaVZFjvlARPy6fbC7O57Ns0EyWb+nEXHQ9vykkE\n\tYBeIxcv8SzN8uj/ccVSQfnKyQ986fv5wjrzAlCWrRZYiDnfnXAoDTorNioIwTaloCRkM\n\tjM8O+xFolPxUcBSZEaZWMCUBbUG41Lz9pBFm+nCe6+ykaYGB+alFvPZLPN2u3lXwoe57\n\tAWkQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=QqTbsUGd9HVFLHS1629TgasGgPFy7SUwkTN1TM+av0g=;\n\tb=MDNwkZee0LX+eOO0vXHFuF8A5t4XKnkEhENFg9YRPQR40Gj3fx5lNnVW67aZCYiJOj\n\t7eHt0yVxqX93S/YHJojgxzX+tWlGoMrvDT+hDocx/q97eHg/xVdgpYBMlfNwUGVihXO4\n\tgWuCEV+Z7AsIHzb908CwYJVrGvewxoFHdS77QPHPGITMKuHjg0o60tApXf2kwGIKigzG\n\tBTXkQoraCOt0Fi43SQf1eO9fMEsHrTBTzz0v5PQsehoCJjtMCgGIGta7PHyg2a4BhGVT\n\tqhbztUSqYZA7u7FXvmtQvoN0S9XAREIBen5ovV4gR3JbuYth758P5gi4WKQbISVRP50/\n\t95zw==","X-Gm-Message-State":"AKwxytfVV/lvVVo6ExSKCAMJPZyy0u8u2sXoYc8UmYAmzCozO3sDTn9Z\n\tAsrVIYuc/5HGfuz5SmGE5tRe0Rmk7OSFMY/8kzzlNQ==","X-Google-Smtp-Source":"ACJfBouCmGFk00eGOlB1OuRFGlbAfQf/iPtXY5B+7sPRkeb8Eq9Z1QRkpFkTRGPiNzjjRbt6nrjuj8+y3NNZQ/ioV44=","X-Received":"by 10.159.33.71 with SMTP id 65mr3652319uab.177.1516242046343;\n\tWed, 17 Jan 2018 18:20:46 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t\n\t\n\t\n\t\n\t<20171207104915.fdqkj35ga2yxeg3n@ninjato>\n\t\n\t","From":"Andrew Worsley ","Date":"Thu, 18 Jan 2018 13:20:45 +1100","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Harini Katakam ","Cc":"Wolfram Sang , Michal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Content-Type":"multipart/mixed; boundary=\"94eb2c0b77409112ed0563039c41\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":2326257,"web_url":"http://patchwork.ozlabs.org/comment/2326257/","msgid":"","list_archive_url":null,"date":"2019-12-17T07:38:03","subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","submitter":{"id":66830,"url":"http://patchwork.ozlabs.org/api/people/66830/","name":"Shubhrajyoti Datta","email":"shubhrajyoti.datta@gmail.com"},"content":"Hi Andrew,\nApologies for the late reply.\n\nOn Thu, Jan 18, 2018 at 7:53 AM Andrew Worsley wrote:\n>\n> On 8 December 2017 at 09:15, Andrew Worsley wrote:\n> > Thanks. I regularly see the warning my patch prints out on boot up as then\n> > there is a big pull of random data from the TPM.\n>\n> Just an update on this bug - I did a i2c capture with pulseview on\n> a boot that included this issue.\n>\n> > On 8 Dec 2017 12:30 am, \"Harini Katakam\" \n> > wrote:\n> >>\n> >> Hi Wolfram and Andrew,\n> >>\n> >> On Thu, Dec 7, 2017 at 4:19 PM, Wolfram Sang wrote:\n> >> >\n> >> >> > I attach a patch of the changes to the i2c driver showing my debug in\n> >> >> > this driver.\n> >> >> > As I said I am happy to send more verbose bug output - I have about\n> >> >> > 36\n> >> >> > odd runs with 9 occurences of the bug.\n> >> >> > Once it happen twice in the one run\n> >> >> >\n> >> >> > I include the crashing line from the runs where the bug occured (I\n> >> >> > added more diagnostics as the runs progressed):\n> >> >>\n> >> >> I'll check with out HW team as well and check your flow to\n> >> >> see if we can reproduce it; will also check if the existing errata\n> >> >> has larger scope.\n> >> >> I'll let you know if we require further assistance with debug\n> >> >> next week.\n> >> >\n> >> > Any news here?\n> >>\n> >> Sorry for the delay.\n> >> I've checked the known errata and confirmed that it wont\n> >> affect this use case. And we haven't been able to hit this\n> >> issue on our HW (with eeprom slave devices).\n> >> I will add my colleague looking into this further to debug.\n> >>\n> >> Regards,\n> >> Harini\n>\n> I suspect a well behaved i2c slave may never show the issue. But the\n> i2c cadence doesn't handle bad slaves safely\n> so I suggest that length check is needed to avoid buffer kernel\n> crashes due to mis-behaving i2c hardware.\n>\n> I got a board that this issue was *very* bad to the point that the\n> TPM_RANDOM requests repeatedly returned the same data and so were\n> failing the sanity tests. So I captured the i2c transactions using\n> pulseview and very bad behaviour from the TPM. The problem disappears\n> at 100KHz and very reliably occurs at 400k on this individual board so\n> I believe this TPM is failing to keep up with the i2c clock and\n> screwying everything up.\n>\n> What I am concerned about is that the i2c-cadence driver is almost\n> always carrying on and returning data with out errors.\n>\nI agree we should attempt to fix this could you resend the patch\nremoving the debug.\n\nthanks and Regards,\nShubhrajyoti","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (no SPF record)\n\tsmtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67;\n\thelo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdmarc=pass (p=none dis=none) header.from=gmail.com","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"DPVXiP44\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 47cVP65Sj4z9sRX\n\tfor ;\n\tTue, 17 Dec 2019 18:38:18 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1728139AbfLQHiR (ORCPT );\n\tTue, 17 Dec 2019 02:38:17 -0500","from mail-ed1-f68.google.com ([209.85.208.68]:37961 \"EHLO\n\tmail-ed1-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1725893AbfLQHiR (ORCPT\n\t); Tue, 17 Dec 2019 02:38:17 -0500","by mail-ed1-f68.google.com with SMTP id i16so6218510edr.5\n\tfor ; Mon, 16 Dec 2019 23:38:15 -0800 (PST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=d5BILoFUsnbiutXxGw+euX6HPcc4knB0s3mzmzgspIQ=;\n\tb=DPVXiP44RHUxPz6UpgYpgrjn4KrtKhiCHTf/nZGx2sFYkO259sGVlmqCf6Mui/+jyO\n\tYWtOqIZz6VCZIzY0ModJSyDI5Ren+h9Eq410paCuCPeu7YHdSWl7fA9KE8WbKqiYi/6W\n\t62zTYwMZtdA+PqqUyJj6VacEyRng+oEhy4fwqOayHDQTwey9OkMS6rs5BoF2hjHVKeT+\n\tj+1BxKI/MIQ0DcR8cBUZb1iicii9ih9e75hcgVm+JjzNsraKDxoHvFF5LI63dsn8E41+\n\tGi8PBtOtnpLAhs3CibZgCAZ+6Vz0PINUQzOe9KcgFnpHNWvKhqLI1+slgjRWovJ5lWNz\n\tYJ6g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=d5BILoFUsnbiutXxGw+euX6HPcc4knB0s3mzmzgspIQ=;\n\tb=VibufewKAw+xOEmxFqNSNF9tSxXCFeFwV05IeniIWbRgKyDvuhqZXkJB9fGMh+kiKP\n\tr9gM1fs5seeRS5YTGpEJ2tlRbmGxqqktqoy0GcXI575o/sjGDVKnQflvvkY9CIT+SEPJ\n\tI2BZ1xvrYEzUwLMMxZc5QlGQHkT153MwmsrZBgucHj+UvC+tITol/Nzh6i/6kysNTHQc\n\t34lb2DnCaUtjpv8zLvLQWLfgq1OUx4vJsvuxkkhSL2GySc5hnkn6CH8yKYRH55ZteFSx\n\ts2jNNXbcj0YfoYSiOp8w2vcCtFyy77M8nINFOtIrfs4FkKW5CbejxZ1122OvuJ4L3c9j\n\tk7Rg==","X-Gm-Message-State":"APjAAAW8PmX6aIzhJdlJndqd7e65wb0+YevB6mn2CLNAfFL2nkFO9sjJ\n\tDI0XGUEy9xBaO/0LvnnHrSwsMaGUejXvez0lRUx3OA==","X-Google-Smtp-Source":"APXvYqxLk43zsNTsrG+AGqbSyEN7hKQZqm8+SK5q0E0gGcZX+NTD5DXzQ8TW2SnvqlnZK+esF+aTGu9evYdhcljPW6I=","X-Received":"by 2002:a17:906:bcd5:: with SMTP id\n\tlw21mr3507555ejb.144.1576568295199; \n\tMon, 16 Dec 2019 23:38:15 -0800 (PST)","MIME-Version":"1.0","References":"<20170916030252.10680-1-amworsley@gmail.com>\n\t<20171005120125.nnhomwg2e2twbaqm@ninjato>\n\t\n\t<20171013184646.cy5gmpwrxbacje3m@ninjato>\n\t\n\t\n\t\n\t\n\t\n\t<20171207104915.fdqkj35ga2yxeg3n@ninjato>\n\t\n\t\n\t","In-Reply-To":"","From":"Shubhrajyoti Datta ","Date":"Tue, 17 Dec 2019 13:08:03 +0530","Message-ID":"","Subject":"Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer","To":"Andrew Worsley ","Cc":"Harini Katakam ,\n\tWolfram Sang , Michal Simek ,\n\tSoren Brinkmann ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-i2c@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-i2c@vger.kernel.org"}}]