In message <20060220144639.GF8924@drowsy.duskware.de>, Martin Husemann writes:
>On Mon, Feb 20, 2006 at 08:29:19AM -0600, Peter Seebach wrote:
>> 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.

>Could you please explain a little more in detail how the EEPROM is
>needed/used/accesses for the emac0 attach function?

Yes.

The emac0 has no hardware storage of MAC address.  The MAC address is
boot-time configuration data, and redboot stores it in the EEPROM.  There's
a bevy of stuff like "eth0_esa" and "eth1_esa" stored in EEPROM that need to
be extracted to configure devices.

>Isn't that a local hack too, that other ports using the emac driver do not
>need?

Yes.

Which is why the code for it should NOT be in the emac driver, or in the opb
bus driver, or the pci bus driver, or anywhere else but in my machdep code and
my config file.

>Can't you solve the problem by giving obp0 an order hook just like
>pci_bus_devorder() for PCI?

I could, but then I'm modifying a driver used by many systems for just one
system.  It's neither generic nor specific; it's just ugly.  The generic
solution doesn't depend on assumptions like "this is on the same bus as that",
or "deferring to end of parent is always enough"; it provides a GENERAL
mechanism for handling ordering requirements.  Furthermore, it puts that
mechanism where it belongs, IMHO.

>I ask because I personally do not like ordering requirements inside config
>files. I see your problem, and the question is: what other options are
>available to solve it.

I guess I'm not seeing why they shouldn't be there.  Isn't something like
this EXACTLY what configuration files are for -- describing a specific
machine?  I can't think of anything but a configuration file that makes sense
for encoding such information.  It is information about my configuration, no?

-s