In message <43F9D5FA.1050906@tadpole.com>, "Garrett D'Amore" writes:
>I greatly like this idea.  In my embedded system, I might have some
>otherwise generic code for e.g. a PCI or PCMCIA controller which depends
>on GPIOs or EEPROMs on another bus.   Right now config_defer or
>config_interrupts can be made to workaround this limitation, but that is
>a hack -- especially if the thing being deferred is a *bus*.

>I'd far rather have a natural way to express a dependency other than
>parent/child in the attachment tree.

Hmm.

Two questions, from a fairly newbie kernel hacker:
1.  Is 'config' machine-dependant at all?  Do I need to build a cross tool
"config" to test patches?
2.  Is my basic proposal reasonably clean?

And one more:
Is there already a way to specify a hook to run "after attach of X"?  In
my scenario, I need two things:

1.  A way to indicate that emac0 must probe only after seeprom0.
2.  A way to, between the configuration of seeprom0 and the attach of emac0,
Do Some Magic using the seeprom0 device.

The obvious thing to do is provide some kind of a registration:
	config_postattach("seeprom0", machdep_seeprom0_postattach, msp_args);
where the latter is something like
	void (*postattach)(struct device *, void *);
and the third argument to postattach would get called after the device named
is attached.

There's a whole lot of code in various places that I think could be cleaned
up quite a bit by this.

-s