public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Pavel Machek <pavel@suse.cz>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	teheo@novell.com
Subject: Re: [linux-pm] Power management for SCSI
Date: Thu, 14 Aug 2008 08:08:26 +0200	[thread overview]
Message-ID: <200808140808.27022.oneukum@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0808131525530.13982-100000@iolanthe.rowland.org>

Am Mittwoch 13 August 2008 21:34:30 schrieb Alan Stern:
> On Wed, 13 Aug 2008, Oliver Neukum wrote:
> 
> > Am Mittwoch 13 August 2008 17:44:46 schrieb Alan Stern:
> > > > All children that are USB must be powered down. We know in fact that most
> > > > drives don't care that the device is suspended. The problem was drive
> > > > enclosures that cut power upon suspension losing cached data.
> > > 
> > > You misunderstood my question.  Are there SCSI transports other than
> > > USB sharing the requirement that all child devices must be suspended
> > > before the link can be powered down?
> > 
> > I dispute that USB in general has this property.
> 
> How can you dispute that?  You said it yourself, in the top quote
> above: "All children that are USB must be powered down."

But the children are SCSI, not USB.

> > Some storage devices
> > need their caches flushed. USB itself is perfectly happy with autosuspending
> > the storage device (host) without telling the disks (devices)
> > 
> > You could even argue that these storage devices violate the USB spec.
> 
> Oliver, you can't have it both ways.  Either we do spin down disks and
> drain device caches before autosuspending usb-storage or we don't.

That is true.

> For safety's sake, obviously we should.  The overhead is minimal since
> this happens only after the idle timeout has expired.  And for devices
> that don't support it (like flash storage), sd skips the spin-down
> command anway.

But you cannot make the conclusion that the ultimate children should have
any autosuspend attributes. We can implement autosuspend in usb storage
and propagate the suspend calls down the tree without SCSI knowing about
autosuspend.

Such a system would have it drawbacks, but it'd be a lot simpler.

	Regards
		Oliver

  reply	other threads:[~2008-08-14  6:08 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-13  9:50 Power management for SCSI Pavel Machek
2008-08-13 14:31 ` Alan Stern
2008-08-13 14:47   ` Oliver Neukum
2008-08-13 14:59     ` Alan Stern
2008-08-13 15:21       ` Oliver Neukum
2008-08-13 15:44         ` Alan Stern
2008-08-13 16:14           ` Stefan Richter
2008-08-13 16:23             ` Alan Stern
2008-08-13 16:21           ` [linux-pm] " Oliver Neukum
2008-08-13 19:34             ` Alan Stern
2008-08-14  6:08               ` Oliver Neukum [this message]
2008-08-14 15:40                 ` Alan Stern
2008-08-14 13:50             ` Pavel Machek
2008-08-14 14:08               ` Oliver Neukum
2008-08-14 15:47                 ` Alan Stern
2008-08-14 21:43                   ` Oliver Neukum
2008-08-14 22:25                     ` Alan Stern
2008-08-15  7:16                       ` Oliver Neukum
2008-08-15 15:25                         ` Alan Stern
2008-08-15 15:56                           ` Oliver Neukum
2008-08-16  5:24                             ` Greg KH
2008-08-19 13:33                           ` [linux-pm] " Oliver Neukum
2008-08-19 15:28                             ` Alan Stern
2008-08-19 23:22                               ` Stefan Richter
2008-08-22 10:52                               ` Pavel Machek
2008-08-22 22:14                                 ` Alan Stern
2008-08-25 12:50                               ` Oliver Neukum
2008-08-25 14:45                                 ` Alan Stern
2008-08-25 15:05                                   ` Oliver Neukum
2008-08-25 16:18                                     ` Alan Stern
2008-08-25 17:34                                       ` Oliver Neukum
2008-08-25 18:39                                         ` Alan Stern
2008-08-13 15:24       ` Oliver Neukum
2008-08-13 15:44         ` Stefan Richter
2008-08-13 16:25           ` Oliver Neukum
2008-08-13 19:37             ` Alan Stern
2008-08-13 19:42               ` James Bottomley
2008-08-13 20:16                 ` Alan Stern
2008-08-13 20:03               ` Leisner, Martin
2008-08-13 20:38                 ` [linux-pm] " Alan Stern
2008-08-19 21:08                   ` Leisner, Martin
2008-08-13 15:46         ` Alan Stern
2008-08-14 13:08   ` Pavel Machek
2008-08-14 15:56     ` Pavel Machek
2008-08-14 22:11     ` Stefan Richter
2008-08-19  7:38   ` Pavel Machek
2008-08-19  7:50     ` [linux-pm] " Oliver Neukum
2008-08-19 14:32     ` Alan Stern

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=200808140808.27022.oneukum@suse.de \
    --to=oneukum@suse.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@suse.cz \
    --cc=stern@rowland.harvard.edu \
    --cc=teheo@novell.com \
    /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