Re: [PATCH v4 3/3] Input: gpio_keys.c: Enable use with non-local GPIO chips.

On Tue, Jun 21, 2011 at 12:55 AM, David Jander [off-list ref] wrote:

On Mon, 20 Jun 2011 12:20:30 -0600
Grant Likely [off-list ref] wrote:

quoted

On Mon, Jun 20, 2011 at 11:03 AM, H Hartley Sweeten
[off-list ref] wrote:

quoted

On Saturday, June 18, 2011 6:18 AM, Grant Likely wrote:

quoted

On Sat, Jun 18, 2011 at 4:17 AM, Dmitry Torokhov wrote:

quoted

On Thu, Jun 16, 2011 at 01:27:32PM -0600, Grant Likely wrote:

quoted

On Tue, Jun 14, 2011 at 11:08:11AM +0200, David Jander wrote:

quoted

Use a threaded interrupt handler in order to permit the handler to use
a GPIO driver that causes things like I2C transactions being done
inside the handler context.
Also, gpio_keys_init needs to be declared as a late_initcall, to make
sure all needed GPIO drivers have been loaded if the drivers are built
into the kernel.

...which is a horrid hack, but until device dependencies can be
described, it isn't one that can be solved easily.

I really do not want to apply this... Currently the order of
initialization does not matter since nothing actually happens until
corresponding device appears on the bus. Does the OF code creates
devices before all resources are ready?

It's not an OF problem.  The problem is that all the platform_devices
typically get registered all at once at machine_init time (on arm),
and if the gpio expander isn't a platform_device, (like an i2c gpio
expander which would end up being a child of a platform_device), then
it won't be ready.  The real problem is that we have no mechanism for
holding off or deferring a driver probe if it depends on an
asynchronous resource.

To avoid the registration order issue, isn't the proper fix to use a
"setup" method in the gpio expander driver?  The gpio-pca953x.c driver has
this and I use it to hook the gpio_keys driver to those gpios.  The
registration order ends up being:

i2c-gpio as a platform_device in the machine init code
pca9539 as part of the i2c_board_info for the i2c-gpio device
gpio-keys as a platform_device via the .setup callback of pca9539

Blech!  That approach fell out of the ugly tree and hit every branch
on the way down!  Points for creativity though.  :-)  Essentially that
ends up being a driver-specific notifier implementation.

Yes, that works, but to me it just highlights a deficiency in the
Linux device model.

Especially, how would I specify this setup handler in a device-tree?

You wouldn't.  Notifiers (and the above poor-man's notifier) only
works for specific cases in traditional board support code.  There
isn't a good pattern for using it with DT data.  You'd have to make
of_platform_populate() parse every node for any properties containing
a phandle it recognizes (assuming you can know whether the resource is
actually needed for the device to operate) and keep track of which
devices should not be registered because other devices haven't been
bound to drivers yet.  Then you need to have a notifier that looks for
those resources showing up, and registers the deferred device.

The DT
compiler still has no support for something like embedded DT-script ;-)

We're not going there.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html