pcmcia_enable_device() now replaces pcmcia_request_configuration().
Instead of config_req_t, all necessary flags are either passed as
a parameter to pcmcia_enable_device(), or (in rare circumstances)
set in struct pcmcia_device -> flags.

With the last remaining user of include/pcmcia/cs.h gone, remove
all references.

CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
CC: Jiri Kosina <jkosina@suse.cz>
CC: linux-scsi@vger.kernel.org
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi> (for drivers/bluetooth)
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Several drivers prefer to explicitly set config_{base,index,regs},
formerly known as ConfigBase, ConfigIndex and Present. Instead of
passing these values inside config_req_t, store it in struct
pcmcia_device.

CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
CC: Jiri Kosina <jkosina@suse.cz>
CC: linux-scsi@vger.kernel.org
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi> (for drivers/bluetooth)
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

IntType was only set to INT_MEMORY (driver pcmciamtd) or INT_MEMORY_AND_IO
(all other drivers). As this flags seems to relate to ioport access, make
it conditional to the driver having requested IO port access. There are two
drivers which do not request IO ports, but did set INT_MEMORY_AND_IO:
ray_cs and b43. For those, we consistently only set INT_MEMORY in future.

CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: laforge@gnumonks.org
CC: linux-mtd@lists.infradead.org
CC: alsa-devel@alsa-project.org
CC: linux-serial@vger.kernel.org
CC: Jiri Kosina <jkosina@suse.cz>
CC: linux-scsi@vger.kernel.org
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi> (for drivers/bluetooth)
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Some drivers prefer to explicitly set Vpp. Instead of passing the
voltage inside config_req_t, store it in struct pcmcia_device.

CC: linux-ide@vger.kernel.org
CC: netdev@vger.kernel.org
CC: linux-mtd@lists.infradead.org
CC: linux-wireless@vger.kernel.org
CC: linux-serial@vger.kernel.org
CC: linux-usb@vger.kernel.org
CC: linux-scsi@vger.kernel.org
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi> (for drivers/bluetooth)
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

pcmcia_modify_configuration() was only used by two drivers to fix up
one issue each: setting the Vpp to a different value, and reducing
the IO width to 8 bit. Introduce two explicitly named functions
handling these things, and remove one further typedef.

CC: netdev@vger.kernel.org
CC: linux-mtd@lists.infradead.org
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Instead of win_req_t, drivers are now requested to fill out
struct pcmcia_device *p_dev->resource[2,3,4,5] for up to four iomem
ranges. After a call to pcmcia_request_window(), the windows found there
are reserved and may be used until pcmcia_release_window() is called.

CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-mtd@lists.infradead.org
CC: Jiri Kosina <jkosina@suse.cz>
CC: linux-scsi@vger.kernel.org
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Signed-off-by: NMark F. Brown <mark.brown314@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This patch initializes the pages per block field in CONFIG1 for
v2 controllers. It also sets the FP_INT field. This is the last
field not correctly initialized, so we can switch from
read/modify/write the CONFIG1 reg to just write the correct
value.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NJohn Ogness <john.ogness@linutronix.de>
Tested-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When DMA error occurs. it's loop hang since it can't exit the loop.
and it's the right DMA handling code as Spec.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Wrong assumption bufferram can be switched between BufferRAM0 and BufferRAM1
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Since info->mtd isn't dynamically allocated, we shouldn't attempt to
kfree() it.  Otherwise we get random fun corruption when unloading
the driver built as a module.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Seems some patches got out sync when being merged.  The Blackfin NFC
driver was updated to use nand_scan_ident(), but it missed the change
where nand_scan_ident() now takes 3 arguments.  So update this driver
to fix build failures.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

When an erroneous PEB is scheduling for scrubbing, we end up with the
following oops:

