Currently on SD/MMC card removal the system exhibits the following message (the platform is ARM Versatile):

    prev->state: 2 != TASK_RUNNING??
    mmcqd/762[CPU#0]: BUG in __schedule at linux-2.6/kernel/sched.c:3826

(akpm: someone tried to fix this, but it's still wrong)

Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

Converts from using struct "class_device" to "struct device" making
everything show up properly in /sys/devices/ with symlinks from the
/sys/class directory.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

After mmc_block's remove function has exited, we must not
touch the card structure in any way. This means we not only
must remove the gendisk, we must also flush out any
remaning requests already queued up.

We previously removed the disk, but didn't flush it,
causing oops:es when removing a card in the middle of a
transfer.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

Replace kernel_thread() with kthread_run()/kthread_stop().

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

Right now ->flags is a bit of a mess: some are request types, and
others are just modifiers. Clean this up by splitting it into
->cmd_type and ->cmd_flags. This allows introduction of generic
Linux block message types, useful for sending generic Linux commands
to block devices.

Signed-off-by: Jens Axboe <axboe@suse.de>

Patch from Juha [l

When the block queue is plugged, mq->req must be set to NULL.
Otherwise mq->req might be left non-NULL, even though mmcqd is
not processing a request, thus preventing the MMC queue thread from
being woken up when new requests do arrive.

Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

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!