kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-26 18:16:26 +00:00
Code Issues Releases Packages Activity
linux/fs/jffs2/wbuf.c

1210 lines
34 KiB
Raw Permalink Normal View History

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
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
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
[PATCH] fix missing includes I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 15:03:48 -08:00
[PATCH] severing fs.h, radix-tree.h -> sched.h Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2006-10-18 13:55:46 -04:00
[PATCH] fix missing includes I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 15:03:48 -08:00
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
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
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
[JFFS2] Use function to manipulate superblock dirty flag Use the corresponding function to mark Superblock dirty instead of doing it directly. Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-03-18 09:58:09 +00:00
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
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
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
[JFFS2] Code cleanup Code beautification and block filing correction for optimization. Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-28 18:53:05 +00:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Debug code clean up - step 3 Various simplifiactions. printk format corrections. Convert more code to use the new debug functions. Signed-off-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-24 16:14:17 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] Fix wbuf recovery of f->metadata->raw node. A data node might not be in the fraglist; it could be f->metadata. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-27 13:15:16 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] Fix wbuf recovery of f->metadata->raw node. A data node might not be in the fraglist; it could be f->metadata. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-27 13:15:16 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Add 'jeb' argument to jffs2_prealloc_raw_node_refs() Preallocation of refs is shortly going to be a per-eraseblock thing, rather than per-filesystem. Add the required argument to the function. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-25 01:50:35 +01:00
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
[JFFS2] Fix writebuffer recovery in the first page of a block For the case when nand_write_page fail with -EIO for the first page in an eraseblock, jffs2_wbuf_recover ends up producing a BUG in jffs2_block_refile as jeb->first_node is not yet set up (it's set up later in jffs2_wbuf_recover). This BUG is not really a bug; it's just jffs2_wbuf_recover calling jffs2_block_refile with the wrong second parameter. This patch takes care of this situation. Signed-off-by: Vitaly Wool <vwool@ru.mvista.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-03-06 17:01:04 +03:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[MTD] Remove read/write _ecc variants MTD clients are agnostic of FLASH which needs ECC suppport. Remove the functions and fixup the callers. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 17:21:03 +02:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[MTD] NAND Signal that a bitflip was corrected by ECC Return -EUCLEAN on read when a bitflip was detected and corrected, so the clients can react and eventually copy the affected block to a spare one. Make all in kernel users aware of the change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 14:56:39 +02:00
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
[MTD] NAND Signal that a bitflip was corrected by ECC Return -EUCLEAN on read when a bitflip was detected and corrected, so the clients can react and eventually copy the affected block to a spare one. Make all in kernel users aware of the change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 14:56:39 +02:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Remove flash offset argument from various functions. We don't need the upper layers to deal with the physical offset. It's _always_ c->nextblock->offset + c->sector_size - c->nextblock->free_size so we might as well just let the actual write functions deal with that. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-23 00:38:06 +01:00
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
[JFFS2] Code cleanup Code beautification and block filing correction for optimization. Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-28 18:53:05 +00:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] Remove flash offset argument from various functions. We don't need the upper layers to deal with the physical offset. It's _always_ c->nextblock->offset + c->sector_size - c->nextblock->free_size so we might as well just let the actual write functions deal with that. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-23 00:38:06 +01:00
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
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
[JFFS2] Code cleanup Code beautification and block filing correction for optimization. Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-28 18:53:05 +00:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Code cleanup Code beautification and block filing correction for optimization. Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-28 18:53:05 +00:00
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[MTD] Remove read/write _ecc variants MTD clients are agnostic of FLASH which needs ECC suppport. Remove the functions and fixup the callers. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 17:21:03 +02:00
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
[MTD] Remove read/write _ecc variants MTD clients are agnostic of FLASH which needs ECC suppport. Remove the functions and fixup the callers. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 17:21:03 +02:00
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
[JFFS2] Code cleanup Code beautification and block filing correction for optimization. Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-28 18:53:05 +00:00
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
[JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code. As the first step towards eliminating the ref->next_phys member and saving memory by using an _array_ of struct jffs2_raw_node_ref per eraseblock, stop the write functions from allocating their own refs; have them just _reserve_ the appropriate number instead. Then jffs2_link_node_ref() can just fill them in. Use a linked list of pre-allocated refs in the superblock, for now. Once we switch to an array, it'll just be a case of extending that array. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-24 02:04:45 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[PATCH] fs: use list_move() This patch converts the combination of list_del(A) and list_add(A, B) to list_move(A, B) under fs/. Cc: Ian Kent <raven@themaw.net> Acked-by: Joel Becker <joel.becker@oracle.com> Cc: Neil Brown <neilb@cse.unsw.edu.au> Cc: Hans Reiser <reiserfs-dev@namesys.com> Cc: Urban Widmark <urban@teststation.com> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Mark Fasheh <mark.fasheh@oracle.com> Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 00:24:46 -07:00
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
[JFFS2] Debug code clean up - step 3 Various simplifiactions. printk format corrections. Convert more code to use the new debug functions. Signed-off-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-24 16:14:17 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Debug code clean up - step 3 Various simplifiactions. printk format corrections. Convert more code to use the new debug functions. Signed-off-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-07-24 16:14:17 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code. As the first step towards eliminating the ref->next_phys member and saving memory by using an _array_ of struct jffs2_raw_node_ref per eraseblock, stop the write functions from allocating their own refs; have them just _reserve_ the appropriate number instead. Then jffs2_link_node_ref() can just fill them in. Use a linked list of pre-allocated refs in the superblock, for now. Once we switch to an array, it'll just be a case of extending that array. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-24 02:04:45 +01:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[MTD] Remove read/write _ecc variants MTD clients are agnostic of FLASH which needs ECC suppport. Remove the functions and fixup the callers. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 17:21:03 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] File node reference for wasted space when flushing wbuf Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every piece of dirty space in the system, so that __totlen can be killed off.... Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-21 13:00:54 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] File node reference for wasted space when flushing wbuf Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every piece of dirty space in the system, so that __totlen can be killed off.... Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-21 13:00:54 +01:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] File node reference for wasted space when flushing wbuf Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every piece of dirty space in the system, so that __totlen can be killed off.... Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-21 13:00:54 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] File node reference for wasted space when flushing wbuf Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every piece of dirty space in the system, so that __totlen can be killed off.... Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-21 13:00:54 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] File node reference for wasted space when flushing wbuf Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every piece of dirty space in the system, so that __totlen can be killed off.... Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-21 13:00:54 +01:00
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
[JFFS2] File node reference for wasted space when flushing wbuf Next step in ongoing campaign to file a struct jffs2_raw_node_ref for every piece of dirty space in the system, so that __totlen can be killed off.... Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-21 13:00:54 +01:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Remove NAND dependencies for NOR FLASH make NAND code work on NOR flash again Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-02 22:12:08 +00:00
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
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
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
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
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
[JFFS2] Remove NAND dependencies for NOR FLASH make NAND code work on NOR flash again Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-02 22:12:08 +00:00
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
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
[JFFS2] Fix block refiling - block refiling when writing directly to flash a buffer which is bigger than wbuf - retry cases for flushing wbuf Signed-off-by: Estelle Hammache <estelle.hammache@st.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-01-24 21:24:18 +00:00
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Add erase block summary support (mount time improvement) The goal of summary is to speed up the mount time. Erase block summary (EBS) stores summary information at the end of every (closed) erase block. It is no longer necessary to scan all nodes separetly (and read all pages of them) just read this "small" summary, where every information is stored which is needed at mount time. This summary information is stored in a JFFS2_FEATURE_RWCOMPAT_DELETE. During the mount process if there is no summary info the orignal scan process will be executed. EBS works with NAND and NOR flashes, too. There is a user space tool called sumtool to generate this summary information for a JFFS2 image. Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-07 09:35:26 +01:00
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
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Simplify writebuffer handling The writev based write buffer implementation was far to complex as in most use cases the write buffer had to be handled anyway. Simplify the write buffer handling and use mtd->write instead. From extensive testing no performance impact has been noted. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 11:49:14 +02:00
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
[JFFS2] Switch to using an array of jffs2_raw_node_refs instead of a list. This allows us to drop another pointer from the struct jffs2_raw_node_ref, shrinking it to 8 bytes on 32-bit machines (if the TEST_TOTLEN) paranoia check is turned off, which will be committed soon). Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-05-26 21:19:05 +01:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
[JFFS2] Add erase block summary support (mount time improvement) The goal of summary is to speed up the mount time. Erase block summary (EBS) stores summary information at the end of every (closed) erase block. It is no longer necessary to scan all nodes separetly (and read all pages of them) just read this "small" summary, where every information is stored which is needed at mount time. This summary information is stored in a JFFS2_FEATURE_RWCOMPAT_DELETE. During the mount process if there is no summary info the orignal scan process will be executed. EBS works with NAND and NOR flashes, too. There is a user space tool called sumtool to generate this summary information for a JFFS2 image. Signed-off-by: Ferenc Havasi <havasi@inf.u-szeged.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-07 09:35:26 +01:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
[JFFS2] Fix race problems with wbuf. Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-04-05 13:51:58 +01:00
[MTD] Remove read/write _ecc variants MTD clients are agnostic of FLASH which needs ECC suppport. Remove the functions and fixup the callers. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-23 17:21:03 +02:00
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
[MTD] NAND Signal that a bitflip was corrected by ECC Return -EUCLEAN on read when a bitflip was detected and corrected, so the clients can react and eventually copy the affected block to a spare one. Make all in kernel users aware of the change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 14:56:39 +02:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[MTD] NAND Signal that a bitflip was corrected by ECC Return -EUCLEAN on read when a bitflip was detected and corrected, so the clients can react and eventually copy the affected block to a spare one. Make all in kernel users aware of the change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 14:56:39 +02:00
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
[MTD] NAND Signal that a bitflip was corrected by ECC Return -EUCLEAN on read when a bitflip was detected and corrected, so the clients can react and eventually copy the affected block to a spare one. Make all in kernel users aware of the change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 14:56:39 +02:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
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
[JFFS2] Fix race problems with wbuf. Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-04-05 13:51:58 +01:00
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
[JFFS2] Core changes required to support JFFS2-on-Dataflash devices. DataFlash page-sizes are not a power of two (they're multiples of 528 bytes). There are a few places in JFFS2 code where sector_size is used as a bitmask. A new macro (SECTOR_ADDR) was defined to calculate these sector addresses. For non-DataFlash devices, the original (faster) bitmask operation is still used. In scan.c, the EMPTY_SCAN_SIZE was a constant of 1024. Since this could be larger than the sector size of the DataFlash, this is now basically set to MIN(sector_size, 1024). Addition of a jffs2_is_writebuffered() macro. Signed-off-by: Andrew Victor <andrew@sanpeople.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-02-09 09:09:05 +00:00
[JFFS2] Fix race problems with wbuf. Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-04-05 13:51:58 +01:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[MTD] NAND Signal that a bitflip was corrected by ECC Return -EUCLEAN on read when a bitflip was detected and corrected, so the clients can react and eventually copy the affected block to a spare one. Make all in kernel users aware of the change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 14:56:39 +02:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[JFFS2] printk warning fixes fs/jffs2/wbuf.c: In function 'jffs2_check_oob_empty': fs/jffs2/wbuf.c:993: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:993: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' fs/jffs2/wbuf.c: In function 'jffs2_check_nand_cleanmarker': fs/jffs2/wbuf.c:1036: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:1036: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' fs/jffs2/wbuf.c: In function 'jffs2_write_nand_cleanmarker': fs/jffs2/wbuf.c:1062: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:1062: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-02-17 16:02:10 -08:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[JFFS2] printk warning fixes fs/jffs2/wbuf.c: In function 'jffs2_check_oob_empty': fs/jffs2/wbuf.c:993: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:993: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' fs/jffs2/wbuf.c: In function 'jffs2_check_nand_cleanmarker': fs/jffs2/wbuf.c:1036: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:1036: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' fs/jffs2/wbuf.c: In function 'jffs2_write_nand_cleanmarker': fs/jffs2/wbuf.c:1062: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:1062: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-02-17 16:02:10 -08:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[JFFS2] printk warning fixes fs/jffs2/wbuf.c: In function 'jffs2_check_oob_empty': fs/jffs2/wbuf.c:993: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:993: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' fs/jffs2/wbuf.c: In function 'jffs2_check_nand_cleanmarker': fs/jffs2/wbuf.c:1036: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:1036: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' fs/jffs2/wbuf.c: In function 'jffs2_write_nand_cleanmarker': fs/jffs2/wbuf.c:1062: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' fs/jffs2/wbuf.c:1062: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-02-17 16:02:10 -08:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] print a message when marking bad block New bad eraseblock is an event which is important enough to be printed about. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-03-08 10:35:10 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] NAND Replace oobinfo by ecclayout The nand_oobinfo structure is not fitting the newer error correction demands anymore. Replace it by struct nand_ecclayout and fixup the users all over the place. Keep the nand_oobinfo based ioctl for user space compability reasons. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-27 22:16:10 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] NAND Replace oobinfo by ecclayout The nand_oobinfo structure is not fitting the newer error correction demands anymore. Replace it by struct nand_ecclayout and fixup the users all over the place. Keep the nand_oobinfo based ioctl for user space compability reasons. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-27 22:16:10 +02:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
[MTD] NAND Replace oobinfo by ecclayout The nand_oobinfo structure is not fitting the newer error correction demands anymore. Replace it by struct nand_ecclayout and fixup the users all over the place. Keep the nand_oobinfo based ioctl for user space compability reasons. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-27 22:16:10 +02:00
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] Introduce writesize At least two flashes exists that have the concept of a minimum write unit, similar to NAND pages, but no other NAND characteristics. Therefore, rename the minimum write unit to "writesize" for all flashes, including NAND. Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-22 23:18:05 +02:00
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
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND Nowadays MTD supports an MTD_OOB_AUTO option which allows users to access free bytes in NAND's OOB as a contiguous buffer, although it may be highly discontinuous. This patch teaches JFFS2 to use this nice feature instead of the old MTD_OOB_PLACE option. This for example caused problems with OneNAND. Now JFFS2 does not care how are the free bytes situated. This may change position of the clean marker on some flashes, but this is not a problem. JFFS2 will just re-erase the empty eraseblocks and write the new (correct) clean marker. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2007-01-31 11:38:53 +02:00
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
[MTD] Rework the out of band handling completely Hopefully the last iteration on this! The handling of out of band data on NAND was accompanied by tons of fruitless discussions and halfarsed patches to make it work for a particular problem. Sufficiently annoyed by I all those "I know it better" mails and the resonable amount of discarded "it solves my problem" patches, I finally decided to go for the big rework. After removing the _ecc variants of mtd read/write functions the solution to satisfy the various requirements was to refactor the read/write _oob functions in mtd. The major change is that read/write_oob now takes a pointer to an operation descriptor structure "struct mtd_oob_ops".instead of having a function with at least seven arguments. read/write_oob which should probably renamed to a more descriptive name, can do the following tasks: - read/write out of band data - read/write data content and out of band data - read/write raw data content and out of band data (ecc disabled) struct mtd_oob_ops has a mode field, which determines the oob handling mode. Aside of the MTD_OOB_RAW mode, which is intended to be especially for diagnostic purposes and some internal functions e.g. bad block table creation, the other two modes are for mtd clients: MTD_OOB_PLACE puts/gets the given oob data exactly to/from the place which is described by the ooboffs and ooblen fields of the mtd_oob_ops strcuture. It's up to the caller to make sure that the byte positions are not used by the ECC placement algorithms. MTD_OOB_AUTO puts/gets the given oob data automaticaly to/from the places in the out of band area which are described by the oobfree tuples in the ecclayout data structre which is associated to the devicee. The decision whether data plus oob or oob only handling is done depends on the setting of the datbuf member of the data structure. When datbuf == NULL then the internal read/write_oob functions are selected, otherwise the read/write data routines are invoked. Tested on a few platforms with all variants. Please be aware of possible regressions for your particular device / application scenario Disclaimer: Any whining will be ignored from those who just contributed "hot air blurb" and never sat down to tackle the underlying problem of the mess in the NAND driver grown over time and the big chunk of work to fix up the existing users. The problem was not the holiness of the existing MTD interfaces. The problems was the lack of time to go for the big overhaul. It's easy to add more mess to the existing one, but it takes alot of effort to go for a real solution. Improvements and bugfixes are welcome! Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2006-05-29 03:26:58 +02:00
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
[JFFS2] Add support for JFFS2-on-Dataflash devices. 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>
2005-02-09 09:17:45 +00:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Add support for JFFS2-on-Dataflash devices. 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>
2005-02-09 09:17:45 +00:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Add support for JFFS2-on-Dataflash devices. 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>
2005-02-09 09:17:45 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Clean up trailing white spaces Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-07 11:16:07 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Add support for JFFS2-on-Dataflash devices. 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>
2005-02-09 09:17:45 +00:00
[JFFS2] Fix dataflash support - assume wbuf may be of size which is not power of 2 - don't make strange assumption about not padding wbuf for DataFlash - use wbuf = DataFlash page and eraseblock >= 8 Dataflash pages From: Peter Menzebach <pm-mtd@mw-itcon.de> Acked-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-09-30 14:59:17 +01:00
[JFFS2] Add support for JFFS2-on-Dataflash devices. 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>
2005-02-09 09:17:45 +00:00
[JFFS2] Teach JFFS2 about Sibley flash Intels Sibley flash needs JFFS2 write buffer functionality Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-08-06 05:51:33 +01:00
[MTD] Merge STMicro NOR_ECC code with Intel Sibley code In 2002, STMicro started producing NOR flashes with internal ECC protection for small blocks (8 or 16 bytes). Support for those flashes was added by me. In 2005, Intel Sibley flashes copied this strategy and Nico added support for those. Merge the code for both. Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-22 23:18:12 +02:00
[JFFS2] Teach JFFS2 about Sibley flash Intels Sibley flash needs JFFS2 write buffer functionality Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-08-06 05:51:33 +01:00
[MTD] Introduce writesize At least two flashes exists that have the concept of a minimum write unit, similar to NAND pages, but no other NAND characteristics. Therefore, rename the minimum write unit to "writesize" for all flashes, including NAND. Signed-off-by: Joern Engel <joern@wh.fh-wedel.de>
2006-05-22 23:18:05 +02:00
[JFFS2] Teach JFFS2 about Sibley flash Intels Sibley flash needs JFFS2 write buffer functionality Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-08-06 05:51:33 +01:00