From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH 2/2] Fix console handling during suspend/resume Date: Sat, 24 Jun 2006 10:29:27 +1000 Message-ID: <1151108967.16946.43.camel@localhost.localdomain> References: <200606221130.30614.david-b@pacbell.net> <200606231106.46863.david-b@pacbell.net> <20060623233244.GB4264@neo.rr.com> <1151108543.16946.41.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1151108543.16946.41.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.osdl.org Errors-To: linux-pm-bounces@lists.osdl.org To: Linus Torvalds Cc: David Brownell , linux-pm@lists.osdl.org, Pavel Machek List-Id: linux-pm@vger.kernel.org > That's bullshit. How can USB operate without interrupts ? It can't. Thus > the final suspend will not be useable for anything below a USB > controller. Among others... That means that every driver that needs to > talk to it's hardware will have to run with "interrupts off"... thus > every driver will need some kind of demoted polled mode that they don't > necessarily have. > = > Thus your "final suspend" ends up only being useful for a small subset > of drivers > = > Also there is nothing magic about "interrupts have been turned off". > It's no magic, it won't prevent everything from happening. How do you > make sure you weren't in the middle of driver routine already ? You > can't. Thus you need your driver to _also_ be able to recover of suspend > being called at any fucking time while it was doing something and not be > able to synchrnize with things like semaphores etc... And the total non-applicability of this model to runtime suspend of individual devices of course.. Ben.