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

[Grant Likely]

On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pavel at denx.de> wrote:
> Hi!
>
>> >>> 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.
>> >
>> > AFAIR, defered probing is known to be a "hack" by its authors. We
>> > should still try to get initcall levels right...
>>
>> I don't /think/ it was the concept of deferred probe that was considered
>> hacky, but perhaps just the first proof-of-concept implementation, and
>> any hackiness was presumably solved before the feature was merged.
>
> Well...
>
> http://lwn.net/Articles/485194/
>
> From:           Grant Likely <grant.likely at secretlab.ca>
> To:                   linux-kernel at vger.kernel.org
> Subject:                [PATCH] drivercore: Add driver probe deferral
> mechanism
> Date:           Mon, 5 Mar 2012 08:47:41 -0700
> Message-ID:
> <1330962461-9061-1-git-send-email-grant.likely at secretlab.ca>
> ...
>
> I know that not everybody is happy with this approach, but I've yet to
> see a better alternative.  However, it is *really easy* to find all
> the
> users of deferred probe since any user must return -EPROBE_DEFER
> explicitly.
> If/when a better approach is found, all the users will be easy to find
> and modify.
>
> ...
>
> It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
> still preferred.

That wasn't the point I was trying to make in the above thread. My
point was that -EPROBE_DEFER is the best option that we currently have
to get rid of the initcall ordering madness. I'm all ears if someone
comes up with a simple and inexpensive alternative that can take into
account dependencies between devices.

g.