Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 22 Oct 2001 20:29:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 22 Oct 2001 20:28:57 -0400 Received: from air-1.osdl.org ([65.201.151.5]:33548 "EHLO osdlab.pdx.osdl.net") by vger.kernel.org with ESMTP id ; Mon, 22 Oct 2001 20:28:40 -0400 Date: Mon, 22 Oct 2001 17:29:04 -0700 (PDT) From: Patrick Mochel X-X-Sender: To: Alan Cox cc: Pavel Machek , Benjamin Herrenschmidt , Jeff Garzik , Subject: Re: [RFC] New Driver Model for 2.5 In-Reply-To: Message-ID: 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 On Tue, 23 Oct 2001, Alan Cox wrote: > > /* Now tell them to stop I/O and save their state */ > > device_suspend(3, SUSPEND_SAVE_STATE); > > I'd very much like this one to be two pass, with the second pass occuring > after interrupts are disabled. There are some horrible cases to try and > handle otherwise (like devices that like to jam the irq line high). I forgot to mention to disable interrupts after the SUSPEND_NOTIFY call. The idea is to allocate all memory in the first pass, disable interrupts, then save state. Would that work? Or, should some of the state saving take place with interrupts enabled? > Ditto on return from suspend where some devices also like to float the irq > high as you take them over (eg USB on my Palmax). From comments Ben made > ages back I believe ppc has similar issues if not worse Yes, the resume sequence is broken into two stages: device_resume(RESUME_POWER_ON); /* enable interrupts */ device_resume(RESUME_RESTORE_STATE); Do you see a need to break it up further? -pat - 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/