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

On Tue, Jun 21, 2011 at 06:34:48AM -0700, Dmitry Torokhov wrote:

On Jun 21, 2011 3:46 PM, "Mark Brown" [off-list ref]

quoted

On Mon, Jun 20, 2011 at 01:45:12AM -0700, Dmitry Torokhov wrote:

quoted

Like Grant says this really isn't terribly sustainable - it's not just
the device registration you need to sort out, it's also the registration
of the drivers so things actually get bound and handing of any delays in
the process of getting things to appear.

If devices are registered only when they are fully usable then driver
registration does not matter.

Right, but this is something that it's not reasonable to implement in
board code - if nothing else implementing it in board code would mean
we'd got lots of repitition of common patterns.

quoted

It's not trivial to get this
right in the general case and it's not reasonable to expect individual
boards to open code things,

Board code has the ultimate knowledge about connected devices though.

Absolutely, board code or data should provide the information about how
things are wired up.  It's the acting on it bit that's the issue.

quoted

quoted

How about we do not register device until all resources are ready? This
is pretty simple concept - do not create an object until it is usable.

Then

quoted

quoted

nobody needs to bother with -EAGAIN or -ENOTYET or any other similar
garbage.

quoted

As soon as you let the user build drivers modular this goes out of the
window.

Why is that? If device is registered only when it is ready to be bound to
then it does not matter when the driver is registered and whether it is
built into the kernel or as a module.

Originally you were talking about registration ordering - solving the
module load issues also requires dynamic delays and rollbacks when
things get unregisterd, something that goes well beyond simple ordering
of the registrations. 

quoted

All the faff with initcall ordering that we do at the minute is
essentially trying to implement this mechanism.

No, what you are doing is creating devices before they are usable and
postponing the driver registration in hopes that devices will be ready by
that time.

Right, which is controlling the ordering of registration so that things
generally work out OK as described above.

Nobody's arguing that we don't want to solve this in a better way, we're
just saying that actually doing that requires improvements in both core
infrastructure and the data we've got available to the infrastructure so
there's no reasonable solutions that we can deploy which are better than
the initcall ordering stuff we're doing at the minute.