[<c0162404>] (prot_queue_del+0x0/0x50) from [<c01635b4>] (ubi_wl_scrub_peb+0xec/0x13c)
[<c01634c8>] (ubi_wl_scrub_peb+0x0/0x13c) from [<c01603bc>] (ubi_eba_read_leb+0x200/0x428)
[<c01601bc>] (ubi_eba_read_leb+0x0/0x428) from [<c015e3c0>] (ubi_leb_read+0xe8/0x138)
[<c015e2d8>] (ubi_leb_read+0x0/0x138) from [<c00d6918>] (ubifs_start_scan+0x7c/0xf4)
[<c00d689c>] (ubifs_start_scan+0x0/0xf4) from [<c00e3650>] (ubifs_recover_leb+0x3c/0x730)
[<c00e3614>] (ubifs_recover_leb+0x0/0x730) from [<c00e444c>] (ubifs_recover_log_leb+0xc8/0x2dc)
[<c00e4384>] (ubifs_recover_log_leb+0x0/0x2dc) from [<c00d7c20>] (ubifs_replay_journal+0xb90/0x13a4)
[<c00d7090>] (ubifs_replay_journal+0x0/0x13a4) from [<c00cdd68>] (ubifs_fill_super+0xb84/0x1054)
[<c00cd1e4>] (ubifs_fill_super+0x0/0x1054) from [<c00ced04>] (ubifs_get_sb+0xc4/0x2ac)
[<c00cec40>] (ubifs_get_sb+0x0/0x2ac) from [<c007f04c>] (vfs_kern_mount+0x58/0x94)
[<c007eff4>] (vfs_kern_mount+0x0/0x94) from [<c007f0e8>] (do_kern_mount+0x40/0xe8)
[<c007f0a8>] (do_kern_mount+0x0/0xe8) from [<c0095628>] (do_new_mount+0x68/0x8c)
[<c00955c0>] (do_new_mount+0x0/0x8c) from [<c00957a8>] (do_mount+0x15c/0x1b8)
[<c009564c>] (do_mount+0x0/0x1b8) from [<c0095890>] (sys_mount+0x8c/0xd4)
[<c0095804>] (sys_mount+0x0/0xd4) from [<c0023c00>] (ret_fast_syscall+0x0/0x2c)
Kernel panic - not syncing: Fatal exception

The problem is that 'ubi_wl_scrub_peb()' does not expect that PEBs may
be in the erroneous tree, which is a bug. This patch fixes the bug
and adds corresponding check to 'ubi_wl_scrub_peb()'. Now it will simply
ignore erroneous PEBs, instead of causing an oops.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

warning: (OPTPROBES && KPROBES && HAVE_OPTPROBES && !PREEMPT && DEBUG_KERNEL ||
MTD_UBI_DEBUG && MTD && SYSFS && MTD_UBI || UBIFS_FS_DEBUG && MISC_FILESYSTEMS &&
UBIFS_FS || LOCKDEP && DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT &&
STACKTRACE_SUPPORT && LOCKDEP_SUPPORT || LATENCYTOP && HAVE_LATENCYTOP_SUPPORT &&
DEBUG_KERNEL && STACKTRACE_SUPPORT && PROC_FS) selects KALLSYMS_ALL
which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS)
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Commit 0798cea8 "UBI: improve corrupted flash handling"
broke delet-compatible volumes handling - it introduced a limit of 8 eraseblocks which
may be corrupted. And delete-compatible eraseblocks are added to the "corrupted" list,
so if we'd have a large delete-compatible volume, UBI would refuse it.

The fix is to add delete-compatible volumes to the erase list instead. Indeed, they are
corrupted, we just have to erase them.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

list_for_each_entry uses its first argument to move from one element to the
next, so modifying it can break the iteration.  The variable re1 is already
used within the loop as a temporary variable, and is not live here.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
iterator name list_for_each_entry;
expression x,E;
position p1,p2;
@@

list_for_each_entry@p1(x,...) { <... x =@p2 E ...> }

@@
expression x,E;
position r.p1,r.p2;
statement S;
@@

*x =@p2 E
...
list_for_each_entry@p1(x,...) S
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch avoids byte access to the NFC buffer. Byte access to the
NFC is not allowed.

