linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] clk: mvebu: fix clk init order
Date: Tue, 04 Feb 2014 00:36:54 +0100	[thread overview]
Message-ID: <52F02816.1050708@gmail.com> (raw)
In-Reply-To: <20140203231603.GA11613@1wt.eu>

On 02/04/2014 12:16 AM, Willy Tarreau wrote:
> 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.

Willy,

you have hit exactly the reason for this patch.

[...]
> 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...

To be precise, it is not a DT-related trick at all. You would have the
same issues, if you'd register those "low-level" (i.e. early) drivers
without DT. It is more about missing init ordering, here.

There could be different ways to work this out, even elevating clock
devices to "normal" probed devices could be possible. I am sure, in the
long run, it will work out, but now this is a fix for v3.14-rc1.

@Jason, Andrew, Gregory, Thomas:
Now that v3.14 is out, anything against taking this in as fixes for rc1?

Sebastian

  reply	other threads:[~2014-02-03 23:36 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-25 18:19 [PATCH 0/4] clk: mvebu: fix clk init order Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 1/4] clk: mvebu: armada-370: maintain clock " Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 2/4] clk: mvebu: armada-xp: " Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 3/4] clk: mvebu: dove: " Sebastian Hesselbarth
2014-01-25 18:19 ` [PATCH 4/4] clk: mvebu: kirkwood: " Sebastian Hesselbarth
2014-01-25 21:32 ` [PATCH 0/4] clk: mvebu: fix clk " Emilio López
2014-01-25 21:44   ` Sebastian Hesselbarth
2014-01-25 22:11     ` Emilio López
2014-01-26  0:25       ` Ezequiel Garcia
2014-01-27 14:39 ` Thomas Petazzoni
2014-01-27 18:21   ` Sebastian Hesselbarth
2014-01-27 18:28     ` Jason Cooper
2014-01-30 10:24 ` Gregory CLEMENT
2014-01-30 10:31   ` Sebastian Hesselbarth
2014-02-03 23:16     ` Willy Tarreau
2014-02-03 23:36       ` Sebastian Hesselbarth [this message]
2014-02-04 14:58         ` Gregory CLEMENT
2014-02-04 20:07           ` Thomas Petazzoni
2014-02-05 14:08 ` Mike Turquette
2014-02-05 17:43   ` Jason Cooper
2014-02-05 18:34 ` Jason Cooper
2014-02-06 17:08   ` Ezequiel Garcia
2014-02-06 18:08     ` Jason Cooper
2014-02-17 14:13   ` Ezequiel Garcia
2014-02-17 14:25     ` Gregory CLEMENT
2014-02-17 14:42       ` Emilio López
2014-02-17 15:04         ` Gregory CLEMENT
2014-02-17 15:31           ` Emilio López
2014-02-17 15:21       ` Ezequiel Garcia
2014-02-17 15:28         ` Gregory CLEMENT
2014-02-17 15:44           ` Ezequiel Garcia
2014-02-17 15:59             ` Gregory CLEMENT
2014-02-17 18:19               ` Ezequiel Garcia
2014-02-18  9:47                 ` Gregory CLEMENT
2014-02-19 16:28                   ` Ezequiel Garcia
2014-02-19 20:24                   ` Emilio López

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F02816.1050708@gmail.com \
    --to=sebastian.hesselbarth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).