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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html