The patch is against linux-next 20100618.
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Tested-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Apparently, the check for a 6-byte ID string introduced by commit
426c457a ("mtd: nand: extend NAND flash
detection to new MLC chips") is NOT sufficient to determine whether or
not a Samsung chip uses their new MLC detection scheme or the old,
standard scheme. This adds a condition to check cell type.
Signed-off-by: NTilman Sauerbeck <tilman@code-monkey.de>
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org

Commit c7b28e25 ("mtd: nand: refactor BB 
marker detection") caused a regression in detection of factory-set bad 
block markers, especially for certain small-page NAND. This fix removes 
some unneeded constraints on using NAND_SMALL_BADBLOCK_POS, making the 
detection code more correct.

This regression can be seen, for example, in Hynix HY27US081G1M and
similar.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Tested-by: NMichael Guntsche <mike@it-loops.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Test on a PXA310 platform with Samsung K9F2G08X0B NAND flash,
with tCH=5 and clk is 156MHz, ns2cycle(5, 156000000) returns -1.

ns2cycle returns negtive value will break NDTR0_tXX macros.

After checking the commit log, I found the problem is introduced by
commit 5b0d4d7c
"[MTD] [NAND] pxa3xx: convert from ns to clock ticks more accurately"

To get num of clock cycles, we use below equation:
num of clock cycles = time (ns) / one clock cycle (ns) + 1
We need to add 1 cycle here because integer division will truncate the result.
It is possible the developers set the Min values in SPEC for timing settings.
Thus the truncate may cause problem, and it is safe to add an extra cycle here.

The various fields in NDTR{01} are in units of clock ticks minus one,
thus we should subtract 1 cycle then.

Thus the correct equation should be:
num of clock cycles = time (ns) / one clock cycle (ns) + 1 - 1
                    = time (ns) / one clock cycle (ns)
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NLei Wen <leiwen@marvell.com>
Acked-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org

The drivers for Xilinx' SystemACE and physically mapped MTDs were missing
prototypes for of_address_to_resource(). This patch adds the necessary
headers.
Signed-off-by: NGraeme Smecher <graeme.smecher@mail.mcgill.ca>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The buswidth for chips of ID 0xD7 is x8, not x16.
This was my previous typo.
Signed-off-by: NBrian Norris <norris@broadcom.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

"plat_id" is always non-NULL here.  There is a zero element on the end
of the m25p_ids[] array and if we hit the end of the loop then plat_id
points to that.

This would lead to a NULL pointer dereference later on in the function.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

This is just a cleanup, it doesn't fix any bugs.

These functions all check retlen inconsistently and it generates a
warning in Smatch (http://smatch.sf.net).  If retlen were ever NULL it
would cause an oops and the code has been this way since 2006 so someone
would have complained.  Also I looked at other places that implemented
the mtd read and write functions and they dereference retlen without
checking.

I removed the checks.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

All hardware initialization will be done in denali_hw_init before
irq handler registered
Change mtd name from "DENALI NAND" to be "denali-nand" since whitespace in
name can cause problems if we use cmdlinepart
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

In mtd->write, Denali controller will use MODE_11 mode to read
NAND flash status, then return back to MODE_1O mode to do page
write.
Here comes a bug for this kind of using, sometimes controller will
not write data to NAND and just return a good interrupt to tell
driver writing work is done. The data in this page is all 0xff and
this page can not be written again. The reason is unknow.

So read Denali controller register WRITE_PROTECT to get NAND status
instead.
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

waring: no space for starting a line
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Fix mtd/nand_base.c kernel-doc warnings and typos.

Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'invert'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:2087): No description found for parameter 'len'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.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>

Fix mtd/nand_base.c kernel-doc warnings and typos.

Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:893): No description found for parameter 'invert'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:930): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'mtd'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'ofs'
Warning(drivers/mtd/nand/nand_base.c:987): No description found for parameter 'len'
Warning(drivers/mtd/nand/nand_base.c:2087): No description found for parameter 'len'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Once the last ECC error was handled, controller will triger an
interrupt. If this interrupt can not be clean on time, controller
may corrupt.
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

denali_write32() just implements a debug function for iowrite32(),
only print out the write value. Remove this function since it's useless
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Fixed a pci_resource_len function error;
Changed returning sequence of probe function;
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

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

There are three reasons to add this support:
1. users probably know the interface type of their flashs, then probe
can be faster if they give the right type in platform data since wrong
types will not be detected.
2. sometimes, detecting can cause destory to system. For example, for
kernel XIP, detecting can cause NOR enter a mode instructions can not
be fetched right, which will make kernel crash.
3. For a new probe which is not listed in the rom_probe_types, if users
assign it in board files, physmap can still probe it.
Signed-off-by: NBarry Song <21cnbao@gmail.com>
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The open and release block_device_operations are currently
called with the BKL held. In order to change that, we must
first make sure that all drivers that currently rely
on this have no regressions.

This blindly pushes the BKL into all .open and .release
operations for all block drivers to prepare for the
next step. The drivers can subsequently replace the BKL
with their own locks or remove it completely when it can
be shown that it is not needed.

The functions blkdev_get and blkdev_put are the only
remaining users of the big kernel lock in the block
layer, besides a few uses in the ioctl code, none
of which need to serialize with blkdev_{get,put}.

Most of these two functions is also under the protection
of bdev->bd_mutex, including the actual calls to
->open and ->release, and the common code does not
access any global data structures that need the BKL.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NChristoph Hellwig <hch@infradead.org>
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>