Thread (6 messages) 6 messages, 5 authors, 2013-06-12

Re: [PATCH] backlight: add CONFIG_PM_SLEEP to suspend/resume functions

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2013-06-10 23:31:38
Also in: lkml

On Fri, 07 Jun 2013 12:02:31 +0200 Arnd Bergmann [off-list ref] wrote:
On Friday 07 June 2013 10:39:20 Jingoo Han wrote:
quoted
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.

drivers/video/backlight/backlight.c:211:12: warning: 'backlight_suspend' defined but not used [-Wunused-function]
drivers/video/backlight/backlight.c:225:12: warning: 'backlight_resume' defined but not used [-Wunused-function]

Signed-off-by: Jingoo Han <redacted>
---
 drivers/video/backlight/backlight.c |    2 ++
 1 file changed, 2 insertions(+)
Your patch looks ok, but I find it extremely annoying to have new warnings
like this one come up every single day in linux-next. It really shouldn't
be this hard to use a macro called SIMPLE_DEV_PM_OPS() correctly.

Below is an implementation of SIMPLE_DEV_PM_OPS and UNIVERSAL_DEV_PM_OPS
that avoids this issue by introducing an unused reference to the suspend
and resume functions. gcc is smart enough to leave out that unused code
by itself, and it would actually improve compile-time coverage to have
something like this, besides being harder to misuse.

This would be a better approach if we didn't already have all the "#ifdef
CONFIG_PM_SLEEP" in place that hide the functions now. Unfortunately we
already have over 300 uses of SIMPLE_DEV_PM_OPS/UNIVERSAL_DEV_PM_OPS
in the kernel today, so removing all the #ifdef atomically without
creating more build errors is rather hard to do.

Maybe someone has an idea how to extend my approach so it works with
and without the #ifdef, to let us transition to a situation that no
longer needs them.
You could create new macros, and add a checkpatch rule to remind people
to not use the old ones.  Then people can migrate over from the old
macros at a leisurely pace.

The problem will be in thinking up decent names for the new macros.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help