From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 9/12] ACPI / PM: Introduce acpi_pm_wakeup_power() Date: Thu, 7 Jan 2010 22:11:50 +0100 Message-ID: <201001072211.50224.rjw@sisk.pl> References: <200912272057.10443.rjw@sisk.pl> <20100106140035.6f622acf@jbarnes-piketon> <201001070011.49755.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from ogre.sisk.pl ([217.79.144.158]:47306 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753950Ab0AGVLe (ORCPT ); Thu, 7 Jan 2010 16:11:34 -0500 In-Reply-To: <201001070011.49755.rjw@sisk.pl> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Jesse Barnes Cc: Matthew Garrett , Len Brown , LKML , pm list , Alan Stern , ACPI Devel Maling List , Linux PCI , Oliver Neukum , Bjorn Helgaas , Shaohua Li , Francois Romieu On Thursday 07 January 2010, Rafael J. Wysocki wrote: > On Wednesday 06 January 2010, Jesse Barnes wrote: > > On Sun, 27 Dec 2009 21:06:26 +0100 > > "Rafael J. Wysocki" wrote: > > > /** > > > + * acpi_pm_wakeup_power - Enable/disable device wake-up power. > > > + * @dev: ACPI device to handle. > > > + * @enable: Whether to enable or disable the wake-up power of the > > > device. > > > + */ > > > +int acpi_pm_wakeup_power(struct acpi_device *dev, bool enable) > > > +{ > > > > I know we've got these all over now, but functions that just take a > > bool are generally hard to read when you just look at the call site. > > If it was called "acpi_pm_set_wakeup_power" and then took an on/off > > enum it would be really easy to see, from the callsite, what was going > > on. > > > > It's a fairly minor complaint, but it's something that's always bugged > > me about the PCI PM code in particular. > > Well, in this particular case acpi_pm_wakeup_power() uses a bool, because > acpi_pm_device_sleep_wake() (which is a caller of it) does. IMO it won't > be logical to use something else just here. > > Also, as you noticed above, this follows a convention used not only in the > PCI PM, but generally in the core PM code. Although we could change this > convention, I'm not really sure that would be worth the effort. That said, it looks like we can drop this (ie. [9/12]) patch altogether if the next one is changed slightly. I'll post the modified [10/12] shortly. Rafael