Eric Lee / smarc-fsl-linux-kernel

10 Jan, 2012

6 commits

11 Sep, 2011

2 commits

31 Mar, 2011

1 commit

20 May, 2010

2 commits

03 Sep, 2009

1 commit

  • bc8cec0df   JFFS2: add missing verify buffer allocation/deallocation ... Browse Code »

    The function jffs2_nor_wbuf_flash_setup() doesn't allocate the verify buffer
    if CONFIG_JFFS2_FS_WBUF_VERIFY is defined, so causing a kernel panic when
    that macro is enabled and the verify function is called. Similarly the
    jffs2_nor_wbuf_flash_cleanup() must free the buffer if
    CONFIG_JFFS2_FS_WBUF_VERIFY is enabled.
    The following patch fixes the problem.
    The following patch applies to 2.6.30 kernel.

    Signed-off-by: Massimo Cirillo
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse
    Cc: stable@kernel.org

    Massimo Cirillo
     

18 Oct, 2008

1 commit

  • 5bf172372   [JFFS2] Write buffer offset adjustment for NOR-ECC (Sibley) flash ... Browse Code »

    After choosing new c->nextblock, don't leave the wbuf offset field
    occasionally pointing at the start of the next physical eraseblock.
    This was causing a BUG() on NOR-ECC (Sibley) flash, where we start
    writing after the cleanmarker.

    Among other this fix should cover write buffer offset adjustment
    after flushing the last page of an eraseblock.

    Signed-off-by: Alexander Belyakov
    Signed-off-by: David Woodhouse

    Alexander Belyakov
     

02 May, 2008

2 commits

22 Apr, 2008

2 commits

09 Aug, 2007

1 commit

11 Jul, 2007

1 commit

  • a6bc432e2   [JFFS2] Add support for write-buffer verification. ... Browse Code »

    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: David Woodhouse

    David Woodhouse
     

10 Jul, 2007

1 commit

05 May, 2007

1 commit

28 Apr, 2007

1 commit

27 Apr, 2007

1 commit

25 Apr, 2007

1 commit

  • c00c310ea   [JFFS2] Tidy up licensing/copyright boilerplate. ... Browse Code »

    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: David Woodhouse

    David Woodhouse
     

23 Apr, 2007

1 commit

  • 566865a2a   [JFFS2] Fix cross-endian build. ... Browse Code »

    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: David Woodhouse

    David Woodhouse
     

18 Apr, 2007

1 commit

  • 7f762ab24   [JFFS2] Disable summary after wbuf recovery ... Browse Code »

    After a write error, any data in the write buffer must
    be relocated. This is handled by the jffs2_wbuf_recover
    function. This function does not fix up the erase block
    summary information that is collected for writing at the
    end of the block, which results in an incorrect summary
    (or BUG if the summary was found to be empty).

    As the summary is not essential (it is an optimisation),
    it may be disabled for the current erase block when this
    situation arises. This patch does that.

    Signed-off-by: Adrian Hunter
    Signed-off-by: Artem Bityutskiy
    Signed-off-by: David Woodhouse

    Adrian Hunter
     

09 Mar, 2007

1 commit

08 Mar, 2007

1 commit

  • 180bfb31f   [JFFS2] Fix writebuffer recovery in the first page of a block ... Browse Code »

    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
    Signed-off-by: Thomas Gleixner
    Signed-off-by: David Woodhouse

    Vitaly Wool
     

19 Feb, 2007

1 commit

  • 7be26bfb2   [JFFS2] printk warning fixes ... Browse Code »

    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
    Signed-off-by: David Woodhouse

    Andrew Morton
     

09 Feb, 2007

1 commit

  • a7a6ace14   [JFFS2] Use MTD_OOB_AUTO to automatically place cleanmarker on NAND ... Browse Code »

    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
    Signed-off-by: David Woodhouse

    Artem Bityutskiy
     

18 Jan, 2007

1 commit

04 Dec, 2006

1 commit

29 Nov, 2006

1 commit

  • 7014568ba   [MTD] [NAND] remove len/ooblen confusion. ... Browse Code »

    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: Vitaly Wool
    Signed-off-by: David Woodhouse

    Vitaly Wool
     

27 Jun, 2006

1 commit

  • f116629d0   [PATCH] fs: use list_move() ... Browse Code »

    This patch converts the combination of list_del(A) and list_add(A, B) to
    list_move(A, B) under fs/.

    Cc: Ian Kent
    Acked-by: Joel Becker
    Cc: Neil Brown
    Cc: Hans Reiser
    Cc: Urban Widmark
    Acked-by: David Howells
    Acked-by: Mark Fasheh
    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

29 May, 2006

4 commits

  • 9a1fcdfd4   [MTD] NAND Signal that a bitflip was corrected by ECC ... Browse Code »

    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

    Thomas Gleixner
     
  • 8593fbc68   [MTD] Rework the out of band handling completely ... Browse Code »
    43

    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

    Thomas Gleixner
     
  • 5bd34c091   [MTD] NAND Replace oobinfo by ecclayout ... Browse Code »

    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

    Thomas Gleixner
     
  • ff268fb87   [MTD] NAND Consolidate oobinfo handling ... Browse Code »

    The info structure for out of band data was copied into
    the mtd structure. Make it a pointer and remove the ability
    to set it from userspace. The position of ecc bytes is
    defined by the hardware and should not be changed by software.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

27 May, 2006

2 commits