[PATCH v8] reset: Add driver for gpio-controlled reset pins

[swarren@wwwdotorg.org (Stephen Warren)]

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.

However, if someone closely associated with the implementation of
deferred probe (e.g. Grant, or a device core maintainer) is willing to
step up and say I'm wrong, I'll drop my objection.