Messages in this thread |  | | Date | Sat, 1 Mar 2014 08:02:31 -0800 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH 2/3] PM: define new ASSIGN_*_PM_OPS macros based on assign_if |
| |
On Sat, Mar 01, 2014 at 12:06:33PM +0100, Pavel Machek wrote: > Hi! > > > > +#define ASSIGN_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ > > > + .suspend = assign_if_pm_sleep(suspend_fn), \ > > > + .resume = assign_if_pm_sleep(resume_fn), \ > > > + .freeze = assign_if_pm_sleep(suspend_fn), \ > > > + .thaw = assign_if_pm_sleep(resume_fn), \ > > > + .poweroff = assign_if_pm_sleep(suspend_fn), \ > > > + .restore = assign_if_pm_sleep(resume_fn), > > > > Ugh, what a mess, really? Is it that hard to get the #ifdef right in > > the code? Why not just always define the functions and then also always > > have them in the structures, and if the feature isn't enabled, just > > don't call/use them? > > The functions may not compile with CONFIG_PM disabled. (And #ifdefs in > the code are considered ugly). > > > Yes, it would cause a _very_ tiny increase in code size if the option is > > disabled, but really, does anyone ever disable those options becides on > > the dreaded 'make randconfig' checkers? > > We don't want CONFIG_PM complexity on some embedded systems...
Really, what embedded systems do not want this?
> and it is useful tostart with simple (!PM) system when introducing new > board.
I'm not saying to disable the option, I'm saying to stop worrying about saving a few hundred bytes in individual drivers with this crazy #ifdef and macro mess that no one understands and always gets wrong.
greg k-h
|  |