summaryrefslogtreecommitdiff
path: root/drivers/scsi/sr_ioctl.c
AgeCommit message (Collapse)AuthorFilesLines
2006-03-23[PATCH] kill cdrom ->dev_ioctl methodChristoph Hellwig1-19/+0
Since early 2.4.x all cdrom drivers implement the block_device methods themselves, so they can handle additional ioctls directly instead of going through the cdrom layer. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Jens Axboe <axboe@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-06Allocate 96 bytes for SCSI sense data replyLinus Torvalds1-1/+1
The SCSI layer uses SCSI_SENSE_BUFFERSIZE (96) for the sense buffer size, even though some other code uses "sizeof(struct request_sense)" (which is 64 bytes). Allocate the buffer using the bigger of the two for safety. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-14[SCSI] sr: split sr_audio_ioctl into specific helpersChristoph Hellwig1-91/+111
split each ioctl handled in sr_audio_ioctl into a function of it's own. This cleans the code up nicely, and allows various places in sr_ioctl to call these helpers directly instead of going through the multiplexer. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Jens Axboe <axboe@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-28[SCSI] convert sr to scsi_execute_reqJames Bottomley1-35/+27
This follows almost the identical model to sd, except that there's one ioctl which returns raw sense data, so it had to use scsi_execute() instead. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-04-21[SCSI] drivers/scsi/sr_ioctl.c: check for failed allocationNate Dailey1-0/+3
I noticed a case in sr_ioctl.c's sr_get_mcn where a buffer is allocated, but the pointer isn't checked for null. Signed-off-by: Nate Dailey <nate.dailey@stratus.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+568
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!