Re: [PATCH 3/4] of/gpio: Implement GPIOLIB notifier hooks

[Grant Likely <grant.likely@secretlab.ca>]

On Fri, Mar 5, 2010 at 1:35 PM, Andrew Morton <akpm@linux-foundation.org> w=
rote:
> On Fri, 5 Mar 2010 13:28:32 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> On Fri, Mar 5, 2010 at 1:00 PM, Andrew Morton <akpm@linux-foundation.org=
> wrote:
>> > On Tue, 9 Feb 2010 22:16:20 +0300
>> > Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>> >
>> >> On Tue, Feb 09, 2010 at 10:13:11AM -0700, Grant Likely wrote:
>> >> [...]
>> >> > > +static int __init of_gpio_notifier_init(void)
>> >> > > +{
>> >> > > + __ __ __ return blocking_notifier_chain_register(&gpio_notifier=
, &of_gpio_nb);
>> >> > > +}
>> >> > > +arch_initcall(of_gpio_notifier_init);
>> >> >
>> >> > Another concern; __if any gpio chips get registered before this
>> >> > arch_initcall (not sure if it is possible or not), then those chips
>> >> > won't get registered with the of gpio infrastructure.
>> >>
>> >> Technically, it is possible, but registering usual GPIO controllers
>> >> in arch_initcall feels not quite right approach in the first place
>> >> (and, btw, it won't work most of the time, because even early drivers
>> >> do not register itself earlier than subsys_initcall).
>> >>
>> >> And arch gpio controllers (like QE GPIO) are usually device-less,
>> >> and they use of_mm_gpiochip_add(), so we fully control them.
>> >>
>> >> Plus I don't see any reason why we couldn't move
>> >> of_gpio_notifier_init() into, say, postcore_initcall, if we ever
>> >> need it.
>> >>
>> >
>> > I'll assume that you're OK with that response.
>>
>> No, not really,
>
> You left me dangling :(

Sorry, got caught up with other things.

>> I'm not really very comfortable with the whole
>> approach being taken. =A0And, while I acked the first patch in the
>> series, that patch isn't needed by anything except patches 2, 3 & 4.
>>
>> Also, the OF stuff is a moving target at the moment with all the
>> rework is being undertaken. =A0I'd rather let this series sit out for
>> another merge cycle so that the underlying OF stuff can settle down.
>
> OK, please take it up on-list?

Okay.  I'm making this reply on list.

Anton, as I've stated before, I'm not thrilled with the approach.
Combine that with the changes being made to drivers/of right now and
the addition device tree to ARM and other architectures, my preference
is to let this patch series lie fallow for one more merge cycle so
that things can settle out in the OF infrastructure code.

g.