linux.git/drivers/mmc/mmc_queue.c, branch v2.6.19 Linux kernel source tree [PATCH] Split struct request ->flags into two parts 2006-09-30T18:23:37+00:00 Jens Axboe axboe@suse.de 2006-08-10T06:44:47+00:00 4aff5e2333c9a1609662f2091f55c3f6fffdad36 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> 
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>
[ARM] 3744/1: MMC: mmcqd gets stuck when block queue is plugged 2006-08-06T08:58:22+00:00 Juha [êölä juha.yrjola@solidboot.com 2006-08-06T08:58:22+00:00 c723e08af18e60cda3bbc90e0d6fb688587aeb9f 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> 
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>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 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! 
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!