summaryrefslogtreecommitdiffstats
path: root/include/mtd
Commit message (Collapse)AuthorAgeFilesLines
* [MTD] NAND: Honour autoplacement schemes supplied by the callerThomas Gleixner2005-05-231-1/+2
| | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [JFFS2] Add support for JFFS2-on-Dataflash devices.Andrew Victor2005-05-231-1/+2
| | | | | | | | | | | | | | | | | For Dataflash, can_mark_obsolete = false and the NAND write buffering code (wbuf.c) is used. Since the DataFlash chip will automatically erase pages when writing, the cleanmarkers are not needed - so cleanmarker_oob = false and cleanmarker_size = 0 DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). The SECTOR_ADDR macro (added in the previous core patch) is replaced with a (slower) div/mod version if CONFIG_JFFS2_FS_DATAFLASH is selected. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [MTD] User interface to Protection RegistersNicolas Pitre2005-05-231-1/+10
| | | | | | | | | | | This is implemented using a ioctl to switch the MTD char device into one of the different OTP "modes", at which point read/write/seek can operate on the selected OTP area. Also some extra ioctls to query for size and lock protection segments or groups. Some example user space utilities are provided. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* [MTD] Support for protection register support on Intel FLASH chipsNicolas Pitre2005-05-231-1/+7
| | | | | | | | | | This enables support for reading, writing and locking so called "Protection Registers" present on some flash chips. A subset of them are pre-programmed at the factory with a unique set of values. The rest is user-programmable. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-165-0/+325
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!
OpenPOWER on IntegriCloud