Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759089AbYCTWeg (ORCPT ); Thu, 20 Mar 2008 18:34:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758882AbYCTWeJ (ORCPT ); Thu, 20 Mar 2008 18:34:09 -0400 Received: from gate.crashing.org ([63.228.1.57]:44699 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758313AbYCTWeD (ORCPT ); Thu, 20 Mar 2008 18:34:03 -0400 Subject: Re: [RFC][PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks From: Benjamin Herrenschmidt Reply-To: benh@kernel.crashing.org To: Alan Stern Cc: "Rafael J. Wysocki" , Pavel Machek , pm list , ACPI Devel Maling List , Greg KH , Len Brown , LKML , Alexey Starikovskiy , David Brownell In-Reply-To: References: Content-Type: text/plain Date: Fri, 21 Mar 2008 09:32:00 +1100 Message-Id: <1206052320.8420.23.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 46 On Thu, 2008-03-20 at 10:45 -0400, Alan Stern wrote: > > I didn't mention locking because it seemed obvious that locking is > needed. Of course a flag alone is mostly useless. > > But we already _do_ have a lock (dev->sem) and we _don't_ have a flag. > I was pointing out that some drivers will want to have a flag added. > Maybe so many drivers will want it that the flag should be added to the > PM structure, where it will be available for every device. If only a > few drivers want this new flag, then yes, they can put it in their > private data structures. What I'm saying is that a flag set prior to prepare() would be almost impossible to get right in term of locking for the reasons I explained. I think this should be under driver reponsibility, using it's own internal locking. Or else, drivers can rely on failure. > > However, I think this is mostly a non-issue, because the core _does_ > > provide something here that is useful for drivers who don't want to > > bother with the above: The failure return from device_add. If drivers > > don't want to do something akin to what I described, they can just be > > made to deal gracefully with the failure from device_add that would > > happen due to the core internal flag being set after the return from > > prepare(). > > Relying on a registration failure to handle this sort of thing is _not_ > a good idea. For example, how would the driver distinguish failure > caused by impending suspend from other sorts of failure? By the precise error code of course. But as I said, I would expect most bus drivers to have their own proper implementation that does the right thing, it's not like it was hard and there aren't that many bus drivers. Relying on failure is a possibility for simple ones that don't want to care much, in which case, there is little need to differenciate the failure caused by suspend from other failures other than maybe printing some garbage in the log vs. not :-) Ben. -- 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/