summaryrefslogtreecommitdiff
path: root/drivers/scsi/sr.h
AgeCommit message (Collapse)Author
2008-02-08[SCSI] sr: fix test unit ready responsesJames Bottomley
Commit 210ba1d1724f5c4ed87a2ab1a21ca861a915f734 updated sr.c to use the scsi_test_unit_ready() function. Unfortunately, this has the wrong characteristic of eating NOT_READY returns which sr.c relies on for tray status. Fix by rolling an internal sr_test_unit_ready() that doesn't do this. Tested-by: Daniel Drake <dsd@gentoo.org> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2008-01-12[SCSI] sr: update to follow tray status correctlyJames Bottomley
Based on an original patch from: David Martin <tasio@tasio.net> When trying to get the drive status via ioctl CDROM_DRIVE_STATUS, with no disk it gives CDS_TRAY_OPEN even if the tray is closed. ioctl works as expected with ide-cd driver. Gentoo bug report: http://bugs.gentoo.org/show_bug.cgi?id=196879 Cc: Maarten Bressers <mbres@gentoo.org> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2008-01-12[SCSI] sr,sd: send media state change modification eventsKay Sievers
This will send for a card reader slot (remove/add media): UEVENT[1187091572.155884] change /devices/pci0000:00/0000:00:1d.7/usb5/5-2/5-2:1.0/host7/target7:0:0/7:0:0:0 (scsi) UEVENT[1187091572.162314] remove /block/sdb/sdb1 (block) UEVENT[1187091572.172464] add /block/sdb/sdb1 (block) UEVENT[1187091572.175408] change /devices/pci0000:00/0000:00:1d.7/usb5/5-2/5-2:1.0/host7/target7:0:0/7:0:0:0 (scsi) and for a DVD drive (add/eject media): UEVENT[1187091590.189159] change /devices/pci0000:00/0000:00:1f.1/host4/target4:0:0/4:0:0:0 (scsi) UEVENT[1187091590.957124] add /module/isofs (module) UEVENT[1187091604.468207] change /devices/pci0000:00/0000:00:1f.1/host4/target4:0:0/4:0:0:0 (scsi) Userspace gets events, even for unpartitioned media. This unifies the event handling for asynchronoous events (AN) and events caused by perodical polling the device from userspace. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> [jejb: modified for new event API] Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2006-03-23[PATCH] kill cdrom ->dev_ioctl methodChristoph Hellwig
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>
2005-08-28[SCSI] sr.c: Fix getting wrong sizePete Zaitcev
Here's the problem. Try to do this on 2.6.12: - Kill udev and HAL - Insert a CD-ROM into a SCSI or USB CD-ROM drive - Run dd if=/dev/scd0 - cat /sys/block/sr0/size - Eject the CD, insert a different one - Run dd if=/dev/scd0 This is likely to do "access beyond the end of device", if you let it - cat /sys/block/sr0/size This shows the size of a previous CD, even though dd was supposed to revalidate the device. - Run dd if=/dev/scd0 The second run of dd works correctly! The bug was introduced in 2.5.31, when Al fixes the recursive opens in partitioning. Before, the code worked like this: - Block layer called cdrom_open directly - cdrom_open called sr_open - sr_open called check_disk_change - check_disk_change called sr_media_change - sr_media_change did cd->needs_disk_change=1 - before returning sr_open tested cd->needs_disk_change and called get_sector_size. In 2.6.12, the check_disk_change is called from cdrom_open only. Thus: - Block layer calls sr_bd_open - sr_bd_open calls cdrom_open - cdrom_open calls sr_open - sr_open tests cd->needs_disk_change, which wasn't set yet; returns - cdrom_open calls check_disk_change - check_disk_change calls sr_media_change - sr_media_change does cd->needs_disk_change=1, but nobody cares Acked by: Alexander Viro <aviro@redhat.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!