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 17:05:27 +0200 [thread overview]
Message-ID: <200808251705.28455.oneukum@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0808251033460.6462-100000@iolanthe.rowland.org>
Am Montag 25 August 2008 16:45:20 schrieb Alan Stern:
> You didn't answer my question: How does the HLD know whether it's okay
> to suspend the link without suspending the device? I should think that
> it _doesn't_ know.
>
> The transport class code might know, or the link's driver -- but not
> the HLD. The HLD probably doesn't even know what type of transport is
> being used!
There's some truth to that. Unfortunately the transport does not know
whether a device or link may be suspended. Take the case of a CD playing
sound. The transport may know what the consequences of suspending
a link will be to the devices, but only the devices know whether the
consequences are acceptable.
> > 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.
>
> I don't understand. Are you saying that whether or not it's correct to
> suspend a link depends on whether the device may need to talk to the
> CPU at unpredictable times? And if so, isn't that the same as saying
Yes.
> that remote wakeup for the link can be enabled?
Remote wakeup is a concept specific to USB. If you are writing for
a generic system the question is indeed whether devices may want
to talk to the host and whether they can.
It seems to me that the ULD will know whether its devices will need
to talk to the CPU.
> > That's the problem. You don't tell the children when the parent might want
> > to suspend.
>
> Why should the children need to know?
Because they'll want to do things like flushing caches.
> If the children are already suspended then we certainly don't
> need to tell them the link is going down.
Yes.
> If the children are active, then the link's driver or the
> transport class must already have given the okay for
> suspending the link while leaving the children active.
Because the transport class may not know either.
Regards
Oliver
next prev parent reply other threads:[~2008-08-25 15:05 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
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 [this message]
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=200808251705.28455.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox