From: Douglas Gilbert <dougg@torque.net>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
James Bottomley <James.Bottomley@SteelEye.com>,
djwong@us.ibm.com, hmh@hmh.eng.br
Subject: Re: [PATCH 2/3] sd: implement START/STOP management
Date: Tue, 20 Mar 2007 13:58:55 -0400 [thread overview]
Message-ID: <460020DF.6090203@torque.net> (raw)
In-Reply-To: <20070320151359.GG6152@htj.dyndns.org>
Tejun Heo wrote:
> Implement SBC START/STOP management. sdev->mange_start_stop is added.
> When it's set to one, sd STOPs the device on suspend and shutdown and
> STARTs it on resume. sdev->manage_start_stop defaults is in sdev
> instead of scsi_disk cdev to allow ->slave_config() override the
> default configuration but is exported under scsi_disk sysfs node as
> sdev->allow_restart is.
>
> When manage_start_stop is zero (the default value), this patch doesn't
> introduce any behavior change.
>
> Signed-off-by: Tejun Heo <htejun@gmail.com>
> ---
> drivers/scsi/scsi_sysfs.c | 31 +++++++++++--
> drivers/scsi/sd.c | 102 +++++++++++++++++++++++++++++++++++++++++++++
> include/scsi/scsi_device.h | 1
> 3 files changed, 130 insertions(+), 4 deletions(-)
>
> Index: work/drivers/scsi/sd.c
> ===================================================================
> --- work.orig/drivers/scsi/sd.c
> +++ work/drivers/scsi/sd.c
> @@ -142,6 +142,8 @@ static void sd_rw_intr(struct scsi_cmnd
> static int sd_probe(struct device *);
> static int sd_remove(struct device *);
> static void sd_shutdown(struct device *dev);
> +static int sd_suspend(struct device *dev, pm_message_t state);
> +static int sd_resume(struct device *dev);
> static void sd_rescan(struct device *);
> static int sd_init_command(struct scsi_cmnd *);
> static int sd_issue_flush(struct device *, sector_t *);
> @@ -206,6 +208,20 @@ static ssize_t sd_store_cache_type(struc
> return count;
> }
>
> +static ssize_t sd_store_manage_start_stop(struct class_device *cdev,
> + const char *buf, size_t count)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(cdev);
> + struct scsi_device *sdp = sdkp->device;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + sdp->manage_start_stop = simple_strtoul(buf, NULL, 10);
> +
> + return count;
> +}
> +
> static ssize_t sd_store_allow_restart(struct class_device *cdev, const char *buf,
> size_t count)
> {
> @@ -238,6 +254,14 @@ static ssize_t sd_show_fua(struct class_
> return snprintf(buf, 20, "%u\n", sdkp->DPOFUA);
> }
>
> +static ssize_t sd_show_manage_start_stop(struct class_device *cdev, char *buf)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(cdev);
> + struct scsi_device *sdp = sdkp->device;
> +
> + return snprintf(buf, 20, "%u\n", sdp->manage_start_stop);
> +}
> +
> static ssize_t sd_show_allow_restart(struct class_device *cdev, char *buf)
> {
> struct scsi_disk *sdkp = to_scsi_disk(cdev);
> @@ -251,6 +275,8 @@ static struct class_device_attribute sd_
> __ATTR(FUA, S_IRUGO, sd_show_fua, NULL),
> __ATTR(allow_restart, S_IRUGO|S_IWUSR, sd_show_allow_restart,
> sd_store_allow_restart),
> + __ATTR(manage_start_stop, S_IRUGO|S_IWUSR, sd_show_manage_start_stop,
> + sd_store_manage_start_stop),
> __ATTR_NULL,
> };
>
> @@ -267,6 +293,8 @@ static struct scsi_driver sd_template =
> .name = "sd",
> .probe = sd_probe,
> .remove = sd_remove,
> + .suspend = sd_suspend,
> + .resume = sd_resume,
> .shutdown = sd_shutdown,
> },
> .rescan = sd_rescan,
> @@ -1776,6 +1804,32 @@ static void scsi_disk_release(struct cla
> kfree(sdkp);
> }
>
> +static int sd_start_stop_device(struct scsi_device *sdp, int start)
> +{
> + unsigned char cmd[6] = { START_STOP }; /* START_VALID */
> + struct scsi_sense_hdr sshdr;
> + int res;
> +
> + if (start)
> + cmd[4] |= 1; /* START */
> +
> + if (!scsi_device_online(sdp))
> + return -ENODEV;
> +
> + res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
> + SD_TIMEOUT, SD_MAX_RETRIES);
Tejun,
I note at this point that the IMMED bit in the
START STOP UNIT cdb is clear. [The code might
note that as well.] All SCSI disks that I have
seen, implement the IMMED bit and according to
the SAT standard, so should SAT layers like the
one in libata.
With the IMMED bit clear:
- on spin up, it will wait until disk is ready.
Okay unless there are a lot of disks, in
which case we could ask Matthew Wilcox for help
- on spin down, will wait until media is
stopped. That could be 20 seconds, and if there
were multiple disks ....
I guess the question is do we need to wait until a
disk is spun down before dropping power to it
and suspending.
Doug Gilbert
next prev parent reply other threads:[~2007-03-20 17:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-20 15:07 [PATCH 1/3] sd: fix return value of sd_sync_cache() Tejun Heo
2007-03-20 15:13 ` [PATCH 2/3] sd: implement START/STOP management Tejun Heo
2007-03-20 15:25 ` [PATCH 3/4] libata: reimplement suspend/resume support using sdev->manage_start_stop Tejun Heo
2007-03-20 15:29 ` Christoph Hellwig
2007-03-21 7:05 ` [PATCH scsi-misc-2.6] SCSI: kill sht->suspend/resume Tejun Heo
2007-03-21 14:19 ` Christoph Hellwig
2007-03-21 15:16 ` James Bottomley
2007-05-14 15:52 ` Tejun Heo
2007-03-20 15:55 ` [PATCH 4/4] libata: implement libata.spindown_compat Tejun Heo
2007-04-17 14:45 ` Jeff Garzik
2007-04-17 15:01 ` James Bottomley
2007-04-17 15:20 ` Jeff Garzik
2007-04-17 15:26 ` James Bottomley
2007-04-17 17:09 ` Tejun Heo
2007-04-17 17:33 ` James Bottomley
2007-03-20 16:39 ` [PATCH 3/4] libata: reimplement suspend/resume support using sdev->manage_start_stop Alan Cox
2007-03-20 16:15 ` Oliver Neukum
2007-03-20 16:58 ` [PATCH 2/3] sd: implement START/STOP management James Bottomley
2007-03-20 17:08 ` Tejun Heo
2007-03-20 17:26 ` James Bottomley
2007-03-21 3:42 ` Tejun Heo
2007-03-20 17:58 ` Douglas Gilbert [this message]
2007-03-20 18:41 ` James Bottomley
2007-03-21 2:35 ` Tejun Heo
2007-03-22 10:21 ` Vladislav Bolkhovitin
2007-03-22 12:29 ` Henrique de Moraes Holschuh
2007-03-22 15:14 ` Vladislav Bolkhovitin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=460020DF.6090203@torque.net \
--to=dougg@torque.net \
--cc=James.Bottomley@SteelEye.com \
--cc=djwong@us.ibm.com \
--cc=hmh@hmh.eng.br \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).