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