Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753235AbbEDNke (ORCPT ); Mon, 4 May 2015 09:40:34 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:35177 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752085AbbEDNk0 (ORCPT ); Mon, 4 May 2015 09:40:26 -0400 MIME-Version: 1.0 In-Reply-To: <201505041535.29878.marex@denx.de> References: <201505041412.46195.marex@denx.de> <201505041535.29878.marex@denx.de> From: Michal Suchanek Date: Mon, 4 May 2015 15:39:44 +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: 1715 Lines: 48 On 4 May 2015 at 15:35, Marek Vasut wrote: > On Monday, May 04, 2015 at 03:18:56 PM, Michal Suchanek wrote: >> On 4 May 2015 at 14:12, Marek Vasut wrote: >> > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: >> >> >> >> It mentions both >> >> 32KB Block Erase (BE) (52H) >> >> and >> >> 64KB Block Erase (BE) (D8H) >> > >> > The SPI NOR framework will use 0xbe opcode, no problem. >> > >> >> 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. >> > >> > Which exact part do you refer to please ? >> >> Start of page 7 where it says sector size 32/64K in either datasheet. >> >> It can refer to both BE opcode variants being supported but it's quite >> unclear. > > My guess here would be that the internal organisation of the SPI NOR is > in 4k blocks, which is no surprise really. My understanding is that opcode > 0x52 erases 8x4k sector (ie. 32k of data) while 0xd8 erases 16x4k sector > (ie. 64k of data). I don't see any problem here -- there are two different > opcodes which do two different things and their behavior matches the one on > various other SPI NORs. > >> Write protection seems to be calculated in 4k sectors and not blocks >> so the block size does not seem very relevant. > > See above. Does it make sense now please ? > Yes, makes sense. 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/