From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: suspend.c vs driver-model.txt Date: Tue, 30 Jul 2002 20:22:19 +0200 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <20020730182219.13608@192.168.4.1> References: <20020730184442.GE7567@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20020730184442.GE7567-jyMamyUUXNJG4ohzP4jBZS1Fcj925eT/@public.gmane.org> Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Pavel Machek , Patrick Mochel Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org List-Id: linux-acpi@vger.kernel.org >1) implies that new requests are not coming, so driver authors do not >have to do if (suspended) sleep() in their hot paths. What about, let's say, an USB device driver that needs the USB host chip (and thus the whole USB subsystem) to be still alive to send proper commands to the device for suspend ? (typically setup the remote wakeup when supported, etc...) There can be even more nasty dependencies when you start stacking things. There are ordering dependencies. Those dependencies are dictated by the bus layout that is fortunately provided for us by the new driver model (let's not mix it with driverfs). It's not a subsystem that has to be suspended not to send requests to a driver, it's a driver that has to stop accepting requests, though it's then perfectly valid for the subsystem to provide a "helper" routine for the driver to deal with that. (Typically, those "helpers" already exist for other purposes anyway like stopping your block queue, stopping your network queue, etc...) Ben. ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31