linux-kernel - RE: [PATCH 3/3] mtd: spi-nand: add devicetree binding

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87F60714EC601C4C83DFF1D2E3D390A04AC98F@NTXXIAMBX02.xacn.micron.com>
Date:	Mon, 12 Jan 2015 01:57:27 +0000
From:	Peter Pan 潘栋 (peterpandong) 
	<peterpandong@...ron.com>
To:	Ezequiel Garcia <ezequiel.garcia@...tec.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"Brian Norris" <computersforpeace@...il.com>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Qi Wang 王起 (qiwang) <qiwang@...ron.com>,
	Frank Liu 刘群 (frankliu) 
	<frankliu@...ron.com>,
	Melanie Zhang 张燕 (melaniezhang) 
	<melaniezhang@...ron.com>
Subject: RE: [PATCH 3/3] mtd: spi-nand: add devicetree binding

> On 01/08/2015 02:04 AM, Peter Pan 潘栋 (peterpandong) wrote:
> >>> This commit adds the devicetree binding document that specifies the
> >>> spi nand devices support.
> >>>
> >>> Signed-off-by: Peter Pan <peterpandong@...ron.com>
> >>> ---
> >>>  Documentation/devicetree/bindings/mtd/spi-nand.txt | 22
> >> ++++++++++++++++++++++
> >>>  1 file changed, 22 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/mtd/spi-
> >> nand.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >> b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >>> new file mode 100644
> >>> index 0000000..9dd3efd
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >>> @@ -0,0 +1,22 @@
> >>> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips
> >>> +
> >>> +Required properties:
> >>> +- #address-cells, #size-cells : Must be present if the device has
> >> sub-nodes
> >>> +  representing partitions.
> >>> +- compatible : Should be the manufacturer and the name of the chip.
> >> Bear in mind
> >>>
> >>
> >> Unless I'm mistaken, we don't need the chip ID here, as SPI NAND
> allows
> >> to autodetect the device. Any reason why we can't just use a generic
> >> compatible "spi-nand" here?
> >> --
> >> Ezequiel
> >
> > In fact, I don't know how to autodetect the SPI NAND device. Micron
> device and
> > Gigadevice device have different read ID functions. The Chip ID here
> is used to
> > determine which function to use.
> >
> 
> Isn't the difference between the Read ID very minor? One of the vendor
> needs a 2-byte ID read, and the other one needs a 3-byte ID read.
> 
> So you can just try with 2-byte, and if that fails (no vendor ID is
> found on the first byte), you can try with the 3-byte command.
> 
> It's not the most elegant solution, but it's not super awful either.
> --
> Ezequiel

I agree with your idea about try different ways to read ID. It is a better way
to detect the chip if it can work properly.

The difference between the Read ID is that some chips need to send a dummy byte
or address after opcode then read 2 byte, some chips needn't send any data after
opcode but read 3 byte.

I'm concerned maybe chip will get into unknown or vendor specified state if we
send the wrong sequence.