linux-toradex.git/drivers/scsi/scsi_lib.c, branch v2.6.16.17

[SCSI] scsi: scsi command retries off by one fix

2006-02-28T03:38:39+00:00

Fix up an off by one error in calculating retries for scsi
commands. This bug was discovered when an SG_IO request
was sent to scsi core with retries = 0, causing the overall
timeout check to go off in scsi_softirq_done.

Signed-off-by: Brian King 
Signed-off-by: James Bottomley

[PATCH] add scsi_execute_in_process_context() API

2006-02-14T17:14:26+00:00

We have several points in the SCSI stack (primarily for our device
functions) where we need to guarantee process context, but (given the
place where the last reference was released) we cannot guarantee this.

This API gets around the issue by executing the function directly if
the caller has process context, but scheduling a workqueue to execute
in process context if the caller doesn't have it.  Unfortunately, it
requires memory allocation in interrupt context, but it's better than
what we have previously.  The true solution will require a bit of
re-engineering, so isn't appropriate for 2.6.16.

Signed-off-by: James Bottomley

[SCSI] Prevent scsi_execute_async from guessing cdb length

2006-01-26T20:13:50+00:00

When the scsi_execute_async interface was added it ended up reducing
the flexibility of userspace to send arbitrary scsi commands through
sg using SG_IO. The SG_IO interface allows userspace to specify the
CDB length. This is now ignored in scsi_execute_async and it is
guessed using the COMMAND_SIZE macro, which is not always correct,
particularly for vendor specific commands. This patch adds a cmd_len
parameter to the scsi_execute_async interface to allow the caller
to specify the length of the CDB.

Signed-off-by: Brian King 
Signed-off-by: James Bottomley

[SCSI] always handle REQ_BLOCK_PC requests in common code

2006-01-14T16:54:45+00:00

LLDDs should never see REQ_BLOCK_PC requests, we can handle them just
fine in the core code.  There is a small behaviour change in that some
check in sr's rw_intr are bypassed, but I consider the old behaviour
a bug.

Mike found this cleanup opportunity and provdided early patches, so all
the credit goes to him, even if I redid the patches from scratch beause
that was easier than forward-porting the old patches.

Signed-off-by: Christoph Hellwig 
Signed-off-by: James Bottomley

[SCSI] Kill the SCSI softirq handling

2006-01-09T15:03:03+00:00

This patch moves the SCSI softirq handling to the block layer version.
There should be no functional changes.

Signed-off-by: Jens Axboe

[SCSI] scsi_end_async() needs to take an uptodate parameter

2006-01-06T11:38:30+00:00

Signed-off-by: Jens Axboe

[BLOCK] update SCSI to use new blk_ordered for barriers

2006-01-06T08:52:55+00:00

All ordered request related stuff delegated to HLD.  Midlayer
now doens't deal with ordered setting or prepare_flush
callback.  sd.c updated to deal with blk_queue_ordered
setting.  Currently, ordered tag isn't used as SCSI midlayer
cannot guarantee request ordering.

Signed-off-by: Tejun Heo 
Signed-off-by: Jens Axboe

[BLOCK] add @uptodate to end_that_request_last() and @error to rq_end_io_fn()

2006-01-06T08:49:03+00:00

add @uptodate argument to end_that_request_last() and @error
to rq_end_io_fn().  there's no generic way to pass error code
to request completion function, making generic error handling
of non-fs request difficult (rq->errors is driver-specific and
each driver uses it differently).  this patch adds @uptodate
to end_that_request_last() and @error to rq_end_io_fn().

for fs requests, this doesn't really matter, so just using the
same uptodate argument used in the last call to
end_that_request_first() should suffice.  imho, this can also
help the generic command-carrying request jens is working on.

Signed-off-by: tejun heo 
Signed-Off-By: Jens Axboe

Fix up SCSI mismerge

2005-12-16T02:17:02+00:00

I forgot to do a git-update-cache on the merged files ...

[SCSI] seperate max_sectors from max_hw_sectors

2005-12-15T23:11:40+00:00

- export __blk_put_request and blk_execute_rq_nowait
needed for async REQ_BLOCK_PC requests
- seperate max_hw_sectors and max_sectors for block/scsi_ioctl.c and
SG_IO bio.c helpers per Jens's last comments. Since block/scsi_ioctl.c SG_IO was
already testing against max_sectors and SCSI-ml was setting max_sectors and
max_hw_sectors to the same value this does not change any scsi SG_IO behavior. It only
prepares ll_rw_blk.c, scsi_ioctl.c and bio.c for when SCSI-ml begins to set
a valid max_hw_sectors for all LLDs. Today if a LLD does not set it
SCSI-ml sets it to a safe default and some LLDs set it to a artificial low
value to overcome memory and feedback issues.

Note: Since we now cap max_sectors to BLK_DEF_MAX_SECTORS, which is 1024,
drivers that used to call blk_queue_max_sectors with a large value of
max_sectors will now see the fs requests capped to BLK_DEF_MAX_SECTORS.

Signed-off-by: Mike Christie 
Signed-off-by: James Bottomley