| Age | Commit message (Collapse) | Author |
|---|
|
Because scsi_print_sense_hdr prefixes with KERN_INFO, the output from
scsi_io_completion looks like:
sd 0:0:0:0: [sdb] Device not ready: <6>: Sense Key : 0x2 [current]
: ASC=0x4 ASCQ=0x3
By using scsi_show_sense_hdr, we can get the much more appealing output:
sd 0:0:0:0: [sdb] Device not ready: Sense Key : 0x2 [current]
sd 0:0:0:0: [sdb] Device not ready: ASC=0x4 ASCQ=0x3
Acked-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Add missing additional sense code and provide pointer to upstream
reference (from Doug Gilbert).
Add missing const (from Michael Tokarev).
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Clean up constants.c and make result printing more user friendly:
- Refactor the command and sense functions so that the actual
formatting can be called from the various helper functions with the
correct prefix.
- Replace scsi_print_hostbyte() and scsi_print_driverbyte() with
scsi_print_result() which is verbose when CONFIG_SCSI_CONSTANTS is
on.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Following on from my post titled: "additional sense codes
need update" see the attachment against lk 2.6.17 .
ChangeLog:
- update additional sense codes table to agree with
SPC-4 revision 5a (14 June 2006)
- adjust some of the opcode names
Signed-off-by: Douglas Gilbert <dougg@torque.net>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
With Achim patch the last user (gdth) is switched away from scsi_request
so we an kill it now. Also disables some code in i2o_scsi that was
broken since the sg driver stopped using scsi_requests.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Use ARRAY_SIZE macro instead of sizeof(x)/sizeof(x[0]) and remove
duplicates of the macro.
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
scsi_print_msg() is an SPI-specific concept. This patch moves it from
constants.c to scsi_transport_spi.c and updates the Kconfig to link in
the SPI class for the drivers which use scsi_print_msg().
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
patch below marks a few scsi core datastructures as const, so that they end up
in the .rodata section and don't cacheline share with things that get dirtied
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
This should eliminate (at least in the mid layer) to make numeric
assumptions about any of the enumeration variables. As a side effect,
it will also make all the messages consistent and line us up nicely for
the error logging strategy (if it ever shows itself again).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
This one removes struct scsi_request entirely from sd. In the process,
I noticed we have no callers of scsi_wait_req who don't immediately
normalise the sense, so I updated the API to make it take a struct
scsi_sense_hdr instead of simply a big sense buffer.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
C files should include the files with the prototypes for their global
functions.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
We have the scsi_print_* functions in the proper namespace for a long
time now and there weren't a lot users left.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
