[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann [off-list ref] wrote:

On Friday 13 December 2013, Tomasz Figa wrote:

quoted

Commit

4178bac ARM: call of_clk_init from default time_init handler

added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.

This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.

Signed-off-by: Tomasz Figa <redacted>

I see of_clk_init(NULL) getting called on two other ARM platforms:

$ git grep -w of_clk_init arch/arm
arch/arm/kernel/time.c:         of_clk_init(NULL);
arch/arm/mach-keystone/pm_domain.c:     of_clk_init(NULL);
arch/arm/mach-mvebu/armada-370-xp.c:    of_clk_init(NULL);
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:        of_clk_init(NULL);

Are the other two platforms ok here?

I assume that mvebu is fine since Sebastian would have noticed breaking
that one and it has a custom init_time function, but keystone seems
broken in the same way as s3c64xx. Santosh, can you have a look?

Yeah, and Free Electrons also sent two systems to Kevin so he has them
in his boot test setup, and they're still happy there. Keystone lacks
such coverage though, so Santosh will need to check.


-Olof