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

[Santosh Shilimkar]

On Wednesday 28 November 2012 12:16 PM, Igor Grinberg wrote:
> 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 <grinberg at compulab.co.il>
>>>
>>> Signed-off-by: Jon Hunter <jon-hunter at ti.com>
>>> ---
>>>    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.
>
Sounds good to me.

Regards
Santosh