Subject: [PATCH 3/3] ARM: AM335x: Fix warning in timer.c

From: [email-masked] (Igor Grinberg)
Date: Wed, 28 Nov 2012 08:46:20 +0200

On 11/28/12 08:28, Santosh Shilimkar wrote:
> On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
>> When compiling the kernel with configuration options ...
>>
>>   # CONFIG_ARCH_OMAP2 is not set
>>   # CONFIG_ARCH_OMAP3 is not set
>>   # CONFIG_ARCH_OMAP4 is not set
>>   # CONFIG_SOC_OMAP5 is not set
>>   CONFIG_SOC_AM33XX=y
>>
>>   ... the following build warning is seen.
>>
>>    CC      arch/arm/mach-omap2/timer.o
>>    arch/arm/mach-omap2/timer.c:395:19: warning: ?omap2_sync32k_clocksource_init?
>>        defined but not used [-Wunused-function]
>>
>> This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
>> CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
>> longer referenced by the timer initialisation function for the AM335x
>> device as it has no 32k-sync timer.
>>
>> Fix this by only including the omap2_sync32k_clocksource_init() function
>> if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled.
>>
>> Cc: Igor Grinberg <[email-masked]>
>>
>> Signed-off-by: Jon Hunter <[email-masked]>
>> ---
>>   arch/arm/mach-omap2/timer.c |    3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index eb96712..085c7e7 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>>       return 0;
>>   }
>>
>> +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
>> +    defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
> #ifndef CONFIG_SOC_AM33XX ?
> 
> #ifdef things are really ugly and needs constant patching and
> hence something like CONFIG_HAS_32K kind of feature flags are
> better. But that will undo certain part of f80b3b
> (ARM: OMAP2+: timer: remove  CONFIG_OMAP_32K_TIMER).

Agreed on ugliness of ifdefs.
What about adding __maybe_unused to the function signature?
That will cover any future SoC also w/o the need to extend the ifdefs. 

-- 
Regards,
Igor.