Messages in this thread | | | Date | Tue, 4 Feb 2014 00:16:03 +0100 | From | Willy Tarreau <> | Subject | Re: [PATCH 0/4] clk: mvebu: fix clk init order |
| |
Hi Sebastian,
On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote: > On 01/30/14 11:24, Gregory CLEMENT wrote: > >On 25/01/2014 19:19, Sebastian Hesselbarth wrote: > >>This patch set fixes clk init order that went upside-down with > >>v3.14. I haven't really investigated what caused this, but I assume > >>it is related with DT node reordering by addresses. > > > >Can you explain what kind of issue do you observe? > > Sure. When probing CLK_OF_DECLAREed clock drivers, clock-gating driver > gets registered before core-clocks. It therefore cannot resolve it's > parent clock name for tclk and all clock gates will have no parent > clock. > > Usually, you'll see in some drivers (e.g. v643xx_eth) div_by_zero errors > poping up, when they calculate a frequency division factors based on > clock gate frequency, which should have been tclk but is 0 now.
Well, to be honnest, I have no idea whether your patch is the right way to fix the problem or not, but what I can say is that it fixes such oopses that appear in 3.14-rc1 when booting on mirabox :
Division by zero in kernel. CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.13.0-bck-mbx #6 Workqueue: kmmcd mmc_rescan [<c0010865>] (unwind_backtrace+0x1/0x98) from [<c000e947>] (show_stack+0xb/0xc) [<c000e947>] (show_stack+0xb/0xc) from [<c0135913>] (Ldiv0+0x9/0x12) [<c0135913>] (Ldiv0+0x9/0x12) from [<c01f708b>] (mvsd_set_ios+0xcb/0x160) [<c01f708b>] (mvsd_set_ios+0xcb/0x160) from [<c01ec1fd>] (__mmc_set_clock+0x2d/0 x40) [<c01ec1fd>] (__mmc_set_clock+0x2d/0x40) from [<c01f1a59>] (mmc_sdio_init_card+0 x391/0x808) [<c01f1a59>] (mmc_sdio_init_card+0x391/0x808) from [<c01f2163>] (mmc_attach_sdio +0x5b/0x218) [<c01f2163>] (mmc_attach_sdio+0x5b/0x218) from [<c01ed0d9>] (mmc_rescan+0x159/0x 1b4) [<c01ed0d9>] (mmc_rescan+0x159/0x1b4) from [<c0024579>] (process_one_work+0xa9/0 x21c) [<c0024579>] (process_one_work+0xa9/0x21c) from [<c002494d>] (worker_thread+0xb5 /0x248) [<c002494d>] (worker_thread+0xb5/0x248) from [<c0027f1b>] (kthread+0x7b/0x94) +0xa7/0x138) [<c04228b3>] (kernel_init_freeable+0xa7/0x138) from [<c027e6cf>] (kernel_init+0x 7/0xb8) [<c027e6cf>] (kernel_init+0x7/0xb8) from [<c000cb9d>] (ret_from_fork+0x11/0x34) mvsdio d00d4000.mvsdio: lacking card detect (fall back to polling)
By the way, seeing how often a trick related to the DT is nedeed to solve an oops or a panic, I'm really scared that this whole DT mess is just becoming the exact copy of the ACPI mess (but 15 years later) and we'll experience the same horrible things :-( Sometimes I'm wondering whether there are not too many structural things put in there...
Regards, Willy
| |