Doh. Pointed out by Guillaume LECERF <glecerf@gmail.com> since I managed
to miss it in my test builds. S'what I get for hacking at 2am, I suppose.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds support for detecting SST 39VF32xxB and 39VF64xxB
chips in CFI mode.
Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

SST 39VF{16,32}xx chips use the 0x0701 command set, fully compatible
with the AMD one. This patch adds support for detecting them in CFI
mode.
Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Accept values of 2-5 for TopBottom, where the newly-added 4 and 5 values
mean a uniform layout. It does indicate WP layout but we don't handle that.

Also don't say "broken" when swapping erase regions in a top-boot chip.
That got retrospectively documented in the spec.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

After looking at AMD's CFI specification [1], both of the extended query
tables are optional. Thus, it looks like relying that at least one of
those tables exist is a bug in cfi_cmdset_0002.

This patch inverts the logic and checks for unlock function pointers before
exiting on error. This approach leaves place to add a call to a fixup
function to try to handle chips compatible with the early AMD specification
from 1995 [2].

[1] http://www.amd.com/us-en/assets/content_type/DownloadableAssets/cfi_r20.pdf
[2] http://noel.feld.cvut.cz/hw/amd/20158a.pdfSigned-off-by: NGuillaume LECERF <glecerf@gmail.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Ensure that the flash device is in a quiescent state before rebooting.
The implementation is closely modeled after the cfi_cmdset_0001 reboot
notifier, commit 963a6fb0 .
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The use of a memcpy() during a spinlock operation will cause very long
thread context switch delays if the flash chip bandwidth is low and the
data to be copied large, because a spinlock will disable preemption.

For example: A flash with 6,5 MB/s bandwidth will cause under ubifs,
which request sometimes 128 KiB (the flash erase size), a preemption delay of
20 milliseconds. High priority threads will not be served during this
time, regardless whether this threads access the flash or not. This behavior
breaks real time.

The patch changes all the use of spin_lock operations for xxxx->mutex
into mutex operations, which is exact what the name says and means.

I have checked the code of the drivers and there is no use of atomic
pathes like interrupt or timers. The mtdoops facility will also not be used
by this drivers. So it is dave to replace the spin_lock against mutex.

There is no performance regression since the mutex is normally not
acquired.

Changelog:
 06.03.2010 First release
 26.03.2010 Fix mutex[1] issue and tested it for compile failure
Signed-off-by: NStefani Seibold <stefani@seibold.net>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Move MANUFACTURER_MACRONIX and MANUFACTURER_SST definitions to the
include/linux/mtd/cfi.h header file and rename them to CFI_MFR_MACRONIX and
CFI_MFR_SST.

All references in drivers/mtd/chips/cfi_cmdset_0002.c are updated to reflect
this.
Signed-off-by: NGuillaume LECERF <glecerf@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

In cfi_intelext_setup and cfi_amdstd_setup, mtd is never NULL.
Remove unnecessary checks.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Stanse found a double unlock in get_chip. get_chip is called with
chip->mutex held and caller is responsible for unlocking it too.

Do not unlock the lock in get_chip on a fail path. This would mean
a double unlock.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Erase-suspend for writing is required to avoid blocking applications
that wish to write some data (to a NOR block other than the one being
erased). Particularly, it solves some huge delays that an application
(which writes to a UBIFS) will experience if UBI attaches to empty NOR
flash. In this case the UBI background thread will erase a lot of blocks
and the application can be blocked for minutes because of the "MTD/CFI
chip lock".

This feature has been disabled for years. Maybe this was because the old
code turned it on for erase-suspend read-only chips also
(cfip->EraseSuspend & 0x1). This is wrong and corrected now.

This patch was tweaked by Norbert van Bolhuis.
Signed-off-by: NNorbert van Bolhuis <nvbolhuis@aimvalley.nl>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The M29W128G Numonyx flash devices are intolerant to any 0xFF command:
in the Cfi_util.c the function cfi_qry_mode_off() (that resets the device
after the autoselect mode) must have a 0xF0 command after the 0xFF command.
This fix solves also the cause of the fixup_M29W128G_write_buffer() fix,
that can be removed now.
The following patch applies to 2.6.30 kernel.
Signed-off-by: NMassimo Cirillo <maxcir@gmail.com>
Acked-by: NAlexey Korolev <akorolev@infradead.org>
Cc: stable@kernel.org
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Prevent NUMONYX M29W128G memories from using write buffer,
because it doesn't work properly.
Signed-off-by: NDarius Augulis <augulis.darius@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The NOR Flash memory K8P2815UQB from Samsung uses the major version
number '0'. Add a quirk to cope with it.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

