Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762361AbYBUA0g (ORCPT ); Wed, 20 Feb 2008 19:26:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934161AbYBUAZs (ORCPT ); Wed, 20 Feb 2008 19:25:48 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:43706 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933953AbYBUAZl (ORCPT ); Wed, 20 Feb 2008 19:25:41 -0500 Date: Wed, 20 Feb 2008 16:25:20 -0800 (PST) From: Linus Torvalds To: "Rafael J. Wysocki" cc: Jesse Barnes , Jeff Chua , lkml , Dave Airlie , linux-acpi@vger.kernel.org, suspend-devel List , Greg KH , Alexey Starikovskiy Subject: Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green. In-Reply-To: <200802210113.05733.rjw@sisk.pl> Message-ID: References: <200802210035.14058.rjw@sisk.pl> <200802210113.05733.rjw@sisk.pl> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2001 Lines: 44 On Thu, 21 Feb 2008, Rafael J. Wysocki wrote: > > > Secondly, the one that people should use ("pci_choose_state()") doesn't > > actually do what you claim it does. It does all kinds of wrong things, and > > doesn't even take the target state into account at all. So look again. > > Well, if platform_pci_choose_state() is defined, pci_choose_state() returns > its result and on ACPI systems that points to acpi_pci_choose_state(), so in > fact it does what I said (apart from the error path). Did you check closer? I repeat: acpi_pci_choose_state() (when called from pci_choose_state()) doesn't even look at the target 'state'. It just blindly assumes that you want the deepest sleep-state you can have. Which happens to be correct for normal suspend, but means that if you want to test other states (through '/sys/devices/.../power'), that sounds broken. I didn't check any closer, but go check it yourself. The short and sweet: acpi_pci_choose_state() totally ignores its 'state' argument. Do you really think that's correct? But yes, "pci_choose_state()' effectively does that too, apart from PM_EVENT_ON, which is never used. (But the whole and only point of pci_choose_state() was to do the PM_EVENT_FREEZE thing differently, which it doesn't do, so I think the real issue here is that the interface is really rather mis-designed) I suspect most people who ever really looked and worked on this code had a specific device in mind, and I'm sure that all of the code individually always ends up making sense from the standpoint of some specific device driver. It's just that it never seems to make sense from a bigger issues standpoint, and often seems senseless from the standpoint of other devices of other types. Linus -- 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/