On Thu, May 18, 2017 at 4:18 PM, Viresh Kumar <viresh.ku...@linaro.org> wrote:
> On 18-05-17, 15:28, Arnd Bergmann wrote:
>> Enabling the arche platform for compile testing showed a harmless
>> warning with CONFIG_PM=n:
>>
>> drivers/staging/greybus/arche-platform.c:632:12: error:
>> 'arche_platform_resume' defined but not used [-Werror=unused-function]
>> drivers/staging/greybus/arche-platform.c:618:12: error:
>> 'arche_platform_suspend' defined but not used [-Werror=unused-function]
>>
>> This marks the functions as __maybe_unused to shut up the warnings.
>>
>> Fixes: 2eccd4aa19fc ("staging: greybus: enable compile testing of arche
>> driver")
>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>> ---
>> drivers/staging/greybus/arche-platform.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/greybus/arche-platform.c
>> b/drivers/staging/greybus/arche-platform.c
>> index 5bce5e039596..eced2d26467b 100644
>> --- a/drivers/staging/greybus/arche-platform.c
>> +++ b/drivers/staging/greybus/arche-platform.c
>> @@ -615,7 +615,7 @@ static int arche_platform_remove(struct platform_device
>> *pdev)
>> return 0;
>> }
>>
>> -static int arche_platform_suspend(struct device *dev)
>> +static __maybe_unused int arche_platform_suspend(struct device *dev)
>> {
>> /*
>> * If timing profile premits, we may shutdown bridge
>> @@ -629,7 +629,7 @@ static int arche_platform_suspend(struct device *dev)
>> return 0;
>> }
>>
>> -static int arche_platform_resume(struct device *dev)
>> +static __maybe_unused int arche_platform_resume(struct device *dev)
>> {
>> /*
>> * Atleast for ES2 we have to meet the delay requirement between
>
> Is __maybe_unused the more preferred way than putting these routines
> under CONFIG_PM_SLEEP ifdef ?
I find that a lot of users get the #ifdef wrong, either using the wrong
macro (CONFIG_PM vs CONFIG_PM_SLEEP) or not using the right
set of functions (e.g. calling a function only from the suspend handler).
The __maybe_unused annotation avoids both problems and also gives
better build time coverage, so that's what I tend to use.
Arnd
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
