On some systems, it may be necessary to probe one device after another.
The PCI bus-ordering hack isn't sufficient, because some devices may be
configurable only after a device on a whole different bus.  The config_defer
code is able to do this, but would result in a generic driver having special
magic, and a callback function, used only on some platforms some of the time.

My initial idea of how to fix this is a hook in autoconfigure.  Config syntax
could be extended to allow
	device at [...] defer otherdevice

If "defer otherdevice" is present, then the device is not attached on a
successful match; rather, it is appended to a list of devices which are
currently deferred.  After a device is attached, the list of deferred
devices is scanned for devices that were waiting for it, and they are
attached, probably with the device they deferred on passed in in some way.

The specific example in question is the TAMS 3011, which has an emac0 (on
opb0, which is the bus PCI is attached to, and MUST come first), and an EEPROM
which is not part of the emac0, which probes later, and which is needed to
correctly attach the emac0.

There are at least five other systems using the emac controller (all PPC405GP
series chips, I believe), and none of them have this requirement.

My theory is that this requirement clearly, conceptually, fits better with
the config file than with specific code.  Questions pertaining to the
requirments or setup of a single board or system ought not to be special cases
in code; they ought to be indicated somehow in the config file.

-s