Subject: Re: CVS commit: src/sys/dev/pci
To: Gavan Fantom <gavan@NetBSD.org>
From: Jason Thorpe <thorpej@shagadelic.org>
List: tech-kern
Date: 02/16/2006 06:45:53
[ Moving discussion to tech-kern ]
On Feb 16, 2006, at 4:06 AM, Gavan Fantom wrote:
> Jason Thorpe wrote:
>> Off-hand, I'd say probably the best way to do this would be:
>> mac-address Ethernet address
>> i82543-cfg1 CFG1 value
>> i82543-cfg2 CFG2 value
>> i82543-swdpin SWDPIN value
>
> That's the way I'm leaning, too.
Oh good :-) s/mac-address/mac-addr/
>> I'm not particularly keen on constructing an entire EEPROM blob
>> for an Ethernet chip in platform-specific code.
>> Besides, individual properties gives you the flexibility to use
>> e.g. an implementation-specific SWDPIN value even if the device
>> has an otherwise valid EEPROM.
>
> Not really, unless there's a way to tie properties to a specific
> *instance* of the driver.
Yes, properties are tied to specific instances. See e.g.
device_register() in arch/evbmips/alchemy/autoconf.c:
if (prop_set(dev_propdb, dev, "mac-addr",
ethaddr, sizeof(ethaddr), 0,
0) != 0) {
printf("WARNING: unable to set mac-
addr "
"property for %s\n", dev-
>dv_xname);
}
> The properties are a fallback in case the checksum fails. This
> allows for the scenario where you have one (EEPROM-less) wm chip
> integrated into the motherboard, and a PCI add-on card also with a
> wm chip on it.
I would say:
if (property exists for this device)
fetch value from property;
else if (eeprom is valid)
fetch value from eeprom;
else
printf("This board sucks, yo!\n");
-- thorpej