From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751913AbbEDOLg (ORCPT ); Mon, 4 May 2015 10:11:36 -0400 Received: from mail-out.m-online.net ([212.18.0.10]:52202 "EHLO mail-out.m-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbbEDOL3 (ORCPT ); Mon, 4 May 2015 10:11:29 -0400 X-Auth-Info: iBI07vqKPEkCubjSXwOsr+VTFO10Zwga4zuv9WzMyqc= From: Marek Vasut To: Michal Suchanek Subject: Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase. Date: Mon, 4 May 2015 16:11:26 +0200 User-Agent: KMail/1.13.7 (Linux/3.14-2-amd64; KDE/4.13.1; x86_64; ; ) 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 References: <201505041535.29878.marex@denx.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201505041611.26119.marex@denx.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, May 04, 2015 at 03:39:44 PM, Michal Suchanek wrote: > 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. I'm glad to hear this got cleared up, thanks ! :) Best regards, Marek Vasut