All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>,
	Andrew Morton <akpm@osdl.org>,
	Nigel Cunningham <ncunningham@cyclades.com>,
	linux-pm@lists.osdl.org, linux-usb-devel@lists.sourceforge.net
Subject: Re: [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Date: Thu, 27 Apr 2006 08:16:51 +0000	[thread overview]
Message-ID: <20060427081651.GC2376@ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0604251626180.839-100000@iolanthe.rowland.org>

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Hi!

> > I'd put it differently.  It's not a poor-man's way at all; passing that
> > information in hardware is the correct solution.  A regular resume would
> > keep the information there too (from STR or standby).  We don't want to
> > have swsusp piling on special cases.
> 
> Okay, I take it back.  Yes, putting the hardware into the appropriate 
> state is the right thing to do.
> 
> On the other hand, it might not be so easy to know what that state is.  
> Perhaps the decision should be left up to the device driver.  If drivers
> were told the difference between "FREEZE to prepare for creating a memory
> snapshot" and "FREEZE to prepare for restoring a memory image" then they 
> could do the right thing always.

Add flags field to pm_message_t, please. There, you have way to pass
down that ino while staying back-compatible.

-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2006-04-27  8:16 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24 21:29 [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend() David Brownell
2006-04-24 21:47 ` [linux-pm] " Rafael J. Wysocki
2006-04-24 22:47   ` David Brownell
2006-04-25 10:34     ` Nigel Cunningham
2006-04-25 14:41       ` Alan Stern
2006-04-25 17:37         ` [linux-pm] " David Brownell
2006-04-25 20:45           ` Alan Stern
2006-04-26  0:30             ` David Brownell
2006-04-27  8:20               ` Pavel Machek
2006-04-27  8:16             ` Pavel Machek [this message]
2006-04-27  8:08         ` Pavel Machek
2006-04-27 14:34           ` [linux-pm] " Alan Stern
2006-04-27 16:55             ` Patrick Mochel
2006-04-27 17:41               ` Alan Stern
2006-04-27 19:21               ` David Brownell
2006-04-27 20:35                 ` Nigel Cunningham
2006-04-27 20:58                   ` Pavel Machek
2006-04-25 16:56       ` David Brownell
2006-04-24 22:31 ` [linux-pm] " Nigel Cunningham
2006-04-25  8:32   ` Rafael J. Wysocki
2006-04-25 16:11     ` David Brownell
2006-04-25 18:56       ` Rafael J. Wysocki
2006-04-25 20:28         ` Nigel Cunningham
2006-04-25 20:53           ` [linux-pm] " Rafael J. Wysocki
2006-04-25 21:03             ` Nigel Cunningham
2006-04-25 22:06               ` Rafael J. Wysocki
2006-04-25 22:18                 ` Nigel Cunningham
2006-04-25 22:34                   ` Rafael J. Wysocki
2006-04-25 23:55                   ` David Brownell
2006-04-26  1:16                     ` Nigel Cunningham
2006-04-26  3:32                       ` [linux-pm] " David Brownell
2006-04-26  3:44                         ` Nigel Cunningham
2006-04-26 14:24           ` Alan Stern
2006-04-26 19:47             ` [linux-pm] " Nigel Cunningham
2006-04-25 21:04         ` David Brownell
2006-04-25 21:41           ` Pavel Machek
2006-04-25 23:13             ` [linux-pm] " David Brownell
2006-04-26  9:07               ` Pavel Machek
2006-04-25 21:55           ` Rafael J. Wysocki
2006-04-25 22:56             ` David Brownell
2006-04-26 11:26               ` Rafael J. Wysocki
2006-04-26 14:38                 ` [linux-pm] " Alan Stern
2006-04-26 15:26                   ` Rafael J. Wysocki
2006-04-26 15:38                     ` Alan Stern
2006-04-26 16:09                       ` Rafael J. Wysocki
2006-04-26 19:06                         ` Alan Stern
2006-04-26 20:37                           ` Rafael J. Wysocki
2006-04-26 21:31                 ` David Brownell
2006-04-26 22:24                   ` Rafael J. Wysocki
2006-04-27 19:44                     ` David Brownell
2006-04-25 15:56   ` David Brownell
2006-04-27 10:54     ` Pavel Machek
2006-04-25 13:50 ` [linux-usb-devel] " Alan Stern
2006-04-25 15:49   ` David Brownell
2006-04-27  1:22 ` Patrick Mochel
2006-04-27 19:41   ` [linux-pm] " David Brownell
2006-05-02 16:12     ` Patrick Mochel
2006-05-26  3:06       ` David Brownell
2006-05-26 19:50         ` Rafael J. Wysocki
2006-05-26 23:16         ` Pavel Machek
2006-05-27  0:19           ` [linux-usb-devel] " David Brownell
2006-05-27 16:38             ` Pavel Machek
2006-06-05 15:31               ` David Brownell
2006-06-05 16:36               ` [patch/rft 2.6.17-rc5-git 0/6] PM_EVENT_PRETHAW David Brownell
2006-06-05 16:36               ` [patch/rft 2.6.17-rc5-git 1/6] fix broken/dubious driver suspend() methods David Brownell
     [not found]                 ` <20060530191140.GA4017@ucw.cz>
2006-06-07  0:53                   ` David Brownell
2006-06-05 16:37               ` [patch/rft 2.6.17-rc5-git 2/6] add PM_EVENT_PRETHAW David Brownell
2006-05-30 19:17                 ` Pavel Machek
2006-06-07  1:02                   ` David Brownell
2006-06-05 16:38               ` [patch/rft 2.6.17-rc5-git 3/6] PM_EVENT_PRETHAW, handle in IDE and PCI David Brownell
2006-05-30 19:21                 ` Pavel Machek
2006-06-07  0:51                   ` David Brownell
2006-06-05 16:38               ` [patch/rft 2.6.17-rc5-git 4/6] PM_EVENT_PRETHAW for various graphics cards David Brownell
2006-05-30 19:30                 ` Pavel Machek
2006-06-07  1:24                   ` David Brownell
2006-06-07 18:57                     ` PM docs and API? bsmith
2006-06-07 22:58                       ` David Brownell
2006-06-05 16:38               ` [patch/rft 2.6.17-rc5-git 5/6] PM_EVENT_PRETHAW, handle for USB David Brownell
2006-06-05 16:38               ` [patch/rft 2.6.17-rc5-git 6/6] PM_EVENT_PRETHAW, issue from PM core David Brownell
2006-05-30 19:28                 ` Pavel Machek

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=20060427081651.GC2376@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@osdl.org \
    --cc=david-b@pacbell.net \
    --cc=linux-pm@lists.osdl.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=ncunningham@cyclades.com \
    --cc=stern@rowland.harvard.edu \
    /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.