> Ok, fine. I just commited some code that should hopefully work on all
> types of cards. A patch relative to 1.12 is appended, it would be
> great if you could verify that this does The Right Thing.
> 
> To kernel wizards (Bill and others :-) what's the right thing to do if
> the size check fails? This most likely means that we have a 64 word
> EEPROM, but is it ok to assume so, or should we panic, or panic iff
> DIAGNOSTIC/DEBUG?

a couple cautions:

i'm not a hardware geek, so this is just based on what minimal
hardware knowledge, but my impression was that "tri-state" means that
the output is floating, and i'd be concerned that this might
occasionally be read as a zero on a bad day due to electrical noise.
i'd look harder at what other drivers do in this case.  (is there
anything useful in, for instance, the FreeBSD PAO distribution?)

panic'ing here seems wrong.

In particular, panic'ing in the attach routine because hardware is not
all there is pretty unfriendly; it's better for the driver to complain
vigorously via printf and then not actually attach the device.. if
this is due to a driver bug, it's unfriendly to force someone to open
the box and unplug the card before they can reboot to rebuild a new
kernel.  (and, for instance, on my laptop, the fxp is not removable..)

probably the way to go here is to:
 a) gripe if the eeprom autosize doesn't give you anything sane-looking.
 b) gripe if you read out a bogus MAC address (e.g., one with either
or both of the broadcast/multicast bit or the "not globally unique"
bit set).

						- Bill