Date: Tue, 22 Mar 2005 02:49:22 +0100
From: Pavel Machek <pavel@ucw.cz>
To: Andrew Morton <akpm@osdl.org>
Cc: rjw@sisk.pl, linux-kernel@vger.kernel.org,
       "Brown, Len" <len.brown@intel.com>
Subject: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389
Message-ID: <20050322014922.GA1512@elf.ucw.cz>
References: <20050321025159.1cabd62e.akpm@osdl.org> <200503212343.31665.rjw@sisk.pl> <20050321160306.2f7221ec.akpm@osdl.org> <20050322004456.GB1372@elf.ucw.cz> <20050321170623.4eabc7f8.akpm@osdl.org> <20050322013535.GA1421@elf.ucw.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050322013535.GA1421@elf.ucw.cz>
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1213
Lines: 30

Hi!

> And they are both "dangerous" -- they introduce new and untested
> functionality while I'm trying to transition from int to
> pm_message_t. They also affect all the drivers.

Actually, there's one even more severe problem with
platform_pci_choose_state...

If we are doing freeze for swsusp snapshot (or freeze for kexec or
something similar, that ACPI does not know about), it is very wrong to
ask ACPI to tell us power levels for devices. ACPI does not even know
about those states, it can not tell us anything meaningfull.

So if this hook is to be reintroduced, it should go down in the
function, and only trigger for ACPI S3 and ACPI S1 cases. Maybe for
swsusp/plaform (== ACPI S4).

But I'd prefer the hook to go away for now, it clearly needs
infrastructure that is not yet there, and provides nothing.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/