MTD internal API presently uses 32-bit values to represent
device size.  This patch updates them to 64-bits but leaves
the external API unchanged.  Extending the external API
is a separate issue for several reasons.  First, no one
needs it at the moment.  Secondly, whether the implementation
is done with IOCTLs, sysfs or both is still debated.  Thirdly
external API changes require the internal API to be accepted
first.

Note that although the MTD API will be able to support 64-bit
device sizes, existing drivers do not and are not required
to do so, although NAND base has been updated.

In general, changing from 32-bit to 64-bit values cause little
or no changes to the majority of the code with the following
exceptions:
    	- printk message formats
    	- division and modulus of 64-bit values
    	- NAND base support
	- 32-bit local variables used by mtdpart and mtdconcat
	- naughtily assuming one structure maps to another
	in MEMERASE ioctl
Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

For "unlock" cycles to 16bit devices in 8bit compatibility mode we need
to use the byte addresses 0xaaa and 0x555. These effectively match
the word address 0x555 and 0x2aa, except the latter has its low bit set.

Most chips don't care about the value of the 'A-1' pin in x8 mode,
but some -- like the ST M29W320D -- do. So we need to be careful to
set it where appropriate.

cfi_send_gen_cmd is only ever passed addresses where the low byte
is 0x00, 0x55 or 0xaa. Of those, only addresses ending 0xaa are
affected by this patch, by masking in the extra low bit when the device
is known to be in compatibility mode.

[dwmw2: Do it only when (cmd_ofs & 0xff) == 0xaa]
v4: Fix  stupid typo in cfi_build_cmd_addr that failed to compile
    I'm writing this patch way to late at night.
v3: Bring all of the work back into cfi_build_cmd_addr
    including calling of map_bankwidth(map) and cfi_interleave(cfi)
    So every caller doesn't need to.
v2: Only modified the address if we our device_type is larger than our
    bus width.

Cc: stable@kernel.org
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The CFI information read from AT49BV6416 lists the erase regions in the
wrong order, causing problems when trying to erase or update the first
or last 64KiB block.

Work around this by inverting the "top boot" flag, which will
effectively reverse the order of the erase regions.

This chip is obsolete, but it's used in some existing designs.
Signed-off-by: NHåvard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch adds TopBottom detection for most Macronix chips with CFI V1.0.

The main purpose of this patch is to add detection of the MX29LV400C B
used on the LaCie Ethernet Disk mini V2 NAS.

It detects the following parts correctly:-
MX28F640C3B T
MX29LV002C  B
MX29LV002NC B
MX29LV004C  T
MX29LV400C  T/B
MX29LV800C  T/B
MX29LV160C  T/B
MX29SL800C  T/B
MX29SL802C  T/B

It detects the following uniform part as bottom but it should work
correctly:-
MX29LV040C

For T parts it causes the erase block table to be reversed correctly.
For other parts it avoids the bogus "Assuming top" message.

It does not detect the following correctly:-
MX28F640C3B B
MX29LV002C  T
MX29LV002NC T
MX29LV004C  B
MX29SL400C  T/B
MX29SL402C  T/B

If desired I could supply a more complicated patch to handle these as
well.

Only the MX29LV400C B has been physically tested; others were checked
against their data sheets.
Signed-off-by: NChristopher Moore <moore@free.fr>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

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>

This is a known erratum confirmed by Spansion.  I have an errata document,
but I can't find a link to it anywhere on their site to include here.

Some of the S29GL064N chips report 64 sectors when they should report 128,
and some of S29GL032N chips report 127 sectors when they should report 63.

Note that when the chip dies are fixed by Spansion, they will still have
the same id.  The fix is done in such a way that it won't affect corrected
chips.

The fixups use the extended id made available by a previous patch.  Without
that, virtually all newer AMD/Spansion chips will have the same ID (0x227e)
and it's not possible to apply the fixup to the correct chips.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Untested, but shouldn't break anything... Makes MTD_XIP arch
independent. I guess this is why xip_iprefetch() was made for.
Signed-off-by: NPaulius Zaleckas <paulius.zaleckas@teltonika.lt>
Acked-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

cfi_amdstd_sync() and cfi_staa_sync() call schedule() without changing task's
state appropriately.

