On Wed, Jul 17, 2013 at 9:57 AM, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 07/16/2013 09:02 PM, Shawn Guo wrote: >> On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote: >>> Registering the driver earlier won't cause any bugs. However, it's not >>> the correct approach. >>> >>> Deferred probe /is/ the approach for assuring correct dependencies >>> between drivers. It works and should be used. There are not enough >>> initcall levels to play games using initcalls and solve all the issues, >>> and the ordering requirements vary board-to-board. Deferred probe at >>> runtime handles this without having to manually place all the drivers >>> into specific initcall levels, and dynamically adjusts to board >>> differences, since it all happens automatically at run-time. >> >> I do not quite follow the argument here. I agree with you that >> deferred probe is the approach to solve dependencies. But it does not >> necessarily mean that initcall can not be used to help it save some >> nasty or nested deferring. Deferred probe and initcalls are not two >> mutually exclusive mechanisms but two which can help each other. > > My understanding is that deferred probe was implemented specifically to > avoid having to, or allowing, the use of initcall levels to determine > probe order.
Correct. Futzing around with initcalls may optimize particular use cases, but it isn't complete. I've been pushing for all drivers to use module_initcall() unless there is a very strong reason to do otherwise. Premature optimization (without measuring time consumed) is not a strong justification. g. _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
