Peter Seebach wrote:
> 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
>   
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.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191