We do not need to invoke 'mtd_can_have_bb()' before invoking
'mtd_block_isbad()' because the latter already handles the case when the MTD
device does not support bad blocks.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch introduces new 'mtd_can_have_bb()' helper function which checks
whether the flash can have bad eraseblocks. Then it changes all the
direct 'mtd->block_isbad' use cases with 'mtd_can_have_bb()'.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

We are cleaning up the implicit presence of module.h that these
drivers are taking advantage of.  Fix them in advance of the
cleanup operation.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

parse_mtd_partitions takes a list of partition types; if the driver
isn't loaded, it attempts to load it, and then it grabs the partition
parser.  For redboot, the module name is "redboot.ko", while the parser
name is "RedBoot".  Since modprobe is case-sensitive, attempting to
modprobe "RedBoot" will never work.  I suspect the embedded systems that
make use of redboot just always manually loaded redboot prior to loading
their specific nand chip drivers (or statically compiled it in).
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: stable@kernel.org

Encapsulate last MTD partition parser argument into a separate
structure. Currently it holds only 'origin' field for RedBoot parser,
but will be extended in future to contain at least device_node for OF
devices.

Amended commentary to make kerneldoc happy
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NArtem Bityutskiy <dedekind1@gmail.com>

Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Although if people have questions about ARCnet, perhaps it's _better_
for them to be mailing dwmw2@cam.ac.uk about it...
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Once upon a time, the MTD repository was using CVS.

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

This also includes code that printed them to the user.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Also limit the amount we scan to one eraseblock.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Correct the location of the recalculation of the FIS directory size,
and also add the same recalculation for the byte-swapped case.
Signed-off-by: NRod Whitby <rod@whitby.id.au>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

This fixes a regression with the RedBoot parsing code introduced by
commit 0b47d654Signed-off-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

RedBoot supports storing the FIS directory and the RedBoot
configuration area in the same block of flash memory.  This is
not the most common RedBoot configuration, but it is used on
commercially available boards supported by the kernel.

A recent patch to mtd/redboot.c (http://lkml.org/lkml/2006/3/20/410)
which corrected the skipping of deleted table entries has exposed the
latent problem of the kernel redboot parser running off the end of the
FIS directory and interpreting the RedBoot configuration information
as table entries.

This patch terminates the table parsing when the first truly empty
entry is found (table entry deletion only clears the first byte of the
name, so two cleared bytes in a row indicates the end of the table),
thereby supporting the combined redboot FIS directory and RedBoot
configuration information flash layout scenario.
Signed-off-by: NRod Whitby <rod@whitby.id.au>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Can't analyze FIS directory in CYGSEM_REDBOOT_FLASH_COMBINED_FIS_AND_CONFIG
really.
Signed-off-by: NYoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Signed-off-by: NYan Burman <yan_952@hotmail.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Fix build warnings from drivers/mtd/redboot.c due to
use of `unsigned long` in `struct fis_image_desc` for
fields being passed to swab32s() which expects __u32 *

Change the entries to uint32_t to make them compatible
with the swab32s() function
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Redboot simply sets the first character of a fis entry to 0xff on "fis
delete".  The kernel redboot parser stops parsing on such an entry, and
without this patch any entries after a deleted image would not be detected.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Sync up the recent redboot fix with MTD CVS.  It uses the correct swab()
functions.

Cc: John Bowler <jbowler@acm.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The RedBoot boot loader writes flash partition tables containing native
byte sex 32 bit values.  When booting an opposite byte sex kernel (e.g.  an
LE kernel from BE RedBoot) the current MTD driver fails to handle the
partition table and therefore is unable to generate the correct partition
map for the flash.

So far as I am aware this problem is ARM specific, because only ARM
supports software change of the CPU (memory system) byte sex, however the
partition table parsing is in generic MTD code.  The patch below has been
tested on NSLU2 (an IXP4XX based system) with a patch,
10-ixp4xx-copy-from.patch (submitted to linux-arm-kernel - it's ARM
specific) required to make the maps/ixp4xx.c driver work with an LE kernel.

Builds of the patched system are in the 'unstable' release of OpenSlug and
UcSlugC available from www.nslu2-linux.org.  These builds are BE, the
archives at www.nslu2-linux.org and www.handhelds.org (see
monotone.vanille.de) can be built LE (currently DISTRO targets
nslu-ltu.conf for LE thumb uclibc (32 bit kernel) and nslu2-lau.conf,
nslu2-lag.conf for LE arm uclibc/glibc) and this patch has been tested
extensively will both BE and LE systems on the NSLU2 (including swapping
between BE and LE by reflashing from both RedBoot and Linux).

The patch recognises that the FIS directory (the partition table) is
byte-reversed by examining the partition table size, which is known to be
one erase block (this is an assumption made elsewhere in redboot.c).  If
the size matches the erase block after byte swapping the value then
byte-reversal is assumed, if not no further action is taken.  The patched
code is fail safe; should redboot.c be changed to support a partition table
with a modified size field the test will fail and the partition table will
be assumed to have the host byte sex.

If byte-reversal is detected the patch byte swaps the remainder of the 32
bit fields in the copy of the table; this copy is then used to set up the
MTD partition map.
Signed-off-by: NJohn Bowler <jbowler@acm.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

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!