From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752365AbbI2U0L (ORCPT ); Tue, 29 Sep 2015 16:26:11 -0400 Received: from mail-pa0-f50.google.com ([209.85.220.50]:35248 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbbI2U0E (ORCPT ); Tue, 29 Sep 2015 16:26:04 -0400 Date: Tue, 29 Sep 2015 13:26:01 -0700 From: Brian Norris To: linux-mtd@lists.infradead.org Cc: linux-kernel@vger.kernel.org, Furquan Shaikh , Stephen Barber , Marek Vasut , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Huang Shijie Subject: Re: [PATCH] mtd: spi-nor: scale up timeout for full-chip erase Message-ID: <20150929202601.GK31505@google.com> References: <1442613557-36838-1-git-send-email-computersforpeace@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442613557-36838-1-git-send-email-computersforpeace@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 18, 2015 at 02:59:17PM -0700, Brian Norris wrote: > From: Furquan Shaikh > > This patch fixes timeout issues seen on large NOR flash (e.g., 16MB > w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The > input parameters matter because spi_nor_erase() uses a different code > path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7) > opcode. > > Fix: use a different timeout for full-chip erase than for other > commands. > > While most operations can be expected to perform relatively similarly > across a variety of NOR flash types and sizes (and therefore might as > well use a similar timeout to keep things simple), full-chip erase is > unique, because the time it typically takes to complete: > (1) is much larger than most operations and > (2) scales with the size of the flash. > > Let's base our timeout on the original comments stuck here -- that a 2MB > flash requires max 40s to erase. > > Small survey of a few flash datasheets I have lying around: > > Chip Size (MB) Max chip erase (seconds) > ---- -------- ------------------------ > w25q32fw 4 50 > w25q64cv 8 30 > w25q64fw 8 100 > w25q128fw 16 200 > s25fl128s 16 ~256 > s25fl256s 32 ~512 > > From this data, it seems plenty sufficient to say we need to wait for > 40 seconds for each 2MB of flash. > > After this change, it might make some sense to decrease the timeout for > everything else, as even the most extreme operations (single block > erase?) shouldn't take more than a handful of seconds. But for safety, > let's leave it as-is. It's only an error case, after all, so we don't > exactly need to optimize it. > > Signed-off-by: Furquan Shaikh > Signed-off-by: Brian Norris Pushed to l2-mtd.git