Hi, On Thu, Apr 05, 2012 at 02:00:57PM +0800, Lin Ming wrote: > > > > Another thing to consider is, user might want to eject the tray by > > software like the > > eject /dev/sr0 command or some UI mouse clicks against the cdrom icon. I'm still > > thinking how to do this correctly. > > Assume eject /dev/sr0 is implemented as: > > int fd = open("/dev/sr0", ...) > ioctl(fd, CDROMEJECT) > Indeed, it is implemented as this :-) > We may need to resume ODD in the ioctl handler(scsi_cmd_ioctl). > I prefer we do this in sr_block_ioctl. Suppose the ODD is now runtime suspended and received an ioctl: if the ioctl's cmd is CDROMEJECT, resume it. For other cases, return an error code like EPERM. When done, according to the result of ioctl: if success, leave it resumed; if failed, put it back to sleep. Something like this: diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index 5fc97d2..aa6e920 100644 --- a/drivers/scsi/sr.c +++ b/drivers/scsi/sr.c @@ -45,6 +45,7 @@ #include <linux/blkdev.h> #include <linux/mutex.h> #include <linux/slab.h> +#include <linux/pm_runtime.h> #include <asm/uaccess.h> #include <scsi/scsi.h> @@ -538,10 +539,21 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd, struct scsi_cd *cd = scsi_cd(bdev->bd_disk); struct scsi_device *sdev = cd->device; void __user *argp = (void __user *)arg; - int ret; + int ret, rpm_resumed = 0; mutex_lock(&sr_mutex); + if (pm_runtime_suspended(&sdev->sdev_gendev)) { + if (cmd == CDROMEJECT) { + scsi_autopm_get_device(sdev); + rpm_resumed = 1; + } + else { + ret = -EPERM; + goto out; + } + } + /* * Send SCSI addressing ioctls directly to mid level, send other * ioctls to cdrom/block level. @@ -570,6 +582,9 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd, ret = scsi_ioctl(sdev, cmd, argp); out: + if (rpm_resumed && ret) + scsi_autopm_put_device(sdev); + mutex_unlock(&sr_mutex); return ret; } Does this work? -Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html