linux-kernel - Re: [PATCH] Add support for flag status register on Micron chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 Apr 2014 12:03:24 +0200
From:	Marek Vasut <marex@...x.de>
To:	grmoore@...era.com
Cc:	ggrahammoore@...il.com, David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	Sourav Poddar <sourav.poddar@...com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Geert Uytterhoeven <geert+renesas@...ux-m68k.org>,
	Jingoo Han <jg1.han@...sung.com>,
	Insop Song <insop.song@...nspeed.com>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Alan Tull <atull@...era.com>,
	Dinh Nguyen <dinguyen@...era.com>,
	Yves Vandervennet <rocket.yvanderv@...il.com>,
	Gerhard Sittig <gsi@...x.de>
Subject: Re: [PATCH] Add support for flag status register on Micron chips

On Tuesday, April 08, 2014 at 06:12:49 PM, grmoore@...era.com wrote:
> From: Graham Moore <grmoore@...era.com>
> 
> This is a slightly different version of the patch that Insop Song
> submitted
> (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de).
> 
> I talked to Insop, and he agreed I should submit this patch as a follow-on
> to his.
> 
> This patch uses a flag in the m25p_ids[] array to determine which chips
> need to use the FSR (Flag Status Register).
> 
> Rationale for using the FSR:
> 
> The Micron data sheets say we have to do this, at least for the multi-die
> 512M and 1G parts (n25q512 and n25q00).  In practice, if we don't check
> the FSR for program/erase status, and we rely solely on the status
> register (SR), then we get corrupted data in the flash.

I talked to Gerhard yesterday and he told me there is something like that on 
ONFI NAND. I think I now understand why that new register is in-place. 
Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and 
one of those reflects that _all_ the dies have finished their operation. This is 
in my opinion seriously misdesigned as it breaks any kind of backward 
compatibility.

> Micron told us (Altera) that for multi-die chips based on the 65nm 256MB
> die, we need to check the SR first, then check the FSR, which is why the
> wait_for_fsr_ready function does that.  Future chips based on 45 nm 512MB
> die will use the FSR only.

Can these SPI flash makers screw the design even more? OT: Why don't we have a 
single standard for all the SF chips which won't need all these crappy quirks 
:-(

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/