From: Ning Jiang <[email protected]>
Make suspend/resume callbacks in device_driver deprecated and scheduled
for removal since they are not used in PM core anymore.
Legacy drivers who still use them need to move suspend/resume callbacks
to dev_pm_ops.
Signed-off-by: Ning Jiang <[email protected]>
---
include/linux/device.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index e04f577..884d9a6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -226,8 +226,8 @@ struct device_driver {
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
void (*shutdown) (struct device *dev);
- int (*suspend) (struct device *dev, pm_message_t state);
- int (*resume) (struct device *dev);
+ int (*suspend) (struct device *dev, pm_message_t state) __deprecated;
+ int (*resume) (struct device *dev) __deprecated;
const struct attribute_group **groups;
const struct dev_pm_ops *pm;
--
1.7.1
On Thu, Jun 14, 2012 at 02:42:17PM +0800, [email protected] wrote:
> From: Ning Jiang <[email protected]>
>
> Make suspend/resume callbacks in device_driver deprecated and scheduled
> for removal since they are not used in PM core anymore.
>
> Legacy drivers who still use them need to move suspend/resume callbacks
> to dev_pm_ops.
How many complier warnings does this patch produce?
Please fix them before submitting this patch. The way kernel
development is is that you fix the problems up with the api, you don't
just mark them and hope someone else will do it for you.
Sorry, I can't take this.
greg k-h
On Thursday, June 14, 2012, Greg KH wrote:
> On Thu, Jun 14, 2012 at 02:42:17PM +0800, [email protected] wrote:
> > From: Ning Jiang <[email protected]>
> >
> > Make suspend/resume callbacks in device_driver deprecated and scheduled
> > for removal since they are not used in PM core anymore.
> >
> > Legacy drivers who still use them need to move suspend/resume callbacks
> > to dev_pm_ops.
>
> How many complier warnings does this patch produce?
>
> Please fix them before submitting this patch. The way kernel
> development is is that you fix the problems up with the api, you don't
> just mark them and hope someone else will do it for you.
>
> Sorry, I can't take this.
Right.
Please disregard my previous message, I sent it before reading this one.
Thanks,
Rafael
On Thu, Jun 14, 2012 at 09:15:47PM +0200, Rafael J. Wysocki wrote:
> On Thursday, June 14, 2012, Greg KH wrote:
> > On Thu, Jun 14, 2012 at 02:42:17PM +0800, [email protected] wrote:
> > > From: Ning Jiang <[email protected]>
> > >
> > > Make suspend/resume callbacks in device_driver deprecated and scheduled
> > > for removal since they are not used in PM core anymore.
> > >
> > > Legacy drivers who still use them need to move suspend/resume callbacks
> > > to dev_pm_ops.
> >
> > How many complier warnings does this patch produce?
> >
> > Please fix them before submitting this patch. The way kernel
> > development is is that you fix the problems up with the api, you don't
> > just mark them and hope someone else will do it for you.
> >
> > Sorry, I can't take this.
>
> Right.
To provide a bit more "constructive" review, the proper thing is to fix
up the whole kernel to never set these fields, and then just delete
them. Ning, feel free to start working on that task, it's a good one to
accomplish and should be pretty well defined.
thanks,
greg k-h
2012/6/15 Greg KH <[email protected]>:
> On Thu, Jun 14, 2012 at 09:15:47PM +0200, Rafael J. Wysocki wrote:
>> On Thursday, June 14, 2012, Greg KH wrote:
>> > On Thu, Jun 14, 2012 at 02:42:17PM +0800, [email protected] wrote:
>> > > From: Ning Jiang <[email protected]>
>> > >
>> > > Make suspend/resume callbacks in device_driver deprecated and scheduled
>> > > for removal since they are not used in PM core anymore.
>> > >
>> > > Legacy drivers who still use them need to move suspend/resume callbacks
>> > > to dev_pm_ops.
>> >
>> > How many complier warnings does this patch produce?
>> >
>> > Please fix them before submitting this patch. ?The way kernel
>> > development is is that you fix the problems up with the api, you don't
>> > just mark them and hope someone else will do it for you.
>> >
>> > Sorry, I can't take this.
>>
>> Right.
>
> To provide a bit more "constructive" review, the proper thing is to fix
> up the whole kernel to never set these fields, and then just delete
> them. ?Ning, feel free to start working on that task, it's a good one to
> accomplish and should be pretty well defined.
All right. I'm working on it.