The patch ensures that the current code (kernel 2.6.22) uses the bits 
like the code prior to the refactoring. The variable "bits" is employed 
in a useful way now.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Updated version of patch, in response to comments from Francois Romieu
<romieu@fr.zoreil.com>

Remove gratuitous casts from iounmap and initialisation of variables.
Signed-off-by: NAmol Lad <amol@verismonetworks.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

ioremap must be balanced by an iounmap and failing to do so can result
in a memory leak.

Tested (compilation only) with:
- allmodconfig
- Modifying drivers/mtd/maps/Kconfig and drivers/mtd/nand/Kconfig to
make sure that the changed file is compiling without warning
Signed-off-by: NAmol Lad <amol@verismonetworks.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Modularize the write function and reorganaize the internal buffer
management. Remove obsolete chip options and fixup all affected
users.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

The hwcontrol function enforced a step by step state machine
for any kind of hardware chip access. Let the hardware driver
know which control bits are set and inform it about a change
of the control lines. Let the hardware driver write out the
command and address bytes directly. This gives a peformance
advantage for address bus controlled chips and simplifies the
quirks in the hardware drivers.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

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

The _board_ driver needs to be mtd->owner, and it in turn pins the
nand.ko module. Fix them all to actually do that, and fix nand.ko not to
overwrite it -- and also to check that the caller sets it, if the caller
is a module.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

It was just too painful to deal with.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.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!