Commit Graph

8 Commits

Author SHA1 Message Date
Adrian Bunk 59018b6d2a MTD/JFFS2: remove CVS keywords
Once upon a time, the MTD repository was using CVS.

This patch therefore removes all usages of the no longer updated CVS
keywords from the MTD code.

This also includes code that printed them to the user.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2008-06-04 17:50:17 +01:00
David Woodhouse 471f717a48 Revert "[MTD] Driver for AT26Fxxx dataflash devices"
This reverts commit 340ea370c2.

It's not needed given the other m25p80 patch (which now handles
at26 "dataflash" as well as most other standard SPI flash chips),
and requires a controller driver that won't be merged upstream
(supplanted by drivers/spi/atmel_spi.c) ... the submitter of
that at91_dataflash26.c driver concurred.

Requested by David Brownell <david-b@pacbell.net>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-08-03 23:02:02 +01:00
Hans-Jürgen Koch 340ea370c2 [MTD] Driver for AT26Fxxx dataflash devices
Add support for AT26Fxxx dataflash devices. These devices have a quite different
commandset than the AT45xxx chips, which are handled by at91_dataflash.c, so a
combined driver turned out to be more ugly than useful.

Tested only on AT26F004.

Signed-off-by: Hans-Jürgen Koch <hjk@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-04-17 13:42:56 -04:00
David Woodhouse 5e535429a9 Remove inter_module_xxx() from DiskOnChip drivers.
Finally putting it back how it was before Keith got at it -- yay :)

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-08 14:05:05 +01:00
Joern Engel acc8dadc0b [PATCH] Remove blkmtd
Remove the blkmtd driver.

- An alternative exists (block2mtd) that hasn't had  bug report for > 1 year.

- Most embedded people tend to use ancient kernels with custom patches from
  mtd cvs and elsewhere, so the 1 year warning period neither helps nor hurts
  them too much.

- It's in the way of klibc.  The problems caused by pulling blkmtd support
  are fairly low, while the problems caused by delaying klibc can be fairly
  substantial.  At best, this would be a severe burden on hpa's time.

Signed-off-by: Joern Engel <joern@wohnheim.fh-wedel.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11 06:18:43 -07:00
Mike Lavender 2f9f762879 [PATCH] spi: M25 series SPI flash
This was originally a driver for the ST M25P80 SPI flash.  It's been
updated slightly to handle other M25P series chips.

For many of these chips, the specific type could be probed, but for now
this just requires static setup with flash_platform_data that lists the
chip type (size, format) and any default partitioning to use.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Mike Lavender <mike@steroidmicros.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-13 16:29:55 -08:00
David Brownell 1d6432fe10 [PATCH] spi: mtd dataflash driver
This is a conversion of the AT91rm9200 DataFlash MTD driver to use the
lightweight SPI framework, and no longer be AT91-specific.  It compiles
down to less than 3KBytes on ARM.

The driver allows board-specific init code to provide platform_data with
the relevant MTD partitioning information, and hotplugs.

This version has been lightly tested.  Its parent at91_dataflash driver has
been pretty well banged on, although kernel.org JFFS2 dataflash support was
acting broken the last time I tried it.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-13 16:29:54 -08: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