1. 11 May, 2009 1 commit
    • Tejun Heo's avatar
      block: add rq->resid_len · c3a4d78c
      Tejun Heo authored
      
      
      rq->data_len served two purposes - the length of data buffer on issue
      and the residual count on completion.  This duality creates some
      headaches.
      
      First of all, block layer and low level drivers can't really determine
      what rq->data_len contains while a request is executing.  It could be
      the total request length or it coulde be anything else one of the
      lower layers is using to keep track of residual count.  This
      complicates things because blk_rq_bytes() and thus
      [__]blk_end_request_all() relies on rq->data_len for PC commands.
      Drivers which want to report residual count should first cache the
      total request length, update rq->data_len and then complete the
      request with the cached data length.
      
      Secondly, it makes requests default to reporting full residual count,
      ie. reporting that no data transfer occurred.  The residual count is
      an exception not the norm; however, the driver should clear
      rq->data_len to zero to signify the normal cases while leaving it
      alone means no data transfer occurred at all.  This reverse default
      behavior complicates code unnecessarily and renders block PC on some
      drivers (ide-tape/floppy) unuseable.
      
      This patch adds rq->resid_len which is used only for residual count.
      
      While at it, remove now unnecessasry blk_rq_bytes() caching in
      ide_pc_intr() as rq->data_len is not changed anymore.
      
      Boaz	: spotted missing conversion in osd
      Sergei	: spotted too early conversion to blk_rq_bytes() in ide-tape
      
      [ Impact: cleanup residual count handling, report 0 resid by default ]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Cc: Borislav Petkov <petkovbb@googlemail.com>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Mike Miller <mike.miller@hp.com>
      Cc: Eric Moore <Eric.Moore@lsi.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Doug Gilbert <dgilbert@interlog.com>
      Cc: Mike Miller <mike.miller@hp.com>
      Cc: Eric Moore <Eric.Moore@lsi.com>
      Cc: Darrick J. Wong <djwong@us.ibm.com>
      Cc: Pete Zaitcev <zaitcev@redhat.com>
      Cc: Boaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      c3a4d78c
  2. 27 Apr, 2009 2 commits
    • Tejun Heo's avatar
      block: kill rq->data · 731ec497
      Tejun Heo authored
      
      
      Now that all block request data transfer is done via bio, rq->data
      isn't used.  Kill it.
      
      While at it, make the roles of rq->special and buffer clear.
      
      [ Impact: drop now unncessary field from struct request ]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Boaz Harrosh <bharrosh@panasas.com>
      731ec497
    • Tejun Heo's avatar
      block: implement and use [__]blk_end_request_all() · 40cbbb78
      Tejun Heo authored
      
      
      There are many [__]blk_end_request() call sites which call it with
      full request length and expect full completion.  Many of them ensure
      that the request actually completes by doing BUG_ON() the return
      value, which is awkward and error-prone.
      
      This patch adds [__]blk_end_request_all() which takes @rq and @error
      and fully completes the request.  BUG_ON() is added to to ensure that
      this actually happens.
      
      Most conversions are simple but there are a few noteworthy ones.
      
      * cdrom/viocd: viocd_end_request() replaced with direct calls to
        __blk_end_request_all().
      
      * s390/block/dasd: dasd_end_request() replaced with direct calls to
        __blk_end_request_all().
      
      * s390/char/tape_block: tapeblock_end_request() replaced with direct
        calls to blk_end_request_all().
      
      [ Impact: cleanup ]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Mike Miller <mike.miller@hp.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: Alex Dubov <oakad@yahoo.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      40cbbb78
  3. 22 Apr, 2009 1 commit
  4. 21 Apr, 2009 1 commit
    • Arjan van de Ven's avatar
      driver synchronization: make scsi_wait_scan more advanced · d4d5291c
      Arjan van de Ven authored
      
      
      There is currently only one way for userspace to say "wait for my storage
      device to get ready for the modules I just loaded": to load the
      scsi_wait_scan module. Expectations of userspace are that once this
      module is loaded, all the (storage) devices for which the drivers
      were loaded before the module load are present.
      
      Now, there are some issues with the implementation, and the async
      stuff got caught in the middle of this: The existing code only
      waits for the scsy async probing to finish, but it did not take
      into account at all that probing might not have begun yet.
      (Russell ran into this problem on his computer and the fix works for him)
      
      This patch fixes this more thoroughly than the previous "fix", which
      had some bad side effects (namely, for kernel code that wanted to wait for
      the scsi scan it would also do an async sync, which would deadlock if you did
      it from async context already.. there's a report about that on lkml):
      The patch makes the module first wait for all device driver probes, and then it
      will wait for the scsi parallel scan to finish.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Tested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d4d5291c
  5. 14 Apr, 2009 1 commit
    • David Howells's avatar
      Fix lpfc_parse_bg_err()'s use of do_div() · 2344b5b6
      David Howells authored
      
      
      Fix lpfc_parse_bg_err()'s use of do_div().  It should be passing a 64-bit
      variable as the first parameter.  However, since it's only using a 32-bit
      variable, it doesn't need to use do_div() at all, but can instead use the
      division operator.
      
      This deals with the following warnings:
      
          CC      drivers/scsi/lpfc/lpfc_scsi.o
        drivers/scsi/lpfc/lpfc_scsi.c: In function 'lpfc_parse_bg_err':
        drivers/scsi/lpfc/lpfc_scsi.c:1397: warning: comparison of distinct pointer types lacks a cast
        drivers/scsi/lpfc/lpfc_scsi.c:1397: warning: right shift count >= width of type
        drivers/scsi/lpfc/lpfc_scsi.c:1397: warning: passing argument 1 of '__div64_32' from incompatible pointer type
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2344b5b6
  6. 13 Apr, 2009 2 commits
  7. 08 Apr, 2009 1 commit
  8. 07 Apr, 2009 5 commits
  9. 03 Apr, 2009 26 commits