Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Oct 2002 11:24:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Oct 2002 11:24:12 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:44664 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Mon, 14 Oct 2002 11:24:11 -0400 To: "Eric W. Biederman" Cc: linux-kernel@vger.kernel.org Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices References: <200210132359.QAA01092@adam.yggdrasil.com> <1034573925.2786.55.camel@cpq> From: ebiederm@xmission.com (Eric W. Biederman) Date: 14 Oct 2002 09:28:43 -0600 In-Reply-To: <1034573925.2786.55.camel@cpq> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2099 Lines: 45 Eric Blade writes: > Here is where I realize that I've forgotten to CC: the list on all the > traffic that I keep sending between Eric and Adam. D'oh. > > > On Sun, 2002-10-13 at 20:07, Eric W. Biederman wrote: > > > > > > However, I'm not trying to quash what you want to discuss. > > > I'd be interested in hearing about clarifications and perhaps > > > extensions of the struct device_driver methods, which I think is what > > > you're getting at, perhaps here or on linux-hotplug. It's just that, > > > for this thread, I'm trying to focus on my patch that eliminates the > > > software suspend on reboot (pros and cons, alternatives to it, etc.). > > > > The 2.5.41 variant is below. The bug is reusing the old enumeration value > > as was previously mentioned. > > > > I tried to submit a fix to this, but the only response I've gotten back > is that it failed to apply. My original patch excluded the bit from > device.h that added a new state to the enumeration, and when it got into > the tree, it got into the tree using the current states that were > available. My bad. > > Eric has already indicated earlier, that Adam's issue is, however, not > with the changes to drivers/base/power.c but to the changes to the IDE > driver. Correct. But when people try to use power management they will see the bug. SUSPEND_POWER_DOWN (a request for the driver to remove power from the device) is a very different state from SUSPEND_DETACH (a request to disassociate the driver from the device). I am not fully convinced the two cases should be merged. SUSPEND_POWER_DOWN as defined should actually cause the behavior Adam was seeing. Which made it doubly interesting. Will you submit a patch detangling this mess? I believe Adams only problem was that it did not obviously fix his problem. Eric - 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/