Re: [PATCH V2 4/7] clocksource: bcm2835: Migrate to new 'set-state' interface

[Stephen Warren <swarren@wwwdotorg.org>]

On 06/15/2015 09:17 PM, Viresh Kumar wrote:
> On 15-06-15, 20:57, Stephen Warren wrote:
>> On 06/12/2015 02:00 AM, Viresh Kumar wrote:
>>> Migrate bcm2835 driver to the new 'set-state' interface provided by
>>> the clockevents core, the earlier 'set-mode' interface is marked
>>> obsolete now.
>>>
>>> This also enables us to implement callbacks for new states of clockevent
>>> devices, for example: ONESHOT_STOPPED.
>>>
>>> We weren't doing anything in the ->set_mode() callback. So, this patch
>>> doesn't provide any set-state callbacks.
>>
>> This generates a panic at boot (on top of 4.1.0-rc8+, which certainly at
>> least booted fine):
>>
>>> [    0.008586] clocksource timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
>>> [    0.018080] ------------[ cut here ]------------
>>> [    0.022843] kernel BUG at kernel/time/clockevents.c:480!
>>> [    0.028299] Internal error: Oops - BUG: 0 [#1] ARM
>>> [    0.033237] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.0-rc8+ #46
>>> [    0.039567] Hardware name: BCM2835
>>> [    0.043092] task: c06fb648 ti: c06f6000 task.ti: c06f6000
>>> [    0.048668] PC is at clockevents_register_device+0x15c/0x174
> 
> This failed the sanity checks of clockevents core. Did you apply the
> first patch as well? Yes, its very much required.
> 
> Also, there were dependencies on the latest tip, prepared for 4.2
> merge window and would have been better if you tested on top of that.
> 
> But those dependencies are for some helpers which aren't used in this
> patch. So, it might work over rc8 + the first patch from this series..
> 
> In case it doesn't, please test it over tip/master once.

I see. You didn't Cc me on patch 1, and didn't mention the dependency in
this patch. That usually means they're all independent, e.g. the same
change in n different drivers.

Anyway, I tracked down the whole series and applied it on top of
next-20150615 and everything seems OK (kernel boots, and UART, USB kbd &
SD card work), so this patch,
Tested-by: Stephen Warren <swarren@wwwdotorg.org>