Re: [PATCH] memstick: use __blk_end_request to complete requests
From: Andrew Morton
Date: Mon Feb 04 2008 - 02:07:16 EST
On Sun, 3 Feb 2008 20:31:10 -0800 (PST) Alex Dubov <oakad@xxxxxxxxx> wrote:
> Signed-off-by: Alex Dubov <oakad@xxxxxxxxx>
>
> --- mspro_block.c.orig 2008-02-04 15:25:16.000000000 +1100
> +++ mspro_block.c 2008-02-04 15:26:28.226886699 +1100
> @@ -668,20 +668,13 @@
>
> spin_lock_irqsave(&msb->q_lock, flags);
> if (rc >= 0)
> - chunk = end_that_request_chunk(req, 1, rc);
> + chunk = __blk_end_request(req, 0, rc);
> else
> - chunk = end_that_request_first(req, rc,
> - req->current_nr_sectors);
> + chunk = __blk_end_request(req, rc, 0);
>
> dev_dbg(&card->dev, "end chunk %d, %d\n", rc, chunk);
> - if (!chunk) {
> - add_disk_randomness(req->rq_disk);
> - blkdev_dequeue_request(req);
> - end_that_request_last(req, rc > 0 ? 1 : rc);
> - }
> spin_unlock_irqrestore(&msb->q_lock, flags);
> } while (chunk);
> -
> }
>
> static int mspro_block_has_request(struct mspro_block_data *msb)
>
Thanks. However please do prepare patches in `patch -p1' form.
Could you please fix the build error in the code in 2.6.24-mm1?
I part-fixed it (then disabled it) with this:
--- a/drivers/memstick/core/mspro_block.c~a
+++ a/drivers/memstick/core/mspro_block.c
@@ -1233,11 +1232,12 @@ static int mspro_block_resume(struct mem
unsigned long flags;
int rc = 0;
-#ifdef CONFIG_MEMSTICK_UNSAFE_RESUME
+#if defined(CONFIG_MEMSTICK_UNSAFE_RESUME) && 0
struct mspro_block_data *new_msb;
struct memstick_host *host = card->host;
- struct mspro_sys_attr s_attr, r_attr;
+ struct mspro_sys_attr *s_attr;
+ struct mspro_sys_attr *r_attr;
unsigned char cnt;
mutex_lock(&host->lock);
_
see, this:
s_attr = container_of(new_msb->attr_group.attrs[cnt],
struct mspro_sys_attr,
dev_attr);
is broken. Attribute groups hold `struct attribute' but this code thinks
they hold `struct device_attribute'. I could bodge it to compile cleanly,
but I don't know if it will work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/