On Wed, 29 Apr 2009, Tejun Heo wrote:
> With recent cleanups, there is no place where low level driver
> directly manipulates request fields. This means that the 'hard'
> request fields always equal the !hard fields. Convert all
> rq->sectors, nr_sectors and current_nr_sectors references to
> accessors.
>
> [ Impact: use pos and nr_sectors accessors ]
>
> Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
> drivers/block/amiflop.c | 6 ++--
> drivers/block/ataflop.c | 10 +++---
> drivers/block/ps3disk.c | 9 ++---
> drivers/block/swim3.c | 34 ++++++++++++----------
> drivers/block/z2ram.c | 6 ++--
Looks OK, so
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx>
> diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c
> index b66ad58..d4e6b71 100644
> --- a/drivers/block/z2ram.c
> +++ b/drivers/block/z2ram.c
> @@ -71,12 +71,12 @@ static void do_z2_request(struct request_queue *q)
> {
> struct request *req;
> while ((req = elv_next_request(q)) != NULL) {
> - unsigned long start = req->sector << 9;
> - unsigned long len = req->current_nr_sectors << 9;
> + unsigned long start = blk_rq_pos(req) << 9;
> + unsigned long len = blk_rq_cur_sectors(req) << 9;
^^^^^^^^^^^^^
I guess this one can become `unsigned int' now, as:
static inline unsigned int blk_rq_cur_sectors(struct request *rq)
{
return blk_rq_cur_bytes(rq) >> 9;
}
and blk_rq_cur_bytes(rq) returns `int', so it must fit in an `int' anyway?
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@xxxxxxxxxxx
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
