Thread (6 messages) flat view 6 messages, 4 authors, 2015-02-10

[PATCH] ARM: shmobile: r8a73a4: Move pfc node to work around probe ordering bug

From: tony@atomide.com (Tony Lindgren)
Date: 2015-02-09 18:34:33
Also in: linux-devicetree, linux-sh, lkml

* Geert Uytterhoeven [off-list ref] [150209 09:17]:
On Mon, Feb 9, 2015 at 5:24 PM, Tony Lindgren [off-list ref] wrote:
quoted
* Geert Uytterhoeven [off-list ref] [150206 12:26]:
quoted
Notes:
  - It seems several people tried to solve this in the core OF probing
    code before, but the final solution never went in?
  - This can be reproduced on other SoCs (e.g. sh73a0 and r8a7740) by
    moving their pfc nodes before their interrupt controller nodes.
  - This patch is against my working tree, so it doesn't apply to
    Simon's repository, but you get the idea....
No issues with the patch, but here are few comments on the core
reasons (without looking at the code in this case) that might help
fix similar issues.

In all the cases I've seen these errors are caused by non-standard
custom initcall levels for drivers like i2c bus. The real solution
is to initialize drivers later with standard module_init, and stop
the race to the bottom with custom initcall levels.

If there is legacy board specific platofrm init code that needs
i2c gpios early, that code can probably be moved to initialize
later on.
In this case no i2c is involved. The drivers for both pinctrl
(renesas,pfc-r8a73a4) and irqchip (renesas,irqc) are registered
at the same level:
  - postcore_initcall(sh_pfc_init);
  - postcore_initcall(irqc_init);
Hence the system uses the "natural" order from within the DTS,
and decided to instantiate the pfc before the irqchip.
OK
 
quoted
Also, there should not be any need for custom driver initcall
levels from Linux generic framework point of view as for example
irqchip implementing drivers work just fine as a loadable module.
As long as no other device that's instantiated earlier references that
irqchip?
Right :) And deferred probe won't still remove the warning in
that case. From what I remember, that's a valid warning from irq
framework point of view.

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help