[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F061CF8.4070906@metafoo.de>
Date: Thu, 05 Jan 2012 22:58:16 +0100
From: Lars-Peter Clausen <lars@...afoo.de>
To: Christopher Heiny <cheiny@...aptics.com>
CC: Shubhrajyoti <shubhrajyoti@...com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jean Delvare <khali@...ux-fr.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Linux Input <linux-input@...r.kernel.org>,
Joerie de Gram <j.de.gram@...il.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Naveen Kumar Gaddipati <naveen.gaddipati@...ricsson.com>
Subject: Re: [RFC PATCH 2/11] input: RMI4 core bus and sensor drivers.
On 01/05/2012 09:49 PM, Christopher Heiny wrote:
> On 01/01/2012 10:38 PM, Shubhrajyoti wrote:
>> Hi Christopher,
>>
>> On Thursday 22 December 2011 07:39 AM, Christopher Heiny wrote:
>>> Signed-off-by: Christopher Heiny<cheiny@...aptics.com>
>>>
> [snip]
>
>>> +#ifdef CONFIG_PM
>>> +static int rmi_bus_suspend(struct device *dev)
>>> +{
>>> +#ifdef GENERIC_SUBSYS_PM_OPS
>>> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>>> +
>>> + if (pm&& pm->suspend)
>>> + return pm->suspend(dev);
>> If driver-pm- suspend is not there should you not fall back to .
>> suspend ?
>
> You're thinking of dev->driver->suspend here, right? If so, that sounds
> good to me.
>
This will add a ambiguity as to how to specify to suspend/resume callbacks.
Just use generic_subsys_pm_ops for your bus' pm ops. It should work and will
also allow drivers to implement other pm callbacks than just suspend and resume.
--
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