In case of e.g.  chip->state == FL_ERASING, cfi_*_sync() will be busy-looping
either redundantly for a fixed interval of time (for SCHED_NORMAL tasks) or
possibly endlessly (for RT tasks and UP).
Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Patch for unlocking all Intel flash that has instant locking on power up.
The patch has been tested on Intel M18, P30 and J3D Strata Flash.
  1.    The automatic unlocking can be disabled for a particular partition
         in the map or the command line.
     a. For the bit mask in the map it should look like:
         .mask_flags   = MTD_POWERUP_LOCK,
     b. For the command line parsing it should look like:
         mtdparts=0x80000(bootloader)lk
  2.    This will only unlock parts with instant individual block locking.
         Intel parts with legacy unlocking will not be unlocked.
Signed-off-by: NJustin Treon <justin_treon@yahoo.com>
Signed-off-by: NJared Hulbert <jaredeh@gmail.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

According to "Common Flash Memory Interface Publication 100" dated December 1,
2001, the interface code for x16/x32 chips is 0x0005, and not 0x0004 used so
far.
Signed-off-by: NBartlomiej Sieka <tur@semihalf.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Convert CFI tables from Atmel cmdset_0001 chips to Intel format and set
BufWrite timeouts to 0 for Atmel cmdset_0001 and cmdset_0002 chips.
Some chips may indicate support for buffered writes even though they
only support dual-word writes.

The CFI fixup must run before fixup_use_write_buffers for this to work.
Signed-off-by: NHåvard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Make cfi_amdstd_erase_varsize static, as declared at the top
of the file to ensure sparse does not print a warning for an
undeclared function, as so:

drivers/mtd/chips/cfi_cmdset_0002.c:1612:5: warning: symbol 'cfi_amdstd_erase_varsize' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

The files cfi_cmdset_0002.c and cfi_cmdset_0020.c do not initialize their
wait queues like is done in cfi_cmdset_0001.c.  This causes an oops when
the wait queue is accessed.  I have copied the code from cfi_cmdset_0001.c
that is pertinent to initialization of the wait queue.
Signed-off-by: NVijay Sampath <vsampath@gmail.com>
Acked-by: NJoern Engel <joern@lazybastard.org>
Acked-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.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>

Add chip driver and JEDEC probe support for the SST 49LF040B flash chip.
Signed-off-by: NRyan Jackson <rjackson@lnxi.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Introduce the MTD_STUPID_LOCK flag which indicates that the flash chip is
always locked after power-up, so all sectors need to be unlocked before it
is usable.

If this flag is set, and the chip provides an unlock() operation,
mtd_add_device will unlock the whole MTD device if it's writeable.  This
means that non-writeable partitions will stay locked.

Set MTD_STUPID_LOCK in fixup_use_atmel_lock() so that these chips will work
as expected.
Signed-off-by: NHåvard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

The memset() in fixup_convert_atmel_pri is supposed to zero out
everything except the first 5 bytes in *extp, but it ends up zeroing
out something way outside the struct instead. Fix this potentially
dangerous code by casting the pointer to char * before doing
arithmetic.
Signed-off-by: NHåvard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

The AT49BV6416 is locked by default, so we really need to provide
at least the unlock() operation for write and erase to work. This
patch implements both ->lock() and ->unlock() and provides a fixup
to install them when an AT49BV6416 chip is detected.

These functions are probably valid on more Atmel chips, but I believe
it's mostly obsolete ones. The AT49BV6416 is in fact obsolete, but
it's used on all current AT32STK1000 development boards.
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NJosh Boyer <jwboyer@gmail.com>

Atmel flash chips don't have PRI information in the same format as
AMD flash chips. This patch installs a fixup for all Atmel chips that
converts the relevant PRI fields into AMD format.

Only the fields that are actually used by the command set is actually
converted. The rest are initialized to zero (which should be safe)
Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: NJosh Boyer <jwboyer@gmail.com>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Signed-off-by: Artem B. Bityitskiy

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

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

This is the drivers/mtd part of the big kfree cleanup patch.

Remove pointless checks for NULL prior to calling kfree() in drivers/mtd/.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: NJoern Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

We've noticed that sometimes "MTD do_write_buffer(): software timeout"
message was printed out when writing to a Fujitsu NOR flash.
It turned out that this was because of a race in the timeout handling
do_write_buffer(). A small timeout of (HZ / 1000) + 1 is used there, and
sometimes if the timer interrupt handling takes more than one or even two
jiffies (which is 1-2 ms with HZ == 1000) and that interrupt happens just
after chip_ready() call, the driver bails out from a ready polling loop
despite the chip has actually become ready while all those interrupts were
handled. To deal with this issue, extra check for chip ready is neccessary on
timeout expiration (and the checks should better be reordered).
As do_write_oneword() uses the same approach, it needs to also be changed.
Signed-off-by: NKonstantin Baidarov <kbaidarov@ru.mvista.com>
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>