Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 13 Oct 2002 19:59:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 13 Oct 2002 19:59:00 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:33655 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Sun, 13 Oct 2002 19:58:59 -0400 To: Russell King Cc: "Adam J. Richter" , eblade@blackmagik.dynup.net, linux-kernel@vger.kernel.org Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices References: <200210132310.QAA01044@adam.yggdrasil.com> <20021014001552.Q23142@flint.arm.linux.org.uk> From: ebiederm@xmission.com (Eric W. Biederman) Date: 13 Oct 2002 18:03:28 -0600 In-Reply-To: <20021014001552.Q23142@flint.arm.linux.org.uk> 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: 2224 Lines: 45 Russell King writes: > On Sun, Oct 13, 2002 at 04:10:01PM -0700, Adam J. Richter wrote: > > I have no objection to replacing or supplementing the reboot > > notifier chain with a method in struct device_driver, but let's not > > overload these methods with ambiguous semantics. I do not want to > > call thirty functions that primarily return memory to various memory > > allocators, mark a bunch of inodes as invalid, and otherwise arrange > > things so that the kernel can smoothly continue to run user level > > programs when, in fact, we just want to pull the reset line on the > > computer. > > And what about setups where you can't pull the reset line from software. > I have several machines here like that. And one of them needs software > to talk to the cards to put them back into a sane state before rebooting. > > "rebooting" in this particular case is "turn MMU off, jump to location 0" And for x86 it is turn MMU off, jump to location 0xffff0. > And I never said anything about needing to allocate memory to do this. > I agree with you that suspending devices on reboot _is_ silly. However, > that's not what I was proposing. > Documentation/driver-mode/devices.txt says: > int (*remove) (struct device * dev); > > remove is called to dissociate a driver with a device. This may be > called if a device is physically removed from the system, if the > driver module is being unloaded, or during a reboot sequence. > > It is up to the driver to determine if the device is present or > not. It should free any resources allocated specifically for the > device; i.e. anything in the device's driver_data field. > > If the device is still present, it should quiesce the device and place > it into a supported low-power state. So there is a little bit that deals with a low power state. At any rate until someone changes the kernel API again ->remove() is the proper method to be calling in this case. 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/