On Fri, Sep 18, 2015 at 02:59:17PM -0700, Brian Norris wrote: > From: Furquan Shaikh <[email protected]> > > 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 <[email protected]> > Signed-off-by: Brian Norris <[email protected]>
Pushed to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
