public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: swsusp issues
Date: Sat, 04 Jun 2005 09:29:56 +1000	[thread overview]
Message-ID: <1117841396.31082.196.camel@gaston> (raw)
In-Reply-To: <20050603232109.GA2132@elf.ucw.cz>

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


> swsusp/powerdown and swsusp/reboot cases should really only require
> save_processor_state and friends filled by architecture... And at
> least i386 and x86-64 (and possibly ia64) will have basically same
> code for all the stuff except save_processor_state and friends...

Eugh.... No. Maybe you can get away without the arch callbackcs on x86,
but there are a bunch of things that need to be properly saved/restored
even for basic swsusp that don't fit in the driver model. (Besides, you
don't even call device_power_down, so the stuffs that are sysdev's
aren't dealt with properly neither).

> I'm not sure what you want to do with "take the control of main.c". If
> you do device calls in different order, or diverge in something
> visible to drivers, you'll create maintanance nightmare. Is it really
> impossible to handle ppc without adding more callbacks?

I'm pretty sure it's impossible to handle anything correctly. Your x86
implementation may "happen" to work but I'm really not confident about
it.

> [Modulo apm emulation, I see why you need callbacks there, but that
> should not be there or it should be in generic code, anyways].

There are other things that need proper massaging.

> > We could provide an "example" default implementation that does only
> > swsusp that an arch can "drop in" if you want, but archs have to
> > implement the various "inline" callbacks anyway (save_processor_state &
> > friends).
> 
> ...aha, so you know that much code can be shared :-). Yes, "example"
> implementation should work okay. Use "example" implementation, add
> custom save_processor_state, and you should have working
> swsusp/powerdown...

I don't care a bit about sharing code in that area. "How much" amounts
to 3 function calls, so honestly, that is not an issue. I agree with
Patrick here, the toplevel enter_state() function should probably just
be arch code.

BEn.



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



  reply	other threads:[~2005-06-03 23:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-03  2:01 swsusp issues Benjamin Herrenschmidt
2005-06-03 11:15 ` Pavel Machek
2005-06-03 22:50   ` Benjamin Herrenschmidt
2005-06-03 23:21     ` Pavel Machek
2005-06-03 23:29       ` Benjamin Herrenschmidt [this message]
2005-06-04  6:13         ` Pavel Machek
2005-06-04  6:23           ` Benjamin Herrenschmidt
2005-06-03 23:25     ` Nigel Cunningham
2005-06-03 23:32       ` Benjamin Herrenschmidt

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=1117841396.31082.196.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    /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