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]
Message-ID: <A765B125120D1346A63912DDE6D8B6310BF57B7B@NTXXIAMBX02.xacn.micron.com>
Date:	Thu, 21 Jan 2016 01:06:48 +0000
From:	Bean Huo 霍斌斌 (beanhuo) 
	<beanhuo@...ron.com>
To:	Adam Somerville <adamsomerville@...il.com>
CC:	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"zajec5@...il.com" <zajec5@...il.com>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	"jteki@...nedev.com" <jteki@...nedev.com>,
	"mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
	"furquan@...gle.com" <furquan@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] spi-nor: fix cross die reads on Micron multi-die devices

 Hi, Adam and Boris

For Micron MT25Q ,MT25T and MT35Q, they does not exist this action even they are
Multi-die devices. So when the last byte of the die selected is read, the next byte output
is the first byte of next die(not the same die). 
You can check this by extended address register chapter in our datasheet, there are detail
Information.

> Hi,
> 
> Thanks for looking at the this.
> 
> I can rewrite so it only affects N25Q devices, I hoped a simpler
> implementation would outweigh the small overhead incurred on non affected
> devices.
> 
> Do you know if there are any plans for MT25* based multi-die devices and if
> they would have the same issue?
> 
> Thanks,
> 
> Adam
> 
> On Wed, Jan 20, 2016 at 2:45 AM, Bean Huo 霍斌斌 (beanhuo)
> <beanhuo@...ron.com> wrote:
> > Hi, Adam
> > This is true, but this only exist in Micron 65nm spi nor N25Q.
> > For our 45nm spi nor MT25Q , MT25TL and MT25Q, does exist this
> question.
> > So I think, can you differentiate between these in your patch?
> >
> >> From: Adam Somerville <adamsomerville@...il.com>
> >>
> >> So as far as I can see there is a bug in the spi-nor driver when
> >> issuing die boundary crossing reads on Micron multi-die devices.
> >> Micron N25Q512A, N25Q00AA and probably any other Micron multi-die
> >> devices do not support a single read request that crosses a die boundary.
> >>
> >> The current behaviour is that the address on the device wraps back to
> >> the start of the first die, with any data returned beyond the
> >> boundary being from the start of the first die.
> >>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