All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Pavel Machek <pavel@suse.cz>,
	linux-pm@lists.linux-foundation.org,
	James.Bottomley@hansenpartnership.com,
	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: Mon, 25 Aug 2008 14:50:07 +0200	[thread overview]
Message-ID: <200808251450.09292.oneukum@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0808191108440.2669-100000@iolanthe.rowland.org>

Am Dienstag 19 August 2008 17:28:28 schrieb Alan Stern:
> On Tue, 19 Aug 2008, Oliver Neukum wrote:
 
> > I suggest by talking to the HLDs.
> 
> Why would the HLD (= ULD?) know?
> 
> For example, consider a USB disk drive.  How is sd.c (the HLD) supposed 
> to know that it's not safe to suspend the USB link without spinning 
> down the drive?  Or consider a traditional SCSI parallel interface

The HLD is responsible for suspending the disk in case the system is
suspended. The HLD must know how to safely suspend a device. It may be
overcautious, but it'll work.

> > It seems to me that abstractly talking there are three criteria for suspension
> > 
> > - the cpu needs to talk to the device now
> 
> I.e., whether the idle timeout has expired, right?
> 
> > - the device may need to talk to the CPU at unpredictable times
> 
> I.e, whether remote wakeup needs to be enabled, right?

I am talking about correctness for controllers. So remote wakeup may or may not
be available. Likewise the bus may be able to predict how long it'll be idle.
 
> > - suspending has side effects
> 
> I'm not sure what you mean by that.  Suspension always has side effects 
> of one kind or another.

But not outside the controller. If you suspend the root hub of a usb bus,
you suspend everything on the bus. It's a feature of the hardware. Other
busses are different.


> There's nothing about my suspend framework to prevent a driver from 
> autosuspending its device while the children are still active.  
> Rather, the framework insists on notifications going the other way: 
> The driver has to be told whenever one of its device's children is 
> suspended or resumed.

That's the problem. You don't tell the children when the parent might want
to suspend.

	Regards
		Oliver

  parent reply	other threads:[~2008-08-25 12:50 UTC|newest]

Thread overview: 69+ 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:31   ` Alan Stern
2008-08-13 14:47   ` Oliver Neukum
2008-08-13 14:59     ` Alan Stern
2008-08-13 14:59       ` Alan Stern
2008-08-13 15:21       ` Oliver Neukum
2008-08-13 15:44         ` Alan Stern
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:23               ` Alan Stern
2008-08-13 16:21           ` [linux-pm] " Oliver Neukum
2008-08-13 19:34             ` Alan Stern
2008-08-13 19:34               ` Alan Stern
2008-08-14  6:08               ` Oliver Neukum
2008-08-14 15:40                 ` Alan Stern
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 15:47                   ` Alan Stern
2008-08-14 21:43                   ` Oliver Neukum
2008-08-14 22:25                     ` Alan Stern
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: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 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-22 22:14                                   ` Alan Stern
2008-08-25 12:50                               ` Oliver Neukum [this message]
2008-08-25 14:45                                 ` Alan Stern
2008-08-25 14:45                                   ` Alan Stern
2008-08-25 15:05                                   ` Oliver Neukum
2008-08-25 16:18                                     ` Alan Stern
2008-08-25 16:18                                       ` Alan Stern
2008-08-25 17:34                                       ` Oliver Neukum
2008-08-25 18:39                                         ` Alan Stern
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:37               ` Alan Stern
2008-08-13 19:42               ` James Bottomley
2008-08-13 20:16                 ` Alan Stern
2008-08-13 20:16                   ` Alan Stern
2008-08-13 20:03               ` Leisner, Martin
2008-08-13 20:03                 ` [linux-pm] " Leisner, Martin
2008-08-13 20:38                 ` Alan Stern
2008-08-13 20:38                   ` Alan Stern
2008-08-19 21:08                   ` Leisner, Martin
2008-08-19 21:08                     ` Leisner, Martin
2008-08-13 15:46         ` Alan Stern
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
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=200808251450.09292.oneukum@suse.de \
    --to=oneukum@suse.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.