Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752402AbbEDLLw (ORCPT ); Mon, 4 May 2015 07:11:52 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:35489 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752082AbbEDLLo (ORCPT ); Mon, 4 May 2015 07:11:44 -0400 MIME-Version: 1.0 In-Reply-To: <201505011620.05512.marex@denx.de> References: <201505010113.50293.marex@denx.de> <201505011620.05512.marex@denx.de> From: Michal Suchanek Date: Mon, 4 May 2015 13:11:03 +0200 Message-ID: Subject: Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. To: Marek Vasut Cc: David Woodhouse , Brian Norris , "Rafa?? Mi??ecki" , Alison Chaiken , Ben Hutchings , Geert Uytterhoeven , "Bean Huo (beanhuo)" , "grmoore@altera.com" , linux-mtd@lists.infradead.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1382 Lines: 42 Hello, On 1 May 2015 at 16:20, Marek Vasut wrote: > On Friday, May 01, 2015 at 09:05:15 AM, Michal Suchanek wrote: >> On 1 May 2015 at 01:13, Marek Vasut wrote: >> I can determine it for this particular chip. However, when the vendor >> datasheet says the block is 64/32K it might mean that chips with this >> ID can have either block size. > > http://www.chingistek.com/img/Product_Files/Pm25LD010020datasheet%20v04.pdf > page 21: > > SECTOR_ER (20h) erases 4kByte sector. > BLOCK_ER (d8h) erases 64kByte sector. > > http://www.gigadevice.com/product/download/366.html?locale=en_US > page 27-28: > > Sector Erase (SE) (20h) erases 4kByte sector > 64KB Block Erase (BE) (d8h) erases 64kByte sector > It's pretty much the same as the datasheet I used http://www.elm-tech.com/en/products/spi-flash-memory/gd25q41/gd25q41.pdf It mentions both 32KB Block Erase (BE) (52H) and 64KB Block Erase (BE) (D8H) So the chip probably tries its best to be compatible with any command set and this last patch is not needed. The memory organization table on page 7 is not all that reassuring, though. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/