From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pd0-x233.google.com ([2607:f8b0:400e:c02::233]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Walv6-0005VI-FC for linux-mtd@lists.infradead.org; Thu, 17 Apr 2014 13:00:00 +0000 Received: by mail-pd0-f179.google.com with SMTP id w10so345396pde.24 for ; Thu, 17 Apr 2014 05:59:35 -0700 (PDT) Date: Thu, 17 Apr 2014 20:59:21 +0800 From: Huang Shijie To: Marek Vasut Subject: Re: [PATCH] mtd: spi-nor: fix the wrong dummy value Message-ID: <20140417125918.GA3248@localhost.localdomain> References: <1397636299-2390-1-git-send-email-b32955@freescale.com> <201404170140.29747.marex@denx.de> <20140417050123.GC29495@localhost> <201404171332.52954.marex@denx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201404171332.52954.marex@denx.de> Cc: Huang Shijie , computersforpeace@gmail.com, linux-mtd@lists.infradead.org, dwmw2@infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Apr 17, 2014 at 01:32:52PM +0200, Marek Vasut wrote: > On Thursday, April 17, 2014 at 07:01:25 AM, Huang Shijie wrote: > > On Thu, Apr 17, 2014 at 01:40:29AM +0200, Marek Vasut wrote: > > > On Wednesday, April 16, 2014 at 10:18:19 AM, Huang Shijie wrote: > > > > The dummy cycles is actually 8 for SPI fast/dual/quad read. > > > > > > > > This patch fixes the wrong dummy value for both the spi-nor.c and > > > > m25p80.c. > > > > > > > > Signed-off-by: Huang Shijie > > > > > > Inspecting this patch, I see the code will behave identically > > > with/without this patch. It is thus unclear to me from the commit > > > message, why this change is necessary. > > > > firstly, in theory, the dummy cycles should be 8, not 1. > > secondly, the DDR QUAD READ may use 4 dummy cycles. > > Right, it took me a bit of reading into the thread until I understood the > intention of the patch. If in doubt, try reading the commit message a day > later and you'll see that it might be insufficient. Basically, try looking > at the commit message from the receiving party's side ;-) my fault. I will update the commit message in the next version. thanks Huang Shijie