kernel/include/scsi/scsi_dbg.h, branch linux-3.17.y

[SCSI] Fix device not ready printk

2007-10-12T18:51:56Z

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 Signed-off-by: James Bottomley

[SCSI] constants.c: cleanup, verbose result printing

2007-03-11T16:14:02Z

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 Signed-off-by: James Bottomley

[SCSI] remove scsi_request infrastructure

2006-06-10T21:24:40Z

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 Signed-off-by: James Bottomley

[SCSI] Rename scsi_print_msg to spi_print_msg

2005-12-16T02:41:27Z

Rename scsi_print_msg to spi_print_msg and move its prototype from scsi_dbg.h to scsi_transport_spi.h Signed-off-by: Matthew Wilcox Signed-off-by: James Bottomley

[SCSI] convert sd to scsi_execute_req (and update the scsi_execute_req API)

2005-08-28T16:33:52Z

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

Linux-2.6.12-rc2

2005-04-16T22:20:36Z

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!