[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201001070011.49755.rjw@sisk.pl>
Date: Thu, 7 Jan 2010 00:11:49 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Jesse Barnes <jbarnes@...tuousgeek.org>
Cc: Matthew Garrett <mjg@...hat.com>, Len Brown <lenb@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
pm list <linux-pm@...ts.linux-foundation.org>,
Alan Stern <stern@...land.harvard.edu>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux PCI <linux-pci@...r.kernel.org>,
Oliver Neukum <oliver@...kum.org>,
Bjorn Helgaas <bjorn.helgaas@...com>,
Shaohua Li <shaohua.li@...el.com>,
Francois Romieu <romieu@...zoreil.com>
Subject: Re: [PATCH 9/12] ACPI / PM: Introduce acpi_pm_wakeup_power()
On Wednesday 06 January 2010, Jesse Barnes wrote:
> On Sun, 27 Dec 2009 21:06:26 +0100
> "Rafael J. Wysocki" <rjw@...k.pl> 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.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists