1. 29 Sep, 2012 1 commit
  2. 31 May, 2012 1 commit
    • Artem Bityutskiy's avatar
      jffs2: get rid of jffs2_sync_super · 8bdc81c5
      Artem Bityutskiy authored
      Currently JFFS2 file-system maps the VFS "superblock" abstraction to the
      write-buffer. Namely, it uses VFS services to synchronize the write-buffer
      periodically.
      
      The whole "superblock write-out" VFS infrastructure is served by the
      'sync_supers()' kernel thread, which wakes up every 5 (by default) seconds and
      writes out all dirty superblock using the '->write_super()' call-back. But the
      problem with this thread is that it wastes power by waking up the system every
      5 seconds no matter what. So we want to kill it completely and thus, we need to
      make file-systems to stop using the '->write_super' VFS service, and then
      remove it together with the kernel thread.
      
      This patch switches the JFFS2 write-buffer management from
      '->write_super()'/'->s_dirt' to a delayed work. Instead of setting the 's_dirt'
      flag we just schedule a delayed work for synchronizing the write-buffer.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      8bdc81c5
  3. 14 May, 2012 1 commit
    • Artem Bityutskiy's avatar
      jffs2: get rid of jffs2_sync_super · 208b14e5
      Artem Bityutskiy authored
      Currently JFFS2 file-system maps the VFS "superblock" abstraction to the
      write-buffer. Namely, it uses VFS services to synchronize the write-buffer
      periodically.
      
      The whole "superblock write-out" VFS infrastructure is served by the
      'sync_supers()' kernel thread, which wakes up every 5 (by default) seconds and
      writes out all dirty superblock using the '->write_super()' call-back. But the
      problem with this thread is that it wastes power by waking up the system every
      5 seconds no matter what. So we want to kill it completely and thus, we need to
      make file-systems to stop using the '->write_super' VFS service, and then
      remove it together with the kernel thread.
      
      This patch switches the JFFS2 write-buffer management from
      '->write_super()'/'->s_dirt' to a delayed work. Instead of setting the 's_dirt'
      flag we just schedule a delayed work for synchronizing the write-buffer.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      208b14e5
  4. 26 Mar, 2012 3 commits
  5. 09 Jan, 2012 6 commits
  6. 11 Sep, 2011 2 commits
  7. 31 Mar, 2011 1 commit
  8. 19 May, 2010 2 commits
  9. 03 Sep, 2009 1 commit
  10. 18 Oct, 2008 1 commit
  11. 01 May, 2008 2 commits
  12. 22 Apr, 2008 2 commits
  13. 09 Aug, 2007 1 commit
  14. 11 Jul, 2007 1 commit
    • David Woodhouse's avatar
      [JFFS2] Add support for write-buffer verification. · a6bc432e
      David Woodhouse authored
      We've seen some evil corruption issues, where the corruption seems to be
      introduced after the JFFS2 crc32 is calculated but before the NAND
      controller calculates the ECC. So it's in RAM or in the PCI DMA
      transfer; not on the flash. Attempt to catch it earlier by (optionally)
      reading back from the flash immediately after writing it.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      a6bc432e
  15. 10 Jul, 2007 1 commit
  16. 05 May, 2007 1 commit
  17. 27 Apr, 2007 1 commit
  18. 25 Apr, 2007 1 commit
    • David Woodhouse's avatar
      [JFFS2] Tidy up licensing/copyright boilerplate. · c00c310e
      David Woodhouse authored
      In particular, remove the bit in the LICENCE file about contacting
      Red Hat for alternative arrangements. Their errant IS department broke
      that arrangement a long time ago -- the policy of collecting copyright
      assignments from contributors came to an end when the plug was pulled on
      the servers hosting the project, without notice or reason.
      
      We do still dual-license it for use with eCos, with the GPL+exception
      licence approved by the FSF as being GPL-compatible. It's just that nobody
      has the right to license it differently.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      c00c310e
  19. 23 Apr, 2007 1 commit
    • David Woodhouse's avatar
      [JFFS2] Fix cross-endian build. · 566865a2
      David Woodhouse authored
      When compiling a LE-capable JFFS2 on PowerPC, wbuf.c fails to compile:
      
      fs/jffs2/wbuf.c:973: error: braced-group within expression allowed only inside a function
      fs/jffs2/wbuf.c:973: error: initializer element is not constant
      fs/jffs2/wbuf.c:973: error: (near initialization for ‘oob_cleanmarker.magic’)
      fs/jffs2/wbuf.c:974: error: braced-group within expression allowed only inside a function
      fs/jffs2/wbuf.c:974: error: initializer element is not constant
      fs/jffs2/wbuf.c:974: error: (near initialization for ‘oob_cleanmarker.nodetype’)
      fs/jffs2/wbuf.c:975: error: braced-group within expression allowed only inside a function
      fs/jffs2/wbuf.c:976: error: initializer element is not constant
      fs/jffs2/wbuf.c:976: error: (near initialization for ‘oob_cleanmarker.totlen’)
      
      Provide constant_cpu_to_je{16,32} functions, and use them for initialising the
      offending structure.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      566865a2
  20. 17 Apr, 2007 1 commit
  21. 09 Mar, 2007 1 commit
  22. 08 Mar, 2007 1 commit
  23. 18 Feb, 2007 1 commit
    • Andrew Morton's avatar
      [JFFS2] printk warning fixes · 7be26bfb
      Andrew Morton authored
      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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      7be26bfb
  24. 09 Feb, 2007 1 commit
  25. 04 Dec, 2006 1 commit
  26. 28 Nov, 2006 1 commit
    • Vitaly Wool's avatar
      [MTD] [NAND] remove len/ooblen confusion. · 7014568b
      Vitaly Wool authored
      As was discussed between Ricard Wanderlöf, David Woodhouse, Artem 
      Bityutskiy and me, the current API for reading/writing OOB is confusing. 
      
      The thing that introduces confusion is the need to specify ops.len 
      together with ops.ooblen for reads/writes that concern only OOB not data 
      area. So, ops.len is overloaded: when ops.datbuf != NULL it serves to 
      specify the length of the data read, and when ops.datbuf == NULL, it 
      serves to specify the full OOB read length.
      
      The patch inlined below is the slightly updated version of the previous 
      patch serving the same purpose, but with the new Artem's comments taken 
      into account.
      
      Artem, BTW, thanks a lot for your valuable input!
      Signed-off-by: default avatarVitaly Wool <vwool@ru.mvista.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      7014568b
  27. 26 Jun, 2006 1 commit
  28. 29 May, 2006 2 commits
    • Thomas Gleixner's avatar
      [MTD] NAND Signal that a bitflip was corrected by ECC · 9a1fcdfd
      Thomas Gleixner authored
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      9a1fcdfd
    • Thomas Gleixner's avatar
      [MTD] Rework the out of band handling completely · 8593fbc6
      Thomas Gleixner authored
      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: default avatarThomas Gleixner <tglx@linutronix.de>
      8593fbc6