Commit Graph

6 Commits (fd0e5187458041c82fea616575104698397d68d3)

Author SHA1 Message Date
David Woodhouse 0f5ae3d2e9 [MTD] Deal correctly with NOR chips which are smaller than the map window
We used to calculate the number of chips to be zero, allocate an array
of that size, then nasty things would happen when we attempt to access
the first object in that zero-sized array.

Now, if the number of _full_ chips that would fit into the map is zero,
we allocate an array of one anyway, and then artificially reduce the
total size of the resulting MTD device to fit in the map.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-14 01:40:50 +01:00
David Woodhouse a15bdeef10 Remove use of inter_module_crap in NOR flash chip drivers.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-08 22:35:05 +01:00
Thomas Gleixner 1f948b43f7 [MTD] chips: Clean up trailing white spaces
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 14:45:15 +01:00
Nicolas Pitre 638d983840 {MTD] add support for Intel's "Sibley" flash
This updates the Primary Vendor-Specific Extended Query parsing to
version 1.4 in order to get the information about the Configurable
Programming Mode regions implemented in the Sibley flash, as well as
selecting the appropriate write command code.

This flash does not behave like traditional NOR flash when writing data.
While mtdblock should just work, further changes are needed for JFFS2 use.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-06 20:12:17 +01:00
Russell King 6170b43401 [MTD] Fix MTD device probing
Try larger numbers of chips before smaller
numbers of chips across the bus width.

This means we'll avoid misdetecting a 2 x16 array as 1 x32 if the
high 16-bits happen to read as zeros in the QRY area.

Signed-off-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-05-23 12:15:15 +02:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00